[En-Nut-Discussion] Watchdog Debugging

[Bernard Fouché]

Nathan Moore wrote:
>
> Just keep in mind that if a hang-up happens within an ISR or critical
> section
> this method won't catch it.
>   
Sure, this is not a perfect solution, it's just a tool among others that 
can help in some situations.

I've also tried other ways, for instance by storing into into RAM not 
just a few bytes but a circular buffer with some debug info, to be able 
to retrieve an history of the events that made the whole system fails 
because sometimes it is not a particular function that is broken, the 
flaw being in the way a chain of events is handled.

Also one has to keep in mind that  things that first appear as being a 
hardware watchdog reset may be related to brown out detection (or any 
other hardware related origin) and before spending time digging into the 
software, one must be sure that the hardware is totally clean. (Some MCU 
allows one to know the previous reset origin)

There are also situations where the hardware watchdog fires because some 
processing is too long by a very little bit, or because processing 
depends on events external to the MCU, and changing the application 
timing with debug features makes the problem disappear or happen 
earlier. (sometimes a very difficult case to fix)

At last using a versioning system like CVS or SVN may help a lot: if you 
are serious in your commit/comment policy, you have a big advantage when 
bizarre things start to show up in a project that was previously working 
correctly. (In my experience this is one of the most efficient debug 
tool whatever the kind of the bug being chased)

So I think that there is no miracle solution that handles all possible 
cases but a set of tools/habits/experience to choose from.

  Bernard