??? 12/20/09 04:34 Read: times |
#171789 - it's not just for debugging ... Responding to: ???'s previous message |
However, one should construct a diagnostic circuit that does help with debugging if one finds that the watchdog times out more than once, say, every 100k power cycles in normal operation. Now, that's way too many to test for, unless one has a really critical application, e.g. life-support, or the like, and a correspondingly large budget.
Investigating watchdog-based timeouts requires that the watchdog has the means to signal that the last reset occurred due to watchdog timeout, else the information is lost. Some MCU's have that facility to support their built-in watchdog. That, in fact, is why genuine testing, i.e. long-term burn-in, etc. is important in applications more important than, say, toys, where a watchdog would be totally superfluous. I know of no diagnostic tool that one can buy, to plug into one's application and divine out what's causing failures. Fault isolation is a tricky business requiring considerable patience as well as considerable resources. If you haven't got a deep-sampling (e.g. 2MByte/channel) logic analyzer, you may be out of luck, depending on how your instrument is triggered. With some internally generated signal indicating a reset has occurred, to tell you that it's happened, for those cases wherein an externally driven reset is not detected, i.e. the MCU doesn't actually drive RESET when its watchdog times out, or some such, a storage 'scope might just not be enough without exactly that sort of signal. There are things that can cause internally-initiated-reset, not all of which are related to brownouts or other power-related matters. Runaway code is perhaps the most common, and very difficult to detect with internal code space. However, if there's a means of detecting internally-generated-reset, then that's a signal that code needs to be subjected to thorough simulation, and careful inspection. Interrupt signals need to be properly conditioned, too. It wouldn't surprise me to find that a stack overflow caused a watchdog timeout, as it could easily cause code to wander off into the weeds. No, I don't think the watchdog helps much with the actual debugging, particularly since it's often turned off, but it does tell you that you're not through debugging. RE |
Topic | Author | Date |
Micro D.I.I. Reset question | 01/01/70 00:00 | |
if the wind blows from the west | 01/01/70 00:00 | |
Monostable multivibrator or watchdog | 01/01/70 00:00 | |
the problem with watchdogs | 01/01/70 00:00 | |
Watchdogs are useful even if they don't help with debugging | 01/01/70 00:00 | |
it's not just for debugging ... | 01/01/70 00:00 | |
Oh yes it can! | 01/01/70 00:00 | |
It's not as widespread as I'd hoped | 01/01/70 00:00 | |
the best I have seen | 01/01/70 00:00 | |
watchdog interrupt | 01/01/70 00:00 | |
That would help, but not in production![]() | 01/01/70 00:00 |