Application Report

SPRA439B - May 2002

Emulation Fundamentals for TI’s DSP Solutions

Charles W. Brokish Field Design and Applications
Senior Member, Technical Staff

ABSTRACT

In software development, perhaps the most critical, yet least predictable stage in the process
is debugging. Many factors come into play when debugging software applications. Among
these factors, time is of utmost importance. The TI emulator is useful when integrating the
hardware and software portions of the user’s application. Time required to set up and debug
a software application can have major impacts on time-to-market, meeting customer
expectations, and ultimately the financial impact of a well-developed product which captures
the market share.

Texas Instruments’ debuggers allow extensive visibility into the processors, their registers,
and the application’s software. This visibility allows the software engineer to understand what
changes are taking place inside of the processor as the application executes. The software
engineer can set breakpoints in the application based on hardware signal values or software
locations within the application. At these breakpoints, the user can understand the state of
the processor and data and determine if their application is still operating correctly. They can
also perform benchmarking (timing analysis) and profiling (CPU loading) of their application
software within the emulator.

Additionally, multiprocessor debug allows the user to debug software on several processors
at the same time and provide a method of stopping one or multiple processors based on a
condition set in another processor—allowing the user to capture the entire system state at
the time in question.

The capabilities mentioned, and many more within the Texas Instruments debuggers, can
greatly reduce debugging time in the software development cycle.

This paper explains the fundamentals of how the emulation logic and emulation tools work
together with the TI digital signal processors (DSP). By understanding the fundamentals of
emulation, you will be able to accelerate the process of setting up and performing software
debug. This knowledge also aids in trouble shooting potential problems in your debugging
setup.

This paper explains the setup of the emulator hardware systems for single and
multi-processor applications. It also explains how the system components interact during
debug. A troubleshooting guide is provided to assist in commonly found setup problems.

The TMS320 DSP family of products and Code Composer Studio are trademarks of Texas Instruments. All other trademarks
are the property of their respective owners.

1
SPRA439B

Contents
1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 General Understandings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Software Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Board Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Single Processor Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Multiprocessor Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Homogeneous Multiprocessor Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Heterogeneous Multiprocessor Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Scanning Through Non-Debug JTAG Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Establishing Communication With Your Emulation Hardware and Target . . . . . . . . . . . . . . . . 20
3.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Physical I/O Space of Your Emulation Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Invoking Emulation-Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Invoking the Emulation Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Using the Parallel Debug Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Troubleshooting Emulation Setup Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Emulation Reset Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Emulator Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Troubleshooting Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Other Debugging Diagnostic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1 XDS Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Third Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 Bulletin Board Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4 Future Tools Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

List of Figures
1 Connecting the XDS560 PCI Card to Your Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Connecting the XDS510 ISA Card to Your Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Connecting the XDS510-PP to Your Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Emulator Connections Without Signal Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Emulator Connections With Signal Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Standard 14-Pin Keyed JTAG Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7 Startup Screen for Code Composer Studio Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8 Specifying Board Name Within CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9 Specifying Physical Address of Emulation Hardware With CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . 12
10 Automatic HW Detection of the XDS560 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11 Specifying Processor Configuration Within CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12 Defining the GEL File to be Used When Opening CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13 Viewing the System Configuration Within CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

14 Emulator Connections for Multiprocessor Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

15 Specifying a Multiprocessor Configuration Within CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
16 Viewing a Multiprocessor Configuration Within CC_Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
17 Specifying a Heterogeneous Multiprocessor Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
18 Specifying the Processors in a Heterogeneous Multiprocessor Configuration . . . . . . . . . . . . . . . . . 19
19 Viewing a Heterogeneous Multiprocessor Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
20 Specifying Non-Emulation Devices in BYPASS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
21 Opening Debug Sessions From the Parallel Debug Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
22 Parallel Debug Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

List of Tables
1 Standard TAP Controller JTAG Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Connection Verification JTAG Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 TI Advanced Emulation JTAG Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 JTAG Signal Activity for Connectivity Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Trouble-Shooting Guide for Emulation Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1 Hardware Setup
In order to understand the workings of the emulation logic on the TI processors, it is first
necessary understand what emulation consists of. This section covers setup of the hardware
into your host operating system.

1.1 Introduction
When using the TI debugger for software debugging on a hardware platform, it is necessary to
perform a few setup procedures to ensure proper working of the target processor with the
XDS560 or XDS510.

The emulation setup is comprised of two tools—the emulator (i.e. XDS560 or XDS510) which
controls the information flow to and from the target, and the debugger, which is the user
interface to this information. Beyond the emulation setup is the target processor. The emulation
logic within the TI processors uses the JTAG (Joint Test Action Group) standard connection, in
procuring the debug information from within the processor.

This section covers the basics of ensuring proper communication setup between the emulation
hardware and the target processor.

