Timer unreliable after a dot->sleep()

[Mark Ruys]

After a dot->sleep() the Timer runs about three times too fast. E.g.:

#include "mDot.h"

Serial pc(USBTX, NC);

void countdown(int count) {
    DigitalOut led(LED1);
    Timer timer;
    timer.start();

    while ( count-- > 0 ) {
        printf("Count %d: %d msec\r\n", count, timer.read_ms());
        led = 1; wait_ms(150);
        led = 0; wait_ms(850);
    }
}

int main() {
    pc.baud(115200);
    mDot* dot = mDot::getInstance();

    printf("\r\nmbed-os %d.%d.%d (%d), libxDot %s\r\n",
        MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION,
        MBED_LIBRARY_VERSION, dot->getId().c_str());

    countdown(5);

    dot->sleep(1, mDot::RTC_ALARM, false /*no deepsleep*/);

    countdown(5);
}

Output:

mbed-os 5.3.2 (133), libxDot 2.0.16-7-ga61aab1-mbed133
Count 4: 0 msec
Count 3: 1001 msec
Count 2: 2003 msec
Count 1: 3004 msec
Count 0: 4006 msec
Count 4: 0 msec
Count 3: 3203 msec
Count 2: 6406 msec
Count 1: 9609 msec
Count 0: 12812 msec

How can I get the Timer run reliable after a dot->sleep()?

[Mark Ruys]

Okay, found a work around to get the clock running at the proper speed.

#include "hal_tick.h"
#include "mbed_rtx.h"

...

    uint32_t us_ticker = us_ticker_read();

    int delay = 1;
    dot->sleep(delay, mDot::RTC_ALARM, false /*no deepsleep*/);
    us_ticker += delay * 1000000;

    if ( TIM_MST->PSC != OS_CLOCK / 1000000 - 1 ) {
        TIM_MST->PSC = OS_CLOCK / 1000000 - 1;
        TIM_MST->EGR = TIM_EVENTSOURCE_UPDATE;
        while ( TIM_MST->EGR & ~TIM_EVENTSOURCE_UPDATE ) {};
        TIM_MST->CNT = us_ticker;
    }

This fixes the issue that after a dot->sleep() the µsec timer has a prescaler of (10 – 1) instead of (32 – 1).

Cheers, Mark

[Peter Ferland]

Which version of mbed is this bug on?

[Mark Ruys]

mbed-os 5.3.2 (133), libxDot 2.0.16-7-ga61aab1-mbed133

and

mbed-os 5.4.2 (139), libxDot 2.0.17-mbed139

Didn’t try other versions.

[Tom Hill]

Is this the case for the mdot as well or something that is specific to xdot?

Thanks,
Yogesh

[Peter Ferland]

It looks like an mbed HAL issue for the stm32l1x series so the mdot should not be effected.

• This reply was modified 9 years, 7 months ago by Peter Ferland.

[Author]

Posts