Independent watchdog (IWDG) or Window watchdog (WWDG)?
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).
The text you pasted into the question gives the answers you need.
- 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.
- 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.
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.