1.2 General Understandings

Debug of the hardware is performed by stopping the core to enable information to be scanned
into and out of the device via the JTAG header. This information is transferred serially through
the JTAG port following the IEEE 1149.1 JTAG specifications[1]. It is important to understand that
this debug method is near real-time, but is intrusive, as it may require that the core be halted to
scan the information.

Emulation Fundamentals for TI’s DSP Solutions 3

SPRA439B

While the connection to the JTAG header may be the same, the scan chains used for emulation
purposes are different from those used for boundary scan. Internally to the processor, there are
various serial scan chains in which the information can be scanned into and out of. The control
of which scan chain is used and what information is contained in each scan chain, is performed
by a microprocessor. This scan manager has the task of controlling this information as it is
scanned to and from the various processors in the scan chain and directing it to and from the
various debugger windows.
The host of the emulator acts as the scan manager as it controls the delivery of the scan
information to and from the target and the debugger window. When using a PC (personal
computer) and the JTAG, connection to the target processor can be made through several
options including a PCI card (Figure 1), an ISA card (Figure 2) or XDS510PP (Figure 3)—the
host of the emulation hardware is the microprocessor in the PC (i.e., the Pentium processor).

4 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

7.875 in

XDS560 Pod
Connector

4.20 in

PCI Fingers

59 in

0.48 in

7 in

2.87 in

Figure 1. Connecting the XDS560 PCI Card to Your Target System

Emulation Fundamentals for TI’s DSP Solutions 5

SPRA439B

Figure 2. Connecting the XDS510 ISA Card to Your Target System

Figure 3. Connecting the XDS510-PP to Your Target System

This information regarding the scan control is available to the PC host via dynamically linked
libraries, otherwise known as DLL files.
Additional information regarding physical connection of the XDS510 and XDS560 debugger
interfaces is available in documentation that is shipped with the product. Other helpful
information[2, 3] can be found at other locations within Texas Instruments, such as the TI bulletin
board and the TI internet homepage, www.ti.com.
Third parties are making other emulation interfaces available, including PCMCIA, USB, and
Ethernet connections (Go to ti.com and select the link to Getting Started with DSP for more
information). With these connection methods, scan management is performed by the CPU of the
host computer and an external processor, respectively.

6 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

1.3 Signal Descriptions

There are five standard signals and ground used for JTAG connections to control the JTAG test
access port (TAP) controller, as defined by the IEEE 1149.1 standard. These signals are shown
in Table 1.

Table 1. Standard TAP Controller JTAG Signals

EMULATOR TARGET
SIGNAL NAME DESCRIPTION
SIGNAL TYPE† SIGNAL TYPE†
TRST Test reset O I
TMS Test mode select O I
TDI Test data input O I
TDO Test data output I O
TCK Test clock (10 MHz clock provided by the XDS510 pod) O I
GND Ground
† I = Input, O = Output

TI also uses two other signals provided on the JTAG header as a method for confirming proper
connection of the emulation hardware (Table 2).

The Target Voltage Detect (or Presence Detect) signal and the Test Clock Return are used to
confirm the presence of the target device and the proper functioning of signals to and from the
XDS510 or XDS560 pod. We discuss their functionality further when we cover EMURST and
trouble-shooting hardware problems.

On some of the newer TI devices, documentation refers to signals called ET0, ET1, and TVD.
These signals are identical to the traditional signals called EMU0, EMU1, and PD, respectively.
However, there names have been changed to better reflect their use within TI’s emulation
solutions.

Presence Detect (PD) has been renamed Target Voltage Detect to indicate that, not only is it
used to detect the presence of a target being connected to the JTAG header, but it is also used
to detect the level of the voltage on the JTAG signals for that device. On the newer emulation
hardware, the JTAG pod is able to adapt the voltage to match the voltage of the target. This
provides a means of interfacing with legacy devices, which operated at a higher voltage (up to
5 V) as well as the newer devices, whose JTAG signals are capable of operating down to the
CPU voltage of 1.8 V and below.

Table 2. Connection Verification JTAG Signals

EMULATOR TARGET
SIGNAL NAME DESCRIPTION
SIGNAL TYPE† SIGNAL TYPE†
Test clock return (Buffered or unbuffered connection of TCK coming back
TCK_RET I O
from the target)
TDV or PD (Vcc) Target voltage detect I O
† I = Input, O = Output

Additionally, Texas Instruments adds two more signals to the JTAG header, which are used for
advanced emulation capability. These signals, shown in Table 3, provide the capability to
perform benchmarking, software profiling and multiprocessor emulation with interprocessor
breakpoint capabilities.

Emulation Fundamentals for TI’s DSP Solutions 7

SPRA439B

Table 3. TI Advanced Emulation JTAG Signals

EMULATOR TARGET
SIGNAL NAME DESCRIPTION
SIGNAL TYPE† SIGNAL TYPE†
EMU0 (OR ET0) Emulation Pin 0 (or Emulation Test 0) I I/O
EMU1 (OR ET1) Emulation Pin 1 (or Emulation Test 1) I I/O
† I = Input, O = Output

The use of the EMU signals is detailed in the C-Source Debugger User’s Guide. The EMU
signals are used by the emulator to provide clocking information when performing software
benchmarking and software profiling. They are also used with the ANALYSIS window of the
debugger to assist in multiprocessor debugging and serve as Global Breakpoints for
multiprocessor setups. Furthermore, on the newer devices, the EMU (or ET) signals provide
data streams for high-speed real-time data exchange (RTDX).
Setup of these signals for multiprocessor debugging is done within the parallel debug manager
(PDM), which is discussed more in Section 3.5.
The EMU signals are both input and output at the target. They can be used as an output and
driven low by a device as a result of breakpoint conditions being met. They can also be used as
inputs and monitored in the debugging logic. This allows one core to set the EMU signal, and
another device (or devices) to break as a result.
Figure 4 demonstrates the common connection of these signals on the user’s hardware design.
If the processor is 6 inches or more from the JTAG header, there could be degradation of the
signal due to loading of the signal path. In this case, you should use buffers to drive the signals
and maintain a suitable signal quality to ensure proper emulation (Figure 5).
VCC I/O

VCC I/O
Emulation Header Target Device
5 TVD 13
EMU0 EMU0
EMU1 14 EMU1
2
4 TRST 1 TRST
GND TMS TMS
6 GND 3
8 TDI TDI
GND 7
10 TDO 11 TDO
GND TCK TCK
12 GND 9
TCK_RET

6 inches or less

Figure 4. Emulator Connections Without Signal Buffering

8 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

VCC I/O

VCC I/O
Emulation Header Target Device
5 EMU0 13
TVD EMU0
EMU1 14 EMU1
TRST 2 TRST
4 1
6 GND TMS TMS
GND TDI 3 TDI
8 7
10 GND TDO TDO
GND 11 TCK
12 TCK
GND 9
TCK_RET

Greater Than
6 inches

Figure 5. Emulator Connections With Signal Buffering

Texas Instruments uses a standard 14-pin keyed header for all of their JTAG devices.

TMS 1 2 TRST
Header Dimensions:
TDI 3 4 GND
Pin–to–pin spacing, 0.100–in(X,Y)
TVD 5 6 No Pin (Key) † Pin width, 0.025–in square post
Pin length, 0.235–in normal
TDO 7 8 GND

TCK_RET 9 10 GND

TCK 11 12 GND

EMU0 13 14 EMU1

Figure 6. Standard 14-Pin Keyed JTAG Header

2 Software Setup
The software on your computer must be setup to recognize the devices that are physically
located within the JTAG scan-chain. The tool that we use to perform this function is called Code
Composer Studio Setup. It is typically installed within your desktop as an icon and executes a
program called CC_Setup.exe.

In this section we explain how to designate which specific target(s) you have within your system.

2.1 Board Configuration Information

The information regarding the scan chain is entered through the use of Code Composer Studio
Setup (CC_Setup). This program allows a user to enter their own names for the target
processors, or use the default names to simply indicate which processor(s) is in the scan chain.

When starting CC_Setup, the user sees a screen with three sections—allowing the user to enter
information regarding the board System Configuration, available board/simulator types, and driv-
er installation as shown in Figure 7. By selecting and dragging an available device from the cen-
ter column into the left-hand column, the user can begin the process of describing their system
configuration.

Emulation Fundamentals for TI’s DSP Solutions 9

SPRA439B

Figure 7. Startup Screen for Code Composer Studio Setup

2.2 Single Processor Debug

If only a single device is included in the scan chain, the signals are connected as shown in
Figure 4 and Figure 5. In this case, the debugger can be set up by specifying the device family
for the target processor, and then providing information regarding the physical connection of the
emulation hardware.
It is also possible to set up the software such that we can debug multiple targets—this is dis-
cussed further in the next section.
When specifying the target device, you should be able to find a descriptor for the device family
and connection method from the center column. For our example, we show a TMS320C55xt
DSP device being connected via the XDS560 hardware. We start by dragging the appropriate
target from the center column to the left column and dropping it under My System.

10 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Upon doing this, we see a dialog box asking for additional information. First is the description of
the Board Name. We can use the default, or select our own (Figure 8).

Figure 8. Specifying Board Name Within CC_Setup

Emulation Fundamentals for TI’s DSP Solutions 11

SPRA439B

