Skip to content

Add test header files and defined behavior for APIs tested using FPGA-Test-Shield #11032

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
Oct 30, 2019

Conversation

mprse
Copy link
Contributor

@mprse mprse commented Jul 12, 2019

Description

This PR adds header files for FPGA tests with given/when/then description for the test cases and proposition for defined/undefined behavior for the tested APIs.

Please fill free to propose the modification in the defined behavior since this first version has been created mainly based on the description of the functions.

When we agree on the final version of the defined/undefined behavior for the tested APIs, then in the next step we can update the tests (increase coverage) and add a mapping between defined behavior and test cases.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[X] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@maciejbocianski @fkjagodzinski @c1728p9 @0xc0170 @jamesbeyond

Notes

BTW I'm OoO from 15/07 to 28/07.

@ciarmcom
Copy link
Member

@mprse, thank you for your changes.
@fkjagodzinski @maciejbocianski @jamesbeyond @c1728p9 @0xc0170 @ARMmbed/mbed-os-hal @ARMmbed/mbed-os-test @ARMmbed/mbed-os-maintainers please review.

Copy link
Contributor

@c1728p9 c1728p9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work so far @mprse!

I recommend linking all the defined behavior to tests or indicating "Not Verified" as done in other APIs, such as the RTC API. I also left some comments inline

@@ -35,9 +35,29 @@ typedef struct analogin_s analogin_t;

/**
* \defgroup hal_analogin Analogin hal functions
*
* # Defined behaviour
* * The function ::analogin_init initializes the analogin peripheral

This comment was marked as resolved.

* # Defined behaviour
* * The function ::analogin_init initializes the analogin peripheral
* * The function ::analogin_read reads the input voltage, represented as a float in the range [0.0, 1.0]
* * The function ::analogin_read_u16 reads the value from analogin pin, represented as an unsigned 16bit value

This comment was marked as resolved.

*
* # Defined behaviour
* * The function ::analogout_init initializes the analogin peripheral
* * The function ::analogout_write sets the output voltage, specified as a percentage (float) in range [0.0, 1.0]

This comment was marked as resolved.

@@ -70,9 +70,72 @@ extern "C" {

/**
* \defgroup hal_GeneralI2C I2C Configuration Functions
*

This comment was marked as resolved.

* * ::spi_irq_handler_asynch checks for transfer termination conditions, such as buffer overflows or transfer complete
* * ::spi_irq_handler_asynch returns event flags if a transfer termination condition was met, otherwise 0
* * ::spi_abort_asynch aborts an on-going async transfer
* * ::spi_active returns non-zero if the SPI port is active or zero if it is not
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be good to re-use the relevant existing SPI API defined and undefined behavior from the feature branch here:
https://github.com/ARMmbed/mbed-os/blob/feature-hal-spec-spi/hal/spi_api.h#L40-L125

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mprse This was resolved?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I created these requirements based on the SPI API defined and undefined behavior from the feature branch.

hal/serial_api.h Outdated
* * The callback given to ::serial_rx_asynch is invoked when the transfer completes
* * ::serial_tx_asynch specifies the logical OR of events to be registered
* * The ::serial_tx_asynch function may use the `DMAUsage` hint to select the appropriate async algorithm
* * ::serial_tx_asynch specifies the character in range 0-254 to be matched
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not 255?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like 255 is a reserved value:

#define SERIAL_RESERVED_CHAR_MATCH (255)

hal/serial_api.h Outdated
* * ::serial_tx_abort_asynch flushes the TX hardware buffer if TX FIFO is used
* * ::serial_rx_abort_asynch aborts the ongoing RX transaction
* * ::serial_rx_abort_asynch disables the enabled interupt for RX
* * ::serial_rx_abort_asynch flushes the TX hardware buffer if RX FIFO is used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these functions are used from interrupts. It may be good to define and test for maximum function call duration. That would ensure interrupt latency stays low.

hal/serial_api.h Outdated
@@ -108,9 +108,69 @@ extern "C" {

/**
* \defgroup hal_GeneralSerial Serial Configuration Functions
*
* # Defined behaviour
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be good to add interrupt latency requirements to defined and/or undefined behavior.

  • Correct operation guaranteed when interrupt latency is < 8 / baudrate_frequency without flow control
  • Correct operation guaranteed regardless of interrupt latency with flow control

For reference USB HAL spec has some timing requirements
https://github.com/ARMmbed/mbed-os/blob/master/usb/device/USBPhy/USBPhy.h#L33-L34:
https://github.com/ARMmbed/mbed-os/blob/master/usb/device/USBPhy/USBPhy.h#L58-L61

* Then the operation is successfull.
*
*/
void fpga_pwm_period_fill_test(PinName pin);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
void fpga_pwm_period_fill_test(PinName pin);
void fpga_pwm_init_free(PinName pin);

