How would you design a watchdog strategy for firmware running several RTOS tasks?

What the interviewer wants to hear

• Hardware independent watchdog with its own clock
• Monitor task collects check-ins from each critical task
• Refresh only when all tasks are healthy
• Never kick from a timer ISR
• Record reset cause and context to diagnose watchdog resets

Model answer

I use the independent hardware watchdog, which runs from its own clock so it still works if the main clock fails, and I enable it early in boot. Each critical task sets a check-in bit or increments a counter every time it completes its loop. A monitor task, or a low-priority supervisor, checks that every task has checked in within its expected period, and only then refreshes the watchdog. If one task hangs or deadlocks, the refresh stops and the device resets. I never kick from a timer ISR, because interrupts often keep running when tasks are stuck. A window watchdog can also catch code that runs too fast or loops wrongly. After reset I read the reset cause register and save information such as which task missed its check-in to a no-init RAM area, so field watchdog resets can be diagnosed.

More medium Embedded Systems Engineer questions

• How would you write a driver for a new I2C temperature sensor?
• Explain the difference between a mutex and a semaphore in an RTOS, with examples.
• A device freezes randomly once every few days in the field. How do you debug it?
• Explain the memory layout of a typical microcontroller program: .text, .data, .bss, stack and heap.
• When would you use fixed-point arithmetic instead of floating point on a microcontroller?
• What is DMA, when would you use it, and what pitfalls do you watch for?
• Design firmware that receives text commands over UART, like "SET LED 1", and responds reliably.
• Explain how the CAN bus works and why it is popular in automotive and industrial systems.
• Your firmware is close to the flash and RAM limits of the MCU. How do you reduce memory usage?