Best way to "shut down" CPU after watchdog has been enabled, 32F417/437

[PHolt.1]

I realise one cannot disable the watchdog, short of a full reset.

One method would be to leave a "magic number" somewhere, say in one of the RTC locations, do a reboot, and if that is found at power-up, you don't enable the watchdog and you perform a shutdown, using the WFI etc method.

But that's not really the point, and it is not safe.

I wonder what would be the most effective thing possible. The watchdog will still be tripping so probably the best way would be to select slowest clock (I have a 25MHz external xtal and a 32768Hz external RTC xtal) and stay in a loop pulsing the watchdog. What is the best way to do this? Perhaps switching to the 16MHz internal oscillator and setting the PLL for the slowest clock?

Any tips much appreciated.

[PHolt.1]

In case somebody finds this thread one day, I got some replies here

https://www.eevblog.com/forum/microcontrollers/no-way-to-shutdown-a-cpu-if-the-watchdog-has-been-enabled/

It is also a bit of a concern that "I have found that the reset flags in STM32 are not always a reliable way to detect the reset source.". If those watchdog status bits do not work reliably, how is one supposed to do it? Storing magic numbers in RAM (possibly the RTC RAM) is pretty weird.

[Pavel A.]

> I got some replies here https://www.eevblog.com/forum/microcontrollers/no-way-to-shutdown-a-cpu-if-the-watchdog-has-been-enabled/

In context of ongoing write to the internal flash, and uncertainty between watchdog reset and over-temperature shutdown ... Uhm. It's complicated.   Time to get back to design and requirements step.

> Storing magic numbers in RAM (possibly the RTC RAM) is pretty weird.

By storing a magic in the SRAM you can distinguish a hot reset (usual result of STM32 internal watchdog) from a power cycle, if the RCC flags are not enough or not reliable. The RTC user registers survive power cycle (with a backup battery) so they do not fit this specific purpose.

[Ozone]

> I wonder what would be the most effective thing possible.

I would say, not initialize it in the first place, if it collides with your use case.

The goal is usually higher availability, and recovery from transient/external errors.
Being involved in safety-related software, I can tell that no certification agency will consider a watchdog as an effective measure if it can be disabled by software.
Although in my case, these systems are part of heavy machinery, and ECU or sub-component energy consumption is not of great concern.

[PHolt.1]

"will consider a watchdog as an effective measure if it can be disabled by software."

Surely a watchdog can be disabled "by software" if you follow the 4 point procedure I posted :)

No processor design can prevent that.

The key Q is what your software does once the watchdog is disabled. In this context you would not run the original code. You would enter a stopped mode, to greatly reduce power consumption.

[Ozone]

> Surely a watchdog can be disabled "by software" if you follow the 4 point procedure I posted :)
> No processor design can prevent that.

This implies a Cortex M, which none of our "safe" devices uses.
Some of them even use external watchdogs that don't need any initialisation, like this one.

> The key Q is what your software does once the watchdog is disabled. In this context you would not run the original code. You would enter a stopped mode, to greatly reduce power consumption.

Yes, though this depends on the use case.
The devices I talk about are operating intermittently from the generator or battery of a larger vehicle, and are turned off otherwise. The ECU power consumption is one or two orders of magnitude smaller than that of the attached actuators, or the machine as a whole. Thus MCU power consumption and sleep modes are not of concern.

I understand it matters in your case, though.

[PHolt.1]

Yes; I have used the MAX705 for this purpose too.

Not sure what is specifically "unsafe" about the 32F4. It's all down to the software :)