Next, we need to specify the physical address that our emulation hardware is connected within
our host computer. When using the XDS510, the default address for TI hardware is address
0x240[4] (Figure 9).

Figure 9. Specifying Physical Address of Emulation Hardware With CC_Setup

12 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

When using the XDS560 emulation hardware, the plug-and-play software of the PC operating
system automatically detects the default address for the hardware (Figure 10). Within the board
properties of the XDS560, you also have the option of selecting what clock speed you want to
use for TCK[5]. You may want to allow the hardware to select the optimal clock speed for your
setup.

Figure 10. Automatic HW Detection of the XDS560

Emulation Fundamentals for TI’s DSP Solutions 13

SPRA439B

Then we must enter the processor configuration. In a single-processor setup, this simply means
selecting the device from the processor family we have chosen, and clicking on Add Single. We
can accept the default processor name, or create our own (Figure 11).

Figure 11. Specifying Processor Configuration Within CC_Setup

14 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Finally, we can select a GEL file that we want to run when Code Composer Studio opens
(Figure 12). The General Extension Language (GEL) is an interpretive language similar to C that
lets you create functions to extend Code Composer Studio’s usefulness.

Figure 12. Defining the GEL File to be Used When Opening CCS

When finished, click the Finish button and your setup should be shown in the left-hand column
(Figure 13).

Figure 13. Viewing the System Configuration Within CC_Setup

Emulation Fundamentals for TI’s DSP Solutions 15

SPRA439B

2.3 Multiple Processor Debug

When multiple devices are included in the scan chain, the data needs to be scanned serially
through all of the devices and the signals need to be connected as shown in Figure 14.

Target Device
EMU0
EMU1
TRST
TMS
VCC TDI
TDO
TCK

VCC
Emulation Header Target Device
5 TVD EMU0 13 EMU0
EMU1 14 EMU1
TRST 2 TRST
4 GND TMS 1 TMS
6 GND TDI 3 TDI
8 GND TDO 7 TDO
10 GND TCK 11 TCK
12 GND TCK_RET 9

Figure 14. Emulator Connections for Multiprocessor Systems

As discussed in Section 1.2, the scan manager controls the bits that are scanned into and out of
the scan chain such that the information is directed to the correct target processor as well as
data coming out being directed to the proper debugger session. For this reason, it is imperative
that the scan manager know exactly which devices are in the scan chain and what order they
are in.
Devices should be entered in the order in which they are physically located within the JTAG
scan chain (from TDI to TDO).

2.3.1 Homogeneous Multiprocessor Debug

When multiple processors of the same type are used in the same scan chain, each processor
must have a unique name, but must have the same TI definition for that processor. In this case,
we can either use the Add Multiple button from Figure 11—in which case the processor names
are simply named sequentially, or we can enter our own names and specify Add Single after
each new name is entered as shown in Figure 15.
As stated earlier, devices should be entered in the order in which they are physically located
within the JTAG scan chain (from TDI to TDO).

16 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Figure 15. Specifying a Multiprocessor Configuration Within CC_Setup

The resulting System Configuration for this system is shown in Figure 16.

Figure 16. Viewing a Multiprocessor Configuration Within CC_Setup

2.3.2 Heterogeneous Multiprocessor Debug

When multiple processors are to be debugged, but they are from different TI processor families,
it is necessary to set up the system for Heterogeneous Multiprocessor Debug. Each processor
must have a unique name, and must have the appropriate TI definition for that processor.

Emulation Fundamentals for TI’s DSP Solutions 17

SPRA439B

When setting up the system for Heterogeneous Debug, the Available Board/Simulator Type
selected must be capable of supporting processors from different families. You can specifically
identify which families are supported within the driver selected by viewing the right-hand
windowpane to see details of the driver, including Processors Supported (Figure 17).

Figure 17. Specifying a Heterogeneous Multiprocessor Configuration

If the TI processors that you are using in your heterogeneous processor system are not listed as
being supported with any of the available drivers, contact Texas Instruments Technical Support
for more assistance. Go to ti.com and select the link to Support for more information.
Figure 18 shows a system setup with a TMS320C55xt DSP device and a TMS470R2x
microcontroller device. In this case, we select the device from the Available Processors and
either select the default name or enter our own name before pressing Add Single. Upon
completing the entry of the individual devices within the scan chain, your system configuration
should be complete (Figure 19).

18 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Figure 18. Specifying the Processors in a Heterogeneous Multiprocessor Configuration

Figure 19. Viewing a Heterogeneous Multiprocessor Configuration

Upon exiting CC_Setup, the information contained in the System Configuration is converted into
a binary format for use by the emulation scan manager.

2.4 Scanning Through Non-Debug JTAG Devices

