IWDG vs WWDG on STM32: which one you actually use in production, and how do you feed it?
Discussion in our team this week, I want outside opinions. Today: IWDG only, ~100 ms timeout, kicked from a low priority FreeRTOS task. Colleague says this is useless, because a stuck high priority task will block the low priority one and we reset, fine, but a runaway loop that still lets the kicking task run will never reset. He wants WWDG with a window, so kicking too early also resets. Constraints: motor control…
Accepted answer
IWDG as the last line, always. It runs from LSI, its own clock. If your clock tree dies, PLL unlock, HSE crystal cracked, WWDG dies with it because it runs from APB clock. IWDG still resets you. Never kick from an ISR or a timer callback. Never kick from "the idle task" either. Do this: every critical task sets its own bit in a check-in word each cycle. One supervisor task, priority just below MotorControl, wakes every 20 ms, checks that ALL bits are set, clears them, then kicks IWDG. If any task did not check in, no kick, reset. Runaway loop in one task = its bit not set = reset. This catches what your colleague is worried about without WWDG. LSI is not accurate. On F4 the datasheet range is wide, something like 17 to 47 kHz. Calculate your timeout at the fast end, not the typical. At boot, read RCC_CSR reset flags (IWDGRSTF, WWDGRSTF, BORRSTF, PINRSTF...), store them, then clear with RMVF. Log it. Otherwise you will never know the watchdog fired, you will only know "it restarted sometimes". WWDG on top is fine if you want early-kick detection, but it is not independent. Do the check-in word first.