Embedded Systems Fundamentals · Interview question

Where in your code should you kick the watchdog, and what's the common mistake?

A strong answer

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.

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

Browse all 472 interview questions
Where in your code should you kick the watchdog, and what's the common mistake? | EmbeddedPrep.io