WWDG vs IWDG in STM32: Why WWDG Is the Better Watchdog for Many Projects

After working on embedded systems over many years from 8-bit microcontrollers to today’s high-performance STM32 MCUs—one lesson remains constant: A system is only as reliable as its fault recovery strategy.

In critical or unattended systems, watchdog timers play a vital role. The STM32H5xx Window Watchdog (WWDG) helps monitor system health. It resets the system if the program does not update the counter in time. The program must refresh the counter before the T6 bit clears.

If you are not familiar with WWDG, I recommend reading my blog post on the Window Watchdog first. It will help you understand the basic concept clearly.

🧭 Why Choose WWDG Over IWDG?

Many junior engineers ask, “Why use WWDG when IWDG already exists?”

The key is control and precision. The IWDG lets you refresh the timer anytime, making it simple but forgiving.

WWDG, however, requires refreshing within a strict time window—not too early and not too late. Think of it as a watchdog with sharp teeth.

This precision helps detect issues like:

• Program hangs.
• Infinite loops.
• Logic mistakes.
• Timer jitter or RTOS starvation.

By enforcing this stricter timing, WWDG catches faults that IWDG might miss. Let’s understand it with a practical example from the field.

🛠️ Real time environmental monitoring system:

Suppose you are designing a solar-powered remote weather station using an STM32H5 microcontroller. The system is installed in a remote area—maybe a farm, a wildlife reserve, or on a mountaintop—where human access is limited.

This embedded system performs the following tasks at regular intervals:

• Measures temperature, humidity, and pressure using digital I²C/SPI sensors.
• Logs data to an external flash or EEPROM.
• Sends the collected data wirelessly via a LoRa transceiver.
• Enters low-power sleep mode between sampling intervals to conserve energy.

Power is precious. There’s no display, no user button, and no one nearby to press reset when things go wrong.

⚠️ The Challenge: Subtle Software Faults

Despite careful design, real-world embedded systems face issues that don’t necessarily cause a crash, but still break functionality:

1. Sensor Communication Stuck in Retry Loop:

Imagine the temperature sensor temporarily loses power due to a loose connector or a voltage dip. Your sensor driver has retry logic, but due to a logic bug, it enters an infinite loop trying to re-establish communication.

From the outside, the MCU is “alive”—the clock is running—but it’s stuck inside that loop.

2. LoRa Stack Freezes in Low-Power Transition:

Your LoRa radio uses a state machine to manage sleep and transmit modes. Under certain timing conditions—maybe during a voltage brownout—the stack enters a bad state where it neither transmits nor wakes up.

No assert is triggered. The MCU is still running. But the system is now silently failing to communicate.

3. Stack Corruption from ESD Event:

Let’s say a long ADC cable picks up an ESD spike from lightning nearby. The ESD pulse isn’t strong enough to damage the MCU, but it causes a bit flip in RAM—possibly in your RTOS scheduler’s stack.

The system doesn’t crash. It just starts behaving erratically or stops calling certain tasks, like your WDT refresh task.

🧨 Why IWDG Is Not Enough:

You might already be using the Independent Watchdog (IWDG). But here’s the problem:

In many implementations, the IWDG is refreshed blindly by the main loop or system tick. As long as the tick is running, the IWDG gets refreshed—even if the system is otherwise broken.

• So in the sensor retry loop case? IWDG still gets kicked.
• LoRa stuck state? IWDG still gets kicked.
• Scheduler starved? Maybe IWDG still gets kicked by a separate timer.

The system is technically alive but functionally dead.

🧩 Using the Window Watchdog (WWDG): A Smarter Approach

Here’s how the Window Watchdog (WWDG) offers a smarter and more deterministic solution:

• ✔️ Enforces Timing Constraints
  WWDG allows refreshing only within a defined time window. Refreshing too early or too late results in a reset. This prevents naive or blind refresh patterns.
• ✔️ Conditional Refreshing
  You can bind the watchdog refresh to specific system checks—like sensor read success, LoRa TX acknowledgment, or task execution milestones. If any one of them fails, the refresh is skipped, and the watchdog will reset the system.
• ✔️ Last Chance Interrupt (EWI)
  Before the reset, WWDG can trigger an early wakeup interrupt (EWI). This gives the system a final chance to log the fault, flush buffered data to non-volatile memory, or even try a graceful shutdown (e.g., send a “going down” LoRa message).

🧪 IWDG vs WWDG: What’s the Difference?

The table below highlights the major differences between the two watchdog (wwdg and iwdg) timers in STM32 microcontrollers: