MCU Watchdog Usage Considerations

Background

Recently a project product had hardware design issues, which resulted in removing the hardware power switch and the hardware system reset function from a designed product. More seriously, the product has already entered production and the hardware cannot be changed, so software watchdogs must be used; otherwise, when the device locks up or behaves abnormally it can only be reset by removing the battery.

The MCU we used is Puran's PY32F030. This chip, in low-power scenarios, presents many issues and pitfalls when using watchdogs and requires careful attention; small mistakes can cause problems.

Key Questions for Watchdog Use in Low-Power Scenarios

When applying a watchdog in low-power scenarios, consider these questions in advance:

1. Is it better to service (kick) the watchdog inside an interrupt or in the main program?
2. Can watchdog initialization occur before clock initialization?
3. If the system clock fails, will the watchdog still function?
4. After deep low-power sleep, is it necessary to service the watchdog? If so, how should it be designed and which wake source should service the watchdog?
5. What is the difference between a software independent watchdog and a hardware independent watchdog?
6. What happens if the system fails before watchdog initialization?
7. What is the difference between enabling a hardware watchdog via option bytes versus enabling it in software?
8. If failures are unavoidable, is there a place to persist device state so it is not lost after a reset?

Watchdog Categories

Watchdogs can be classified by implementation method into software watchdogs and hardware watchdogs:

Software watchdog: A mechanism implemented in software and typically configured and managed by the system software.

Hardware watchdog: A dedicated hardware module embedded in the processor or chip.

By usage pattern, they can be further divided into independent watchdogs and window watchdogs:

Independent watchdog: Usually monitors the overall system state rather than a specific task or process. If the system fails, deadlocks, or becomes unresponsive so the application cannot service the watchdog, the watchdog timeout will trigger a reset.

Window watchdog: Focuses on monitoring a specific task or process and requires servicing within a defined time window. If the watchdog is serviced too early or too late, it triggers an error. Because servicing must occur within a time window, it is called a window watchdog.

For the PY32F030 series MCU used here, which is a 32-bit Cortex-M0+ core, the chip includes an independent watchdog (IWDG) and a window watchdog (WWDG).

The main practical difference between software and hardware independent watchdogs lies in how the watchdog is started. The following discussion mainly targets the independent watchdog.

Starting the Watchdog

There are several ways to start the watchdog:

1. Start via an interface call.
2. Start by directly setting registers.
3. Start by configuring option bytes.

If the hardware watchdog is enabled via option bytes, the chip will automatically enable the LSI clock. In that case, software cannot disable the LSI clock.

Differences Between Software and Hardware Independent Watchdogs

1. A software independent watchdog is initialized by software and can be disabled by turning off its clock.
2. If the system fails after power-up but before the watchdog is initialized, the watchdog will not take effect. This situation often occurs when the software initialization itself hangs or crashes.
3. A hardware independent watchdog is configured either via the programmer when flashing or by modifying option byte parameters in software.
4. Once a hardware independent watchdog is configured, it becomes effective from power-up and cannot be stopped unless the configuration parameters are changed again.
5. When the hardware independent watchdog is enabled, the LSI clock will be automatically enabled and cannot be turned off.

Sleep, Wake, and Servicing the Watchdog

In low-power devices, the MCU often spends most of its time in deep sleep to save power. In deep sleep mode, the watchdog continues to run.

Therefore, while in deep sleep the system still needs periodic wakeups to service the watchdog; after servicing, the device can return to sleep.

If using LPTIM as the wake source, the above considerations still apply, but the probability of issues may be lower.

Preserving State Across Watchdog Resets

A final approach is to partition RAM and allocate an IRAM2 region to store some status bits. Configure that region not to be initialized on startup so that data in IRAM2 is preserved across watchdog resets.

To place a variable in the IRAM2 partition, you can specify its address like this:

uint8_t myVariable __attribute__((at(0x20000FFC));

Recommendations for PY32F030

For the Puran PY32F030 MCU, if you plan to use the independent watchdog, pay attention to the following:

1. Prefer configuring and enabling the hardware watchdog at programming time.
2. Do not use the RTC as the wake source to service the watchdog.
3. Reserve an IRAM partition to preserve state across resets.

Final Notes

Some pitfalls are not apparent until encountered. Embedded application engineers may not be aware of potential chip design defects.

If a chip is significantly cheaper than alternatives, pay extra attention during evaluation to determine why it is so inexpensive and whether there are hidden issues. Even with time pressure, perform small pilot production runs before full-scale deployment.