STM32: lp_ticker_fire_interrupt: Event handler not called instantly when scheduled with past timestamp

[fkjagodzinski]

Description

• Type: Bug
• Related issue: us_ticker_fire_interrupt: Event handler is never called #5051
• Priority: Major

Bug

Target
NUCLEO_F070RB
NUCLEO_F429ZI
NUCLEO_L476RG

Toolchain
GCC_ARM, ARM, IAR

Toolchain version
GCC_ARM -- 6.3.1,
ARM -- 5.24 (Flex) ARM Compiler 5.06 update 5 (build 528),
IAR -- ANSI C/C++ Compiler V7.80.4.12462/W32 for ARM

mbed-cli version
1.2.0

mbed-os sha
003dd7c

Code

#include "mbed.h"
#include "hal/ticker_api.h"
#include "hal/lp_ticker_api.h"
#include "rtos.h"

Semaphore sem(0, 1);
Timer timer;

void foo(uint32_t id) {
    (void) id;
    timer.stop();
    sem.release();
}

int main() {
    ticker_event_t e;
    const ticker_data_t *lp_td = get_lp_ticker_data();
    ticker_set_handler(lp_td, foo);

    us_timestamp_t past_ts = ticker_read_us(lp_td) - 1ULL;
    ticker_insert_event_us(lp_td, &e, past_ts, NULL);

    // As ticker_insert_event_us() is called with a timestamp earlier
    // than the current  -- lp_td->interface->fire_interrupt is called.

    // sem should have been released by lp_ticker_fire_interrupt()
    int32_t num_tokens = sem.wait(0);

    // In case sem hasn't been released -- wait forever.
    if (!num_tokens) {
        timer.start();
        sem.wait(osWaitForever);
    }
    printf("%10i\n", timer.read_us());

    DigitalOut led1(LED1, 1);
    while (true) {
        if (num_tokens) {
            led1 = !led1;
        }
        Thread::wait(100);
    }
}

Sample output for NUCLEO_F070RB:

    131023

Expected behavior
The ticker event handler foo() is called immediately after ticker_insert_event_us().

Actual behavior
The ticker event handler foo is called with ~130 ms delay.

cc @bulislaw @0xc0170

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

bump, could you reproduce this behavior?

[LMESTM]

@0xc0170 - I'll have a quick look
but can't you reproduce the test with using the MBED APIs rather than direct calls to HAL layers - which is not supposed to happen, right ?

[fkjagodzinski]

The code embedded above does not use upper layers to simplify the use case. Same behaviour occurs when LowPowerTimeout::attach() is called with 0.0 s delay. Please take a look here.

[LMESTM]

@fkjagodzinski OK thx
I pushed #5289 - could you confirm this is fine for you?
@jeromecoutant would you consider this patch as part of your ongoing tests ?

[fkjagodzinski]

#5289 fixes this issue for all NUCLEO boards mentioned above.
@LMESTM Thank you and sorry for the delay!