It is also possible to scan information through the JTAG ports of devices that are not being
debugged via the TI Emulator. This condition arises if a customer wants to perform boundary
scan on devices within their target board. Boundary scan is performed using the JTAG header
as well, but uses different software than is used for TI’s emulation.

Emulation Fundamentals for TI’s DSP Solutions 19

SPRA439B

When devices are included in the JTAG scan path, but are not being emulated, it is possible to
scan the emulation information through these devices by putting them in BYPASS mode. It is
first necessary to understand how large their JTAG instruction registers are.
Figure 20 shows an example of a design in which devices exist in the JTAG scan path that are
not being emulated, and are placed in BYPASS mode.

Figure 20. Specifying Non-Emulation Devices in BYPASS Mode

In this case, the bypass device named Other has a JTAG instruction register length of four bits.
This information is passed on to the scan manager such that the JTAG registers can be set up to
bypass through these devices. Note also, that the chip in front of the descriptor (in this case
Boundary Scan Device) for bypass devices shows up with a ? indicating that the emulation
software knows nothing of the device other than its JTAG instruction register length.

3 Establishing Communication With Your Emulation Hardware and

Target
Once you have installed your emulator hardware and set up your board configuration, it is time
to establish communication with the hardware from your host computer. This section explains
some of the files used to confirm connectivity of the hardware.

20 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

3.1 Hardware Setup

Before executing any files, make sure that your emulator is set up according to the directions
that were included in shipping. Make sure that the 14-pin JTAG header is connected from the
emulator pod to the target and that the emulator pod is connected to your host computer by the
appropriate means (ISA card, Parallel Port, SCSI bus, etc.), depending on which emulator you
are using.

3.2 Physical I/O Space of Your Emulation Hardware

Be sure to confirm the physical address of the emulator on your host computer.
The XDS560 installation makes use of the plug-and-play capabilities in most PCs today. With
this capability, the Code Composer Studiot software is able to detect the address of the
hardware without having to explicitly define the address.
If you are using an ISA slot in a PC, the XDS510 requires 32 bytes of IO space on the PC and
comes shipped with a default setting of 0x0240–0x025F. If this space is already taken within
your PC, you can set the board to be addressed elsewhere in the I/O space (0x0280, 0x0320,
0x0340)[6].
Similarly, if you are using an XDS510-PP, the default address is 0x0378. And the default SCSI
address on an XDS510-WS is address 4. The XDS510 ISA card and XDS510-WS require
changing switches on the hardware if the default location is not available on the host computer.
On older versions of TI debuggers, it was necessary to enter environment variables to specify
the physical address of the emulation hardware. However, it should not be necessary to use
environment variables for this purpose when using Code Composer Studio, as that information
is entered within CC_Setup.

3.3 Invoking Emulation-Reset

You are now able to invoke the Emulation-Reset software. This software resets the internal
emulation debugging logic as well as several other functions. Depending on which debugging
software you are using, the emulation-reset software may have a different name. The program
that ships with Code Composer Studio is XDSReset.exe, while the older debuggers include the
software as EMURST.exe.
Among the functions performed by the emulation-reset software are:
1. Check for the correct I/O address of the emulator hardware.
2. Verify that there is no debugger currently running in multiprocessor mode.
3. Reset the Test Bus Controller.
4. Check if power exists on the Target Voltage Detect (or Presence Detect) pin. If not, pull
TRST_ high and generate error message CANNOT DETECT TARGET POWER. If TVD
has power, then pull TRST_ low and then high.
5. Put the device in Test Logic Reset (TLR).
6. Check if the device is in TLR. If not, create the error message XDS510 RESET FAILED.
In most cases, this setup goes smoothly, and you are now ready to begin debugging your
software by starting the emulator.

Emulation Fundamentals for TI’s DSP Solutions 21

SPRA439B

3.4 Invoking the Emulation Debugger

When invoking the emulation debugger, you simply need to double-click the Code Composer
Studio icon—which should execute CC_App.exe. There are several parameters that can be
passed when invoking CC_App, including specification of a desired GEL file, and other options.
Refer to the user’s guide that shipped with your debugging software for more information on
these options. This user’s guide is likely a softcopy document.

3.5 Using the Parallel Debug Manager

When debugging systems that have more than one TI device defined, you are required to use
the Parallel Debug Manager (PDM). The Parallel Debug Manager provides a method of
synchronous debugging of your multiprocessor application.

If you have configured a multiprocessor system within CC_Setup, the Parallel Debug Manager is
automatically invoked when you start CC_App.

After the Parallel Debug Manager is invoked, you can spawn emulator sessions from within the
PDM environment similar to the way they are invoked from the icon in a single-processor system
configuration (Figure 21). PDM has provisions to allow for grouping of the processors within the
JTAG scan path to provide debugging commands to a select set of processors without all of the
processors being affected.

