You should kick it only from code whose execution proves the system is actually healthy, typically the main loop, ideally gated on flags confirming that each critical task ran this cycle. The classic mistake is kicking from a free-running periodic timer ISR. That ISR will keep firing and kicking the watchdog on its own schedule even if the main application has completely deadlocked, so the watchdog sees a "live" system and never resets, you've silently disabled your safety net. The whole value of the watchdog is that it resets when real work stops happening, so you must tie the kick to evidence of real progress: have each subsystem set an "I ran" flag, and kick only when all required flags are set, then clear them. Kicking from an interrupt that runs regardless of application health is worse than no watchdog, because it gives false confidence.
Embedded Systems Fundamentals · Interview question
Where in your code should you kick the watchdog, and what's the common mistake?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
The Watchdog Timer
The hardware that resets a hung MCU: a countdown timer firmware must periodically kick, why you kick only from healthy code, and the window-watchdog twist.
More The Watchdog Timer questions
What is a watchdog timer and what problem does it solve?What's the difference between an independent watchdog and a window watchdog?How do you choose the watchdog timeout, and what goes wrong at the extremes?Why does your chip keep resetting when you pause at a breakpoint, and how do you handle long legitimate operations?
Browse all 472 interview questions