On 2008-04-04, N. Coesel <[email protected]> wrote:
> At 16:15 04-04-08 +0000, Grant Edwards wrote:
>>On 2008-04-04, N. Coesel <[email protected]> wrote:
>>
>>> If you write you code portable, you can use and CPU you want.
>>> Besides, debugging on an embedded device is not the fastest
>>> way to debug. Just write for Windows/Linux first and then port
>>> your code to the embedded device.
>>
>>That only works for code that's not real-time and doesn't use
>>any of the peripherals -- and that's never where the problems
>>are.
>
> You can't set breakpoints in real-time code and interrupt routines without
> disturbing the process. So the use of JTAG debugging is very limited.
True. I very rarely do debugging via JTAG either.
> I use counters to monitor real-time processes non intrusively.
> The counters come in handy in the production device as well. I
> usually implement a command that shows how many bytes and
> interrupts where processed by a UART. Saving the stack pointer
> every timer interrupt in a special place tells me exactly
> where code got stuck (and tripped the watch-dog).
Those are the sorts of things I usually do. The only thing
missing from the list is "toggle some spare port pins in
strategic locations in the code".
Back in the days of real in-circuit emulators, I never found
breakpoints and single-stepping to be very useful. However, a
time-stamped trace buffer with conditional triggers was always
useful for getting timestamped traces of writes to certain key
variables.
These days if I get really desperate, I'll set up a circular
buffer of "event records" and create a trace function that
writes timestamped event records into that buffer. Then add
some sort of mechanism to dump out the buffer, and bob's your
uncle.
I've seen parts with JTAG interfaces that claime to have
real-time trace capabilities, but I've never had a chance to
use one.
--
Grant Edwards grante Yow! They collapsed
at ... like nuns in the
visi.com street ... they had no
teen appeal!
