RIOT-OS
tests/periph/uart: clean up and add power off cmd
Contribution description
This updates the test app to use the XFA shell interface and ztimer. In addition, a shell command to power off the UART interface is added to e.g. confirm that power consumption indeed goes down.
Testing procedure
The test should work as before, except for one shell command to power down the UART being added.
Issues/PRs references
None
Murdock results
:heavy_check_mark: PASSED
29c54528619ee4592e636ec3dc55f14f8fcbccf5 tests/periph/uart: clean up and add power off cmd
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 44 | 0 | 44 | 01m:30s |
Artifacts
I can confirm that the XFA changes work as expected, all commands are still call-able.
The off-command works on the nRF52DK and nRF52840DK (but without PR #19926 ) it obviously doesn't do very much. With the PR applied as well I measured the following current values with an HP 34410A: Idle after Boot: 0.529mA Init 1 115200: 0.538mA Off 1: 0.529mA
The off-command works on the NUCLEO-G474RE as well, however it does not appear to fully disable the UART. The current is measured at JP6, which is labeled "IDD". Idle after boot: 10.341-10.350mA Init 1 115200: 12.177-12.185mA Off 1: 10.361-10.368mA
The current consumption goes back to the value of "Idle after boot" when I hit the reset button. Most likely this has nothing to do with your changes.
On the NUCLEO-L073RZ it works too, however it is somewhat more difficult to measure because the current consumption constantly wanders all over the place... However it has two UARTs and per UART a change of about 300-400uA can be measured when turning them on and off.
Everything below this line is not caused by your changes.
The "test" command does reeeeeeally work reliably for me, but that is not caused by your changes. There appear to be two separate issues with this test command:
- The current implementation of the nRF52s does not allow arbitrary baud rates, so the test fails when trying to configure 48000 Baud (and other baud rates that follow).
- The test appears to trip over leftover data in the UART buffer.
Initially, the test always fails with the 0xFFFFFFFf content in the buffer. On the next try, there is probably some stuff from the previous run and on the third try, it seems to succeed on the lower baudrates and then trips over the first issue.
> test 1
2024-05-10 13:02:29,133 # test 1
2024-05-10 13:02:29,134 # [START]
2024-05-10 13:02:29,149 # mismatch at index 11: ffffffff != 0
2024-05-10 13:02:29,150 # [FAILURE]
> test 1
2024-05-10 13:02:30,954 # test 1
2024-05-10 13:02:30,955 # [START]
2024-05-10 13:02:30,969 # mismatch at index 0: 0 != 48
2024-05-10 13:02:30,970 # [FAILURE]
> test 1
2024-05-10 13:02:32,543 # test 1
2024-05-10 13:02:32,544 # [START]
2024-05-10 13:02:32,571 # error configuring 48000 baud
2024-05-10 13:02:32,572 # [FAILURE]
The NUCLEO-G474RE has a similar behaviour:
> test 1
2024-05-10 13:11:24,399 # test 1
2024-05-10 13:11:24,399 # [START]
2024-05-10 13:11:24,416 # mismatch at index 11: ffffffff != 0
2024-05-10 13:11:24,417 # [FAILURE]
> test 1
2024-05-10 13:11:27,208 # test 1
2024-05-10 13:11:27,208 # [START]
2024-05-10 13:11:27,224 # mismatch at index 0: 0 != 48
2024-05-10 13:11:27,225 # [FAILURE]
> test 1
2024-05-10 13:11:28,692 # test 1
2024-05-10 13:11:28,693 # [START]
2024-05-10 13:11:28,716 # mismatch at index 11: 48 != 0
2024-05-10 13:11:28,717 # [FAILURE]
> test 1
2024-05-10 13:11:30,334 # test 1
2024-05-10 13:11:30,335 # [START]
2024-05-10 13:11:30,351 # mismatch at index 0: 65 != 48
2024-05-10 13:11:30,352 # [FAILURE]
> test 1
2024-05-10 13:11:32,069 # test 1
2024-05-10 13:11:32,070 # [START]
2024-05-10 13:11:32,086 # mismatch at index 0: 6c != 48
2024-05-10 13:11:32,087 # [FAILURE]
> test 1
2024-05-10 13:11:34,162 # test 1
2024-05-10 13:11:34,163 # [START]
2024-05-10 13:11:34,179 # mismatch at index 0: 6c != 48
2024-05-10 13:11:34,180 # [FAILURE]
> test 1
2024-05-10 13:11:37,220 # test 1
2024-05-10 13:11:37,221 # [START]
2024-05-10 13:11:37,237 # mismatch at index 0: 6f != 48
2024-05-10 13:11:37,238 # [FAILURE]
~~On the NUCLEO-L073RZ the test does not work at all, always giving this result: Interestingly it does not matter if the UART pins on D0 and D1 are bridged or not.~~
> test 1
2024-05-10 13:15:16,894 # test 1
2024-05-10 13:15:16,895 # [START]
2024-05-10 13:15:16,912 # mismatch at index 0: ffffffff != 48
2024-05-10 13:15:16,913 # [FAILURE]
> test 2
2024-05-10 13:15:19,205 # test 2
2024-05-10 13:15:19,206 # [START]
2024-05-10 13:15:19,223 # mismatch at index 0: ffffffff != 48
2024-05-10 13:15:19,224 # [FAILURE]
UPDATE: The pins D0 and D1 are not connected to USART2 in the default solder bridge configuration. These pins are used for the USART that go to the J-Link. When connecting the correct pins, test 1 shows the same behavior as on the G474 and interestingly test 2 always works:
> test 1
2024-05-10 15:17:51,636 # test 1
2024-05-10 15:17:51,637 # [START]
2024-05-10 15:17:51,671 # mismatch at index 10: 0 != 21
2024-05-10 15:17:51,672 # [FAILURE]
> test 1
2024-05-10 15:17:54,579 # test 1
2024-05-10 15:17:54,580 # [START]
2024-05-10 15:17:54,596 # mismatch at index 0: 0 != 48
2024-05-10 15:17:54,597 # [FAILURE]
> test 1
2024-05-10 15:17:55,589 # test 1
2024-05-10 15:17:55,589 # [START]
2024-05-10 15:17:55,626 # mismatch at index 10: 0 != 21
2024-05-10 15:17:55,627 # [FAILURE]
> test 1
2024-05-10 15:17:57,005 # test 1
2024-05-10 15:17:57,006 # [START]
2024-05-10 15:17:57,022 # mismatch at index 0: 0 != 48
2024-05-10 15:17:57,022 # [FAILURE]
> test 1
2024-05-10 15:17:57,853 # test 1
2024-05-10 15:17:57,854 # [START]
2024-05-10 15:17:57,870 # mismatch at index 10: 0 != 21
2024-05-10 15:17:57,871 # [FAILURE]
> test 2
2024-05-10 15:17:58,699 # test 2
2024-05-10 15:17:58,699 # [START]
2024-05-10 15:17:58,743 # [SUCCESS]
> test 2
2024-05-10 15:17:59,596 # test 2
2024-05-10 15:17:59,596 # [START]
2024-05-10 15:17:59,640 # [SUCCESS]
