> 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).

        Well it depends on the project. Usually I always have a "debug output" on
my projects during development. Generally this simply means I have debug
output coming out of the serial port of the PIC (or being printed out on an
LCD if that's being used). The first task when trying to find out why
something isn't working is WHERE the fault is happening, so my first burn
usually prints out a message for every routine that is run, that way I can
track where the PIC is and what it's doing. Once I figure out where the PIC
is getting stuck I add debug output code to output important statistics, for
example if a piece of code is implementing some protocol the state variable
is output whenever it is changed, or a message every time an interrupt is
detected.

        This is all general, but I have found that it doesn't usually take too many
program cycles to nail down the issue. TTYL

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