Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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


List of 11 messages in thread
TopicAuthorDate
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      

Back to Subject List