Page 154 - The Art of Designing Embedded Systems

Troubleshooting Tools 14 1

A very scary development is the incredible proliferation of CPUs.
Vendors are proud of their ability to crank out a new chip by pressing a few
buttons on a CAD system, changing the mix of peripherals and memory,
producing variant number 214 in a particular processor family. Variants
are a sign of a good, healthy line of parts (look at that mind-boggling array
of 8051 parts), but are a nightmare for tool vendors. Each requires new
hardware, software, support, evaluation boards, and the like. In the “good
old days,” when we saw only a few new parts per year per family, support
was easy to find. Now my friends who make microcontroller tools com-
plain of the frantic pace needed to support even a subset of the parts.
As a tool consumer you probably don’t care about the woes of the
vendors. But part proliferation creates a problem that hits a bit closer to
home: for any specific variant there may only be a handful of customers.
Tool support may never exist for that part if vendors feel there’s not a big
enough market. An odd fact of the tool market (from compilers to ICES) is
that the health of the market is a function of the number of customers using
a chip, not the number of chips used. CPU vendors are happy to get one or
two huge design wins, say an automotive company that sucks up millions
of parts per year. Tool folks might only sell a couple of units to such a cus-
tomer, far too few to pay their huge development costs.
Yet, despite the problems inherent with any tool so closely coupled
to the CPU, the ICE is without a doubt the most powerful and most useful
tool we have for debugging an embedded system. Only an ICE gives a
nonintrusive real-time view of the firmware’s operation.
Why use an ICE?

If your target hardware is not perfect, most other tools will not
function well. An ICE is probably the most useful tool around
for finding and troubleshooting hardware as well as software
problems.
The ICE uses no target resources. In general, all ROM. RAM, and
interrupts will be untouched.
There is no better way to debug real-time code than using trace
coupled with extensive triggering capabilities. The emulator cap-
tures the busses, and, in conjunction with the source-level debug-
ger, correlates raw bus activity to your C source files.
Emulator downsides include:

No tool is more expensive than an emulator.
As discussed earlier, speed and mechanical issues mean that some
systems will just not be candidates for emulator-based debugging.