UNIT 4 JTAG, BDM and Nexus

Design of Embedded Systems –
UNIT 4
In-Circuit Emulators
BDM/JTAG and Nexus
Dr.T.C.Kalaiselvi
Associate Professor /Department of ECE
Kongu Engineering
College
Perundurai
Topics to be covered
BDM, JTAG, and Nexus
• 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.
• 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?
• Chip vendors are beginning to supply
Hardware implementations of the debug
kernel as 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
• 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
• 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).
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.
• 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
n-wire tool connected to an embedded
system.
• wiggler -it wiggles several
pins on the processor to
implement the protocol of the debug core being
used.
BDM
• 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.
• 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.
• 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
• 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.
Status signals output through the BDM
debug core.
• Processor codes output
BDM command set
Joint Test Action Group (JTAG)
• The JTAG (IEEE 1149.1) protocol evolved from work in the PC-board test industry.
• 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 ashared 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.
JTAG loop.
• 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.
Debug core using JTAG
• Two noteworthy improvements were the addition of addressable
loops and JTAG-based commands.
• The JTAG-based command uses the standard JTAG protocol for
moving the serial bit stream but then controls the core through
debug commands, rather than by directly jamming in new values.
Thus, instead of a serial loop with 10,000 bits, a bit stream of several
hundred bits could be sent to the debug core. The bit stream would
be interpreted as a command to the core (such as, “change the value
of register R30 to 0x55555555").
• The other improvement — addressable loops — replaces one long
loop with a number of smaller loops. A short JTAG command is sent
out to set up the proper loop connection.
• Then, the smaller loop can be manipulated instead of a single long
loop. Addressable loops have another compelling application:
multiple processor debugging
Nexus
• The automobile industry provided the motivation

for the next attempt at bringing some form of
standardization for on-chip debugging. Several of
the largest automobile manufacturers conveyed to
their semiconductor vendors a simple message:
• Either standardize your on-chip debugging
technology so we can standardize our development
tools, or we’ll specify you out of consideration for
future automobile designs.
• The automobile manufacturers were tired of having to re-
supply their embedded development teams every time
they chose a new microprocessor for a new application.
• Not only is there a steep learning curve for the design
engineers to become proficient with yet another processor
and another debugging tool, but here is also the reality
that the modern automobile contains dozens of embedded
microcontrollers.
• Thus, the variety of development tools in use was
becoming a major design and support nightmare and a
major impediment to improved productivity.
Basic structure of the Nexus interface.
• In 1998, the Global Embedded Processor Debug Interface
Standard (GEPDIS) was organized by tool providers Bosch ETAS
and HP Automotive Solutions Division and by embedded
microcontroller providers Hitachi Semiconductor, Motorola
Vehicle Systems Division, and Infineon Technologies.
• The group’s original working name was the Nexus Consortium
(“Nexus: a connected group”), but it is now known as the 5001
Forum, in recognition of its affiliation with the IEEE-ISTO.
• The standard was assigned the designation ISTO-5001, Global
Embedded Microprocessor Debug Standard. The standard was
formally approved by the IEEE Industry Standards and Technology
Organization (ISTO) in early 2000.
• The Nexus standard introduces several new concepts to embedded processor
debugging. The first is scalability. A processor can comply with the Nexus standard
at several levels of compliance.
• The first level provides for simple run control commands. Each successive level
adds more capabilities and requires more pins on the processor to implement.
These additional pins allow real-time trace data to be output by the processor
without stalling the processor core.
• Thus, a manufacturer of an 8-bit embedded controller might only need to
implement the first level of compliance because I/O pins are precious
commodities for a low-cost device.
• Manufacturers of high- performance 32-bit embedded processors would probably
want to implement a higher level of compliance to provide real-time trace and
other capabilities.
• Also, Nexus used the JTAG protocol (IEEE 1149.1) as the standard protocol for the
lowest level of compliance. This means a well-accepted standard protocol, with a
rich set of existing tools and software support, is usable for the Nexus
Methodology.

UNIT 4 JTAG, BDM and Nexus

Uploaded by

Copyright:

Available Formats

UNIT 4 JTAG, BDM and Nexus

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UNIT 4 JTAG, BDM and Nexus

Uploaded by

Copyright:

Available Formats

Design of Embedded Systems –

• BDM is Motorola’s proprietary debug interface.

• BDM was first implemented

• The automobile industry provided the motivation

You might also like