Tagged: auto-reset, robustness
Hi antapc,
Thank you for posting your findings here. Although my understanding is SysTick would not be running during standby/sleep, leaving only the RTC to run. Unless there is a possible race condition upon waking up that locks the board up.
Hi Phang Moh,
I think the gist of it was the system needs to wakeup from __WFI() before SysTick starts firing off events due to a WDT issue, hence the need to disable it prior to going to sleep and then enabling once the system and things like RAM are ready. I forgot to mention in my post that post #18 in that Atmel forum link explains what’s going on. This of course could be totally unrelated to Thomas’s issue but I just thought I’d mention it in case it might help.
On a side note too: Debugging sleep code via a connected USB seems to cause hangs once you hit about the 40 cycle mark…at least in my setup anyway. No issues at all when USB is disconnected…apart from the odd very rare random lockup during sleep – which might be sorted…?
Thanks antapc and Phang Moh!
Just for info: my main problem was related to the use of LoraWAN, where logging stopped after a few days until resetting. When I went back to Lora with the radiohead library, I got good performance, with now a few months of logging. Any recurring issues now are related to external factors…
I do have loggers (different from the ones that triggered this discussion) which are continuously USB powered with no problems whatsoever.
This site uses cookies. By continuing to browse the site, you are agreeing to our use of cookies.
OKWe may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.
Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, refusing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.
We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.
We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.
These cookies collect information that is used either in aggregate form to help us understand how our website is being used or how effective our marketing campaigns are, or to help us customize our website and application for you in order to enhance your experience.
If you do not want that we track your visit to our site you can disable tracking in your browser here:
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Google reCaptcha Settings:
Vimeo and Youtube video embeds:
The following cookies are also needed - You can choose if you want to allow them:
You can read about our cookies and privacy settings in detail on our Privacy Policy Page.
Privacy Policy