I've tried using the avr watchdog timer in the Arduino environment but it doesn't seem to catch everything I expected. I have the wdt_reset() in loop() and wdt_enable(WDTO_2S) in setup(). So if I call a function and put in an intentional delay I can trip the watchdog easily. But if I create a memory corruption like the stack meeting the heap it doesn't seem to catch it. I'm thinking I need an external hardware watchdog. I'm already using an RTC and I think some come with a watchdog feature so that might be an easy fix. Any thoughts? Thanks.

 

The watchdog is there to catch endless loops in the code. Not memory corruption.

As long as the code continues to hit the wdt_reset statement the watchdog will never fire, no matter how senseless the performance is.

 

That's what I figured. In my application I'm turning a pump on and off based on certain conditions. I don't it want it to ever be stuck open because of any problem. But clearly if the wdt_reset is still being hit in loop() after a memory corruption then a hardware watchdog won't do much for me.

 

I'm turning a pump on and off based on certain conditions. I don't it want it to ever be stuck open because of any problem.

Can you use an external watchdog circuit that shuts the pump off if it's been on longer than a given maximum?

 

It turns on because one set of conditions are met and turns off because of another. But, you've got me thinking. It might be possible to set a maximum time limit anyway. Turn the pump off then let the original condition turn the pump back on. In practice it won't be that simple. Still, I could toggle an output pin that would trigger an external watchdog when the limit is reset. Will discuss with client, but it will have to wait for the next rev of the board anyway. Thanks.

 

As long as the code continues to hit the wdt_reset statement the watchdog will never fire, no matter how senseless the performance is.

Yeah.. you never want to reset the WDT in a loop that may not exit depending on other things happening. If your code is such that it can come back to the beginning of the main loop, that's the place to reset the WDT. If the code below has long delays though you may be sunk. If that is the case, consider setting the WDT time to some big value to accommodate the delays. A better way would be to break up the delays in your code to get to the top of the main loop often enough to support the WDT. Keep in mind that even if you are forced to use an external WDT with a longer time to accommodate your code as is, you still have to be sure that you only reset it at a point in the code where you know that everything is running.

I use timers instead of delays to perform task timing so that the code runs round and round fast enough to support a reasonably short WDT. Before resetting the dog, the code runs a quick sanity check looking for things like stack creep, interrupts still enabled, IO configuration etc. Only when all is right is the dog reset. My point of reference is PIC but you can try to do some of that in Arduino too but we would need some code to see if any of that would do for you.

Just my .02