Figure 21. Opening Debug Sessions From the Parallel Debug Manager

The Parallel Debug Manager allows single-point control of starting and stopping of several
processors synchronously. Synchronous debug includes the ability to synchronously start, stop,
and step the processors (Figure 22). It also includes the ability to perform global breakpoints
through the use of the EMU signals as detailed in Section 1.3.

Figure 22. Parallel Debug Manager

Additional details on the Parallel Debug Manager are available in the C Source Debugger User’s
Guide for the specific processor you are using.

22 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

4 Trouble-Shooting Emulation Setup Errors

4.1 Emulation Reset Errors
If you have run into errors when invoking the emulation reset software, first check the set up of
the physical connection to the host computer and make sure that power is supplied to the target.
Also make sure that the signals on the board are buffered if the device is more that 6 inches
from the JTAG header, as shown in Figure 5. You may also want to inspect the TCK_RET signal
on an oscilloscope. This indicates the integrity of the signals on the board in terms of cleanliness
as well as magnitude. A weak signal on TCK_RET may indicate that buffers are needed in your
system to accommodate long paths. The absence of TCK_RET or TVD indicates a connectivity
problem within your setup.
Before invoking the emulator you should…
• Make sure to note the settings on your physical XDS510 board regarding the I/O space
addressed.
– Make sure to set the I/O space address accordingly within Code Composer Setup.
– If you are using a parallel port debugger, make sure that you set the I/O address
correctly and that the parallel port on your PC is set up to support the mode which you
intend to use it (i.e., SPP4, SPP8, ECP). Refer to the manufacturer’s instructions on
parallel port setup.
Errors in the emulation hardware address result in the error message: CANNOT DETECT
TARGET POWER. Make sure that you have set up the XDS510 correctly before looking for
errors on your target.
When resetting an XDS560 board, there are several errors that can be displayed. This hardware
checks connectivity to the target board at several locations including:
• The emulation board within the PC
• The board’s connection to the JTAG cable
• And the cable’s connection to the target
Errors in the above connections result in messages—covered in Table 5 as well as thoroughly
detailed in the XDS560 Troubleshooting Guide[7].

4.2 Emulator Errors

Occasionally, a target passes emulation-reset, but yields errors when invoking the emulator. We
address some of these errors and possible setup conditions that might yield the errors.
Among the most common problems encountered when starting the emulator are simply system
configuration errors. System configuration errors cause a variety of errors. For example, if the
devices that are defined within CC_Setup are not the same, or even in the wrong order as those
on the physical target, you may see data errors. These errors may include all zeros, all ones (or
Fs if viewing HEX data), or repetitive bit patterns throughout registers and memory displays.
The emulator is still sometimes able to start with an incorrect board configuration. However, it
does not scan out the correct information. This is due to the fact that the scan manager is
distributing the information coming out of the TDO pin to the corresponding debugger window. If
the device ordering in the system configuration is incorrect, the bit-stream coming out of TDO is
incorrectly broken up and the debugger window does not get the correct information for the
target device you intend to debug.

Emulation Fundamentals for TI’s DSP Solutions 23

SPRA439B

If it appears that the board configuration is correct within CC_Setup and the bits being displayed
in the emulator are all zeros or all ones, the physical connection of the JTAG signals should be
investigated. A solder short across a JTAG header can cause signals to be shorted and give
erroneous information at the TDO pin. Make sure to test each of the JTAG signals described in
Table 4 and Table 5.
Documentation on some of the newer TI devices refers to signals called ET0, ET1, and TVD.
These signals are identical to the traditional signals called EMU0, EMU1, and PD, respectively.
However, there names have been changed to better reflect their use within TI’s emulation
solutions.
Presence Detect (PD) has been renamed Target Voltage Detect to indicate that, not only is it
used to detect the presence of a target being connected to the JTAG header, but it is also used
to detect the level of the voltage on the JTAG signals for that device. On the newer emulation
hardware, the JTAG pod is able to adapt the voltage to match the voltage of the target. This
provides a means of interfacing with legacy devices, which operated at a higher voltage (up to
5 V) as well as the newer devices, whose JTAG signals are capable of operating down to the
CPU voltage of 1.8 V and below.
Monitor each signal on an oscilloscope to determine if it is at the appropriate level, or if it is
changing as it should be.
Table 4 shows the standard signals included on the JTAG header that should be investigated
and what level should be expected at each pin, depending on the mode of operation.

Table 4. JTAG Signal Activity for Connectivity Verification

