Timer handler called immediately on app_timer_start()

[Eliot Stock]

On an nRF51822 without the Soft Device, I use the app timers in a driver for a GPS module that uses the UART. Each time I start reading from the UART, I also start a timer with a timeout of 2 seconds. When the timer handler is called, I set a bool to indicate that the read has timed out and the driver continues.

This works just fine for 3 to 5 minutes, but then I notice that the timer is having its handler called immediately after app_timer_start() in every case. I have no idea why.

static app_timer_id_t                  m_gps_response_timeout_timer_id;

In my gps_init(), which is called once only, at the start:

err_code = app_timer_create(&m_gps_response_timeout_timer_id, APP_TIMER_MODE_SINGLE_SHOT, gps_response_timeout_handler);
	APP_ERROR_CHECK(err_code);

Every time I read a sentence from the GPS:

err_code = app_timer_start(m_gps_response_timeout_timer_id, GPS_TIMEOUT, NULL);
APP_ERROR_CHECK(err_code);

...UART stuff, including checking for timeout, in a loop...

err_code = app_timer_stop(m_gps_response_timeout_timer_id);
APP_ERROR_CHECK(err_code);

Header macros:

#define GPS_TIMER_PRESCALER 0
#define GPS_TIMEOUT APP_TIMER_TICKS(2000, GPS_TIMER_PRESCALER)

Timeout handler:

void gps_response_timeout_handler(void * p_context)
{
    UNUSED_PARAMETER(p_context);
    m_gps_response_timed_out = true;
}

I've verified that the timeout handler function is really getting called. Why would this work for a few minutes then stop working? I do have other timers in the same code, but they all have their own timer IDs of course.

[Eliot Stock]

This is happening at 4 minutes and 18 seconds after reset, every time, like clockwork.

[Håkon Alseth]

We've had a couple of known bugs regarding the app_timer in the latest release, which we are working on fixing. I have the app_timer source file that will be included in the next release of the nRF51 SDK. Could you try that?

-H

app_timer.c

[Eliot Stock]

That does indeed seem to have fixed the problem! My code's been running for 18 mins now without seeing the same behaviour.

I'm using SDK 5.1.0 though, not 5.2.0, just FYI. Not sure if the same problem exists in 5.2.0 but I'll stick with 5.1.0 plus this modified source until the next release I guess.

[Eliot Stock]

I spoke too soon. Although the patched app_timer.c fixes the issue I was seeing originally, it also breaks the implementation of app_timer_cnt_get() for me. That function is now returning a very low number of ticks (3) where it used to return the right value. This breaks all the timestamps in my log.

Do you want me to try this patched app_timer.c with the 5.2.0 SDK instead?

[Håkon Alseth]

Sorry for the delay, Eliot. I had to get a hold of the developer of app_timer to understand the changes made. The issue you're seeing is due to a bugfix, where the counter is reset if it sees that no other app_timer instances are running.

If you add a dummy-timeout handler (empty handler) with a timeout of MAX_RTC / 2 (255 seconds if prescaler 0 set, see RM chapter 18 for calculation) do you still see the issue of the counter being reset?