nrf timers unstable with ticks faster than 100 Hz

[pabigot]

I have a test application that uses k_timer to wake every 10 seconds and display information about elapsed time differences between k_uptime_get() and k_cycle_get(). It operates correctly with the default 100 ticks per second.

Increasing to 1000 ticks per second the system appears to work, but instrumentation shows that the timer ISR is actually firing every 5.855 ms. Other values greater than 200 show the same behavior, with different intervals that are ticks-per-second dependent but generally on the order of 5-12 ms.

Increasing to 32768 ticks per second (supposedly the workaround to enable high-resolution alarms) the k_timer handler is never called and the ISR shows a burst of about 8 wakeups at 11 ms intervals followed by silence. Presumably the counter got set to an offset too small to guarantee a wakeup and the first callback will be in 512 s when the counter wraps.

[pizi-nordic]

FYI: @carlescufi

[pabigot]

The test application referenced has a timer in the main thread that wakes at 1 Hz, captures some clock information, and queues a k_work instance that displays the captured data with printk. The expected behavior was to see two invocations of z_clock_set_timeout() every second regardless of ticks-per second.

Some of the instability and unexpected behavior appears to be due to CONFIG_TIMESLICE being enabled by default. Although CONFIG_TICKLESS_KERNEL=y and the next useful work is scheduled 1 s in the future z_clock_set_timeout() is still being invoked too frequently: roughly every 7.81 ms with TICKS_PER_SEC=1000, but with occasional back-to-back bursts (less than 35 us between calls on a 16 MHz nRF51). The continuous rapid invocation during idle periods is not evident with the default 100 Hz tick rate.

This is an unreported issue with timeslicing (@andyross), and can eliminating by turning that feature off.

The rest of the instability is due to edge conditions in the nrf_rtc_timer code, in particular that the minimum delay required to guarantee a compare event is not met when ticks-per-sec is greater than 1024. Those issues are addressed in #12605. With that patch applied CONFIG_TICKS_PER_SEC=8192 appears to work reliably both with and without timeslicing being enabled. It is not feasible to increase ticks-per-second past that limit.

[pabigot]

These issues appear to be resolved after various timer improvements in the last couple months. pca10028 running my test application uses 32 KiHz ticks and no longer displays bursts of interrupts that do not correlated to application demands.