App timer list gets corrupted with SDK 13 -> Dead lock

[2PrintBeta]

Hello Nordic Team,

I have an application running on SDK 13.0 which uses the app_timer for some timeout handling and so does repeatedly call app_timer_start and app_timer_stop to handle the potential timeouts.

I now noticed, that in some uses cases the application comes to a complete stop and the module just hangs.-> Pretty bad for the user.

From debugging i noticed, that the code always is in the timer_timeouts_check() function of app_timer.c and somehow the timer list got corrupted as the next pointer from the current timer entry points to it self, and so this function gets stuck in the while loop.

I found some other description on this problem, and the comments always say it is fixed in the next SDK release. Unfortunately it never mentions which version :-) And i also did not find any mention of it in the release notes of SDK 13.1, SDK14 or SDK15.

Can you please check if and when that was fixed, or is i somehow can fix it myself ?

kind regards

[Jørgen Holmefjord]

Hi,

I see that we have an internal report of a similar issue that have not yet been resolved. A workaround that have been mentioned is to use app_scheduler for the timer tasks, could you see if that solves your issue?

Best regards,
Jørgen

[2PrintBeta]

Hi,

I am not sure i understand correctly.

To clarify what my application does: 

My application currently sends some request over ble to another device. And it starts an app_timer to handle the timeout of this request. If the answer to this request arrives in time,the timer is stopped. If it does not, the timer handler gets called, which might place a new request and create another timeout timer.  The timers are all single-shot.

Do you mean i should only start/stop the timers from the main loop via the app_scheduler ? Sounds very compilcated and might seriously change the timing if the system is loaded.

Do you have an example ?

[2PrintBeta]

I just changed my application to handle those timeouts differently which prevents this problem.

Instead of starting and stopping the timers, i use a faster repeating timer and check variables to see if a command timedout. This completely prevents the problem and is a workung workaround for us.

Nevertheless the underlying problem still persists and might cause serious issues for other users.