Ticker stops unexpectedly

[Samuel3d]

The Ticker class is bugged for NUCLEO-F030R8 and NUCLEO-L053R8 as for some frequency high enough the Ticker stops unexpectedly. I.e for a 0.0001s period, the ticker stops after about 390ms.

The code used is:

#include "mbed.h"
Ticker toggle_led_ticker;
DigitalOut led1(LED1);
void toggle_led() {
    led1 = !led1;
}
int main() {
    // Init the ticker with the address of the function (toggle_led) to be attached and the interval (100 us)
    toggle_led_ticker.attach_us(&toggle_led, 100);
    while (true) {
        // Do other things...
    }
}

[0xc0170]

cc @bcostm @adustm

[bcostm]

Same as issues #816 and #1701

Fix has been found. Deployment will come soon.

[ciarmcom]

ARM Internal Ref: IOTMORF-197

[aetheln]

on some st platforms using 16-bit timer there is a check for the past event in function us_ticker_set_interrupt

    if (delta <= 0) { // This event was in the past
        us_ticker_irq_handler();
    } else {
      ...

when the condition happens, it will cause processing of the event immediately. In the Ticker class, the processor function will schedule the next event, the calling path may trigger a recursive call along the calling path of ticker_insert_event, us_ticker_set_interrupt, us_ticker_irq_handler ..., In a high load system, some ticker event may miss it's window and cause the condition to happen. But in the ticker_insert_event function, the following piece of code have one reentry issue:

    /* if prev is NULL we're at the head */
    if (prev == NULL) {
        data->queue->head = obj;
        data->interface->set_interrupt(timestamp);
    } else {
        prev->next = obj;
    }
    /* if we're at the end p will be NULL, which is correct */
    obj->next = p;

the obj->next pointer modification is after set_interrupt. When the reentry condition happens, the pointer final value will be wrong.
A simple fix here is to move obj->next = p; before set_interrupt.
Also it might be better for the st hal us_ticker_set_interrupt function to avoid call to the irq handler by scheduling the handling in a very near future, for example, 1 us later.

[0xc0170]

@aetheln Thanks for the reporting. The HAL should not call irq handler directly if delta <= 0. As you proposed to schedule in a near feature, or set a flag that would trigger the us ticker irq.

To the second, we shall have a look. Might be worth doing anyway.

@bcostm @adustm @LMESTM please could you have a look at this?

[0xc0170]

@aetheln It might e better to track this issue separately, the above issue might have been already solved

[sg-]

@Samuel3d @bcostm is this resolved?

[smarek]

Still an issue for me, NRF51(4/8)22 targets

[LMESTM]

@0xc0170 @sg-
I just tested today on L053R8 stm32 target and I confirm that the problem is not seen.
Can you please remove devices:st flag and move to nrf accoring to above comment ?