App Timer assert - APP_TIMER_SAFE_WINDOW

I have started getting an assert in my code while testing new functionality.

I am using SDK 17.1.0 and the nRF52840 DK

The assert is line 321 in app_timer2.c

        /* If assert fails it suggests that safe window should be increased. */
        ASSERT(app_timer_cnt_diff_compute(drv_rtc_counter_get(p_instance),
                                          drv_rtc_compare_get(p_instance, 0)) < APP_TIMER_SAFE_WINDOW);

Looking at the the description of APP_TIMER_SAFE_WINDOW_MS in sdk_config.h

// <o> APP_TIMER_SAFE_WINDOW_MS - Maximum possible latency (in milliseconds) of handling app_timer event.
// <i> Maximum possible timeout that can be set is reduced by safe window.
// <i> Example: RTC frequency 16384 Hz, maximum possible timeout 1024 seconds - APP_TIMER_SAFE_WINDOW_MS.
// <i> Since RTC is not stopped when processor is halted in debugging session, this value
// <i> must cover it if debugging is needed. It is possible to halt processor for APP_TIMER_SAFE_WINDOW_MS
// <i> without corrupting app_timer behavior.

#ifndef APP_TIMER_SAFE_WINDOW_MS
#define APP_TIMER_SAFE_WINDOW_MS 300000
#endif

Am I correct in thinking this means that this will assert if, for (1024-300) seconds, or ~12 minutes, the app_timer event is not handled?

If so, how do I go about debugging which timer isn't handled?

I initially saw this after leaving a board running for around 36hrs. I think I saw it again, didn't get the error log unforunately, after over 24 hours. I have tried to set up a test to replicate is and saw it withing 4-5 hours. It is still in sat in this state with the debugger attached but I don't know where to begin with working out the cause.

The debugger output is:

[03624616] <error> app: ERROR 3735928559 [Unknown error code] at nRF5_SDK_17.1.0_ddde560/components/libraries/timer/app_timer2.c:321
PC at: 0x000362B3
[03624623] <error> app: End of error report

I want to understand why this is occuring, why it isn't after a fixed period of time and whether increasing APP_TIMER_SAFE_WINDOW_MS is a fix or a bandaid.

Parents Reply
  • 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.

Children
No Data
Related