This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

app_timer2 assert by APP_TIMER_SAFE_WINDOW

Hi,

There was an app timer immediate expiration issue with my project which is using nrf52840 + SDK 15.3.0 on custom board.

So I changed apptimer code to app timer2 like the issue post below.

https://devzone.nordicsemi.com/f/nordic-q-a/62406/app-timer-sometimes-expires-immediately

Recently, I've enbled nrf assert to catch unknow issues and then an assert happens like below. (booting -> leave the device for a while)

In "components/libraries/timer/app_timer2.c":

        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);

The settings I am using :
#define APP_TIMER_SAFE_WINDOW_MS 300000
#define APP_TIMER_CONFIG_RTC_FREQUENCY 0  // <0=> 32768 Hz 
The device sleep time could be maximum 48 hours but usually, 1 hour but 24bit counter just have around 8~9 minutes and it will be reset.
I guess app_timer_cnt_diff_compute with 24-bit mask seems not to fit this long time timer.
Can I ignore that assert or any other suggestions?
Thank you.
  • Hello,

    The device sleep time could be maximum 48 hours but usually, 1 hour but 24bit counter just have around 8~9 minutes and it will be reset.
    I guess app_timer_cnt_diff_compute with 24-bit mask seems not to fit this long time timer.


    Yes, this is correct - as can be seen in the APP_TIMER_SAFE_WINDOW_MS documentation - the APP_TIMER_SAFE_WINDOW_MS is the maximum value that the app_timer_cnt_diff_compute is allowed to return. With your 24 bit counter width and 32768 Hz frequency you have a potential maximum of 512000 ms. Since this is > your APP_TIMER_SAFE_WINDOW_MS, it asserts.

    How high resolution do you need on this 48 hour wakeup? If you reduce your RTC frequency you can avoid waking up so often as every 9th minute.

    Is there a particular reason for having the app timer configured to 32 kHz?

    Best regards,
    Karl

  • Thank you for supporting

    How high resolution do you need on this 48 hour wakeup?

    -> It doesn't need to be so accurate but I am using the apptimer rtc counter as the OS system tick as well so it should be high resolution.

    Is there a particular reason for having the app timer configured to 32 kHz?

    -> it's for system tick.

    I know I can use apptimer for sleep/wakeup and other rtc for system tick and I've tried that but there was another issue by using apptimer for sleep/wakeup and using other rtc for system tick. so if possible, I want to keep using apptimer for both sleep/wakeup timer and rtc counter as system tick.

    so still I need the app_timer_cnt_diff_compute code for any other reasons?

  • eleven-x_devteam said:
    Thank you for supporting

    No problem at all, I am happy to help!

    eleven-x_devteam said:
    -> It doesn't need to be so accurate but I am using the apptimer rtc counter as the OS system tick as well so it should be high resolution.
    eleven-x_devteam said:
    -> it's for system tick.

    Thank you for clarifying.

    eleven-x_devteam said:
    so if possible, I want to keep using apptimer for both sleep/wakeup timer and rtc counter as system tick.

    Well, this depends on what sleep mode you are intending to use. If you are in SYSTEM_OFF mode ( lowest possible power consumption ) then you will need an external interrupt to wake up.
    If possible, I would highly recommend this, if your device is only going to wake up every 48 Hour - it would save a lot of power, to stay in SYSTEM_OFF for those 48 hours, rather than a low power SYSTEM ON state ( with timers running ).

    eleven-x_devteam said:
    so still I need the app_timer_cnt_diff_compute code for any other reasons?

    I do not quite understand this question, you have not shown me any code in which you use app_timer_cnt_diff_compute.
    If you are asking if you can ignore the assert for the size of APP_TIMER_SAFE_WINDOW, then I must say that you can, but I would advise against it if you plan on using any app_timer for any other purpose.
    Altering of any driver might break it in unforeseen ways.

    Best regards,
    Karl

  • Thank you for your answer.

    If possible, I would highly recommend this, if your device is only going to wake up every 48 Hour - it would save a lot of power, to stay in SYSTEM_OFF for those 48 hours, rather than a low power SYSTEM ON state ( with timers running ).

    I am using system_on since I've check power mode at the beginning of this project that it's not available to use rtc wake up with system off mode.

    And the 48 hours is just a maximum case. For example, the device wakes up hourly checking significant data and it wakes up every 24 or 48 hours for non-significant data. Also, it can wake up any interrupt of some sensors any time. so the timeout for the app timer is various.

    I do not quite understand this question, you have not shown me any code in which you use app_timer_cnt_diff_compute.

    I meant the code in my original post.

    In "components/libraries/timer/app_timer2.c":

            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);
    I would advise against it if you plan on using any app_timer for any other purpose.
    -> Do you mean multiple uses of the app timer? I am using the app timer for device wakeup and sensor response timeout also nrf_serial driver also using but I haven't got any issue.

    I guess ignoring the assert probably should be fine but you are just not sure 100% if it'll be OK in any case, am I correct?

  • One more thing, I think this assert can happen even with a small timeout if you use 32k because the app timer2 supports 64 bit rtc counter and the end_val is 64 bit and it will be bit masked of 24 bit in app_timer_cnt_diff_compute and the diff could be larger than APP_TIMER_SAFE_WINDOW. But I guess the reason why apptimer2 supports 64 bits rtc counter is to be able to calculate the counter even with 32K. Then the assert code seems not so meaningful in this case.

  • Related