BDM, JTSG anh Nexus

Chapter 7: BDM, JTAG, and Nexus
Overview
Traditionally, the debug kernel has been implemented in firmware. Thus, for the
kernel to execute correctly on new hardware, the new design must at least get the
processor–memory interface correct. Unfortunately, as clock speeds increase and
memory systems grow in size and complexity, this interface has become more and
more demanding to engineer, which raises a question “how you can debug the
system when you can’t rely on the system to execute even the debug kernel?”
Increasing levels of integration create a related problem: How do you modify
firmware when it’s embedded on a chip in which you can’t use a ROM emulator?
To address these and other related issues, chip vendors are beginning to supply
hardware implementations of the debug kernel as part of the chip circuitry. When
the functionality of the debug kernel is part of the chip circuitry, debugging tools
can continue to deliver run control and to monitor system resources even if the
processor chip isn’t able to communicate with the rest of the board. This
robustness makes it much easier to determine whether intermittent “glitches” are
hardware or software problems.
Putting debug control directly in the processor solves other problems, too. In chips
with sophisticated pipelines and complex caches, integral debug circuitry can
report processor state without concern for the cache and pipeline visibility
problems that limit logic analyzers. Well-designed debug interfaces can reduce the
overall package pin count. Also, when implemented in silicon, the debug core can’t
be accidentally destroyed by software that has run amok and has written over a
debug kernel located in the target system. (Not only is this a nice convenience, it
can be a major time-saver if the debug kernel has to be downloaded to the target
system every time the system crashes.) As processors and embedded systems
become faster and more complex, on-chip debug support becomes more critical.
Finally, when the debug kernel is implemented as a fixed, standard part of the
processor, hosted tool vendors can’t communicate with the “debug kernel” via a
proprietary protocol any longer. Thus, moving the debug kernel into hardware has

contributed to the emergence of new standard interface protocols. Three major
debug protocols are used today: BDM (Background Debug Mode), IEEE 1149.1
JTAG (Joint Test Action Group), and IEEE-5001 ISTO (Nexus).

Hardware Instability
In general, you will be integrating unstable hardware with software that has never
run on the hardware. The instability of the hardware means that the interface
between the processor and the memory might be faulty, so that any code, even a
debugger, cannot possibly run reliably in the target system.
With today’s processors running at frequencies over 1GHz and bus speeds in
excess of 200MHz, circuit designers must take into account the dreaded analog
effects. A printed circuit board that checks out just fine at DC might fail completely
at normal bus speeds.
An embedded system that has a marginal timing problem or a cross-talk problem
can appear to work correctly for long stretches of time and then just die. When the
right combination of 1s and 0s appears on the right bus at the right time, a glitch
occurs, and a bit flips where it shouldn’t, taking the system down with it. Until
recently, these kinds of problems could wreck a project. Unless the proces sor-to-
memory system was stable, the system could not be turned on. The only tool that
could overcome this problem was the ICE.

Background Debug Mode
BDM is Motorola’s proprietary debug interface. Motorola was the first embedded
processor vendor to place special circuitry in the processor core with the sole
function of processor debugging. Thus, BDM began the trend to on-chip debug
resources. Today, embedded processors or microcontrollers are expected to have
some kind of dedicated, on-chip debugging circuitry. The hardware design need
only bring the processor’s debug pins out to a dedicated connector and the debug
tool, called an n-wire or wiggler. Figure 7.1
is a schematic representation showing

an n-wire tool connected to an embedded system.

Figure 7.1: n-Wire tool.
Embedded system connection to a host computer using an n-wire
connection to the processor debug core.

Note
The hardware module that interfaces to the embedded system’s n-wire debug port
is sometimes called a wiggler because it wiggles several pins on the processor to
implement the protocol of the debug core being used.
Compared to the cost of a traditional ICE, a wiggler is an incredible bargain. For
example, I purchased 10 wigglers for use with the Motorola MF5206e ColdFire
processor for about $40 each (including an educational discount). The wiggler,
from P&E Micro, connects through the parallel port of a PC and includes a basic
debugger that runs on the PC and communicates with the BDM core in the
processor. The wiggler is inexpensive because the complex portions of the
functionality have been moved into the chip, where circuitry is cheap. The wiggler
does little else other than implement the debug core’s timing and protocol
interface to the CPU.
BDM was first implemented with the 683XX family and is used with the ColdFire
processor family. BDM connects to a 26-pin connector that is mounted on the
target PC board. Figure 7.2
shows the pinout for the BDM debug interface.

Figure 7.2: Pinout for the Motorola BDM debug interface.
Pinout for the Motorola BDM debug interface. The connection is
implemented using a standard 26-pin connector to a third-party BDM tool.
BDM is noteworthy because it supports both processor control and a form of real-
time trace monitoring. The four bits — DDATA0–DDATA3 — output debug data,
and the four bits — PST0–PST3 — output processor status while the processor is

