5 years ago.

Timeouts stop working at desired rate after a long running time

Hi All,

I'm building my nRF51822 system offline using GCC and eclipse which is working great! However, I am experiencing issues with the Ticker and Timeout functions where they run absolutely fine for about 2 hours, and then fail.

When I say fail, my Timeout function still runs, but at a very slow callback rate (minutes, when it should be seconds). After a quick debug, it seems that the compare register in RTC1 is being fed the variable "cc" which is overflowing. This is setting the next Timeout event too far in the future.

app_timer.c

/* this could also be to blame, i need to check if this is being set to something too large?? */
uint32_t ticks_to_expire = mp_nodes[m_timer_id_head].ticks_to_expire;

/* cc seems to be getting set to a value too far from the current RTC1->COUNTER value - which creates a long timeout delay */
cc += (ticks_elapsed < ticks_to_expire) ? ticks_to_expire : ticks_elapsed;
cc &= MAX_RTC_COUNTER_VAL;

Building with the online mbed compiler yields the same result!

I am using the Laird BL600 module with the 1st revision Nordic nRF51822 silicon. I will keep debugging the app_timer.c module, but the error could possibly be coming from us_ticker.c or us_ticker_api.c. If someone can confirm that endurance Timeout's work with the nRF51822, that would be great as I can narrow it down to my setup.

Below is my test code which fails.

Timeout Error - TestBench

DigitalOut led( p11, 1 );
Timeout    blinkTimer;

void blinkLed( void )
{
    static bool boFlash = true;
    
    if( boFlash == true )
    {
        led = 0;
        blinkTimer.attach( &blinkLed, 0.1 );
        boFlash = false;
    }
    else
    {
        led = 1;
        blinkTimer.attach( &blinkLed, 1.9 );
        boFlash = true;
    }
}

int main( void )
{
    blinkTimer.attach( &blinkLed, 2.0 );

    while( true )
    {
        sleep();
    }
}

On running the above code my mbed1768 exhibited the same behaviour. However I use Ticker and Timeout in my programs, there they work with no issues. So, try blinkTimer.detach(); before you attach(...)

posted by Pramod Joglekar 17 Nov 2014

I just updated to include detaching before attaching. This didn't help. It still fails at 71.58 minutes!

posted by Richard Tucker 17 Nov 2014
Comment on this question

6 Answers

4 years, 9 months ago.

I have exactly the same problem on the NUCLEO F401RE. It fails after about 70 minutes. This has to be a bug!

Only workaround seems to detach and re-attach.

Which version of the mbed library are you using? This should not happen with latest version! If it still does please make a regular forum topic since questions are not intended and do not really work for discussing such problems.

posted by Erik Olieman 13 Feb 2015

I used the online compiler. But I have to revert my previous comment. Re-attaching seems not to work.

posted by Richard Treu 13 Feb 2015

I would suggest take out the detach step, it is unnecessary and probably the reason why your reattach didn't work. On my hand, some ISR can be detached for good occasionally.

posted by Zhiyong Li 13 Feb 2015
4 years, 10 months ago.

sorry this is not answer/ due to non working of comment column

Hi, I encountered same problem on STM32 NUCLEO L152RE board. My program run ticker and whole program stops just 4294second after from wakeup. Is there any information or update about this issue?

There is wordaround. By using latest meed-src, ticker works after 4294second.

posted by yasuo kawachi 27 Dec 2014
4 years, 9 months ago.

This issues seems still exist in Rev 92. Although the following code runs fine on mbed, similar code with bunch of other code doesn't run well in my customized board. The ticker stops after roughly 72 minutes, exactly as you guys are experiencing.

My temporal solution is to detach and re-attach the function whenever it is called. My code has been running fine so far for two days. Not perfect, but I can get by with it for now.

#include "mbed.h"
DigitalOut led_alarm(LED1);
Serial pc(USBTX, USBRX);
char todosthFlag= 1;
Ticker ledTicker;
void ledFliper() {
    todosthFlag = 1;
    led_alarm = !led_alarm;    
}

void xbeeCallBack() {
    char msg = xbee.getc();
}
int main() {
    time_t currentTime;
    char timeofDay[10];
    set_time(1433930802);
    xbee.attach(&xbeeCallBack);
    ledTicker.attach(&ledFliper, 5.0);
    while(1) {
        currentTime = time(NULL);
        strftime(timeofDay, 9, "%X", localtime(&currentTime));
        if(todosthFlag) {
            pc.printf("%.8s\n\r", timeofDay);
            todosthFlag = 0;            
        }
        wait(0.25);
    }    
}

4 years, 10 months ago.

Hi,

Has there been any resolution to this problem? I ran into this yesterday too!

