Ported an nRF52840 project from SDK 17.0.0 to 17.1.0 and now app_timer_start() locks up

[Sydney]

We're working on an nRF52840-based project that started development on SDK 17.0.0 and Softdevice S140 7.0.1, but we wanted to get it to the latest release before production, so I ported our project over to 17.1.0 and Softdevice S140 7.2.0. Before beginning the port, I diffed 17.0.0 against 17.1.0 just to get a feel for what had changed, and I did notice that app_timer2.c had changed pretty meaningfully.

I got it compiling without too much trouble, but when I run, it seems to get caught in an infinite loop after/during a call to app_timer_start(). In our application while initializing everything before beginning the main loop, we create a timer with app_timer_create() and then immediately start it with app_timer_start(). Here's the call stack where it gets stuck:

Here's where the nrf_sortlist_add() call is happening in the timer_req_process() call in app_timer2.c. Inside nrf_sortlist_add() there's a while loop that loops until a pointer is null. It looks like it's never setting to null somehow so the loop is infinite.

This seems like it'd be too significant an issue to be a bug that made it into the release of the SDK, and I can't help but notice the comment block stating that this is a corner case, so that makes me wonder if we're just doing something non-standard or unexpected that worked in previous SDK releases but just happens to catch some error case in the latest SDK. I confirmed that I can put app_timer2.c and app_timer.h from 17.0.0 back into my project and leave everything else on 17.1.0 and my project works normally again, so it really is limited to app_timer2.c.

Any ideas what might be causing this? We're not opposed to using the 17.0.0 version of app_timer2.c if needed but it would be nice to understand the issue and make sure we're not doing anything unexpected with app timer.

[Simonr]

Hi

The change to app_timer2 was fixed in order to allow it to be started and stopped from higher interrupt priorities than previous. In our example projects the timers_start(); call isn't called until the other init functions are called as well. I would recommend trying that as the fact that you try starting it right away might cause some issues if you have some other services/peripherals not initialized yet with this new priority level.

Best regards,
Simon

[Sydney]

Is that a known limitation of the updated app_timer2.c? I changed our firmware to schedule out that timer start call, and then the exact same problem happened on a second timer create->start during initialization. I scheduled that one out too, and I got a very similar problem during some BLE activity very shortly afterward. I'm not really sure what to try at this point. I'm surprised that an application that worked without any issues before is so broken with this updated app_timer2.c.