Page 234 - The Art of Designing Embedded Systems

A Firmware Standards Manual 221

Does the tool run at full target speed, or will you have to slow
things down? What is the impact?
Will the mechanical connection between the tool and the target be
reliable? It’s quite tough to get a decent connection to many mod-
ern SMT and BGA processors.
IntenuptsDMA-Will the tool let you debug ISRs? Are interrupts/
DMA ever disabled unexpectedly? If the tool does not respond to
intermpts/DMA when stopped at a breakpoint (very common), will
this have a deleterious effect on your debugging?
Tasking-If the product uses an RTOS, the tool must provide
some support for that RTOS. Insure that the debugger itself is
aware of the RTOS, and can display important task constructs in
a high-level format. What happens if you set a breakpoint on a
task40 the others continue to run? If not, what impact will this
have on your development?
Internal peripherals-Is the tool aware of the CPU’s internal pe-
ripherals? Many are; they let you look at the function of the periph-
erals at a very high level. Do timers stop running at a breakpoint
(common)? Will this cause development problems?

Be wary of doing all of your development with the tool’s down-
loader. Burn a ROM from time to time to make sure the code itself runs
properly from ROM, and to insure the product properly addresses the
ROMs.
Leave all debugging resources in the product when it ships. Disable
them via a software flag so they lie latent, ready for action in case of a
problem. Remember the Mars Pathfinder: JPL diagnosed and fixed a pri-
ority inversion bug while the unit was on Mars, using the RTOS’s trace
debug feature, which had been left in the product.