XDS Target Connection Guide

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

  • Image:Google-16x16.png Search for an article here:

Contents



Introduction

Texas Instruments supports a variety of eXtended Development System (XDS) JTAG controllers with various debug capabilities beyond only JTAG support.

If your device supports the export of core trace or system trace over the EMU pins and you want your target to be compatible with XDS products capable of acquiring either trace types; for guidelines, see SPRU655.

For all other debug functions, regardless of the XDS product type, this document describes target requirements that, when followed, allow for compatible operation between most XDS products. Even when a specific XDS supports a different native header, adapters are available that allow for swapping between XDS products.

Currently the XDS family consists of the following product types:

  • XDS100 v1
  • XDS100 v2
  • XDS510
  • XDS560
  • XDS560T
  • XDS560 v2 System Trace

Warning: You must confirm that a specific XDS supports the voltage level of your target device or devices. Adapters are available that also support voltage translation, if required. For specific operating voltage ranges and operating frequencies, see your manufacturer's documentation.

For the latest material regarding TI's XDS products, see TI's Foundational Tool Emulation WIKI site at:

Category:Emulation

Related page at: JTAG Connectors

XDS Features

This article describes the requirements necessary to incorporate an XDS header on a board that includes devices that support a variety of debug features. Table 1 shows the relationship of XDS types and headers to specific features.


Table 1. XDS Features
Feature(2) XDS100v1 XDS100v2 XDS510 XDS560 XDS560 w/Rev D Target Cable XDS560T XDS560 v2 System Trace
Header Type/ Pins 14/20CTI(4) 14/20CTI(4) 14 14 20 CTI TI 60 MIPI 60
Adaptive JTAG Clocking(1) n/a X X(5) X(5) X n/a X
Emulation Boot Modes X X X X X X X
HS-RTDX n/a n/a n/a X X n/a n/a
Core Trace(3) n/a n/a n/a n/a n/a n/a n/a
System Trace(3) n/a n/a n/a n/a n/a X X
Target Voltage Reference (TVRef) X X X X X X X
System Reset (nReset) X(4) X(4) n/a n/a X n/a X
  1. Only used for devices with ARM cores.
  2. For exact specifications on features and compatible voltage levels, see your XDS manufacturer's documentation.
  3. If your device supports the export of core trace or system trace over the EMU pins and you want your target to be compatible with XDS products
    capable of acquiring either trace types, see the guidelines in SPRU655.
  4. XDS100v1 and XDS100v2 can be manufactured with 14, 20 or both connectors in some configurations. If your XDS100v1 or XD100v2 supports the
    20-pin connector it may also support the System Reset feature. For details, see your specific manufacturer's documentation.
  5. To determine if your specific XDS supports adaptive clocking, check with your XDS manufacturer.

There are four classes of signals on the XDS header:

  • JTAG
  • EMU
  • TVRef
  • nRESET

TVRef

TVRef is supported on all headers and is used by the XDS to detect the absence of target power and set the input level on EMU and JTAG voltage translation devices within the XDS, if used. For the voltage range supported by your specific product, check with your XDS manufacturer. Adapters are generally available for XDS systems that don't meet the voltage level requirements of a specific device.

nReset

nReset, for XDS products that support it, provides a mechanism for remotely resetting your entire system if the nReset signal from the emulation header is integrated into your applications power-up-reset hardware. XDS products that don't support this feature are generally only capable of resetting the TI devices on the scan chain.


Adaptive Clocking

TI devices that utilize an ARM core that requires Adaptive Clocking support an RTCK pin. RTCK is used by the XDS (if it supports Adaptive Clocking) to gate TCK until the XDS detects the RTCK edge in response to the previous TCK edge. The RTCK delay allows the ARM core to synchronize the JTAG input signals to the core's functional clock rate, thus automatically scaling TCK to the ARM's functional clock rate.

Use of Adaptive Clocking with devices that support an RTCK pin will result in:

  • Higher performance (faster downloads and step speeds) than without Adaptive Clocking.
  • Greater debugger stability.

The XDS must be enabled for adaptive clocking mode through the debugger.

If your TI device has an RTCK pin, then this pin must be connected to the XDS header's RTCK signal, regardless of the target header type used. If your XDS supports adaptive clocking, it must be enabled through the IDE (CCS). If your XDS does not support adaptive clocking an adapter may be required to achieve the device's full JTAG operating rate. Running the XDS with a TCK rate that is less than 1/8th the ARM's functional clock rate is also an option if adaptive clocking is not supported by your XDS.

 For additional requirements for target cards that support multiple TI devices that support RTCK, see the  Multi-device Adaptive Clocking section.

Corner Case

Please read Adaptive Clocking for additonal information.



EMU Pin Functions

EMU pins are bi-directional multifunctional pins that provide support for the following features:

  • Boot Modes
  • Cross Triggers
  • Core Trace
  • System Trace
  • HS-RTDX

In the case of Boot Modes, the EMU0/1 pin state is driven by the XDS. HS-RTDX provides bi-directional data transport. Both Core and System Trace transport event history and timing data from the target to the XDS. Cross triggers are bi-directional triggers that allow an event in one device to cause a debug action in other devices. To determine which EMU pins are used for each function, see the device's data sheet.

