Introduction

Traditional versus on-chip

BDM, JTAG

Pushing the envelope

A variety of implementations

Issues to consider

Introduction
(Back to top)

Many of today's high-performance embedded processors implement some form of on-chip debugging mechanism. On-chip debugging is a generic term used to describe the debugging functionality incorporated into the silicon and/or microcode of a microprocessor or microcontroller, providing embedded system developers with many of the same debugging features found in in-circuit emulators. For example, processors such as those in the Motorola CPU32 family provide debugging features through a serial background debug mode (BDM) interface. The IBM/Motorola PowerPC 603 and 603E, on the other hand, provide on-chip debugging features via the JTAG (Joint Test Action Group) serial test pins. And some other processors, such as Motorola's PowerPC 821, implement on-chip debugging via an interface called on-chip emulation (OnCE).

For design teams with access to tools such as the HP16500B/C logic-analysis system or HP1670 benchtop logic analyzer, preprocessors are available to take maximum advantage of the on-chip debugging features of these processors.

Traditional versus on-chip
(Back to top)

The traditional method of debugging an embedded system has been to use an in-circuit emulator and/or a ROM monitor. However, emulators are frequently more complex than necessary for application development and they're often very expensive. As a result, emulators are usually used to bring up and debug custom hardware, to tackle hardware/software integration problems, or to find difficult software problems that require real-time tracing or bus event detection. While a ROM monitor is less expensive than an emulator, it provides a less detailed view of the processor's operation. It also uses target memory and needs a UART, both of which are usually scarce resources in cost-sensitive embedded systems.

In general, all of the on-chip debugging mechanisms implement basic functions such as downloading code, reading and writing registers, reading and writing memory, single stepping, and processor reset. Higher level functions, such as displaying source code and setting breakpoints, can be provided by host-based debugger packages that communicate with the processor through the on-chip serial interface.

BDM, JTAG
(Back to top)

Background debug mode (BDM) was first used by Motorola in the CPU32 family of processors to provide the same basic capabilities as a ROM monitor, but with no additional resources (such as ROM, RAM or a UART) for debugging a system. BDM is reasonably fast because debugging primitives are implemented directly in the processor.

The JTAG (also known as IEEE 1149.1) specification for boundary-scan testing, which uses serially connected, binary test points called scan chains, was not originally intended for software debugging. It is adapted to this new role by inserting appropriate opcodes into the instruction register.

JTAG debugging is generally slow because of the length of the scan chain and because operations require the scan chain to be traversed several times. To avoid this problem, some processors (the IBM PowerPC 403, for example) implement a second JTAG scan chain to provide an alternate, shorter path to the on-chip debugging registers. Debugging via the JTAG port has an advantage over DBM, however, in that it requires no additional processor pins, making use of those which have already been dedicated to JTAG.

The on-chip emulation (OnCE) interface, used in the PowerPC 821, combines features of BDM and JTAG debugging. Debug-specific registers on the processor are accessed via the JTAG pins, but unlike BDM, there is no specific debug command set. Instead, the host debugger executes debugging functions by stuffing processor opcodes into an instruction stuff register.

Pushing the envelope
(Back to top)

Performance improvements in new embedded processors have made it difficult to design emulators that can trace and control the processor correctly. Memory accesses which hit in internal caches, for example, aren't visible to an emulator. Emulators also have difficulty keeping up with the high internal clock rates of the new processors and in dealing with superscalar processors that execute more than one instruction per clock cycle.

For all of these reasons, it has become very difficult to build emulators which can correctly emulate new high-performance processors. With this in mind, Hewlett-Packard developed its distributed emulation strategy, which takes advantage of on-chip debugging features and provides alternate ways to achieve emulator-like functionality.

An important added benefit of on-chip debugging and distributed emulation is that it allows a wide range of debugging systems to be implemented to address varied development requirements and budgets. The tools that are absolutely necessary for on-chip debugging are a host computer, debugger software running on the host, and a way to connect the host to the serial debug interface on the processor. If full bus analysis and real-time event detection are needed, a logic analyzer and appropriate software and hardware utilities can be added to the system to monitor the processor bus.

A variety of implementations
(Back to top)

The simplest, cheapest implementation of the distributed emulation concept accesses on-chip debugging features via a PC and a parallel port, but this is also the slowest method. In this configuration, the bits on the PC parallel port are manipulated by host software to control the serial interface to the target processor and to send and receive debugging information.

This approach provides essentially the same functionality as a ROM monitor, is inexpensive, and is usually adequate for application-level development. A more sophisticated implementation of the distributed emulation approach distributes the functionality of an emulator among several different tools, which can be distributed logically and geographically over a network. Here, the connection to the target processor is controlled by a standalone box which has a LAN interface for communicating with the host-based debugger and an appropriate serial interface for communicating with the on-chip debug facility.

This system can include a logic analyzer for monitoring the processor bus, connected to the host over a LAN. A preprocessor is used to provide physical connectivity between the logic analyzer and the target processor, as well as host-resident software that can interpret and display information from the logic analyzer. The logic analyzer also provides a trigger output which can halt the target processor (via the on-chip debug interface) when a particular bus event occurs.

Issues to consider
(Back to top)

Some of the issues that may need to be addressed when using on-chip debugging are how to correctly configure the target system after a reset, how to best use on-chip breakpoints, and how to selectively turn off caching so that the logic analyzer can see critical events. With on-chip debugging, the processor typically comes out of reset in some default state and must be appropriately configured before a debug session can begin.

A debugger that supports on-chip debugging, such as Software Development Systems' SingleStep, provides mechanisms for configuring the target system, saving the configuration, and restoring the configuration after a target reset. Configuring, saving and restoring the configuration happens before control of the debugger is given back to the user, so it is effectively hidden from the user; i.e., once configured, the debugger ensures that the target environment is always correctly configured.

On-chip breakpoint logic is becoming common on high-performance embedded processors as a way to compensate for limitations inherent in emulators. Because the breakpoint logic is built into the core of the processor, all instruction and data accesses are visible, even if these accesses hit in internal cache.

The disadvantages of on-chip breakpoints are that there are usually only a few of them available and they typically don't offer the same level of flexibility as a full-featured emulator. If code that seems to be causing a problem is running entirely from cache, a logic analyzer can't see the event that would indicate an error. In cases like this, bugs can often be found by disabling the cache during the execution of the suspect code.