Wrong function name.

@@ -270,7 +270,7 @@ static void uart_test_common(int baudrate, int data_bits, SerialParity parity, i
tester.reset();
}

void test_init_free(PinName tx, PinName rx, PinName cts = NC, PinName rts = NC)
void fpga_uart_init_free_test(PinName tx, PinName rx, PinName cts = NC, PinName rts = NC)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
void fpga_uart_init_free_test(PinName tx, PinName rx, PinName cts = NC, PinName rts = NC)
void fpga_uart_init_free_test(PinName tx, PinName rx, PinName cts, PinName rts)

Defaults moved to the header file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is still valid. Defaults should always go in the header file.

@SeppoTakalo
Copy link
Contributor

Conflicts with the base, please rebase.

@fkjagodzinski
Copy link
Member

I've updated the defined and undefined behavior section of the serial HAL header. The patch is available here: fkjagodzinski@e1c3da6 (I don't have a permission to push to this branch).

@mprse, could you cherry-pick fkjagodzinski@e1c3da6 here before you do any rebase/update?

Please note, I've left a few FIXME notes -- these points still need clarification.
I also added the missing parts regarding IRQ behavior mentioned in #11001.

@mprse
Copy link
Contributor Author

mprse commented Jul 30, 2019

PR has been rebased and updated (review comments have been addressed). @c1728p9 @fkjagodzinski Thanks for the review!

@mprse, could you cherry-pick fkjagodzinski/mbed-os@e1c3da6 here before you do any rebase/update?
Please note, I've left a few FIXME notes -- these points still need clarification.

@fkjagodzinski Thanks for helping with the requirements for the serial API. I have cherry-picked your changes as you suggested and resolved FIXME notes in the following commit: 9aea87c.

I recommend linking all the defined behavior to tests or indicating "Not Verified" as done in other APIs, such as the RTC API.

This will be done in the next step. I assume that when this is merged authors of the FPGA tests will review the tests, add missing tests cases for the requirements that can be verified and link the defined behavior to tests.

This one is ready for CI/further review.

@mbed-ci
Copy link

mbed-ci commented Aug 1, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

@fkjagodzinski
Copy link
Member

I think we should establish a naming convention for the test functions. Currently we have a few naming patterns here:

  1. fpga_<HAL_API>_<test_name>_test:
    • fpga_analogin_init_test,
    • fpga_gpio_irq_test,
    • fpga_pwm_period_fill_test,
    • fpga_uart_init_free_test,
  2. fpga_test_<test_name>:
    • fpga_test_basic_input_output,
  3. fpga_test_<HAL_API>_<test_name>:
    • fpga_test_i2c_init_free,
  4. fpga_<HAL_API>_test_<test_name>:
    • fpga_i2c_test_byte_read,
    • fpga_spi_test_init_free,
    • fpga_uart_test_common
  5. fpga_<HAL_API>_<test_name>:
    • fpga_pwm_init_free.

I think we could go with fpga_test_<HAL_API>_<test_name> for all the FPGA tests and test_<HAL_API>_<test_name> for non-FPGA ones. What do you think?

@mprse
Copy link
Contributor Author

mprse commented Aug 13, 2019

I think we should establish a naming convention for the test functions. Currently we have a few naming patterns here:

  1. fpga_<HAL_API>_<test_name>_test:

    • fpga_analogin_init_test,
    • fpga_gpio_irq_test,
    • fpga_pwm_period_fill_test,
    • fpga_uart_init_free_test,
  2. fpga_test_<test_name>:

    • fpga_test_basic_input_output,
  3. fpga_test_<HAL_API>_<test_name>:

    • fpga_test_i2c_init_free,
  4. fpga_<HAL_API>_test_<test_name>:

    • fpga_i2c_test_byte_read,
    • fpga_spi_test_init_free,
    • fpga_uart_test_common
  5. fpga_<HAL_API>_<test_name>:

    • fpga_pwm_init_free.

