Skip to content

EFM32: Unresponsive after 12 days #5840

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chrissnow opened this issue Jan 12, 2018 · 7 comments · Fixed by #5854
Closed

EFM32: Unresponsive after 12 days #5840

chrissnow opened this issue Jan 12, 2018 · 7 comments · Fixed by #5854

Comments

@chrissnow
Copy link
Contributor

chrissnow commented Jan 12, 2018

Description

  • Type: Bug
  • Priority: Major

Bug

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
12 day

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 :-)

@pan-
Copy link
Member

pan- commented Jan 12, 2018

@ARMmbed/team-silabs

@chrissnow
Copy link
Contributor Author

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();
    }
}

@stevew817
Copy link
Contributor

Ouch, that's not good. Will look into it on Monday.

@chrissnow
Copy link
Contributor Author

Looks like It's not crashing as such but threads stop being executed\scheduled.
Perhaps the RTOS isn't coping with the rollover.

@chrissnow
Copy link
Contributor Author

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);
	}
}

@stevew817
Copy link
Contributor

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.

@stevew817
Copy link
Contributor

@chrissnow @0xc0170 Added a fix through #5854

stevew817 added a commit to SiliconLabs/mbed-os that referenced this issue Jan 15, 2018
This commit fixes ARMmbed#5840. Fix verified by running mbed_hal-lp_ticker test suite with preloaded RTC counter such that it wrapped in the middle of the suite.
Also removes explicit sleep blocking from the us_ticker implementation, since sleep blocking for us tickers is done at mbed HAL level now. This was causing one of the lp_ticker tests to fail.
cmonr pushed a commit that referenced this issue Jan 27, 2018
This commit fixes #5840. Fix verified by running mbed_hal-lp_ticker test suite with preloaded RTC counter such that it wrapped in the middle of the suite.
Also removes explicit sleep blocking from the us_ticker implementation, since sleep blocking for us tickers is done at mbed HAL level now. This was causing one of the lp_ticker tests to fail.
cmonr pushed a commit that referenced this issue Jan 27, 2018
This commit fixes #5840. Fix verified by running mbed_hal-lp_ticker test suite with preloaded RTC counter such that it wrapped in the middle of the suite.
Also removes explicit sleep blocking from the us_ticker implementation, since sleep blocking for us tickers is done at mbed HAL level now. This was causing one of the lp_ticker tests to fail.
cmonr pushed a commit that referenced this issue Jan 27, 2018
This commit fixes #5840. Fix verified by running mbed_hal-lp_ticker test suite with preloaded RTC counter such that it wrapped in the middle of the suite.
Also removes explicit sleep blocking from the us_ticker implementation, since sleep blocking for us tickers is done at mbed HAL level now. This was causing one of the lp_ticker tests to fail.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants