In my last project the code runs a big loop and my watchdog, a MAX1232, is reset by toggling from high to low and low to high at different locations within the loop. So, to reset the watchdog, the entire loop has to be run through. Or by other words, when the micro is trapped in an erroneous local loop the micro gets reseted.

That's all sounding nice: "When the micro makes a mistake, then the watchdog guarantees, that it is getting reset." But that's not true in a non-negligible number of cases. We should ask: "WHY is the micro running ill at all?". If the watchdog becomes active because something is wrong with the circuit, means a chip failure or shielding mistake, then there's a big chance that the micro gets reseted over and over again, without that the customer might notice anything. The result can be a wrong measurement, for instance, because the micro is reseted during non-negligible periods of time, but the measurement might not be wrong enough to be detected by the customer.

So, using a watchdog makes only sense, if the customer is explicitely informed by the circuit, that the watchdog has become active and that a serious problem has occured!

Another point is, that system failures can occur, which cannot be cured by a simple reset, so that a "well performing" watchdog wouldn't be of any benefit for the customer! I remember an application in a weldering plant, where due to a grounding mistake the micro hang-up from time to time. The watchdog's reset pulses didn't show the desired result but the micro stayed in hang-up condition. Only a complete power-down would have been the proper cure in this situation.

So, using a watchdog makes only sense, if the micro is not only reseted but also completely powered-down and -up again for a brief period.

Kai