timer events triggered in a row

Question

Hi 
 I seek your support for the following 2 app_timer (or else) issue: 
 (1)
in there any reason as to why multiple app_timers will sometime trigger all in a row although they have very different timeouts? 
 My case is button detection for short, long and very long presses: when a press is detected, it fires 2 timers, then depending on when you depress, related timers are _stop-ped and the correct handler is called. It usually works well. But sometimes (usually after a reset and low battery and the softdevice being initialized but not used), if I press, I get short + long-handler + very-long-handlers being fired all in a row as if timers had a timeout of 0. 
 same effect with a GPIO based trigger that turns the display on to show some data until a given display timeout (app_timer based). Sometimes (same situation as previous), the display timeout handler is called immediately as if timeout is 0. 
 In both case, all app_timer timeouts are hardcoded (#define) 
 (2)
considering a timeout function that sometimes needs to be extended (display timeout set to 4sec, some consequent events may need to reset (or change) the timeout): sometimes the app_timer_stop and _start sequence is not respected; being aware that those calls are actually queued and then interrupted, I scheduled the { _stop _start } ... but that does not help... 
 Final note: I cannot reproduce the cases on demand. I am also trying to isolate the issue (dedicated app) but without success until now... 
 env: { N51822 QFAAH0 1627WW + sdk_v5_2_0_39364 } 
 thank you

Kenneth · Accepted Answer

This is a possible issue in app_timer.c, that can cause the timeout handler to execute two times in a row. This has been fixed in later SDK. The workaround you can try: 
 Add a delay of 100us after timer_timeouts_check_sched() in compare_reg_update(), like this: 
 static void compare_reg_update(app_timer_id_t timer_id_head_old)
{
...
 timer_timeouts_check_sched();
 nrf_delay_us(100); // Add this delay.
...
}
 
 Best regards,
Kenneth