When using ApplicationWatchdog on an Electron I believe it is advisable to call System.sleep(SLEEP_MODE_DEEP, long seconds) rather than System.reset. As I understand the documentation, reset will NOT restart the cellular modem. The problem is that I cannot seem to call any of the sleep functions from ApplicationWatchdog…doing so generates a “invalid use of void expression” error.
Any suggestions?
The watchdog feature is currently disabled and not usable FYI.
Really?!? That is new news. Was it posted somewhere that I missed?
@RWB, the Application Watchdog (done via FreeRTOS) works as documented. It is the STM32 IWDG hardware watchdog that is not enabled.
@Darmitage, the Applicaton Watchdog timer runs on its own high priority thread with a small amount of allocated stack. Can you show your callback code with the sleep call?
I guess it's a good time to ask what the difference is between those 2 different watchdogs?
Why isn't the Application Watchdog as good as the IWDG Hardware watchdog feature?
@RWB, the application watchdog (AWDG) is a software solution and subject to failure if the processor freezes or FreeRTOS fails. The Independent Watchdog (IWDG) is a hardware component of the STM32 processor that operates much like an external watchdog in that it needs to be “poked” at regular intervals or it will reset the processor.
Because the AWDG is done in firmware, your application can gracefully shut down or (soft) reset the processor whereas with the IWDG, a hard reset offers no possibility of a “controlled” reset.
Thanks for the overview.
I assumed if your code freezes the processor it also freezes FreeRTOS at the same time but I guess that’s not the case all the time.
Is FreeRTOS running on a separate thread of the processor or something like that?
I am currently using ApplicationWatchdog wd(660000, System.reset) which compiles, but isn’t what I apparently should use on an Electron as a simple System.reset doesn’t reset the cellular modem.
What I had hoped would be an easy fix would be to call deep sleep instead.
For example, ApplicationWatchdog wd(660000, System.sleep(SLEEP_MODE_DEEP, 60); which would do a complete restart after a minute.
Unfortunately that will not compile properly. Any suggestions? Seems like this should be simple!
BTW, ultimately the ‘right’ answer would be to use both an application watchdog and a hardware watchdog. I’ll get there eventually…
@Darmitage, the reasons for the errors when you try to call sleep from the ApplicationWatchdog declaration is that you cannot pass parameters when specifying the callback function. Instead, create a new void function, and in that function, call System.sleep():
void mayday() {
System.sleep(SLEEP_MODE_DEEP, 60);
}
ApplicationWatchdog wd(660000, mayday);
Now, before you go too far, note that System.reset() and the reset which comes from a DEEP_SLEEP call the same STM32 software reset function (NVIC_SystemReset). Neither of these is the equivalent of hitting the reset button on the Electron.
Great help! Can’t thank you enough.
In a number of other posts folks indicated that there was a significant difference between System.reset and waking up from a DEEP_SLEEP on the Electron. Specifically when it comes to the cellular modem reset. Is this not the case?
@Darmitage, after carefully re-reading the STM32F2xx reference manual, it is clear that the software reset, the button (external) reset and the exit-from-standby reset produce the same effect on the Electron (see diagram below). The important aspect of the Electron modem is that it is not hardware reset in these conditions. As such, the state of the modem prior to DEEP_SLEEP or System.reset() is the factor which will affect how the modem behaves after “soft” resets (power is maintained to the modem while the STM32 resets). You may want to re-read those posts in context of this knowledge. 
That’s helpful. And your analysis is way above my pay grade.
I was thinking that DEEP_SLEEP did cut power to the cellular modem, while System.reset did not.
Short of an external watchdog, is there a way to fully ‘reboot’ everything?
@Darmitage, that IS the way to reboot everything. For a “true” reset, you would need to cut all power to the Electron, battery and all.
@rickkas7 Has some Electron code here that shows you how to reset the Modem and Sim card.
It doesn't cut the power but powers the module down (unless you're using SLEEP_NETWORK_STANDBY for deep sleep).
How the module takes this would be documented by ublox, but AFAIK this does not wipe the radio module clean.
Has this functionality been incorporated into the system firmware since 0.5.0?
If so, is it possible to force SLEEP_MODE_DEEP as noted above?
Also, switch to safe mode?
@ScruffR @rickkas7 Any comments? Original post is quite old, but changes since then are not entirely clear in the docs.
If the device fails to connect via cellular for more than 10 minutes the cellular modem is powered down and back up automatically. It’s not really necessary manually manage this anymore.
You should only do System.reset() from the application watchdog callback. While doing a System.sleep(SLEEP_MODE_DEEP, 10) has the advantage of powering down the modem, it’s not good to do it from the application watchdog. Making extra calls including the ones to power down the modem will likely just cause the device to lock up if it’s already in the watchdog callback.
The best advice is to just let Device OS 1.5.2 or later handle powering down the modem when necessary.
Thanks for the quick reply, Rick.
Automatic handling with the firmware is great. Is that new with 1.5.3?
In the past, I had problems losing cloud connectivity due to an application firmware problem, i.e., solid or blinking cyan, but no cloud. Only solution was to locally switch to safe mode to upload the updated firmware.
So, in that situation, the system reset won’t help.
Is there a way to use the watchdog to switch to safe mode instead of system reset?
Sorry, I meant 1.5.2. It’s not a new feature, but that the latest default release and it’s a good one to go with.
If you’re getting a solid LED you’re most likely have corrupted memory or deadlock, caused by accessing a mutex protected resource in a way that it becomes impossible for the holder of the mutex to release it. Accessing a mutex protected resource from a SINGLE_THREADED_BLOCK is one way, but there are others. That should be the first priority to find, because when that happens the only recourse is usually a hardware watchdog.
