IWDG vs WWDG on STM32: which one you actually use in production, and how do you feed it?
Karthikeyan S@karthik_embedded
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 loop at 1 kHz, must reset within ~100 ms if the control loop dies, field units have no debugger obviously, and we must know afterwards that it was a watchdog reset.
What do you do? IWDG, WWDG, both? Which task kicks it?
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.
Get the best of #bare_metal weekly
One email each Monday with the most useful posts. No spam; unsubscribe in one click.
Comments
Sign in to join the conversation.
Sign in to commentAccepted answer
Mehmet Aydoğan@malloc_mehmet
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.
Karthikeyan S@karthik_embedded
Mehmet, this is exactly the answer I wanted. Check-in word is going in this sprint. And the LSI range, I calculated with 32 kHz typical. Our "100 ms" could be 68 ms on a fast chip. Thank you.
Matthias Kühn@m_kuehn
In automotive the internal watchdogs are not considered independent enough. We use an external windowed watchdog, usually inside the system basis chip, with a question and answer protocol. For a pump controller that is probably too much. The check-in pattern above is the important part.
Diego Ramírez@diego_firmware
+1 to the flags pattern. Also small thing that bites everybody: the IWDG keeps running when the debugger halts the core, so you sit on a breakpoint and the chip resets under you. Set the freeze bit in DBGMCU (DBG_IWDG_STOP) in debug builds only.
Leo Chen 陈立@szhw_leo
Also put the reset reason in the Modbus registers, then service tool can read it without opening the panel. We do this for every board.
Karthikeyan S@karthik_embedded
Leo, reset reason over Modbus, very good idea. Our service guys will love me for one week.