Boot Modes

Boot modes are values on the EMU pins that are driven by the XDS to the target and sampled by the target on the rising edge of nTRST or at device power-up. Boot modes can also be used to force some devices into the "Wait-in-Reset" state. The EMU pins that are used for boot modes can also be used for other functions once the boot is complete or reset is released, such as trace or HS-RTDX.

Cross Triggers

When an EMU pin is used for a cross trigger, since the EMU pins are bi-directional, there is no need to dedicate an EMU pin as output or input trigger. Events that trigger out an EMU pin can be set up in multiple devices. At the same time all those devices can also be set to react to a trigger-input on the same EMU pin.

HS-RTDX

HS-RTDX transports bi-directional data over an EMU pin, typically over either EMU0 or EMU1, at the JTAG TCK frequency at a maximum frequency of 35 MHz. If your design uses multiple TI devices that support HS-RTDX, and your XDS supports multiple HS-RTDX channels (the XDS560 supports HS-RTDX over EMU0 and EMU1), you may run HS-RTDX simultaneously with two devices. HS-RTDX requires integration with a target library. An XDS, such as the XDS560, that supports HS-RTDX is also required.

Core and System Trace

Core trace typically provides, at a minimum, processor PC trace and, depending on the silicon implementation, may also provide processor data trace and event trace. System trace is a message-based technology that, in enabled silicon, can export application instrumentation and hardware generated messages from system-level monitors. Many devices support on-chip Embedded Trace Buffers (ETBs) either exclusively or in combination with support for exporting trace data through the device's EMU pins. In cases where a device exclusively utilizes an ETB, a trace capable header (either the TI or MIPI 60-pin headers) is not required to replace the traditional 14- or 20-pin headers on the board, but ETBs only allow visibility to shallow snapshots of data (typically in the 4 KB to 32 KB range). To determine if your device supports exporting core or system trace through the EMU pins and/or supports one or multiple ETBs, see the device data sheet. The advantage of exporting Core and System Trace data through the EMU pins to an XDS with trace capture support, such as the XDS560T or XDS560 v2 System Trace product, is that the capture depth is much greater, providing a much larger region of visibility and enabling precise profiling and code coverage tooling.

In the case of core trace export or if core trace and system trace export are both supported by a TI device, this requires utilizing a 60-pin header in place of the traditional 14- or 20-pin emulation header. In the case where a device only supports export of system trace data, a TI 20-pin CTI header may be used. Regardless of which header you choose, when designing a system for core trace or system trace there are additional design considerations and constraints that are beyond the scope of this document. When designing a system for either core trace or system trace we recommend that you follow the guidelines in SPRU655.

Not all XDS, target cables, and target device combinations support all emulation features. For your specific XDS and the data sheet for your device to confirm that the desired functionality is supported, see the user's guide.

Adapters

Pin converting adapters allow most XDS products to be used with any target that utilizes one of the standard supported headers. Use of any adapter can have a negative impact on performance.

Additional target adapters are supported to adapt 3.3v XDS products down to lower voltage target IOs and to support Adaptive Clocking required for devices with ARM cores.

Table 2. JTAG Cable Adapters
For XDS Type: From XDS To Target Notes
XDS560/XDS510/XDS100v1 TI 14-Pin TI 60-Pin
XDS560 Rev D TI 20-Pin TI 60-Pin
XDS560T TI 60-Pin TI 14-Pin
XDS560T TI 60-Pin TI 60-Pin Pin Saver
XDS560 v2 System Trace MIPI 60-Pin TI 20-Pin (CTI) Check Availability
XDS560 v2 System Trace MIPI 60-Pin TI 14-Pin Check Availability
XDS560 v2 System Trace MIPI 60-Pin TI 60-Pin Check Availability
XDS560 v2 System Trace MIPI 60-Pin ARM 20-Pin Check Availability
XDS560/XDS510/XDS100(1) TI 14-pin TI 20-pin
XDS560 TI 20-pin TI 14-pin
XDS560 TI 20-pin ARM 20-pin
  1. A TI 14-pin to TI 20-pin adapter can be used with a TI 20-pin to
    ARM 20-pin if you need to connect an XDS510 or 14-pin XDS100
    to an ARM 20-pin header.

JTAG Adapter Overview

There are two types of connectors:

  1. Emulator-This is the connector on the emulator/JTAG ICE/UIF/XDS unit
  2. Target-This is the connector on the target card

Types of adapters:

  1. Pin Converters-Passive conversion of one connector type to another
  2. Adapter-Some active components for different purposes. Ex: Addition of adaptive clocking, buffering of TCK/RTCK signals, Isolation, etc.

Adapter Part Numbers

