JTAG signal integrity and maximum cable lengths

For JTAG-based debugging, you must have a very reliable connection between RVI and the target, because there is no way to detect or correct errors. For this reason it is important to guarantee good signal integrity.

One factor that can limit the maximum cable length is propagation delays. Normally the RVI run control unit samples data returning from the target using the same clock as for sending data, TCK. If the propagation delay gets too long then the RVI run control unit samples the signal at the wrong time. This can be resolved by using adaptive clocking. In this mode the target returns a clock, RTCK, and RVI does not sample data on TDO, or send more data on TDI, until clocked by this signal.

In an ASIC or ASSP (for example, in ARM processor based microcontrollers) the TDO and RTCK signals are not typically implemented with a stronger driver than other signals on the device. The strength of these drivers varies from device to device. An example specification is to sink or source 4mA. Many designs connect these pins on the device directly to the corresponding pins on the RVI connector.

Over very short lengths of cable, such as the one supplied with RVI, this type of weak driver is adequate. However, if longer cables are used then the cable becomes harder to drive as the capacitive load increases. When using longer cables it becomes essential to consider the cable as a transmission line and to provide appropriate impedance matching, otherwise reflections occur.

RVI has much stronger drivers and they are connected through 100Ω series resistors to impedance match with the JTAG cable. This is very much better than the typical circuit used at the target end.

With the typical situation at the target end (weak drivers, no impedance matching resistors) you can only expect reliable operation over short cables (approximately 30cm). If operation over longer cables is required:

Reducing the clock speed used by RVI avoids some, but not all, of the problems associated with long cables. If reducing the speed of downloading code and reading memory in the debugger is not a significant problem, try experimenting with lowering this clock speed.

Show/hideSee also

Copyright © 2010-2011 ARM. All rights reserved.ARM DUI 0517D
Non-ConfidentialID071311