Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A Is Feeding a Watchdog Timer from an ISR a Bad Practice?

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...

posted 1d ago by Olin Lathrop‭

Answer
#1: Initial revision by user avatar Olin Lathrop‭ · 2024-12-17T15:18:27Z (1 day ago)
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.