Independent watchdog (IWDG) or Window watchdog (WWDG)?

Question

I'm still searching to find an answer for this question:

Since the STM32 MCUs already have a perfect watchdog (I mean the Window watchdog (WWDG)), why is there also a simple watchdog (Independent watchdog (IWDG)) ?

I found this page that has said:

ST Microelectronics has a line of Cortex-M3 devices. The M3 has become extremely popular for lower-end embedded devices, and ST's STM32F is representative of these parts (though the WDT is an ST add-on, and does not necessarily mirror other vendors' implementations). The STM32F has two different protection mechanisms. An "Independent Watchdog" is a pretty vanilla design that has little going for it other than ease of use. But their Window Watchdog offers more robust protection. When a countdown timer expires, a reset is generated, which can be impeded by reloading the timer. Nothing special there. But if the reload happens too quickly, the system will also reset. In this case "too quickly" is determined by a value one programs into a control register.

Another cool feature: it can generate an interrupt just before resetting. Write a bit of code to snag the interrupt and you can take some action to, for instance, put the system in a safe state or to snapshot data for debugging purposes. ST suggests using the ISR to reload the watchdog -- that is, kick the dog so a reset does not occur. Don't take their advice. If the program crashes the interrupt handlers may very well continue to function normally. And using an ISR to reload the WDT invalidates the entire reason for a window watchdog.

and this:

STMicroelectronics' new series of STM32F4 Cortex™-M4 CPUs has two independent watchdogs. One runs from its own internal RC oscillator. That means that all kinds of things can collapse in the CPU and the WDT will still fire. There is also a “window watchdog” (WWDT) which requires the code to tickle it frequently, but not too often. This is a very effective way to insure crashed code that randomly writes to the protection mechanism does not cause a WDT tickle, and the WWDT can generate an interrupt shortly before reset is asserted.

Now let's take a look at the reference manual:

The STM32F10xxx have two embedded watchdog peripherals which offer a combination of high safety level, timing accuracy and flexibility of use. Both watchdog peripherals (Independent and Window) serve to detect and resolve malfunctions due to software failure, and to trigger system reset or an interrupt (window watchdog only) when the counter reaches a given timeout value. The independent watchdog (IWDG) is clocked by its own dedicated low-speed clock (LSI) and thus stays active even if the main clock fails. The window watchdog (WWDG) clock is prescaled from the APB1 clock and has a configurable time-window that can be programmed to detect abnormally late or early application behavior. The IWDG is best suited to applications which require the watchdog to run as a totally independent process outside the main application, but have lower timing accuracy constraints. The WWDG is best suited to applications which require the watchdog to react within an accurate timing window.

The window watchdog is used to detect the occurrence of a software fault, usually generated by external interference or by unforeseen logical conditions, which causes the application program to abandon its normal sequence. The watchdog circuit generates an MCU reset on expiry of a programmed time period, unless the program refreshes the contents of the downcounter before the T6 bit becomes cleared. An MCU reset is also generated if the 7-bit downcounter value (in the control register) is refreshed before the downcounter has reached the window register value. This implies that the counter must be refreshed in a limited window.

As you can see, none of them have explained Why there are two watchdogs. if I ask, "What are the differences between the two watchdogs?", then you will count all of the features that you can see in the above excerpts, and compare them both, coming to the obvious conclusion that the Window watchdog (WWDG) is the winner! So, then, Why there are two watchdogs?

I want to know... When should I use the IWDG? ...And when should I use the WWDG?

Finally, why do they call the second watchdog a "Window watchdog"?

Answer 1

Regular watchdog timers must be reset at some time before they time out. If you have a 100ms WDT you can reset it every 99.9ms or every 10us and it will never time out.

Window watchdog timers have a time window within which they must be reset. If you reset it too early or too late (from the previous reset) it will cause the processor to reset.

The purpose, if it is not obvious, is to help ensure that the code resetting the WDT is the intended code, operating in the intended fashion. Some kind of unforeseen condition that generates high-frequency WDT resets won't prevent the system from being reset.

Running a WDT from the system clock could be a bit of an issue- if the clock fails and if there is not an independent clock monitor circuit, bad things can happen. The independent clock for the WDT means that if the thing for some reason started running at 1/10 speed, the WDT would reset (but the window WDT would not).