JTAG
CONDITIONS
SIGNAL
TVD (PD) HI Vcc or I/O voltage (if different than CPU) of the device if target board has power
TCK Both 10.368 MHz square wave clock signal coming from the JTAG pod on the XDS510. Faster clocks possible on XDS560.
TCK_RET Both Duplicate of TCK. If this signal is dirty or attenuated, buffers should be used on the JTAG signals as shown in Table 5.
TMS Both Controls the state machine, so it should change every time another debug operation is performed
Low When the device is in Run-Test/Idle mode.
HI When the device is set in Test Logic Reset state
Active-Low signal: Emulation logic should be out of reset to perform emulation
TRST HI NOTE that if this signal is not pulled down internally on the specific device you are using, this signal should have a
pull-down resistor on it to ensure that the emulation logic is RESET when the emulation hardware is not attached.
This signal is the information that is being scanned into the target from the emulator pod. It should change levels as
TDI Both
data is scanned through the target
This signal is reading internal information from the target and should be changing to reflect the data that is being
TDO Both
scanned out.
GND Low This signal should be clean and zero volts.

24 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Table 4. JTAG Signal Activity for Connectivity Verification (Continued)

JTAG
CONDITIONS
SIGNAL
At start–up, these signals are typically HI, as they are used to indicate global breakpoints as well as being used for
benchmarking and profiling.
EMU0/EMU1 HI NOTE that if these signals are not pulled up internally on the specific device you are using, you should place pullup
resistors on them to ensure that they are inactive when the emulation hardware is not attached.
On some devices, they can affect the operational mode of the device if they are not pulled up.
If the device has hit a global breakpoint which has caused a CPU halt for debug, the EMU signals may still be low
Low
to indicate that the break conditions have been met.
If the device is actively being debugged and you are performing such functions as benchmarking, profiling, or RTDX,
Both
the EMU signals may be toggling to transmit data to the emulation hardware board.

By viewing the signals shown above on an oscilloscope, you can determine if the signals are
changing properly during normal emulation and emulation startup. If you cannot get your
emulator started due to errors, make sure to monitor these signals at the time of invoking the
emulator to determine if there is activity on them.

5 Troubleshooting Guide
In the event that your emulator tools cause errors that you do not understand, Table 5 allows you
to determine some of the commonly found errors in the emulation setup. Look in the first column
to determine the error you are seeing, and then use the second column to track down the
possible errors.

Table 5. Troubleshooting Guide for Emulation Errors

PROBLEM POSSIBLE SOLUTION
Error Message: CANNOT DETECT TARGET • Make sure that the target has proper voltage supplied to it
POWER • Check that the emulator board is securely installed
• Check that the cabling is securely connected between the emulator and the target
• Make sure that the port address of the emulator hardware is set correctly
• Make sure that the emulator hardware setting for the port address correspond to that entered
within CC_Setup
• Make sure you don’t have another I/O device conflicting for the same I/O space on your host
computer
Error Message: CANNOT INITIALIZE THE • Make sure that the target has proper voltage supplied to it
TARGET!! • Make sure the processor is not in RESET
• Make sure that the port address of the emulator hardware is set correctly (as explained
above)
• Check that the cabling is securely connected between the emulator and the target
• Make sure you have correctly entered the board information within CC_Setup.
• Run the Emulation Reset software before invoking the emulator to verify that emulation logic
is in proper state
Error Message: Processor access timeout • External device may be holding the hardware HOLD signal
• Processor may be waiting for READY signal from external peripheral
Data in the debugger screen displays all • Check the solder connections on the JTAG header for short circuits. Check the board
zeros or all F’s schematics to ensure proper routing of the JTAG signals
• Make sure you are using the correct board configuration within CC_Setup
Data in the debugger screen displays • Make sure you are using the correct board configuration file
repetitive bit -patterns
Data in the debugger screen displays • Check for dirty signals on the JTAG header
random bit-patterns where specific data is • Check memory map definition with that in the debugger initialization file to ensure that there
expected is actually memory present

Emulation Fundamentals for TI’s DSP Solutions 25

SPRA439B

Table 5. Trouble-Shooting Guide for Emulation Errors (Continued)

PROBLEM POSSIBLE SOLUTION
Error Condition: • Make sure that the target has proper voltage supplied to it.
• Check that the emulator board is securely installed.
Code Composer Studio halts at splash • Check that the cabling is securely connected between the emulator and the target.
screen. (Windows 98 only)
Error Message: The cable pod is not connected or is improperly connected at the back of the PC. Verify that
Can’t Initialize Target CPU: cable is connected and that the pod connector’s screws are tightened into the XDS560 PCI
SC_ERR_CTL_CBL_BREAK_NEAR <–182> bracket.
Error Message: The target header from the XDS560 pod is not connected or is improperly connected to a
Can’t Initialize Target CPU: target board.
SC_ERR_CTL_CBL_BREAK_FAR <–183> The cable pod is not connected or is improperly connected at the back of the PC. Verify that
cable is connected and that the pod connector’s screws are tightened into the XDS560 PCI
bracket.
On some PENTEK boards, the target emulation header uses the Target Disconnect pin of
the XDS560. Verify that pin 4 of the target board emulation header is grounded. If not, then
add a wire-wrap wire from pin 4 to pin 8 of the target emulation header. Refer the XDS560
Technical Reference Manual for additional information.
Error Message: Make sure that the target has proper voltage supplied to it.
Can’t Initialize Target CPU: Check that the emulator board is securely installed.
SC_ERR_NO_TRG_POWER <–180> Check that the cabling is securely connected between the emulator and the target.
Make sure that the XDS560 hardware settings for the port address are correct