Adapters
TI Part Number, Link to product, or 3rd party product Number Target connector
10-pin ARM 14-pin TI 20-pin TI 20-pin ARM 60-pin TI 60-pin MIPI
Emulator Connector 10-pin ARM N/A Roadmap Roadmap MDL-ADA2
14-pin TI TMDSADP1414-ISO (Isolation adapter) or TMDSADP1414 (Voltage Translation, RTCK Signal Boost, and Adaptive Clocking) TMDSADP1420; (Voltage Translation, RTCK Signal Boost, and Adaptive Clocking) or TMDSADPEMU-20T (RTCK Signal Boost) TMDSADPEMU-20A (RTCK Signal Boost) TMDSADP1460 Roadmap
20-pin TI Usually supplied by manufacturer with emulator. Check manufacturer. N/A Usually supplied by manufacturer with emulator. Check manufacturer. Usually supplied by manufacturer with emulator. Check manufacturer. Roadmap
20-pin ARM Lauterbach LA-7748 (Code JTAG-ARM-CON-20-TI14)
 TMDSADPEMU-20T (RTCK Signal Boost) TMDSADPEMU-20A (RTCK Signal Boost) Roadmap
60-pin TI Usually supplied by manufacturer with emulator. Check manufacturer. N/A Roadmap
60-pin MIPI Usually supplied by manufacturer with emulator. Check manufacturer. Usually supplied by manufacturer with emulator. Check manufacturer.  Usually supplied by manufacturer with emulator. Check manufacturer. Usually supplied by manufacturer with emulator. Check manufacturer. N/A

Useful Tip

Adapters available from TI can be found at:
http://focus.ti.com/docs/toolsw/folders/print/tmdsadp.html
TI third parties also provide adapters.

Emulation Header Signal Definitions

Every XDS and corresponding target header supports the following IEEE 1149.1 standard signals.

Table 3. JTAG 1149.1 Port Description
PIN XDS Signal
Type(1) 		Target Signal Type NAME DESCRIPTION
TRST- O I Test Logic Reset When asserted (low active) causes all test and debug logic in the device to be reset along with the IEEE 1149.1 TAP.
TCK O I Test Clock This is the test clock used to drive an IEEE 1149.1 TAP state machine and logic. Depending on the XDS attached, this is either a free running clock or a gated clock that requires on RTCK monitoring.(2)
TMS O I Test Mode Select Directs the next state of the IEEE 1149.1 TAP state machine
TDI O I Test Data Input IEEE 1149.1 Scan data input to the device
TDO I O Test Data Output IEEE 1149.1 Scan data output of the device
RTCK(5) I O(4) TCK Return Depending on the XDS attached the JTAG signals are clocked out with RTCK(3). An XDS that supports adaptive clocking monitors RTCK to determine when to gate TCK.
  1. I = Input, O = output, relative to the XDS.
  2. If a device with an ARM core is connected, adaptive clocking may be required (TCK is gated requiring RTCK monitoring by the XDS) to operate TCK above 4 MHz.
  3. The XDS100v1 does not support RTCK but TI recommends connecting it per section N to remain compatible with other XDS products.
  4. If your device supports an RTCK pin, connect it to this emulation header pin. See Adaptive Clocking.
  5. Other TI documents refer to RTCK as TCK_RET or TCLKRTN.

The following signals may also be present on your XDS Target Cable and are common to many XDS products. For the signals supported for each specific header type, see section X. 

Table 4. Additional Common Emulation Header Signal Descriptions
PIN XDS Signal Type Target Signal Type NAME DESCRIPTION
TVRef(2) I O Target Voltage Reference Should be tied to the I/O voltage of the target device. Used to detect if power is active and to set JTAG signal voltage level translators if supported by the XDS(1).
TDIS I O Target Disconnect XDS that support this signal can detect the difference between a powered-down target and when the target cable is not physically connected.
EMU[0:n] I/O(1) I/O Emulation Port Depending on your device and XDS, EMU pins support boot modes, cross triggers, HS-RTDX, Core Trace and System Trace. See your XDS user’s guide and device data sheet for supported features.
nRESET(3) O I Target Reset This is an optional signal that if integrated into your applications power-up-reset circuit may be used to remotely reset the target board from a debugger.
  1. To confirm compatibility with your XDS for signal types voltage levels, check your specific device’s data sheet.
  2. Other TI documents refer to TVRef as TVD, VREF_DEBUG, and VTRef (ARM’s naming convention).
  3. Other TI documents refer to nRESET as nSYSRST or nTGTRST.

Header Information

  • Target cable design and connectors vary between XDS manufacturers. For target mechanical requirements that could impact device heights in proximity to the emulation header on your board and possible keep-out areas required for good connection and room to disconnect the cable connector, see your XDS manufacturer’s documentation.
  • For TI 60-pin and MIPI 60-pin header information, see SPRU655.


Header Recommendations
Processor Family Recommended Header Alternate Header Notes
C2000/C5000/C6000 (no ARM in device) 14 pin TI Header 20-pin TI Header
MSP430 MSP430 14-pin Header
OMAP / Sitara / Davinci (device has one or multiple ARM CPU, but does not support MIPI System Trace (STM), core tracing, or ARM ETM/TPIU core tracing to the pins) 20 pin TI header 20 pin ARM Header 20 pin ARM header if compatibility with ARM tools is desired
OMAP / Sitara / Davinci / C6000 (device supports CTools MIPI System Trace (STM) but NOT core tracing or ARM ETM/TPIU core tracing to the pins) 20 pin TI header 60 pin MIPI connector 20 pin TI header recommend for maximum MIPI STM trace performance. 60 pin MIPI conector a possibility if compatiblity with devices which support Core tracing/ETM+TPIU is desired.
OMAP / Sitara / Davinci / C6000 (device supports CTools MIPI System Trace (STM)  AND core tracing or ARM ETM/TPIU core tracing to the pins) 60 pin MIPI connector ARM 34 pin Mictor 60 pin MIPI connector recommended to support both MIPI STM and core tracing. ARM 34 pin Mictor only recommended when XDS support is not needed and compatiblity with ARM tools is required.


