Motorola's Background Debug Mode is one of a variety of on-chip debug technologies. Collectively, they offer some of the best features of debug monitors and in-circuit emulators—with far less headache and cost.
In the beginning, there was the debug monitor. Inexpensive but effective, it still serves handily alongside the most expensive debugging tools. Yet monitors have their drawbacks and weaknesses. For instance, they require ROM, RAM, and a communications channel from the target; they need to be ported to the target hardware; and they don't let you set breakpoints in programs running out of ROM.
After the debug monitor came the in-circuit emulator (ICE). By applying some clever hardware methods (usually based on special bond-out versions of processors), an ICE provides capabilities far beyond those of a simple ROM monitor. The ICE's most powerful features include complex breakpoints (even in ROM), real-time traces of processor activity, and no use of target resources. But this extra functionality comes at a high cost.
Emulators can be expensive. In fact, the increasing speed, complexity, and integration levels of modern processors limit the availability of bond-out versions, making emulators difficult and expensive to design. As a result, some debugging features unique to ICEs are unavailable for modern processors.
To counter these trends, many semiconductor vendors now integrate dedicated debug circuitry into their chips. Each vendor generally has its own proprietary name for this technology, such as BDM, OnCE, and MPSD. Other vendors simply add software debug capabilities to their existing JTAG ports. Collectively, we'll call these technologies on-chip debug. Such hardware-based capabilities take the place of a software debug monitor, yet offer some additional features previously associated only with emulators. And they do both at a modest cost.
Background debug mode
Motorola's Background Debug Mode (BDM) is the best known of the proprietary on-chip debug solutions. It defines a communications standard for interfacing to a debug core via a 10- or 26-pin connector on the target system. A host computer, running a BDM-compatible remote debugger, can communicate with and control the processor through this interface.
The basic BDM command set is generally the same across processor families, but differences exist due to the inherent architectural differences. These differences are handled by the particular debugger that drives the BDM.
BDM commands are 17-bits long (actually 16 command bits and one status/control bit). Commands are shifted serially along the serial-data-in (DSI) signal from the debugger to the processor; each may be followed by one or more extension words. Responses are shifted serially out of the processor on the corresponding serial-data-out (DSO) signal. These data transmissions are synchronized to a serial-clock (DSCLK) signal, which is driven by the remote debugger.
Table 1 summarizes the core BDM command set for 68k and ColdFire processors. (Motorola's PowerPC processors, which also have a BDM interface, operate quite differently.) As you can see, these commands are similar to those of a typical debug monitor. The remote debugger builds on simple capabilities like reading and writing registers and individual memory locations. BDM commands invoked while the processor is running and involving memory will "steal" bus cycles from the CPU, much as a DMA controller would.
Command | Mnemonic | Description |
Read Register | RAREG/RDREG | Read the selected address or data register and return the result |
Write Register | WAREG/WDREG | Write the specified value to the selected address or data register |
Read Memory | READ | Read from the specified memory location |
Write Memory | WRITE | Write to the specified memory location |
Dump Memory | DUMP | Read from a block of memory |
Fill Memory | FILL | Write to a block of memory |
Resume Execution | GO | Resume instruction execution at the current value of the PC (after pipeline flush) |
Table 1. The basic BDM command set for 68k and ColdFire
As the debugger reads and writes memory and registers, and halts the CPU and restarts it, the processor proper doesn't have any knowledge that these activities are taking place. When it's not halted, it simply hums along fetching instructions as specified by the program. Execution of the special BGND instruction or assertion of the /BREAKPOINT signal from the debugger will cause the CPU to halt and the on-chip debug hardware to take over. If the GO command is then received, the pipeline will be flushed and the CPU restarted.
Though on-chip debugging like this provides basic capabilities similar to a debug monitor, it also offers some of the features of an ICE. For example, on-chip debugging doesn't need to use target memory or a communication channel; dedicated hardware and circuitry already in place do the job instead. It's also possible to use this tool to view registers and memory without halting the processor, which is a nifty feature.
Bus activity monitoring
Of course, most in-circuit emulators contain real-time trace circuitry, which allows them to capture the activity on the processor's bus and, with on-chip support, the processor's internal states. This data is generally logged to a trace buffer for later analysis by the programmer. Such data is particularly helpful when you're trying to debug problems involving behavior that can only be captured while the processor runs at full speed.
Conveniently, on-chip debug agents reside inside any caches and memory management units they may share silicon with, so they see address and data values just like the CPU sees them. Even if you can't get at these from the outside of the chip, say with a logic analyzer, it may be possible to capture them with an on-chip debugger. But this needs to be a feature of the particular on-chip debug agent and debugger you're using.
For example, the ColdFire's BDM connection contains eight additional output signals, which can output nibble-formatted information on the processor's state. With some logging capability and clever software on the host side, the real-time execution history of the processor can be reconstructed from this information.
In search of a standard
As a technology, the biggest problem with on-chip debugging are the lack of a consistent set of capabilities and single communications interface across processor architectures. Though a few vendors have standardized on JTAG ports for the physical connection, capabilities vary widely. Fortunately, an industry consortium called Nexus has established a standard for on-chip debug. It's formally called IEEE-ISTO 5001. If that is adopted widely, you may soon be able to use the same remote debugger to talk directly to processors from multiple vendors.
Further reading
Haller, Craig. "The Zen of BDM," online at http://www.macraigor.com/zenofbdm.pdf, ca. 1996-1997.
This article was published in the March 2003 issue of Embedded Systems Programming. If you wish to cite the article in your own work, you may find the following MLA-style information helpful:
Berger, Arnold and Michael Barr. "Introduction to On-Chip Debug" Embedded Systems Programming, March 2003, pp. 47-48.
Related Barr Group Courses:
For a full list of Barr Group courses, go to our Course Catalog.
