Skip to content

Update built_in_tests.md #881

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.

Sign up for GitHub

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 1 commit into from
Dec 14, 2018
Merged

Update built_in_tests.md #881

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 14 additions & 19 deletions docs/porting/porting_full_process/built_in_tests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
## Testing your port

It's important to test your port at the end of each module porting, rather than only once when you've imported all modules. There are three testing methods:
It's important to test your port at the end of each module porting, rather than only once when you've imported all modules. There are two testing methods:

1. Using the Mbed OS built-in tests with [*Greentea*](../tools/greentea-testing-applications.html).
1. Using the Mbed OS built-in tests with *manual testing*.
1. Running the Mbed OS built-in tests with [*Greentea*](../tools/greentea-testing-applications.html).
1. Manually running the Mbed OS built-in tests.

## Testing with the Greentea framework

Expand All @@ -15,18 +15,19 @@ Read the following page to understand how tests are structured:

To run the Mbed OS built-in tests, you need to have ported and verified at least these HAL modules:

- DAPLink or compatible interface firmware.

<span class="notes">If DAPLink is still under development, please [use manual tests](../porting/manual-testing.html).</span>
- Low power ticker.
- Serial port (synchronous transfer). To verify that it works, load a test binary with `printf()`. Verify debug messages can be seen on your serial terminal program.
- Microsecond ticker.


You'll also need to have ported DAPLink or compatible interface firmware to your interface chip.
<span class="notes">If DAPLink is still under development, you can still [run tests manually](../porting/manual-testing.html).</span>

#### mbedls

The board under test needs to be supported in mbedls for automated tests to work.
The platform under test needs to be supported in mbedls for automated tests to work.

If an updated mbedls pip package hasn't been released yet, you need to direct pip to use your local directory (which includes the code changes to support the new board):
If an updated mbedls pip package including support for your platform hasn't been released yet, you need to direct pip to use your local directory (which includes the code changes to support the new platform):

1. Clone [https://github.com/ARMmbed/mbed-ls](https://github.com/ARMmbed/mbed-ls).
1. [Add your target to the platform database](https://github.com/ARMmbed/mbed-ls#adding-platform-support)
Expand Down Expand Up @@ -58,6 +59,7 @@ Here is an example of a successful run:

<!-- Needs to be updated with output from mbed-cli (mbed test) -->
```
mbed test --run -n tests-concurrent-gpio
mbedgt: greentea test automation tool ver. 1.4.0
mbedgt: using multiple test specifications from current directory!
using 'BUILD/tests/CC3220SF/GCC_ARM/test_spec.json'
Expand Down Expand Up @@ -114,7 +116,7 @@ mbedgt: completed in 20.24 sec

## Manual testing

You may want to run manual tests, for example if DAPLink is still under development. You will need to export your tests from Greentea and import them to your IDE. For example:
You may want to run tests manually, for example if DAPLink is still under development. You will need to export your tests from Greentea and import them to your IDE. For example:

1. Find the test directory:

Expand Down Expand Up @@ -143,7 +145,7 @@ You may want to run manual tests, for example if DAPLink is still under developm
mbed export -i <exporter> -m <new_target>
```

1. Open the project with pyOCD (using the same configuration you used [when you initially set up pyOCD](#creating-GDB-pyOCD-debug-configuration).
1. Flash the program with pyOCD (using the same configuration you used [when you initially set up pyOCD](#creating-GDB-pyOCD-debug-configuration).

1. Run the program:

Expand All @@ -160,17 +162,10 @@ Whether you're using Greentea or performing manual tests, the procedure for usin

To build and run the Mbed OS tests:

1. In your `mbed-os-example-blinky` clone, rename `main.cpp` to `main.txt`:

```
mv main.cpp main.txt
```

1. Build the tests:

<!-- any reason why we're doing a clean build here everytime? I'd really recommend dropping this one, build times will be very high -->
```
mbed test -m <new_target> -t gcc_arm --compile -c
mbed test -m <new_target> -t gcc_arm --compile
```

If you see some build errors, it means that some HAL modules required to run the tests are missing and need porting.
Expand Down Expand Up @@ -205,7 +200,7 @@ To build and run the Mbed OS tests:
- The `common_tickers` test image is at `mbed-os-example-blinky/BUILD/tests/<new_target>/gcc_arm/mbed-os/TESTS/mbed_hal/common_tickers`.
- The `common_tickers_freq` test image is at `mbed-os-example-blinky/BUILD/tests/<new_target>/gcc_arm/mbed-os/TESTS/mbed_hal/common_tickers_freq.`

1. You need to flash the test image to the board. You can use either pyOCD or the Eclipe IDE. You may also be able to use IAR and Keil (if they already support the new target).
1. You need to flash the test image to the board. You can use pyOCD (from the command line or IDE), or you could use IAR and Keil (if they already support the new target).

The easiest method is using the pyOCD flash tool:

Expand Down