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 ?

[0xc0170]

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

@smarek Can you plesae be more specific?

cc @nvlsianpu @pan-

[smarek]

@0xc0170 I've described the problems I'm having in ticket #4108

[smarek]

Also I've just tested with latest release (branch mbed-os-5.4), and the issue is still present.

[0xc0170]

Also I've just tested with latest release (branch mbed-os-5.4), and the issue is still present.

Can you test 5.5 ?

[smarek]

@0xc0170 ok, I've tested with 5.5 and the problem, that appears while using Ticker is gone.
What is not allright is what I've described in #4108 and that is issue when running the same example but using RTOS::Thread instead of Ticker.

Code as follows:

#include "mbed.h"

Thread led_blink1;

DigitalOut led1(P0_8); 
DigitalOut led2(P0_9); 
DigitalOut led3(P0_10); 

void topledTick() {
        while(1){
                led1 = !led1;
                led2 = !led2;
                led3 = !led3;
                wait(1);
        }
}

int main() {
        led_blink1.start(callback(topledTick));
        while (1) {     }
}

This will randomly hang in between 2 and 30 seconds
Compiled example is merged with softdevice "s130_nrf51_2.0.0_softdevice.hex", if it is any important

[pan-]

@smarek I've tested the code above with 5.5 on an NRF51_DK (replacing P0_8 by LED1, P0_9 by LED2 and P0_10 by LED3) and it doesn't hang. The issue might live in your custom target code.

[smarek]

@pan- let's continue this under #4108