Post History
Feeding the watchdog from an interrupt service routine is indeed a bad idea, usually. It depends on what you are really trying to protect against. The purpose of a hardware watchdog is usually to...
Answer
#1: Initial revision
Feeding the watchdog from an interrupt service routine is indeed a bad idea, usually. It depends on what you are really trying to protect against. The purpose of a hardware watchdog is usually to allow recovery if the processor stops doing what it's supposed to be doing. The question then becomes how do you measure "supposed to be doing". If you are only concerned about the processor itself no longer executing code due to a physical reason, like an ESD event, then feeding the dog from an interrupt routine is OK. However, there are other possible reasons the process can stop doing what it's supposed to be doing that this method won't catch. If the processor takes a bad jump someplace, it could be executing garbage foreground code, but interrupts might still run normally. If you have multiple tasks running, then a single task could be wedged, but the interrupt method won't detect that. By having only foreground code (as opposed to interrupt code) feeding the dog, more of the system has to be functional to not cause a hardware reset. In a cooperative multi-tasking system, you could have one task occasionally feed the dog. If that one task is running occasionally, then all tasks must be running occasionally. An even more robust system, necessary in pre-emptive multi-tasking, is for each task to set a flag occasionally but faster than you need to feed the dog. One task periodically checks the flags and only feeds the dog if all flags are set. Of course it resets the flags then, ready for the next interval.