Does the IWDG window value cause a reset if the watchdog is refreshed too often on STM32G473?

[JohnFrancis]

I’m working with an STM32G473QETx.

Does the IWDG window value cause the MCU to reset if the watchdog is refreshed too often (i.e., refreshed too early)?

if I set the IWDG window value to something smaller (e.g., 1600), will the MCU reset if I refresh the watchdog more frequently than expected?

Any clarification on how the IWDG window works on the STM32G4 series would be appreciated.

[TDK]

No, the IWDG doesn’t have a window, just refresh it before it hits 0 and it won’t reset. Reset it as often as you like.

[waclawek.jan · Accepted solution]

@TDK,

the newer STM32 - including 'G4 - have window option in the IWDG. And then if IWDG_WINR is set to a value lower than IWDG_RLR, it can cause reset if the watchdog is refreshed too soon after previous refresh.

JW

[JohnFrancis]

Thank you for your reply. Suppose I don’t need to use the IWDG window option — what value should I set? I configured the IWDG timeout to 1.5 seconds by using a prescaler of 32 and a reload value of 1600 based on my clock frequency. The IWDG window value must be between 0 and 4095. Which value should I set to effectively disable the window option?

[TDK]

Thanks for the correction Jan, always learning. So they turned the IWDG into a WWDG but didn’t change the name. Odd choice. Suppose the clock is still independent so maybe it should be called IWWDG.

[Chris21]

[waclawek.jan]

@JohnFrancis 

> . Which value should I set to effectively disable the window option?

Anything higher than (or equal to) the reload value.

As said in the description quoted by @Chris21 above, leaving IWDG_WINR at its default 0xFFF is sufficient.

@TDK,

I guess this is result of some regulatory (as in "safety" standards) pressure, as you've said, probably combination of "independent" clock (LSI) and windowed operation was required, and this was the path of least resistance.

[rant mode on] As feature size decreases (with yet to be seen consequences on longevity and manufacturability/fab diversity), feature creep apparently affects probably all traditional STM32 IP modules. For may years ST stubbornly ignores requests of users for proper versioning and documentation of these changes (one of the rare exceptions being RTCv2 vs. RTCv3 description in AN4759), as obviously the official ST policy are handwaves towards clicking in CubeMX and relying on the Cubes/HALs to provide the migration path.

JW