7e71164cc6
Add a test that repeatedly reschedules a timer before it expires, and has no other timers active. If the timer internal state overflows due to counter wrap either the uptime or the tick counter may appear to go backwards. The test runs until it fails, or until a specified amount of measured time has passed. This test is build-only for automated test programs as the default limit to pass is one hour, and some platforms may require an even longer period. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
28 lines
1.3 KiB
Plaintext
28 lines
1.3 KiB
Plaintext
Title: Timer Starvation test
|
|
|
|
The purpose of the test is to detect whether the timer implementation
|
|
correctly handles situations where only one timeout is present, and that
|
|
timeout is repeatedly rescheduled before it has a chance to fire. In
|
|
some implementations this may prevent the timer interrupt handler from
|
|
ever being invoked, which in turn prevents an announcement of ticks.
|
|
Lack of tick announcement propagates into a monotonic increase in the
|
|
value returned by z_clock_elapsed().
|
|
|
|
This test is not run in automatic test suites because it generally takes
|
|
minutes, hours, or days to fail, depending on the hardware clock rate
|
|
and the tick rate. By default the test passes if one hour passes
|
|
without detecting a failure.
|
|
|
|
Failure will occur when some counter wraps around. This may be a
|
|
hardware timer counter, a timer driver internal calculation of
|
|
unannounced cycles, or the Zephyr measurement of unannounced ticks.
|
|
|
|
For example a system that uses a 32768-Hz internal timer counter with
|
|
24-bit resolution and determines elapsed time by a 24-bit unsigned
|
|
difference between the current and last-recorded counter value will fail
|
|
at 512 s when the updated counter value is observed to be less than the
|
|
last recorded counter.
|
|
|
|
Systems that use a 32-bit counter of 80 MHz ticks would fail after
|
|
53.687 s.
|