On some targets like STM family boards with LPTIM enabled an interrupt is triggered on counter rollover.
We need special handling for cases when next_match_timestamp < start_timestamp (interrupt is to be fired after rollover).
In such case after first wake-up we need to reset interrupt and go back to sleep waiting for the valid one.
On some targets like STM family boards with LPTIM enabled there is a required delay (~100 us) before we are able to reprogram LPTIM_COMPARE register back to back.
This is handled by the low level lp ticker wrapper which uses LPTIM_CMPOK interrupt. CMPOK fires when LPTIM_COMPARE register can be safely reprogrammed again.
This means that on these platforms we have additional interrupt (CMPOK) fired always ~100 us after programming lp ticker.
Since this interrupt wake-ups the board from the sleep we need to go to sleep after CMPOK is handled.
Background:
There is an errata in LPTIM specification that explains that CMP Flag
condition is not an exact match (COUNTER = MATCH) but rather a
comparison (COUNTER >= MATCH).
As a consequence the interrupt is firing early than expected when
programing a timestamp after the 0xFFFF wrap-around.
In order to
work-around this issue, we implement the below work-around.
In case timestamp is after the work-around, let's decide to program the
CMP value to 0xFFFF, which is the wrap-around value. There would anyway be
a wake-up at the time of wrap-around to let the OS update the system time.
When the wrap-around interrupt happen, OS will check the current time and
program again the timestamp to the proper value.
The DEVICE_FOO macros are always defined (either 0 or 1).
This patch replaces any instances of a define check on a DEVICE_FOO
macro with value test instead.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
There is no problem with this test during the morph, but some issue has been noticed while testing new Jenkins CI in Oulu on NRF52_DK.
I was able to reproduce the issue locally. The difference between morph and local run is that CPU statistics are enabled on morph. This makes the difference and test passes.
The sleep test case perform sleep for 100 us, 200 us, ... ,1000 us in loop (us ticker wakes the board) and verifies if sleep time matches the assumption.
I got the following results:
sleep wake-up after
100 us ~100 us ok
200 us ~200 us ok
300 us ~300 us ok
400 us ~400 us ok
500 us ~14 us (??)
When requested sleep time is equal to 500 us some unexpected interrupt occurs which wakeup the board and force the test to fail.
Register state just after exit from sleep:
Control and State Register: 0x00400000 (ISRPENDING - Interrupt pending flag is set).
NVIC Interrupt Set-pending Register[0]: 0x00000004 (UARTE0_UART0_IRQn) or 0x00000200 (TIMER1_IRQn - timer used by us ticker).
UART interrupt is generated because of green-tea transmission. We know that it is performed while test is executed since we need to wait before going into deep-sleep since otherwise the transmission will be broken. So to take care of UART interrupt we need to wait before sleep test in the same way like it is done in deep-sleep test.
Increases tolerance value for sleep_usticker_test to cover extra time needed
for cpu stats computation (for more details see MBED_CPU_STATS_ENABLED).
Prevent scheduling interrupt during ticker initialization (in lp_ticker_init)
while test execution.