b748d5219a
The test_timer_periodicity test is racy and subject to initial state bugs. The operation of that test is to: 1. Start a timer with a known period 2. Take the current time with k_uptime_get() 3. Wait for the timer to fire with k_timer_status_sync() 4. Check that the current time minus start time is the period But that's wrong, because a tick expiring between any of the first three steps is going to skew the math (i.e. the timer will have started on a different tick than the "start time"). And taking an interrupt lock around the process can't fix the issue, because in the tickless world we live in k_uptime_get() is actually a realtime quanity based on a hardware counter and doesn't rely on interrupt delivery. Instead, use another timer object to synchronize the test start to a driver tick, ensuring that even if the race is unfixable the initial conditions are always correct. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| timer_api | ||
| timer_monotonic | ||