I think we could go with fpga_test_<HAL_API>_<test_name> for all the FPGA tests and test_<HAL_API>_<test_name> for non-FPGA ones. What do you think?

I agree that this should be unified, but generally, it is not a problem while the test functions have different names in all test files. This is required to add a mapping to the defined behavior. E.G. in case of spi we had basic test and fpga test and some test functions had the same names. This is why I added fpga_ prefix to the fpga test functions.
When this is merged (defined behavior is ready), then the next step is to add mappings and optionally missing test cases for the untested requirements. This will be a good moment to unify the test names.

@mprse mprse force-pushed the bring_fpga_tests_master_spec branch from b4c32e5 to 741044c Compare August 13, 2019 07:30
@mprse
Copy link
Contributor Author

mprse commented Aug 13, 2019

Rebased on the master to resolve conflicts.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 19, 2019

@mprse Shall this get our attention now (rebase needed first) ?

@mprse
Copy link
Contributor Author

mprse commented Sep 19, 2019

Yes, I will rebase this PR tomorrow.

@mprse
Copy link
Contributor Author

mprse commented Oct 28, 2019

Rebased on the master to solve i2c test conflict.
Ready for CI.

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 28, 2019

CI started

@mprse
Copy link
Contributor Author

mprse commented Oct 28, 2019

Please review @maciejbocianski @jamesbeyond .

@mbed-ci
Copy link

mbed-ci commented Oct 28, 2019

Test run: FAILED

Summary: 1 of 4 test jobs failed
Build number : 7
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-GCC_ARM

@mprse
Copy link
Contributor Author

mprse commented Oct 29, 2019

Test run: FAILED

Not sure but it looks like some CI issue. Few boards in Jenkins are marked with an exclamation mark with info passed in 0 s, but marked as unstable.

@mprse mprse mentioned this pull request Oct 29, 2019
@0xc0170
Copy link
Contributor

0xc0170 commented Oct 29, 2019

CI restarted

@mprse
Copy link
Contributor Author

mprse commented Oct 29, 2019

Recent updates:

  • Added analogin_free(), gpio_free(), i2c_free() functions to HAL,
  • Added defined behaviour for free() functions,
  • Added weak default implementation of analogin_free(), gpio_free(), i2c_free(),
  • Modified the FPGA tests to make use of the free() functions.

Tested on K64F/FPGA-Test-Shield:

mbedgt: test suite report:
| target       | platform_name | test suite                                  | result | elapsed_time (sec) | copy_method |
|--------------|---------------|---------------------------------------------|--------|--------------------|-------------|
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-analogin | OK     | 22.18              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-gpio     | OK     | 24.15              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-gpio_irq | OK     | 23.45              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-i2c      | OK     | 22.34              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-pwm      | OK     | 52.05              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-spi      | OK     | 25.52              | default     |
| K64F-GCC_ARM | K64F          | tests-mbed_hal_fpga_ci_test_shield-uart     | OK     | 28.04              | default     |
mbedgt: test suite results: 7 OK

@mprse mprse force-pushed the bring_fpga_tests_master_spec branch from b7332f5 to 2ff3112 Compare October 29, 2019 13:19
@mbed-ci
Copy link

mbed-ci commented Oct 29, 2019

Test run: FAILED

Summary: 3 of 11 test jobs failed
Build number : 8
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_mbed2-build-GCC_ARM
  • jenkins-ci/mbed-os-ci_mbed2-build-IAR
  • jenkins-ci/mbed-os-ci_mbed2-build-ARM

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 29, 2019

CI aborted , will restart

@mprse
Copy link
Contributor Author

mprse commented Oct 29, 2019

Fixed style.

@mbed-ci
Copy link

mbed-ci commented Oct 29, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 9
Build artifacts

@mprse
Copy link
Contributor Author

mprse commented Oct 30, 2019

CI passed I think that this one is ready to go in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants