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

Lots of redundancies with other replies but -

- ENSURE that watchdog is either disabled or being properly reset always.
Starting with watchdog disabled is advisable. I have seen a whole product
run correctly but sluggishly with the watchdog resetting it regularly and
unintendedly.

- In processors which have a user settable stack pointer, set the stack
pointer at the earliest possible point in the code. (This is USUALLY the
first instruction - some processors demand some other action as the first
instruction).

- ENSURE that max available stack depth for interrupts / subroutines is
NEVER exceeded. (The depth may vary with circumstance. If you have IRQs and
Interrupts you may sometimes (fatally) overflow stack area when IRQ occurs
while at max stack depth in some subroutine.

- Beware sharing (fatally) registers/RAM between IRQ and foreground tasks.

- Ensure all subroutines have returns via all possible paths (and don't fall
off end into other code). Same applies for interrupts with appropriate
return.

- Ensure you use interrupt return for interrupt and subroutine return for
subroutine.

- Conditional paths may lead to death but be only called sometimes.

- If you assume a register has a given starting value ensure you put it
there during initialisations.
Safest method is to zero ALL RAM etc and assume it starts at zero.
Initialising with specific desired values as required and not initialising
those locations that don't assume startup values is fine AS LONG AS you
always get it right. Some processors will often but not always zero RAM.
Assuming that they always do will get you sooner or later.

- ENSURING that subroutines and interrupts do not corrupt the waters is
wise. Results vary with processor used. Some will push status flag on ints,
some don't. Some save various regs on IRQ, some don't.

- Ensure you understand EXACTLY what conditional branches do
(signed/unsigned/plus/half carry/overflow/ negative/ ... can create a host
of joys.

- Initial / boundary conditions often kill you. Murphy says that stopping a
loop one over or under or starting 1 below or above intended point is easier
than getting it right. The last character in an array will be unprocessed
when you leave. One more than the last character/number in an array will
have been processed. The character returned will be one off from where you
think it came from. Your multiplication / division will handle N+/- 1 bit
when N is intended etc.



        Russell McMahon

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