In real-time embedded systems—especially in safety-critical applications like automotive, industrial automation, medical devices, and smart metering—reliable fault detection and recovery mechanisms are critical to maintain system stability and safety.
The Window Watchdog (WWDG), available in the STM32H5 series microcontrollers, plays a key role in this area. Unlike basic watchdog timers, the WWDG enforces precise timing constraints to detect both missed and premature refresh attempts—helping catch erratic behavior or stalled firmware early.
In this article, you’ll explore how the WWDG works, why it matters in safety- and reliability-focused applications, and how to implement it effectively in your STM32H5-based design using IAR Embedded Workbench.
What is Window Watchdog (WWDG)?
The Window Watchdog (WWDG) in STM32 microcontrollers helps detect software faults by monitoring the timing of refresh operations. To avoid a system reset, the application must refresh the watchdog within a specific time window. If it refreshes too early or too late, the WWDG triggers a reset.
Unlike the Independent Watchdog (IWDG), which only checks if a refresh happens, the WWDG enforces when it happens. This timing requirement adds extra protection against erratic or stuck code.
🎯WWDG main features:
- Uses the APB clock.
- Programmable free-running down-counter.
- Configurable time window for refresh operations
- Conditional reset
- Reset (if watchdog activated) when the down-counter value becomes lower than 0x40.
- Reset (if watchdog activated) if the down-counter is reloaded outside the window.
- Early wake-up interrupt (EWI):
🎯 Why is WWDG Used in STM32 Applications?
- To catch software faults, especially:
- Code stuck in loops
- Crashes or task starvation
- Unexpected early or delayed execution
- To detect jitter or scheduling issues in real-time systems
- To enable fail-safe behavior in safety-critical applications.
- Best suited for applications which require the watchdog to react within an accurate time window.
- To allow early warning interrupt (EWI) for graceful recovery before reset.
The extra window timing requirement makes WWDG ideal for fine-grained health monitoring in RTOS or timed-loop systems.
⏰ When is WWDG Triggered?
The Window Watchdog (WWDG) generates a system reset (or an early warning interrupt, if enabled) under the following conditions:
🔁 Reset Conditions:
- Too early refresh – If the application refreshes the watchdog counter before the allowed window opens.
- Missed refresh – If the application fails to refresh the watchdog before the window closes.
- Counter underflow – If the down-counter reaches 0x3F, the minimum possible value.
⚠️ Early Warning Interrupt (EWI):
If EWI is enabled and the counter reaches the early warning threshold, the WWDG triggers an interrupt before resetting the system. This gives the application a final opportunity to log errors or perform safe shutdown operations.
📌 Example:
Let’s say the refresh window is defined between 0x7F (max) and 0x50 (min).
The Window Watchdog (WWDG) is a down-counter, which means it starts from a set value (e.g., 0x7F) and counts down toward 0x3F (the lowest possible value). Your application is only allowed to refresh the watchdog after the counter has dropped below the upper window value (0x7F) and before it drops below the lower limit (0x50).
⚠️ What Triggers a Reset?
- ⛔ Too early: If you refresh the watchdog while the counter is still above 0x50, it means you’re refreshing too early, and the system will reset.
- ⛔ Too late: If the counter drops below 0x3F (minimum), and you haven’t refreshed it, the watchdog will timeout and trigger a reset.
- ✅ Correct window: You must refresh after the counter passes 0x50, but before it hits 0x3F.
So in this case, the valid refresh window is: between 0x50 and 0x3F (not 0x7F to 0x50 as initially stated).
🛠️ Summary:
| Counter Value | Result |
|---|---|
| > 0x50 | Refresh too early → ❌ Reset |
| 0x50 to 0x40 | Valid refresh window → ✅ OK |
| < 0x40 | Missed refresh → ❌ Reset |
How does it work?
As we know the Window Watchdog (WWDG) in STM32 microcontrollers is designed to monitor software execution and reset the system if it becomes unresponsive or behaves unexpectedly. Let’s understand how it works including the setup steps.
1. Clock Source:
- The watchdog uses APB clock.
- The clock source is divided by 4096 and then scaled again using the WDGTB prescaler.
- WDG Prescaler (WDGTB) further divides ((DIV1/2/4/8)) the clock to control how fast the 7-bit counter decrements.
2. Down counter:
It uses a 7-bit down-counter (T[6:0]), starting from a maximum value of 0x7F and counting down to 0x3F. If the counter reaches 0x3F (down-counter value becomes lower than 0x40), a system reset is triggered.
T[6:0] CNT DownCounter:
- A 7-bit counter that counts down automatically.
- It starts from a high value (e.g., 0x7F) and counts down towards 0x3F.
3. Window Value:
The window value in the Window Watchdog (WWDG) defines the earliest point at which the watchdog can be safely refreshed. It sets the upper limit of the refresh window.
Window Register W[6:0]:
- Sets the upper limit of the refresh window.
- Refreshing the watchdog only allowed when
T[6:0] <= W[6:0] and > 0x3F.
4. Reset Triggers:
To prevent a system reset, the application must periodically refresh the Window Watchdog (WWDG) within the valid refresh window. If the watchdog is not refreshed correctly or on time, it will trigger a system reset.
🔁 A reset will occur in the following situations:
- If you refresh too early (T[6:0] > W[6:0]) → 🔥 Reset
- If you don’t refresh in time, and it rolls over from 0x40 to 0x3F → 🔥 Reset
- If T6 becomes 0 → 🔥 Reset
Summary:
| Counter Value | Action |
|---|---|
counter > window |
❌ Too early → Reset |
0x40 <= counter <= window |
✅ Valid refresh |
counter < 0x40 |
❌ Too late → Reset |
⏱️ Calculating the counter and window Value:
🕒 WWDG Timeout Formula:
tWWDG = tPCLK × 4096 × 2WDGTB[2:0] × (T[5:0] + 1)
You can simply also use the,
tWWDG = tPCLK × 4096 × 2WDGTB[2:0] × (0x7F-0x3F)
🕒 WWDG Window Value Formula:
window(W[6:0]) = 0x7F - (tWWDG/ (tPCLK × 4096 × 2WDGTB[2:0]))
📘 Where:
| Term | Meaning |
|---|---|
t_WWDG |
Desired timeout in milliseconds |
t_window |
Minimum time before WWDG can be refreshed (in ms) |
WDGTB[2:0] |
Prescaler bits 0-7 |
tPCLK |
APB clock period in milliseconds → tPCLK = 1 / fPCLK × 1000 |
4096 |
Internal divider in WWDG |
0x3F |
Base offset because counter counts from T+1 to 0x3F (63) |
0x7F |
Max Count value |
🟡 Ensure:
- windowValue ≤ 0x7F
- windowValue ≥ 0x40
5. Early Wakeup Interrupt (EWI):
You can optionally enable the Early Wakeup Interrupt (EWI) feature. When enabled, the WWDG triggers an interrupt just before the counter reaches 0x3F—giving your application a chance to:
- Save diagnostic logs
- Set an error flag
- Attempt recovery before a forced reset
Note: Triggered at 0x40 to warn the software before a reset.
🔐 Best Practices for Reliable Watchdog Implementation:
In this section, we cover industry-proven best practices and highlight common pitfalls (bugs and misunderstandings) developers face while implementing WWDG specially in STM32.
1. Enable Watchdog Early:
Enable the watchdog right after completing the essential system initialization.
2. Avoid Refreshing Inside Interrupts:
Refreshing the watchdog timer from within Interrupt Service Routines (ISRs) can hide faults in the main application. If the main loop or scheduler crashes or becomes unresponsive, ISRs may continue to execute and refresh the watchdog, preventing it from detecting the problem.
So best practice is to always refresh the watchdog timer in the main loop or in a dedicated health-monitoring task. This ensures that the watchdog only resets if the main application is running correctly.
3. Refresh Within the Allowed Window (WWDG Only)
WWDG requires the counter to be refreshed only when T[6:0] is between 0x40 and W[6:0]. Refreshing too early or too late causes a system reset. Use caution when calculating timing, especially with variable system clocks.
4. Use Early Wakeup Interrupt (EWI):
The early wakeup interrupt triggers when the counter reaches 0x40, providing a chance to log fault information or take preventive action before a reset. Use this to implement graceful recovery or last-moment state saving.
5. Log Reset Causes:
When the system starts up, check the reset flags (like __HAL_RCC_GET_FLAG(RCC_FLAG_WWDGRST)) to see why the system restarted. Save this info to non-volatile memory (like flash or EEPROM). It can help you understand if the watchdog caused the reset or if something else went wrong.
6. Disable Watchdog During Debugging (Optional):
Use the debug freeze feature to prevent unwanted resets when stepping through code. For WWDG:
DBGMCU->APB1FZR1 |= DBGMCU_APB1FZR1_DBG_WWDG_STOP;
7. Select Timeout and Prescaler Carefully:
Configure the timeout based on your system’s timing requirements. For WWDG, use the formula:
tWWDG = tPCLK × 4096 × 2^WDGTB × (T[5:0] + 1)
Make sure the window and counter values are properly calculated to avoid accidental resets.
8. Intentionally Test Watchdog Behavior:
Remove or delay the refresh call during development to ensure the system resets as expected. Also test edge cases like refreshing too early to validate WWDG behavior.
8. Test Watchdog Under Fault Conditions:
Don’t assume your watchdog works—test it. Introduce controlled faults:
- Remove refresh temporarily.
- Delay task execution.
- Simulate CPU lock.
Make sure the system resets and recovers correctly.
9. Use IWDG in Low-Power Modes
WWDG doesn’t operate in STOP or STANDBY modes. If watchdog protection is required during deep sleep, use the Independent Watchdog (IWDG) instead.
10. Known Issues and Common Mistakes:
| Issue | Description | Recommendation |
|---|---|---|
| EWIF flag set before enabling WWDG | On some STM32 devices, EWIF is already set before enabling the watchdog. | Always clear EWIF using __HAL_WWDG_CLEAR_FLAG() before enabling WWDG. |
| Immediate reset due to T6 = 0 | Writing a value to WWDG_CR with T6 = 0 (MSB cleared) causes an instant reset. | Always ensure T6 = 1 by setting values >= 0x40. |
| Accessing WWDG without enabling its clock | Results in bus faults or undefined behavior. | Call __HAL_RCC_WWDG_CLK_ENABLE() before any access. |
| Reset on early refresh (T > W) | Refreshing the counter while CNT > W[6:0] triggers an early reset. | Only refresh when 0x3F < CNT ≤ W[6:0]. Monitor counter if needed. |
| EWI not triggering | Developers forget to enable NVIC or clear pending flags. | Enable WWDG_IRQn in NVIC and clear EWIF before enabling EWI. |
| Watchdog not frozen in debug mode | Causes resets during breakpoints or code step-through. | Use DBGMCU_APB1FZR1_DBG_WWDG_STOP to freeze the watchdog in debug. |
| WWDG assumed to work in STOP mode | WWDG doesn’t function in low-power STOP/STANDBY modes. | Use IWDG for watchdog functionality in those modes. |
🔧 Application Benefits:
The Window Watchdog (WWDG) is ideal for applications that require precise fault detection within a defined time window. Its flexible configuration and advanced features make it well-suited for safety-critical and time-sensitive systems.
Key Benefits:
- ✅ Accurate timing control – Ensures the watchdog reacts only within a valid time window, helping catch both delayed and premature refreshes.
- 🔧 Configurable timeout range – Adjustable through the prescaler. For example, the STM32L476xx series supports timeouts from 51.2 µs to 28.2 ms.
- 🚀 Flexible startup options – You can choose between hardware or software-controlled watchdog activation.
- ⏰ Early Wakeup Interrupt (EWI) – Alerts the system just before a reset occurs, allowing time for diagnostics or state saving.