STM32 Indepentent Watchdog

There is no such thing as perfect code—software that accounts for every possible scenario and never fails simply does not exist. Even the most experienced firmware developers make mistakes, and in complex systems, those mistakes can have serious consequences. A famous example is Ariane 5, a half-billion-dollar rocket that was destroyed due to a software stack overflow. And you are no exception.

From time to time, bugs will slip into your code and escalate to the point where the system—whether a robot, device, or controller—hangs in an undefined or unrecoverable state.

While unit tests and static analysis tools are essential for identifying these issues early, they are not enough on their own. Your system must also be able to recover from failures. Without a reliable recovery mechanism, a single software error can lead to complete system failure or even irreparable damage.

STM32 microcontrollers address this need with a peripheral called the Independent Watchdog (IWDG). If the firmware hangs or enters a fault state, the watchdog automatically resets the MCU. Because it operates independently of the main system clock and software execution, your code cannot interfere with its operation, making it a robust, last-line defense for system reliability.

In this article, I explain the operating principle of the independent watchdog in STM32 MCUs and develop simple code to demonstrate its use. For the MCU, I will use the NUCLEO-l476, but this content applies to any STM32 MCU. 

STM32 Independent Watchdog Operating Principle

First, let's look at the clock tree ot the typical STM32 MCUs. The watchdog (IWDG) runs on a separate extremely low-power clock. It implies that if the main clock fails, it can continue running and reset the system, and that IWDG has minimal impact on the STM32 MCU's power consumption. 

Next, we can look at the block diagram of the independent watchdog. The first thing we notice is the prescaler. It is possible to downgrade the input clock frequency. With each clock click, the downcounter value is decremented, with its initial value governed by the reload register. When the downcounter hits zero, the watchdog automatically resets the microcontroller. To avoid that, it is essential to refresh the watchdog, which sets the downcounter value back to the reload value. 

Think of the independent watchdog as a bomb with a timer. Before the timer hits zero, you have to reset the timer (writing to the key register). This action sets the timer to the default value, but the clock continues to decrement, meaning you have to always be alert to press the button. If you forget to press the button in time, the timer reaches zero, and the bomb will explode (the watchdog will reset the MCU).

 The next logical question is how this mechanism helps the STM32 MCU to recover. The answer is very simple. In your code, you must periodically reset the watchdog's downcounter. If your code hangs or terminates in the fault state, it cannot reset the downcounter value, and after some time, the watchdog will reset the MCU. This time delay is adjusted by the prescaler and reload value. 

STM32 Independent Watchdog Implementation

Finally, let's write some code to implement the independent watchdog. First, we create a new project and open the STM32CubeMx Graphical tool to configure the watchdog. If you are a complete newbie in this regard, check out my STM32 Programming Course for beginners:

STM32 Programming Course for Beginners

Within System Core, press on IWDG. Tick the box to activate. I set the prescaler to 32, so the clock will run at 1 kHz (32 kHz / 32 = 1000). I will set the reload value to 1000, meaning that the downcounter value hits zero in 1 sec. Within our code, we have 1 second to refresh the watchdog counter. We keep the default Window Value. 

Generate the code, and we can see a new function, MX_IWDG_Init, to initialize the watchdog:

To test our code, I will call the HAL_IWDG_Refresh function within a while loop every 900 msec. 

Let's flash the code by pressing the debug button. When we run the code, nothing interesting happens, and it continues to function. But if we set a longer delay, let's say 1100 msec, the MCU will reset automatically, and the IDE will lose connection with the MCU. Why is it happening? Because the MCU has to refresh the watchdog within a second. Otherwise, it will reset the MCU, which is exactly what happened when we set a 1100 msec delay.

In real code, where can we refresh the watchdog? Usually, within periodic interrupts and tasks. For example, if the microcontroller receives data packets at regular intervals, we can add a line to refresh the watchdog in the interrupt handler for data reception. In cases when the data reception fails - cable removed or wireless communication lost - the watch automatically resets the MCU, and we avoid serious negative consequences that can arise from the loss of communication with the MCU.  

It can also be a lifesaver in robotic applications. If the firmware fails, the watchdog will reset the MCU to avoid damage to motors and other critical components. 

Hope the concept behind an independent watchdog is clear and that you have all the knowledge to implement it in your code. If you have any questions, do not hesitate to write me.