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

Occasional second-long freezes using app_timer

We want to use app_timer_create/app_timer_start to create a periodic timer, but noticed that there were a few seconds missing. After printing out each tick, we see that there are occasional "freezes" or delays where the timer doesn't seem to advance. These lasts for around 1.5 seconds if I interpret the logs correctly.

For debugging, we started with the Apple notification example ble_app_ancs_c and added a very simple timer callback that just increments a variable. (Note that I have copied these examples by typing from a screenshot, so there may be minor syntax errors introduced by mistake)

APP_TIMER_DEF(m_systime_tmr);

static volatile uint32_t tick=0;
static volatile uint32_t tickback=0;

static void system_tick_handler(void * p_context)
{
    tick++;
}

static void time_test_init(void)
{
    uint32_t ret;
    ret = app_timer_create(&m_systime_tmr,
                                       APP_TIMER_MODE_REPEATED,
                                       system_tick_handler);
    APP_ERROR_CHECK(ret);
    NRF_LOG_INFO("1S tick = %d.",APP_TIMER_TICKS(1000));
    app_timer_start(m_systime_tmr, APP_TIMER_TICKS(1000), NULL);
}

.

...

// Start execution.
NRF_LOG_INFO("Apple Notification Center Service client example started.");
advertising_start(erase_bonds);
time_test_init();

// Enter main loop.
for (;;)
{
    idle_state_handle();
    if(tickback!=tick)
    {
        tickback = tick;
        NRF_LOG_INFO("tick = %d.",tick);
    }
}

...

The logs are from my colleague in China who doesn't yet have an account here, but here is a screenshot from the PC showing one of the missing events. As you can see, it works well for a long time, but suddenly there is a longer delay between two ticks. After the delay, it continues again.

I already checked the SoftDevice specification with regards to BLE timing, and there should not be any system interrupt taking that long time. If I understand correctly this will be using some RTC running at 32 kHz.

I would like to know if this is the expected behavior. If it's not, do you have any ideas on how to debug this further? If it is, is there a way to prevent or minimize the problem?

Parents Reply Children
No Data
Related