See all other comments: Mbed-src should work for sure. Also I think latest normal mbed release should work (right click on mbed lib in your library, click update).

posted by Erik Olieman 08 Jan 2015

I am now using the source, it works now. Phew!

posted by Mordechai Brodt 08 Jan 2015

I take that back; It does not seem to work reliably long term at all. After a while of running, it slows down as described above.

posted by Mordechai Brodt 09 Jan 2015

Erik, I have looked at the the comments; I have downloaded the mbed src, and then uploaded that to my project, and removed the original mbed library. I got the source code from http://developer.mbed.org/users/mbed_official/code/mbed-src/ Thanks, Mordechai

posted by Mordechai Brodt 09 Jan 2015
5 years ago.

Could you try if you build it using the latest mbed-src lib? http://developer.mbed.org/users/mbed_official/code/mbed-src/. There has been a bug fix there which isn't in the main mbed lib yet.

Yea i've tried with the very latest off GitHub.

This includes: us_ticker_api.c (Potential fix for #646) us_ticker.c (fix for the case where there are multiple tickers firing at nearly th…)

Could any of this be related to the open issue: #656 ? https://github.com/mbedmicro/mbed/issues/656

posted by Richard Tucker 17 Nov 2014

That was indeed the one I was referring to. And I am not enough into the nrf to know if it is related to that one. Although in general from 32-64 bit issues i would expect more a 1 hour error (time for 32-bit to overflow roughly).

posted by Erik Olieman 17 Nov 2014

It could very well be 1 hour.. It's tough to try and measure. My test currently is to battery reset and walk away, then come back every 30 minutes or so to check if the LED is still blinking.

Thanks for your help anyway, maybe rgrover will see this thread and comment!

posted by Richard Tucker 17 Nov 2014

OK so some further testing has revealed it consistently fails at around 1 hour 11 minutes 30 seconds. Cant really tell what that relates too?

How did you determine a 32bit overflow gives roughly a 1 hour rollover?

posted by Richard Tucker 17 Nov 2014

Mbed ticker has 1us resolution (well as only target the NRFisn't set to provide this in the underlyign hardware, but thisi s what the library uses). 32-bit overflow is 4 billion and a bit. So with 1us resolution this is 4000 and a bit seconds. Which is equal to 1 hour, 7 minutes, and a bit :).

posted by Erik Olieman 17 Nov 2014

Ah!!

32bits = 4294967295

4294967295 / 1000 / 1000 = 4295 seconds

4295 / 60 = 71.58 minutes

71.58 minutes = Almost exactly what I am seeing. 1 hour, 11 minutes, 36 seconds, yep.. I think the 32bit rollover is the issue. Ill use this to debug further. Thanks for the direction!

posted by Richard Tucker 17 Nov 2014

I am experiencing exactly the same ticker function problem with the FRDM-KL25Z. The same problem is reported here http://developer.mbed.org/users/kenjiArai/notebook/lpc1114fn28---suggestion-for-improvement/. The ticker function is essential and I hope the mbed team can resolve this really soon.

posted by Peter Ampt 17 Nov 2014

Well that is good news (for me) that it is not a platform issue. Your posted problem is exactly what i am seeing am therefore seems to be an mbed API issue.

Hopefully the mbed team will implement a fix shortly!

posted by Richard Tucker 17 Nov 2014

On LPC11u24 with latest mbed-sources it is still working fine after 1.5 hours. In other words, on all non-NRF ones at least make sure you got latest code (not regular mbed lib, mbed-src lib).

posted by Erik Olieman 17 Nov 2014

Use latest mbed-src as Erik pointed out, and report back results. Thanks

posted by Martin Kojtal 17 Nov 2014

OK so from what I gather, all non NRF platforms should work with the latest mbed-src lib. NRF platform's are still buggy!?

I will continue debugging to try and resolve this issue..

posted by Richard Tucker 17 Nov 2014

Well I am pretty sure that non-NRF ones should work with latest mbed-src. NRF one I am not 100% sure, which is why I made the exception :D.

posted by Erik Olieman 18 Nov 2014

Just an update. I haven't had a chance to develop my mbed system for a while. However, I fired it up again with v93 of the library. Still no luck, the problem remains, tickers stop after 71 minutes.

posted by Richard Tucker 08 Feb 2015

Another update. It seems the fix rgrover is proposing on github works. https://github.com/mbedmicro/mbed/pull/932

I've compiled and had my original test code running for a few days now without any hiccups!

Well done rgrover, much appreciated!

posted by Richard Tucker 09 Mar 2015
4 years, 10 months ago.

Has anyone ever tried to directly use hardware timer interrupt?

Exactly what this fix entails :) https://github.com/mbedmicro/mbed/pull/932

posted by Richard Tucker 09 Mar 2015

You need to log in to post a question