lp timeout test fails on NUCLEO_L073RZ

[marcuschangarm]

Description

Tested on two different boards.

+-----------------------+---------------+---------------------------------------+---------------------------------------------------+--------+--------+---------+--------------------+
| target                | platform_name | test suite                            | test case                                         | passed | failed | result  | elapsed_time (sec) |
+-----------------------+---------------+---------------------------------------+---------------------------------------------------+--------+--------+---------+--------------------+
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay accuracy (attach)                       | 1      | 0      | OK      | 1.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay accuracy (attach_us)                    | 1      | 0      | OK      | 1.07               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay during deepsleep (attach)               | 1      | 0      | OK      | 1.08               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay during deepsleep (attach_us)            | 1      | 0      | OK      | 1.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay during sleep (attach)                   | 1      | 0      | OK      | 1.05               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 1 s delay during sleep (attach_us)                | 1      | 0      | OK      | 1.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 10 ms delay accuracy (attach)                     | 1      | 0      | OK      | 0.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 10 ms delay accuracy (attach_us)                  | 1      | 0      | OK      | 0.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 5 s delay accuracy (attach)                       | 1      | 0      | OK      | 5.05               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | 5 s delay accuracy (attach_us)                    | 1      | 0      | OK      | 5.06               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback called once (attach)                     | 1      | 0      | OK      | 0.24               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback called once (attach_us)                  | 1      | 0      | OK      | 0.08               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback not called when cancelled (attach)       | 1      | 0      | OK      | 0.09               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback not called when cancelled (attach_us)    | 1      | 0      | OK      | 0.09               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback override (attach)                        | 1      | 0      | OK      | 0.08               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Callback override (attach_us)                     | 1      | 0      | OK      | 0.08               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Multiple timeouts running in parallel (attach)    | 1      | 0      | OK      | 0.09               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Multiple timeouts running in parallel (attach_us) | 1      | 0      | OK      | 0.09               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Timing drift (attach)                             | 0      | 1      | FAIL    | 9.84               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Timing drift (attach_us)                          | 0      | 0      | SKIPPED | 0.0                |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Zero delay (attach)                               | 1      | 0      | OK      | 0.05               |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | mbed-os-tests-mbed_drivers-lp_timeout | Zero delay (attach_us)                            | 1      | 0      | OK      | 0.05               |
+-----------------------+---------------+---------------------------------------+---------------------------------------------------+--------+--------+---------+--------------------+

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-948

[0xc0170]

cc @ARMmbed/team-st-mcd

[LDong-Arm]

This issue is seen with RTC when compiled with ARM_GCC. The device time reported by the board is less than the actual time, showing that it probably ticks too slowly:

Host: ~11.2 s
Target (LPTIM): ~11.2 s
Target (RTC, GCC_ARM): ~10.8 s (narrowly fails)
Target (RTC, ARMC6): ~10.95 s (narrowly passes)
Transport delay: ~0.07 s (consistent and negligible)

It seems RTC is much less accurate than LPTIM, and (with RTC used) the device time narrows falls on the 5% error range. The difference produced by GNU and ARM compilers is fairly small (though noticeable).

The follow commit changed the wakeup timer from LPTIM to RTC:

commit 4bead92
Author: Russ Butler russ.butler@arm.com
Date: Thu Feb 28 10:09:50 2019 -0600

Use the RTC for the low power ticker on L073RZ

Due to a bug the LPTIM peripheral can cause interrupts to fire at the
wrong time on the NUCLEO_L073RZ. This patch switches the backend
of the low power ticker to the RTC until this bug is addressed.

Locally reverting the commit above makes the test pass, though as its commit message suggests, it's intended to address another bug.

[LDong-Arm]

The failure is down to the high latency of RTC-based lp_ticker.

"Timing drift" test works by attaching itself to Ticker with perioud = 10000us (10ms), incrementing a counter once Ticker calls back, attaching again, ... (repeating thousands of times). At the end, calculate time = counter * period.

If we increase the period (of each call) by 10x (to 100ms), the test passes with very precise timing. We infer that Ticker has good timing but the latency is high and accumulates to produce a noticeable time shift.

I estimate the latency to be ~300us (0.3 ms) per call in the following way:

calls = reported time / 10000us
time lost = actual time - reported time
latency per call = time lost / calls

[LDong-Arm]

The latency of RTC-based lp_ticker seems inheritly high, as confirmed on a few other targets as well. Perhaps the best we can do is wait for LPTIM issue to be fixed and re-enable it.

See #9785 #10536 #10537

[LMESTM]

Should be solved by #10701

[0xc0170]

Should be solved by #10701

👍