App Timer assert - APP_TIMER_SAFE_WINDOW

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Tue, 03 Oct 2023 04:57:51 GMT

Krzysztof says that the assert is too strict and could give false positive (which I already mentioned)

Anyway, it means that assert is too strict and does not cover for this case. 
I will look into fixing this assert. The SDK16 version was not covering timeouts 
longer than 24 bits thus it was changed. For now you can get back to assert from 
v16 as long as you are not using timeouts > 24 bits.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Rost — Mon, 02 Oct 2023 15:16:18 GMT

:) Finally I found something reasonable and repeated the issue with debugging, the CC is incorrectly set as described here by Krzysztof.

The fix would be as shown in post above in SDK17.1 in file app_timer2.c:321

ASSERT(app_timer_cnt_diff_compute(drv_rtc_counter_get(p_instance), 
       mp_active_timer->end_val & RTC_COUNTER_COUNTER_Msk) < APP_TIMER_SAFE_WINDOW);

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Mon, 02 Oct 2023 05:57:02 GMT

Rost,

Good thoughts, I agree to most of it. But sometimes the developer puts an assert and figures out later when the assert is hitting in a condition when the use case is genuine, then their assumption of the state machine in a particular state is wrong. In this case, the actual developer thinks that the assert is catching a lot of false positives so probably that assert should not be there.

In General it is a good habit for a developer to put debug asserts in places where they know a condition should not occur, but sometimes (rarely), those asserts have bugs aswell.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Rost — Fri, 29 Sep 2023 14:22:30 GMT

Sorry guys, I assumed initially that's a joke, but I see that quite serious suggestion.

Once a developer puts any kind of ASSERT, usually (not always) it protects from some more crucial conditions, generally protect one developer from another developer's stupidity, in common case it avoid many obvious errors in production. So smart developers try to insert such ASSERTs to show on early stage of code about wrong arguments, incorrect conditions, problems on runtime.

I caught the same error today, that's why I've been writing the message right now.I don't know a reason why it happens in my code, but what should NOT be done absolutely: to comment the ASSERT in own SDK code while you haven't get deep understanding why the timer handling goes out of the range of expected lag window.

Especially for people with such "easy fixes" approach in their head: just turn into Release mode from Debug, so you get no ASSERT macro anymore, but the assert call means you have got already an issue in your code.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Thu, 04 May 2023 19:39:57 GMT

It is verified by the customer and not regression tested on our end. That is a workaround that is suggested by Nordic to be used at your own risk since we do not do any production release testing on that workaround and most likely will not be able to do it in the near future on the older SDK solutions.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

tellg — Thu, 04 May 2023 10:54:20 GMT

Is the suggested fix a verified fix recommended by Nordic?

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Wed, 17 Aug 2022 10:57:12 GMT

Hi,

There unfortunately be no minor fixes coming into the SDK as I have learnt there are no planned released for nRF5 SDK as of now. All resources and roadmaps are for newer nRF Connect SDK.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

tellg — Wed, 17 Aug 2022 10:25:20 GMT

Any new status on this? I am using the same nrf5SDK version (17.1.0) and sometimes experience this too.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Fri, 12 Nov 2021 14:05:56 GMT

[quote user="TomDavies"]Are there plans to issue an update to the SDK to fix the issue?[/quote]

Yes, hopefully this will be fixed soon, i will send a gentle reminder to the team.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Tom — Fri, 12 Nov 2021 10:26:09 GMT

Thanks Sushell, I forgot to circle back on this one but the test was running for almost a week without any issues.

Are there plans to issue an update to the SDK to fix the issue?

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Tom — Mon, 01 Nov 2021 11:11:25 GMT

I've made the change and rerunning the tests. So far, so good. I will report back in a couple of days, if there are no more crashes.

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Thu, 28 Oct 2021 17:58:47 GMT

known issueIt looks like this is a known issue. It could be a false positive, try remove the assert in on_compare_evt

and replace it with the below

        ASSERT(app_timer_cnt_diff_compute(drv_rtc_counter_get(p_instance),
                                          mp_active_timer->end_val & RTC_COUNTER_COUNTER_Msk) < APP_TIMER_SAFE_WINDOW);

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Tom — Tue, 26 Oct 2021 19:04:50 GMT

Thanks for getting back to me Susheel.

By registration do you mean calls to app_timer_create?

There are 4 repeated timers and 2 single shot timers. When the assert occurred 3 of the repeated timers would have been running and neither of the single shot timers should have been running (triggered by user input, but unit was left testing and wouldn't have received the correct triggers to start the single shot timers).

They are all created at boot up, once the system is initialised there are no other timers created.

All the timers have their own callback functions and both the single shot timers log that they have been called (there were no logs to indicate that the single shot timers handlers were called but I will verify this again).

Of the remaining timers, one is responsible for feeding the WDT, so seems unlikely to be the one not handled, otherwise the WDT would have kicked in. The others drive a bluetooth notification and toggling a status LED.

I will add debug logs to the create calls and the LED toggle, I will log bluetooth activity and hopefully I'll be able to narrow down which isn't being handled.

Once I can identify which isn't being handled, what would be the next steps to working out why it isn't being handled?

RE: App Timer assert - APP_TIMER_SAFE_WINDOW

Susheel Nuguru — Tue, 26 Oct 2021 18:12:05 GMT

what kind of app_timer registration are you having? probably you should have some debug logs that print when you register a timer and also some debug logs when the timer callback is called. This becomes easier if it is a APP_TIMER_MODE_SINGLE_SHOT timer. This should not have happened if you are not disabling the application timer interrupts. If you have not changed anything in the sdk_config.h file and the app_timer2 code, then it looks like this is a bug that seems to very hard to trigger and debug.