Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 5 months 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();
}
}
6 Answers
9 years, 2 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 13 Feb 2015
9 years, 3 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?
9 years, 2 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(¤tTime));
if(todosthFlag) {
pc.printf("%.8s\n\r", timeofDay);
todosthFlag = 0;
}
wait(0.25);
}
}
9 years, 3 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 08 Jan 2015I 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 09 Jan 2015Erik, 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 09 Jan 2015
9 years, 5 months 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 17 Nov 2014That 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 17 Nov 2014It 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 17 Nov 2014OK 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 17 Nov 2014Mbed 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 17 Nov 2014Ah!!
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 17 Nov 2014I 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 17 Nov 2014Well 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 17 Nov 2014On 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 17 Nov 2014OK 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 17 Nov 2014Well 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 18 Nov 2014Just 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 08 Feb 2015Another 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 09 Mar 2015
9 years, 3 months ago.
Has anyone ever tried to directly use hardware timer interrupt?
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 2014I 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