16-05-2012, 01:22 PM
Debugging Embedded Systems Advanced RISC Machines Inc (ARM)
Embedded In circuit emulator.pdf (Size: 28 KB / Downloads: 72)
Introduction
A significant portion of product design time is spent on integration and debugging of both hardware
and software. This is especially true for systems such as engine management, hard disk control and
modems due to their real time constraints.
Deeply embedded cores (i.e. microprocessors which are buried within the heart of an ASIC or
custom chip) have made the debug of systems progressively more difficult as there is often limited
access to the processors’ busses and signals. This is worsened by the use of multi-processor
systems such as the controller-DSP architectures common to hard disk drives, pagers and
cellphones.
This article briefly examines some of the traditional ways of debugging processor systems. It then
considers a new approach that ARM has developed to help solve some of the problems with In
Circuit Emulators, Monitor Programs and Logic Analysers.
In Circuit Emulators (ICE)
An ICE contains real-time event detection, real-time tracing and memory emulation, all integrated
behind a unified user interface. This often provides the software engineer with a layer of protection
from the hardware. In addition, an ICE does not require the system around it to be functional,
allowing a degree of parallelism in software and hardware development to reduce time to market.
What problems are associated with standard ICEs?
· An ICE's pod interferes with the normal timing of the target system and may therefore reduce
maximum speed.
· Physical processor replacement requires intricate pods which are notoriously unreliable.
Replacing the processor also changes electrical characteristics meaning that problems can
emerge which cannot be replicated when the ICE is used.
· ICE's lag processor availability. Typically 6-9 months can be expected between processor
release and ICE availability.
· A deeply-embedded CPU requires a large "bond-out" chip to bring internal signals out for the
ICE to see. Given the effort required to produce an ICE, custom variants of processors may not
be supported by ICE at all.
· ICE can be expensive
Debug Monitors
The Debug Monitor resident on the target system is an alternative to ICE, providing the user with
many of the features needed to test and debug software such as setting breakpoints, uploading data
from target memory and downloading application programs.
An advantage of this approach is that the software being developed can run on the same processor
and associated hardware as the final system. In addition, the cost of a Debug Monitor system is low
and so every engineer can have one.
However, the need to have the Debug Monitor in ROM on the target system is a significant problem
since it must either be removed from the final product or left in ROM at extra cost.
A communication channel to a host computer running the user interface of the debugging software is
also required. A UART and suitable line driver in the target system are normally needed for this. The
software driver for the UART must be written and successfully ported to the target system before
the Debug Monitor will work, and before any system debugging can start.
In addition, the Debug Monitor code must be ported to the target system hardware, meaning that in
many systems from a hardware perspective, the majority of the system must be functional before the
Debug Monitor can be used at all.
Logic Analysers
These are often useful as a debug tool in addition to either of the above debug methodologies,
although on their own they are usually insufficient. This is because they offer only a historical view of
the action of code. The user can not change variables or jump to different parts of the program, so
“what-if” tests are impossible without recompiling code. In addition, most analysers only have a
fixed amount of memory, so the amount of trace per run is limited.