Table 5. Summary: TI 14-pin Header Information

Manufacturer: Samtec USA
Model Number: TSM-17-DV
Manufacturer’s Overview: http://samtec.com/technical_specifications/overview.aspx?series=TSM


Table 6. Summary: TI 20-pin Header Information

Manufacturer: Samtec USA
Model Number: FTR-110-51-S-D-06
Manufacturer’s Overview: http://www.samtec.com/technical_specifications/overview.aspx?series=FTR
Recommended XDS Connector: RSM-110-02-S-D

or

Manufacturer: OUPIIN (http://www.oupiin.com/)
Model Number: 2212-2X10G00D/2.8-1P6B (surface mount / mate length is 2.80 mm / 1 pin # 6 pulled Bulk package)

2212-2X10G00D/2.8-1P6U (surface mount / mate length is 2.80 mm / 1 pin # 6 pulled tube package)

Manufacturer’s Overview: http://www.oupiin.com/
Recommended XDS Connector: 2212-2X10G00D/2.8-1P6B or 2212-2X10G00D/2.8-1P6U


Table 7. Summary: ARM 20-pin Header Information

Manufacturer: Samtec USA
Model Number: TSM-110-DV
Manufacturer’s Overview: http://samtec.com/technical_specifications/overview.aspx?series=TSM
Recommended XDS Connector: SSW-110-22-G-D-VS


Table 8. Emulation Header Pin Definition
Pin TI 14-pin TI 20-pin CTI ARM 20-pin
1 TMS TMS VTRef
2 TRST nTRST Vsupply
3 TDI TDI nTRST
4 TDIS (GND) TDIS (GND) GND
5 TVRef TVRef TDI
6 KEY KEY GND
7 TDO TDO TMS
8 GND GND GND
9 RTCK RTCK TCK
10 GND GND GND
11 TCK TCK RTCK
12 GND GND GND
13 EMU0 EMU0 TDO
14 EMU1 EMU1 GND
15 nRESET nRESET
16 GND GND
17 EMU2 DBGRQ
18 EMU3 GND
19 EMU4 DBACK
20 GND GND

TI 60-pin and MIPI 60-pin Header Information

  • For TI 60-pin and MIPI 60-pin header information, see SPRU655.


Target Connection Design

It is extremely important to provide high-quality signals between the XDS header on your target and the target device. In some cases you may be connecting multiple devices to a single emulation header or you may need to physically locate the emulation header farther away from the device than what’s recommended for non-buffered operation. Depending upon the situation, you must supply the correct signal buffering and multiple processor interconnections to ensure proper XDS and target system operation.

Current XDS products operate JTAG’s clock in the 10-MHz to 50-MHz range, but future XDS products will operate at higher clock rates; thus, to provide some design margin for duty cycle distortion and compatibility with future XDS products, TI recommends designing JTAG signals for 100-MHz operation.

Also, the target connection requirements are dependent on the features supported by both the device and XDS. For devices and XDS that support core or system trace the board-level design requirements are more stringent because of the higher clock rates of these functions. For design guidelines if your device supports export of core or system trace by the EMU pins, see SPRU655.

In cases where your XDS does not support a feature, such as Core Trace or System Trace, but your target device does support the feature we recommend that you carefully evaluate the trade-offs of designing a target that is compatible with both your current XDS and higher performance XDS that may be required to resolve difficult issues.

Single Device Non-buffered Configuration

If the EMU pins do not support core or system trace and If the routing length of all JTAG and EMU signals between the device and the emulation header are less than six inches then buffering of the JTAG signals is not necessary. For termination and routing guidelines if your device’s EMU pins support core or system trace export, see SPRU655.

The following diagram shows the standard non-buffered signal connections. Each of the following sections discuss cases specific to a signal or header.

Note: The following diagram deviates from previous TI documentation in that TI now suggests utilization of series termination resistors on the JTAG clock signals and TDO. The reason for this change is the latest XDS controllers utilize signal drivers with faster rise and fall times than previous generations, thus increasing the chances of reflections on these critical signals.

Figure 1. Single Emulation Header With Single Target Device and Unbuffered JTAG and EMU Signals (Note 1)

Image:Fig1_Single_UnBuff.jpg

Trace Design Process for single emulation header with a single target device and un-buffered JTAG and EMU signals.

  1. All Routing distances from the device pins to the emulation header must be less than 6 inches.
  2. If your device does not have a RTCK pin then use Configuration 1. For JTAG signal termination requirements for this configuration, see Non-buffered JTAG Signal Termination.
  3. If your target device has a RTCK pin then use Configuration 2. For JTAG signal termination requirements for this configuration, see Non-buffered JTAG Signal Termination.
  4. DVDD is the JTAG/EMU pin IO voltage reference.
  5. For JTAG signal series termination requirements, see Non-buffered JTAG Signal Termination.
  6. Pull-ups on EMU0 and EMU1 may be optional. For cases where external pull-ups are required or should be considered, see EMU pin Considerations.
  7. A pull-down on TRST may be optional. For cases where an external pull-down is required or should be considered, see JTAG and nTRST Special Considerations.
  8. If your device contains more than two EMU pins then it’s likely that it supports the export of core trace or system trace (or both). These are high speed features that impose additional target board requirements (for details, see SPRU655).


Non-buffered JTAG Signal Termination

Figure 1 shows the minimum termination requirements for the JTAG clock signals.

  • If your target device does not have an RTCK signal:
Connect TCK and RTCK as shown for "JTAG Clock Configuration 1" of Figure 1. Loopback TCK supplied by the emulation header to the emulation header’s RTCK. In this configuration, 22-Ω series termination resistors are required for both TCK and RTCK both of which should be placed in close proximity to the emulation header.
  • If your target device has an RTCK signal:
Connect TCK and RTCK as shown for “JTAG CLOCK Configuration 2” of Figure 1. Connect the device’s RTCK to the emulation header’s RTCK. In this configuration a 22-Ω series termination resistor placed in close proximity to the emulation header on TCK. A series termination resistor is also required for RTCK placed as close to the device as possible. The size of the RTCK series termination resistor will typically be in the 22- to 42-Ω range. It should be sized to match the impedance of the manufacturer’s target cable (normally 50 Ω) minus the impedance of the device’s RTCK buffer. The output impedance of a device buffer can normally be determined from the device’s IBIS model. TI document SPRU655 contains an appendix that provides instructions for extracting the RTCK buffer’s output impedance from the device’s IBIS model.
  • For JTAG signals that are not clocks:
On JTAG input signals that are not clocks, series termination resistors are generally not required. On the device’s JTAG output signal (TDO) a termination resistor is required placed as close to the device as possible. To determine the size of the TDO series termination resistor, follow the same instructions for sizing the RTCK series termination resistor.

JTAG and nTRST Special Considerations (includes TMS and TDI)

If your device does not have internal pull-up resistors on TMS and TDI or an internal pull-down resistor on TCK, it is required that these be provided externally on your board.

Since TDO and RTCK are outputs, external pull-up or pull-down resistors are not required.

Most TI devices require nTRST and the device reset to both be asserted at power-up to properly initialize the device. nTRST may be left asserted when the device reset is released for normal device operation. For any variations from these requirements, see your device data sheet.

It’s required that nTRST be pulled down externally if an internal pull down is not provided in the device. Since internal pull-ups and pull-downs are typically weak (in the 20K to ~30K range), to increase noise immunity when an XDS cable is not connected, it is recommended an external pull-down be provided per Figure 1.

If you utilize a non XDS product for boundary scan testing, since TRST is an optional function in the IEEE 1149.1 specification, check the manufacturer’s documentation for nTRST support. If not supported, you will need the capability to pull the device’s nTRST pin up (inactive) on your target card for Boundary Scan to function. Most TI devices use an internal pull down on nTRST to hold the emulation logic in reset at power up of the device to ensure the device will operate in its normal functional mode. To determine if nTRST has an internal pull down, check the TI device-specific data sheet.

Note: Low power applications may require stronger external pull-ups or pull-downs to improve noise margins on the JTAG input signals (TMS, TDI, TCK and nTRST) when an emulation cable is not connected.

EMU pin Considerations

In cases where the device has more EMU pins than the XDS supports, the general rule is to connect as many EMU signals as possible to the XDS header. Even in cases where your specific XDS only supports a subset of the EMU pin functionality provided by a specific device, TI recommends connecting as many EMU pins as possible between the device and the XDS header to be compatible with other XDS products that may provide additional functionality.

The internal pull-ups on EMU0 and EMU1 are typically weak (in the 20K to ~30K-Ω range). There are a couple of functional cases where you may want to increase the noise immunity when an emulation cable is not connected by providing external pull-up resistors on EMU0 and EMU1 per Figure 1:

  • If your device supports boot modes on the EMU0 and EMU1 pins, these pins are latched during POR to set the boot mode.
  • Some TI devices utilized EMU0 and EMU1 to select the device’s operating mode. The default normal operating mode is selected with both EMU0 and EMU1 pulled up. Other modes typically include Boundary Scan.

If you are not sure what functions are provided on EMU0 and EMU1 it’s always safe to pull these two signals up.

All EMU pins on the device should be pulled up externally if the device does not have internal EMU pin pull-ups.

For additional information for multi-device configurations and EMU pins, see EMU Pin considerations in multi-device configurations.

nRESET Special Considerations

When using an XDS that supports the nRESET signal, it provides a mechanism for remotely resetting your entire system if integrated into your applications power-up-reset hardware. An XDS that does not support this feature is only capable of resetting the TI devices on the scan chain.

nRESET is an open-drain output from the XDS so this signal must be pulled up with a 4.7K-Ω PU on the target card to the level required by your board’s POR circuit.

This signal is driven active by the XDS for a minimum of 500 µs.

Also see JTAG_Connectors#Q:_What_is_the_SRST_pin_for.3F or System Reset (Emulation)


TDIS (Target Disconnect)

TDIS is supported for TI headers only and is used by the XDS to determine if the target cable is physically connected. This pin is tied to ground on the target board.

Note: A pull-down or current limiting resistor on TDIS will not work with all XDS models. With TDIS connected directly to GND, some XDS models will sink a small amount of current (by design) through a pull-up in the XDS. A pull-down or a current limiting resistor connected to TDIS on the target may cause the XDS to not detect the target and result in a “Far cable break” error.

TVRef

TVRef is recommended to be connected to the device’s JTAG and EMU pin IO power supply voltage source through a 100 Ω current limiting resistor. See your device data sheet for the JTAG and EMU pin IO voltage level.

The current limit resistor provides a current source for adapters that may be necessary and when a target is powered down with an emulator connected it will protect the target from powering itself from the emulator through TVD.

If your scan chain contains devices that require multiple IO voltages, since TVRef can only be set to a single voltage level, you must use translation buffers to drive the JTAG signals to/from devices that require IO voltages different from TVRef. All signals that drive into the XDS header must do so at the TVRef level.

XDS100/XDS510/XDS560 14-pin Header Special Considerations

If your device has more than two EMU pins, you can still use a 14-pin header, but you will not be able to export core trace and, in most cases system trace, if either are supported by your device. In both cases, a larger capacity connector is required; 60-pin for core trace and 20-pin for system trace. If your device has only a single EMU pin then connect it to EMU0 on the 14-pin header. All EMU pins on the device should be pulled up externally unless the device has sufficient internal EMU pin pull-ups.

The 14-pin header is no longer recommended for new designs. TI suggests using the TI 20-pin CTI connector which has a significantly smaller footprint than the 14-pin header.


XDS560 20-pin Header

If your device supports system trace, for board requirements when using the TI 20-pin CTI header for system trace, see SPRU655.

If your device has more than five EMU pins, you can still use a 20-pin header but you will not be able to export core trace (assuming your device supports core trace). In the core trace case, a larger capacity connector is required (60-pin for core trace). If your device has less than five EMU pins, connect the pins that are available on the device to the same numbered pin on the header (EMU0 on the device to EMU0 on the header).

ARM 20-pin Header

In cases where you are using a TI device with the ARM 20-pin header, you will need to use an adapter to utilize an XDS.

When connecting an ARM 20-pin header to a TI device there are two header pins that are left as no connects, DBGRQ and DBGACK. These signals are not supported by TI devices. If you are using an adapter from an ARM 20-pin header to an XDS target cable, the Vsupply header signal may be used by some adapters as an alternate voltage reference, but the XDS does not use this as a current source.

The ARM 20-pin header does not support EMU pins, so any functionality provided by an XDS over the EMU pins (such as boot modes) will not be available. In this case, if the device does not contain internal pull-ups on the EMU pins, the EMU pins of the device should be pulled-up externally. If your target card consists of multiple devices with ARM cores connected on a single serial JTAG scan chain and your devices support EMU pins, then you can still connect the EMU pins between devices to support debug cross triggers (if supported by your devices). Boot modes (if supported by your device) may also be modified from the default value on your board through pull-up/pull-down resistors, but you will not be able to change the boot mode value from the XDS. You will need to make sure when you go to production the default boot mode is set (both EMU0 and EMU1 pulled up) for all devices that support boot modes.

Adaptive clocking is generally required by devices that contain ARM cores. If your device has an RTCK pin, then this pin must be connected to the target cable’s RTCK signal, regardless of the target header used. For additional information, see Adaptive Clocking.

For additional requirements and potential limitations, if connecting multiple devices that all have ARM cores, see Multiple Device Adaptive Clocking.

XDS560T/XDS560 v2 System Trace 60-pin Headers

For core and system trace emulation header design requirements SPRU655.

Buffered Case

If the distance between the XDS header and the processor is greater than six inches, it is recommended that JTAG signals be buffered per Figure 2. For information on non-JTAG signals, see Single Device Non-buffered Configuration.

Note: The Figure 2 deviates from previous TI documentation in that TI now suggests utilization of AC termination resistors on the input to the TCK buffer and series termination on other critical signals. The reason for this change is the latest XDS controllers utilize drivers with faster rise and fall times than previous generations, thus increasing the chances of reflections on these critical signals.

Figure 2. Single Emulation Header with Single Target Device and Buffered JTAG Signals

Image:Fig2_Single_Buffered.jpg

Trace Design Process for single emulation header with a single target device and buffered JTAG signals.

  1. If your device does not have a RTCK pin then use Configuration 1.
  2. If your target device has a RTCK pin then use Configuration 2.
  3. DVDD is the JTAG/EMU pin IO voltage reference.
  4. The 33-Ω series termination resistor values in this diagram were selected based on using a 74LVC1G32 (or gate) as a non-inverting buffer. Size the value of the termination resistors based on the output impedance of your buffer.
  5. Pull-ups on EMU0 and EMU1 may be optional. For cases where external pull-ups are required or should be considered, see EMU pin Considerations.
  6. A pull-down on TRST may be optional. For cases where an external pull-down is required or should be considered, see JTAG and nTRST Special Considerations.
  7. If your device contains more than two EMU pins then it’s likely that it supports the export of core trace or system trace (or both). These are high speed features that impose additional target board requirements (for details, see SPRU655).
  8. Pull-up resistors are recommended on all buffer inputs to eliminate the possibility of the buffer output oscillating when an XDS cable is not connected.


For buffered configurations (for JTAG timing details, see JTAG Timing), TDO must propagate back from the device to the emulator within ½ a TCK cycle, so if you buffer RTCK at the same place on your target card that you buffer TCK, the max delay does not include the TCK delay, only the TDO delay. If you wrap TCK back to RTCK at the JTAG header and don’t buffer it, then you have to take into account the TCK delay plus the TDO delay in determining the max delay.


Multiple Devices

If your target board contains multiple JTAG 1149.1 compliant devices, you can utilize a single emulation header with the devices connected in a serial scan chain and the EMU pins connected in parallel between devices per Figure 3. Using this configuration enables the following features that are specifically provided to aid debug in multi-device systems:

  • Synchronous execution control
  • Global breakpoints
  • Cross triggers on the EMU pins


Figure 3. Single Emulation Header with Multiple Target Devices and Buffered JTAG Signals

Image:Fig3_Multi_Connection_JTAGBuffered.jpg

Trace Design Process for single emulation header with a single target device and buffered JTAG signals.

  1. If your devices have an RTCK pin, see Multi-device Adaptive Clocking.
  2. If the final device on the scan chain is within 6 inches of the emulation header, then the TDO buffer may not be required.
  3. DVDD is the JTAG/EMU pin IO voltage reference.
  4. This configuration assumes that the devices are within 6 inches of each other. Additional buffering may be required on TDO and TDI between devices if the routing distance is greater than 6 inches.
  5. The 33-Ω series termination resistors in this diagram were selected based on using a 74VC1G32 (or gate) as a buffer. You should size the series termination resistor based on the output impedance of your buffer.
  6. Pull-ups on EMU0 and EMU1 may be optional. For cases where external pull-ups are required or should be considered, see EMU pin Considerations.
  7. A pull-down on TRST may be optional. For cases where an external pull-down is required or should be considered, JTAG and nTRST Special Considerations.
  8. If your device contains more than two EMU pins, then it’s likely that it supports the export of core trace or system trace (or both). These are high-speed features that impose additional target board requirements (for details, see SPRU655).
  9. Pull-up resistors are recommended on all buffer inputs to eliminate the possibility of the buffer output oscillating when an XDS cable is not connected.

Generally TCK, TMS, TDI and TDO should be buffered to provide adequate signal drive between the processor array and the XDS. It is recommended that TCK, TMS and TDI be buffered through the same physical package for better control of signal skew effects. If the last device on the scan chain is less than 6 inches from the XDS header then the TDO buffer is not necessary.

Input buffers on TMS, TDI, and TCK should have pull-up resistors connected to DVDD I/O voltage reference to hold these signals at a proper value when the XDS target cable is not connected. A resistor value of 4.7 kΩ or greater is suggested.

In cases where your design has just a few devices (not more than 3) on a serial scan chain and the JTAG signal (TCK, TMS, TDO and TDI) routing is less than 6 inches, buffering the JTAG signals may not be necessary. If you decide your design does not require buffers, the series termination resistors recommended in Single Device Non-buffered Configuration may still be necessary.

If your design utilizes more than three devices, it is recommended you simulate, at a minimum, the TCK and TMS paths. TI does not recommend placing more than 30 devices on a single JTAG scan chain.

EMU Pin considerations in multi-device configurations

Buffering EMU0 and EMU1 is not generally recommended because these signals are typically bi-directional.

If your device does not support HS-RTDX, then the only requirement is to ensure that the EMU pins transition between logic levels is fast enough to support cross triggers requirements.

  • Fall time – less than 100 ns
  • Rise time – less than 1 µs.

To calculate fall time you need to use the drive current of a single device’s EMU pin, the delta voltage swing (VMAX to VOL ) of the EMU pin driving the array, and the capacitive loading of all other devices in the array with the following equation.

Tfall = (Vdelta * Ci * Ndevices-1)/ Io

Where Vdelta is VOH(MAX) - VOL.

The Io, VOH(MAX), VOL, and Ci values are available in the device data sheet.

To calculate the rise time, use the equation:

tr = 1.5(Rpullup X Ndevices X Ci_per_device)


Note: This is the basic RC time constant of the circuit where the 1.5T point is at ~80% of the rise time. For accuracy, if your device contains pull-ups on the EMU pins (see the device datasheet), they will typically be weak (~30K Ω). This should be accounted for when calculating Rpullup.

For devices that support HS-RTDX, the requirements are more strict because the logic level transitions on the EMU pins, in both directions, must occur within a TCK clock period. If you cannot meet this requirement, you are required to reduce the XDS TCK frequency to a level that will satisfy the requirement. It is recommended that you set TCK 10% below the maximum frequency to provide some guard band for environmental changes.

JTAG Timing

Figure 4 shows the basic JTAG timing. Specifically, the XDS exports TMS and TDI on the rising edge of RTCK. TDO is clocked out of the device on the falling edge of TCK and thus only has ½ a TCK cycle to propagate to the XDS where it’s latched on the next rising edge of RTCK. For detailed timing parameters, see your XDS manufacturer’s documentation.

Figure 4. JTAG Timing

Image:JTAG_Timing.jpg

Multi-device Adaptive Clocking

If your design has multiple devices with RTCK signals that require Adaptive Clocking, you must choose between either a series or parallel topography. The parallel topography will provide more performance than the series topography, but it is more complex to implement.

For more information, see Adaptive Clocking.


Series Topography

As shown in Figure 5, the series topography cascades RTCK between device’s in the serial scan chain. This causes the next device to synchronize it’s TCK to the RTCK of the previous device in the scan chain. This has two effects on the system:

  • RTCK presented to the XDS will be slower than the slowest device in the serial scan chain.
  • Even if all devices are running at the same functional clock rates, delays through the synchronization logic will slow the final RTCK.

Using the serial topography, you can still utilize an XDS that does not support Adaptive Clocking, provided you set TCLK to a rate slower than 1/8th the slowest core’s functional clock rate.


Figure 5. Device With RTCK Series Topography

Image:Fig4_RTCK_Devices.jpg

  1. This figure only shows connections without regard to buffering or termination that may also be required. For additional details on connecting multiple devices, see Multiple Devices.

Parallel Topography

The Parallel Topography, as shown in Figure 6, can be utilized to avoid the RTCK clock degradation caused by the cascading of RTCK between devices in the serial scan chain (see Series Topography). Parallel Topography requires the use of an external CPLD to implement the clock voting logic. The clock voting logic presents TCK to all devices in parallel, but then waits to generate the next RTCK edge to the XDS until all devices have responded with the expected RTCK edge. As with the Serial Topography, RTCK to the XDS is throttled down to the slowest device, but the added RTCK delay caused by cascading is avoided.

Using the parallel topography, you can still utilize an XDS that does not support Adaptive Clocking, provided you set TCLK to a rate slower than 1/8th the slowest core’s functional clock rate.


Figure 6. Devices with RTCK Parallel Topography

Image:Fig5_RTCK_Dev.jpg

  1. This figure only shows connections without regard to buffering or termination that may also be required. For additional details on connecting multiple devices, see Multiple Devices.

An example of the board level clock voting logic implementation can be found at Adaptive Clocking.

Mixed Devices

If your design contains both devices with RTCK pins and those without an RTCK pin, regardless of the topography, the TCK signal of those devices without an RTCK pin must be driven with the RTCK from those devices with RTCK since these devices must govern the XDS RTCK rate.

Figure 7 shows mixing devices with RTCK in a series topography and those without RTCK. Those devices without an RTCK are grouped together at the end of the scan chain, and their TCK signals are driven with the RTCK from the last device in the scan chain with a RTCK.


Figure 7. Multiprocessor Mixed Device Types (with and without RTCK) Series Topography

Image:Fig6_Multi_Mixed_RTCK.jpg

  1. This figure only shows connections without regard to buffering or termination that may also be required. For additional details on connecting multiple devices, see Multiple Devices.

Figure 8 shows mixing devices with RTCK in a parallel topography and those without RTCK. Those devices without an RTCK are grouped together at the end of the scan chain, and their TCK signals are driven with the RTCK from the voting logic.


Figure 8. Multiprocessor Mixed Device Types (with and without RTCK) Parallel Topography

Image:Fig7_Multi_Mixed_RTCK.jpg

  1. This figure only shows connections without regard to buffering or termination that may also be required. For additional details on connecting multiple devices, see Multiple Devices.

Special Considerations for HSRTDX

HS-RTDX bi-directional data transfers utilize a combination of EMU pins for data transport and TCK to clock the data. Use of HS-RTDX with an EMU pin is mutually exclusive of other EMU pin features except boot modes. The XDS560 supports two channels of HS-RTDX data transport where each channel uses a single EMU pin (typically EMU0 or EMU1). You can select which EMU pin is used for HS-RTDX data transport with a device or processor through the debugger. Since transport speeds are high (with TCK running at 35 MHz data rates of 2 MB/s are typical), special attention must be given to EMU signal routing on your board.

If your design contains multiple devices that support HS-RTDX, see EMU Pin considerations in multi-device configurations.


Troubleshooting

See the material on troubleshooting JTAG Connectivity Problems at: Debugging_JTAG_Connectivity_Problems.

Related


For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article XDS Target Connection Guide here.
Retrieved from "http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide"
Leave a Comment

Comments

Comments on XDS Target Connection Guide

Kyle.roberts said ...

On my current design, we are sending the JTAG signals from the emulator, across a sizable backplane, through a connector to a module board. Since the JTAG signals travel a long distance in a very noisy environment, we are using the buffered configuration. However, this configuration provides no extra support for the EMU pins. The app notes mention adding strong pull-ups to the signals, but I am curious what the best practice is for handling these signals such that they can travel a long distances (> 24 inches) in a noisy environment. The issue we were seeing was that noise on the EMU pins was causing our DSP to go into the "Wait In Reset" boot mode.

Question answered on the Forum (http://e2e.ti.com). Link

--Kyle.roberts 12:38, 20 April 2010 (CDT)

Personal tools