Target
EFM32PG and PG12 (probably all EFM32)
Expected behavior
Works for more than 12 days.
Actual behavior
Crashes after around 12 days.
Steps to reproduce
Leave alone for 12 days, may be able to preload CNT to bring this sooner
It looks like it is related to

So perhaps the overflow interrupt is the cause.
It may not be related but I have enabled tickless support.
I'm still investigating but if someone from the Silabs team could take a look that would be great :-)
@ARMmbed/team-silabs
I can confirm that if you preload RTCC->CNT with 0xFFFF0000 it will fail after around 16 seconds.
void lp_ticker_init()
{
static bool first = true;
if(first ==true)
{
RTCC->CNT=0xFFFF0000;
first =false;
}
if(!rtc_reserved) {
core_util_critical_section_enter();
rtc_init_real(RTC_INIT_LPTIMER);
rtc_set_comp0_handler((uint32_t)lp_ticker_irq_handler);
rtc_reserved = 1;
core_util_critical_section_exit();
}
}
Ouch, that's not good. Will look into it on Monday.
Looks like It's not crashing as such but threads stop being executed\scheduled.
Perhaps the RTOS isn't coping with the rollover.
This main along with the above ticker init changes is enough to show the problem.
#include "mbed.h"
DigitalOut led(LED1, 1);
int main() {
while (true) {
led = !led;
Thread::wait(500);
}
}
Think I know what's going on...
Wrap-around of the RTC counter doesn't happen at the same time as when the frequency-adjusted us timestamp wraps. Since the conversion goes one-way, the RTCC counter value gets truncated into a us value, but when the us value wraps the RTCC counter doesn't reset along with it. This means when finally the RTCC counter wraps, the read-out us value suddenly jumps from 0x23ffff08 to 0x0. I'll make and PR a fix.
@chrissnow @0xc0170 Added a fix through #5854
Most helpful comment
Think I know what's going on...
Wrap-around of the RTC counter doesn't happen at the same time as when the frequency-adjusted us timestamp wraps. Since the conversion goes one-way, the RTCC counter value gets truncated into a us value, but when the us value wraps the RTCC counter doesn't reset along with it. This means when finally the RTCC counter wraps, the read-out us value suddenly jumps from 0x23ffff08 to 0x0. I'll make and PR a fix.