6 Other Debugging Diagnostic Tools

6.1 XDS Probe

XDSPROBE.exe is a utility that ships with Code Composer Studio. It is capable of exercising the
JTAG scan path to test for connectivity to the target device as well as determining if device(s)
match what is defined within the board configuration file from CC_Setup.
There are far more capabilities to this tool which are defined within the on-line documentation
within Code Composer Studio. The tool can be found in the \ti\cc\bin directory.

6.2 Third Party Tools

Texas Instruments has an extensive third party network that develops tools for the TI DSP
Solutions (Go to ti.com and select the link to Getting Started with DSP). Occasionally, these
companies will create their own tools to aid in verifying connectivity of the XDS510 for emulation.
These tools can be used as additional aids to what is described in this document.
Support of these tools as well as questions regarding their use should be directed through the
third party.

6.3 Bulletin Board Tools

Texas Instruments also occasionally develops special tools to perform specific tasks and places
them on the TI Electronic Bulletin Board (Go to ti.com and select the link to Support and then
DSP FTP Support Site) for free access. These tools can be downloaded and used at the user’s
discretion. These tools are provided for free, and as such, are not supported.

26 Emulation Fundamentals for TI’s DSP Solutions

 SPRA439B

Among these tools on the Bulletin Board is a tool called XDS_DIAG.EXE. This tool is an older
tool, which performs similar functions to XDSPROBE.

6.4 Future Tools Development

Texas Instruments is dedicated to the development of industry-leading development and debug
tools. As such, TI is continually developing new capabilities, which allow customers increased
flexibility and visibility in software development.
Updates to these and other tools may be available upon occasion via the Update Advisor within
Code Composer Studio. Be sure to check for updates occasionally.
Keep in touch with your local distributor and/or TI representative to stay abreast of the newest
tools and technology available. You can also monitor the Bulletin Board and internet homepage
to find new capabilities as TI announces additional developments.

7 References
1. IEEE Std 1149.1 (JTAG) Testability Primer, (literater number SSYA002)
2. XDS51X Emulator Installation Guide, (literature number SPNU070)
3. JTAG/MPSD Emulation Technical Reference, (literature number SPDU079)
4. XDS51x Emulator Installation Guide, (literature number SPNU070)
5. XDS560 Emulator Technical Reference, (literature number SPRU589)
6. XDS51x Emulator Installation Guide, (literature number SPNU070)
7. XDS560 Troubleshooting Guide, (literature number SPRU503)

Emulation Fundamentals for TI’s DSP Solutions 27

 IMPORTANT NOTICE

Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications,
enhancements, improvements, and other changes to its products and services at any time and to discontinue
any product or service without notice. Customers should obtain the latest relevant information before placing
orders and should verify that such information is current and complete. All products are sold subject to TI’s terms
and conditions of sale supplied at the time of order acknowledgment.

TI warrants performance of its hardware products to the specifications applicable at the time of sale in
accordance with TI’s standard warranty. Testing and other quality control techniques are used to the extent TI
deems necessary to support this warranty. Except where mandated by government requirements, testing of all
parameters of each product is not necessarily performed.

TI assumes no liability for applications assistance or customer product design. Customers are responsible for
their products and applications using TI components. To minimize the risks associated with customer products
and applications, customers should provide adequate design and operating safeguards.

TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right,
copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process
in which TI products or services are used. Information published by TI regarding third–party products or services
does not constitute a license from TI to use such products or services or a warranty or endorsement thereof.
Use of such information may require a license from a third party under the patents or other intellectual property
of the third party, or a license from TI under the patents or other intellectual property of TI.

Reproduction of information in TI data books or data sheets is permissible only if reproduction is without
alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction
of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for
such altered documentation.

Resale of TI products or services with statements different from or beyond the parameters stated by TI for that
product or service voids all express and any implied warranties for the associated TI product or service and
is an unfair and deceptive business practice. TI is not responsible or liable for any such statements.

Mailing Address:

Texas Instruments
Post Office Box 655303
Dallas, Texas 75265

Copyright  2002, Texas Instruments Incorporated