running at full speed. Thus, a third-party tool equipped to analyze the information
flow from the BDM port can provide the developer with important information
about the execution flow of the processor core. Figure 7.3
shows the processor
codes output through pins PST0–PST3.
The 14 possible processor status output codes shown in Figure 7.3
are designed to
be used in conjunction with a user’s or debugger’s knowledge of the program’s
memory image in order to completely track the real-time execution of the code.
Notice how codes are provided for change-of-flow instructions, such as 0101 for
the execution the first instruction after a taking branch and 1100 for entry into an
exception handler.
A complete discussion of the behavior of the PST3-PST0 pins would quickly drive
all but the most dedicated readers into “geek overload”, so I’ll end my discussion
here. If you are interested, you can find the details in the Motorola MCF5206e
User’s Manual.
The ColdFire instruction set also includes special instructions, PULSE and WDDATA.
These instructions were specially created to better integrate the debug core
operation with the instruction execution flow. PULSE causes the binary code 0100
to be output on the PST pins. This signal might be accepted as a trigger signal by a
hardware debug tool, such as a logic or performance analyzer. Similarly, the
WDDATA instruction enables the processor to write a byte, word, or long word
operand directly to the DDATA port. Thus, the user might want to insert the PULSE
instruction at function entry and exit points to perform execution time
measurements.

Figure 7.3: Processor codes output.
Status signals output through the BDM debug core.
For example, suppose a certain function normally wouldn’t cause a problem. That
is, its execution meets the needs of the real-time service it performs. Occasionally,

an interrupt occurs while this function is executing, however, and the resulting
execution time for this function plus the ISR (interrupt service routine) is now over
the allotted time budget. This situation might be impossible to analyze statically,
but a tool that can perform a series of time-duration measurements, keyed by the
PULSE instruction, would provide a high-accuracy data set for the designer to use.
Figure 7.4
is summary of the BDM command set.
Referring to Figure 7.4
, it’s striking how similar these commands are to the
commands that you might issue to any debugger. However, remember that these
commands are going directly into the CPU core and operate independently of any
program code the user might be trying to execute.

Figure 7.4: BDM command set.
BDM command set for the Motorola ColdFire processor family.
The debug core of the ColdFire processor directly supports real-time debugging by
providing additional resources for gathering information and providing some user
control without the need to halt the processor. This assumes that some slight
intrusion is permitted but halting the CPU core, as is required by some of the BDM
commands discussed in Figure 7.4
, is not acceptable. This support comes in the
form of additional registers that can be programmed via the BDM port to cause
breakpoints to occur under various conditions. The breakpoint can cause the
processor to HALT execution or can be treated as a high-priority interrupt to the
processor. This forces the CPU to enter a user-defined debug ISR. The processor
continues to execute instructions when it receives this breakpoint.
Joint Test Action Group (JTAG)
The JTAG (IEEE 1149.1) protocol evolved from work in the PC-board test industry.
It represented a departure from the traditional way of doing board tests. PC boards
were (and still are) tested on complex machines that use dense arrays of point

contacts (called a bed of nails) to connect to every node on the board. A node is a
shared interconnection between board components. Thus, the output of one device,
a clock driver, for example, might connect to five or six inputs on various other
devices on the board. This represents one node of the board. Connecting a pin
from the board tester to this node (typically a trace on the board) allows the tester
to determine whether this node is operating correctly. If not, the tester can usually
deduce whether the node is short-circuited to power or to ground, whether it’s
improperly connected (open-circuited), or whether it’s accidentally connected to
another node in the circuit.
JTAG was designed to supplement the board tester by connecting all the nodes in
the board to individual bits of a long shift register. Each bit represents a node in
the circuit.

Note
A shift register is a type of circuit that receives or transmits a serial data stream. A
COM port, Ethernet port, FireWire, and USB are examples of serial data streams.
Usually, the serial data stream is keyed to a multiple of a standard data width.
Thus, an Ethernet port can accept a data packet of 512 bytes. RS232C transmits 1
byte at a time. In contrast, a JTAG serial data stream might be hundreds, or
thousands, of bits in length.
For JTAG to work, the integrated circuit devices used in the design must be JTAG-
compliant. This means that each I/O pin of a circuit component should contain a
companion circuit element the interfaces that pin to the JTAG chain. When enabled,
the state of each pin is sampled, or “sniffed,” by the companion JTAG cell. Thus,
by properly reconstructing the serial bit stream in the correct order, the entire
state of the circuit can be sampled at one instance (see Figure 7.5).
Figure 7.5 is a simple schematic representation of a JTAG loop for three circuit
elements. The loop consists of an entry point to a device and a separate exit point.
Connecting the exit points to the entry points allows you to create a continuous
loop that winds through the entire circuit.

A JTAG loop can be active, as well as passive. An I/O pin in the circuit can be
forced to a given state by writing the desired bit value to the corresponding JTAG
location in the serial data stream. Because the serial data stream can be
thousands of bits in length, the algorithms for managing JTAG loops tend to
become very complex, very fast. By their nature, JTAG loops can become rather
slow as well, because many bits must be shifted each time a value is read or
changed.
JTAG gave board test people an alternative to expensive board testers, and,
perhaps more significantly, a device equipped with a JTAG loop could be easily