On Wed, 4 Jun 2003 18:07:58 -0400, you wrote:

>I am curious about how people debug their code once they have burned it
>into the chip and it does not work correctly.  Would appreciate any
>feedback I can get.
>
>I'm not talking about the commercial guys, now, with their =
zillion-dollar
>systems, but the poor hobbyists (like me) who have a breadboard, a chip,=
 a
>few components, and a simulator.
>
>Simulators are wonderful, but at some point you have gone through the =
code,
>and it all looks correct; you have run it through the simulator and it
>works perfectly, you burn it into the chip, and BAM! it does not work. =
:-(
>
>So how do people debug it at that point?  (I have some ideas, but I am =
sure
>there are a whole raft of things I have not thought of).
>
>John
Writing the whole thing in a simulator and then expecting it to all work =
when you stick it in a chip
is NOT a good way to do things.  Apart from testing complex calculations,=
 I think simulators are of
very limited use -I can't remember ever using one, even before I got an =
emulator.=20
Embedded stuff is usually just too real-world dependent for sims to be of=
 much use.

Start small, test as you go.=20

Write and test the initial code to set up the ports, then as you write =
more functions, test as you
go, that way you are (mostly) limiting the number of bugs you've written =
to the new parts of the
code.=20
Keep many versions - certainly every version you have tested successfully=
 - If something stops
working, go back to the previous version and carefully look at the =
differences, and if necessary
re-add stuff a little at a time.=20

Start with code to output an easily recognisable signal (pulse, LED, beep=
 etc.) on reset - that way
you spot spurious resets due to WDT timeout, MCLR/power glitches, jump =
tables going into the weeds
(usually..!) .

If possible, use a chip with more pins than the one you will use in the =
final project, that way you
can output debug info on spare pins - even simple 'set pin when code =
reaches this point' debug code
can be very useful to give a clue where things have gone wrong.=20

if you have int code, set a spare pin on entry to the int code, clear it =
on exit - you now have a ;I
am in int code' debug signal which can give a lot of useful info.=20

if you're eventually targeting an OTP part, develop with flash and use =
assembly-time switches
(if..then..else) to change the things that differ between parts.=20

Add debug code within assembler if..then's to allow debug functions to be=
 turned on and off as
required - especially useful if you have few pins for debug flags.=20

e.g. :=20

debug_int equ 1 ; =3D0 to turn off interrupt debugging
#define intdebugbit porta,1

int_code
 if debud_int =3D=3D1=20
 bsf  intdebugbit
 endif
<your int code>
 if debuf_int =3D=3D1=20
 bcf  intdebugbit
 endif
 retfie

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body