Use both if you can.

As the page says, resetting the WDT with an ISR is generally bad juju (but may be acceptable if the ISR verifies the reset of the firmware is functioning before resetting the timer).

Answer 2

The text you pasted into the question gives the answers you need.

1. You use IWDG when you need a simple watchdog or when you need a completely independent watchdog - IWDG has its own clock, WWDG derives its clock from one of the bus clocks - if it fails or your software shuts it off then the watchdog dies.
2. You use WWDG when you need a watchdog that can only be reset within a certain timespan (window.) If your software resets the WWDG too late, then the WWDG will trip a reset of the processor. If your software resets the WWDG too EARLY then it will also cause a reset of the processor.

It is called a "window watchdog" for the simple reason that only a watchdog reset during a specified time period (window of opportunity) will prevent the watchdog from resetting your processor.

Both do similar jobs, but they do them differently. Which you need depends on the requirements you have to meet.

Answer 3

There is another reason for using the window watchdog, either instead or or in addition to the independent watchdog. WWDG has an interrupt you can hook. This means that, if code has got into a loop or fugue, you can set a breakpoint in the WWDG ISR, and work backwards to find out what the firmware was doing when the dog barked.

You cannot do this with IWDG. As the name suggests, that's independent of the processor. Rather than raising an interrupt, it simply asserts and deasserts /RESET - which doesn't give you many clues as to why it barked. I'd strongly suggest setting a WWDG within your normal operating parameters, plus an IWDG at a much longer period, perhaps 2* WWDG maximum. Create a kick-dog function that kicks both. This way, the IWDG only barks when the WWDG locks out too, as a final backup.

Answer 4

My take on it:

Use both at the same time, because they look for different failed conditions:

The Independent Watchdog (IWDG) timer needs to be reset continually before it times out. In practice you can just add the reset code everywhere you have a valid program state, or once in the main loop if you have a main loop that's supposed to execute frequently without any major delays. This way, if your call to reset the timer (this is sometimes called "petting", "tickling, or simply "resetting" "the watch dog") doesn't occur in time, it means your code either A) accidentally got stuck somewhere you didn't foresee---some sort of unforeseen infinite loop type state, or B) intentionally got stuck somewhere you enforced via an assert() function call with an embedded infinite loop that you want the code to go to whenever some important condition is not true. So, now that your assert condition is false, your code intentionally gets stuck in an infinite loop, and the watchdog resets the microcontroller to get it back to a valid state. Note also that "the independent watchdog (IWDG) is clocked by its own dedicated low-speed clock (LSI) and thus stays active even if the main clock fails" (see ST RM0008 Reference Manual p493).

It seems to me however that the Window Watchdog (WWDG) timer is designed to look not for the cases described above (where your code either unintentionally or intentionally [via an assert] gets "stuck" somewhere), but more specifically for the case where A) your code does NOT execute something it should. In other words, it has a fault that causes its main loop or other subsection of code to execute too quickly (or to be skipped entirely), so you reset the watchdog too soon, outside its window, and the mcu gets reset. Or, B) the other condition it can spot is a failed timer setup. Perhaps you are resetting it at a fixed interval, but your timer used to create this interval either gets its configurations accidentally changed somewhere it shouldn't have, or you misconfigure it in the first place, then the time interval will be off, your fixed time interval reset will reset the WWDG outside its window (either too soon or too late), and the mcu gets reset to notify you and/or fix the condition.

This is my take on it. Thoughts or feedback are welcome.

Answer 5

"windowed" watchdog is just a regular watchdog that protects some how for even worse programming practices. Like others said, you have a "time frame" usually adjustable where your "feed" should be supplied.

None of them are bullet proof if your code can enter in a automatically sustained loop. Eg. If you plan to "feed" based on timer related IRQs, this can be extremely bad practice since your code can stuck in some do/while in the mail thread, while interrupts can still feed your WWDT in correct sequence.

Actually, you can use interrupts to feed WWDT if you can lower your IRQ priority under normal execution code like you can do on MIPS (Microchip).

If your code is life support, critical, etc., just drop all of them and use external WDT (Q&A based preferable).