> "When my program blows up randomly, the first thing I look for is..."

There is no easy answer to that.  If you have no idea what causes the
symptom, you probably need to work backwards.  Wait until it "crashes" and
look carefully at all the state.  Something will probably be amiss.  At
the very least it will not be responding properly to a new input.  You can
give it a new input and see why it handles it improperly.  At that point
*something* must be identifiably wrong.  Hopefully you can find a way to
set a break on the illegal condition and start working backwards.  If
you're lucky you can see what went wrong in the trace buffer right before
the illegal condition was caught.  Otherwise you may have to look back to
find an earlier illegal condition to trigger on and repeat the process.

Note that this kind of debugging is the last resort.  Pouring thru trace
buffer listings is tedious and slow, and is worth a great many Good
Programming Practises to avoid.

If you are using interrupts, step thru the interrupt routine carefully
even if you think its working right.  It might be trashing some state of
overflowing the stack, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads