N. Coesel wrote:
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. 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).
So, you admit that real in-design debug is unavoidable? :)
I use BDM to get those counters and state variables out of the device
once internal check
signalled that something is not quite right (watchdog is sometimes too
slow for this), or, an
external debug harness generates a flag that behavior is incorrect. This
way I may not have
UART in the design at all, saving a few words of flash and ram, pins and
space on PCB.
The interface for the pheripherals is usually a really thin layer so the
upper layers can be tested in a test environment which also allows for
testing limits the hardware may never reach.
The same "test environment" due to overall performance difference and
different execution time
for different operations, may easily lead you into even logical
approach, algorithm, that will work
perfectly on that "test environment", but will be unfeasible on a real
embedded controller chip. In
such a case you will have to redesign the whole thing from scratch after
long and painful struggle.
Vit.
