RE: app_timer2 library new bug

Hieu — Wed, 08 Mar 2023 13:05:22 GMT

Hi CHATAR,

I think I found the "bug." It lies in the timer_expire() function of app_timer2.c.

The details of the issue are provided below, but first are two alternatives you can consider:

- Use APP_TIMER_MODE_SINGLE_SHOT and always restart the timer in the handler
- Defer the call to app_timer_start() out of the handler. This can be done, for example, with a boolean flag.

Next, I would like to explain the technical details:

Here is a snippet of code from the timer_expire() function. I marked the critical lines at the beginning of them:

    #if APP_TIMER_CONFIG_USE_SCHEDULER
            app_timer_event_t timer_event;

            timer_event.timeout_handler = p_timer->handler;
            timer_event.p_context       = p_timer->p_context;
            uint32_t err_code = app_sched_event_put(&timer_event,
                                                    sizeof(timer_event),
                                                    scheduled_timeout_handler);
            APP_ERROR_CHECK(err_code);
    #else
            NRF_LOG_DEBUG("Timer expired (context: %d)", (uint32_t)p_timer->p_context)
/**/        p_timer->handler(p_timer->p_context);
    #endif
            CRITICAL_REGION_ENTER();
            /* check active flag as it may have been stopped in the user handler */
            if (p_timer->repeat_period && !APP_TIMER_IS_IDLE(p_timer))
            {
/**/            p_timer->end_val += p_timer->repeat_period;
                cont = true;
            }
            else
            {
                cont = false;
            }
            CRITICAL_REGION_EXIT();

Let's keep in mind that: In the library, a timer is set as inactive by having the end value field set to an invalid value.

In your use case, each time the timer expires, the following things happen:

app_timer_stop() is called, stopping the timer. end_val is set to APP_TIMER_IDLE_VAL.
app_timer_start() is called. end_val is set to <now> + repeat_period.
In timer_expire(), after the application handler, the driver check:
- If the timer is in repeat mode (repeat_period != 0) and the timer is not stopped (end_val != APP_TIMER_IDLE_VAL)
  - end_val is set to <now> + repeat_period

If app_timer_start() is not called in the handler, then the timer_expire() logic above would be correct.

However, in your use case, app_timer_start() is used and thus the logic causes repeat_period to be added to end_val twice.

Whether or not this is a "bug" depends on whether or not the design is expected to handle app_timer_start() in the handler. I can imagine your use case being logical, so I may agree this is a bug.

Nonetheless, both the workaround I propose above should work, so unfortunately this issue will not be fixed.

I am sorry for the inconvenience. If the workarounds don't work for you for any reasons, please let me know.

Hieu

RE: app_timer2 library new bug

CHATAR — Tue, 07 Mar 2023 10:29:33 GMT

Hi Hieu,

this is just an example to show you the bug, in our program we have no choice but to use repeated mode and stop in the inerrupt in our complex behavior is mandatory, believe me. So in the previous version of sdk (17.0.2) the lib was working fine but now I have this bug.

RE: app_timer2 library new bug

Hieu — Mon, 06 Mar 2023 11:23:28 GMT

Hi CHATAR,

Let me try to reproduce and debug this and I will get back to you soon.

Meanwhile, may I ask why you start the timer in repeat mode if you would stop and restart it in the handler?

Also, you might already know this, but the app timers are not the actual TIMER peripheral, so you might want to avoid naming the instance and the handler in that way. It could be confusing.

Hieu