Device-os: STM32F Hardware Watchdog - we want it back

[ScruffR]

We (some Elites) have been talking about this in several direct discussions and got the word of Particle (Will & Mat) that we will regain access to the HW watchdog feature (with "easy" to use API and documentation).

In order to have this promise not getting lost, this issue should be a standing reminder.

[pkourany]

Agree. The Windowed Watchdog is a good candidate since the Independent Watchdog, once started, can't be stopped. This is not convenient in sleep modes!

[m-mcgowan]

I would love to see some use cases written out so we can be sure we are building the feature as desired.

[ScruffR]

Any usecase that currently uses an external watchdog (see forum - I think @pkourany has dealt with most of these cases so far) and any case where the unconditional tickling of the Application Watchdog in Particle.process() and the likes reduces user control over the actual timeout.

A prime factor for me would be the sole authority to tickle the WD by the user application - _not_ in a library (via a guideline for library contributors - with option to "delegate" authority) and _not_ in system (by business rule - also optional delegation by user code).

---

@pkourany, does the IWDG really also fire while the device is in Standby/Stop Mode?
Or would an implicit tickle as "first" action on wake (exception to _"no system tickle"_ rule :blush:) help your needs?

[pkourany]

@ScruffR, once started, the IWDG will keep running even in STANDBY and STOP modes:

The watchdog function is implemented in the VDD voltage domain that is still functional in
Stop and Standby modes.

The only time it won't run is when the STM32 enters debug mode where it can be disabled. The WWDG doesn't run in STANDY and STOP modes and is disabled on RESET. Once enabled, it can't be disabled until the next RESET. However, its timer is limited to values less than 100ms so this may not be amenable to the system firmware / user code environment.

I'm not quite sure why STM chose to not allow for a user selected control bit to disable IWDG during sleep.

[ScruffR]

@technobly, rc.4 & 5 have come and gone, now we are at rc.10. What's the status?

[shivams]

Any updates on this feature? FWIW, someone has posted on the Particle forum that they are able to use the internal Watchdog. I haven't tested the posted code, but the OP claims that it works.

[ScruffR]

The problem is not that it wouldn't work, but once started it can't be stopped and hence your device can't sleep without always having to come out of sleep to tickle the IWDG.
Or even slow cloud reconnects could cause IWDG resets.

So the problem is how to deal with these restrictions without too much impact on other features.

But still an official update would be nice.

[avtolstoy]

So the problem is how to deal with these restrictions without too much impact on other features.

@ScruffR, you've hit the nail on the head.

We already have a PR that implements a so-called System Monitor that utilizes both the WWDG and IWDG on STM32F2-based devices and deals with all the complexities like inability to kick the watchdog during flash write operations or sleep, blocking functions and many other edge cases that may cause issues with a hardware watchdog active. Think of it as an Application Watchdog on steroids for all the subsystems of DeviceOS as well as application firmware.

It's not been merged and included in any release yet simply because it's such a massive feature touching every part of the DeviceOS and we wanted to be extra certain that it performs well, however with all the other initiatives Particle has taken we needed to reprioritize. It is still on our roadmap, along with the tracer/checkpoints feature that allows to continuously record and store the state of the device and retrieve it in case something goes wrong (e.g. an SOS, reset due to a watchdog etc.) to get an understanding of the cause.

I'll share below some of the design ideas / goals that we've put into System Monitor feature from its spec:

Monitor thread

The first step in monitoring the health condition of the device is the monitor thread. The idea is quite similar to Application Watchdog, with a few differences. Monitor thread is a high priority thread that mainly does two things:

• Monitors the health of one or more threads (checking that they periodically report)
• Kicks the hardware watchdogs if all the threads being monitored are functioning normally

To provide the most flexibility, threads that need monitoring may register themselves to the monitor thread with a specific timeout. In order to cover some complicated cases in system firmware like blocking functions on WICED-based devices, this timeout value should be re-configurable in runtime.

WWDG

By default only the WWDG is enabled with a relatively short timeout period. If triggered, additional logic may be employed (from EWI interrupt handler) in order to determine whether the device is in an unrecoverable state. Having the ability to run some code before a hardware reset happens also allows the firmware to capture trace information (see #1451) for debugging purposes, which will allow the users to debug the issues in their application code that cause the watchdog to be triggered, as well as report system firmware issues.

The advantage of using only the WWDG by default is that it does not interfere with STOP and STANDBY modes, since the LSI clock that powers the WWDG is stopped while the device is sleeping.

IWDG

Projects that require additional guarantees, should be able to enable the IWDG as well by flipping a feature flag.

In that case, the IWDG is enabled with a relatively longer timeout (along with the WWDG) and acts as the last frontier in the chain of firmware monitoring. However, since it is powered by an independent clock and continues to count even in STOP and STANDBY modes, the devices will have to wake up at the very least every 30 seconds in order to continue operating. This procedure could be automagically handled by the system firmware, keeping the timeouts and wakeup conditions for the user firmware unchanged.