Debugging JTAG Connectivity Problems
From Texas Instruments Embedded Processors Wiki
Search for an article here:
Strategy for debugging JTAG connectivity problems
- Check that you are using high quality cables for connections. For example, with USB 2.0 emulators, please use a cable which is certified for USB 2.0 High Speed operation. (Poor cable quality has resulted in a failure to connect, unstable connection, etc. )
- Determine whether the emulator is correctly setup in Windows (i.e. is the USB driver, etc. working) by checking in the Windows System Devices control panel. If this is not right, then you need to contact your emulator vendor to make sure the driver is installed properly. For XDS100, please check the XDS100 page.
- Determine whether your JTAG connection is working at the lowest level. See below for details on how to use DBGJTAG to confirm that the JTAG connection is good. (Or other 3rd party utility such as SDCONFIG) If this fails or has errors, then there are the problem is with the software communicating to the emulator. This could be because there is a hardware problem, the configuration in CCS is setup incorrectly, or the software is not installed correctly.
- Check your Code Composer Studio configuration and try to connect. If you are able to confirm that the low level connection is OK (i.e. scan chain test is OK), then there is no problem with the USB/Ethernet or CCS configuration. The problem is probably with the Code Composer Studio setup, service release or chip support package. Please check Troubleshooting CCS
Check your JTAG connection
- Check your schematic to see whether the JTAG header is correctly connected on the PCB. Details can be found on the JTAG_Connectors page.
- Is the voltage the same on all your JTAG pins?
- Does your emulator support the I/O voltages of your device? (You may want to contact your emulator vendor for details on XDS100, XDS510 or XDS560 products)
- Review the Emulation FAQ
- Check for Electro-Magnetic Interference (EMI). If you are working with electronics that are near motors or other electrical components that could induce currents, then shielding and isolation may be important. There is an isolation adapter here: [1]. This typically manifests itself as the connection to CCS becoming unstable or intermittent. This would mean the connection could randomly drop out.
Emulator not plugged in
- The purpose of this test is to verify that the emulator is plugged in propery to the PC and is recognized by the software.
- We will use Dbgjtag to do this test. IMPORTANT! Spectrum Digital users must use the utility called "SDconfig", which can perform very similar functions. Please refer to the section Using SDConfig to test JTAG connections below
- In this example, the emulation SW is unable to access the emulator because it is not plugged in or the operating system drivers have a problem. (Please keep your emulator plugged into the PC for the test. )
- The option "-f brddat\ccbrd0.dat" selects the emulator currently configured in CCS setup.
- The option "-rv" attempts to reset the emulator
| C:\CCStudio_v3.3\cc\bin>dbgjtag -f brddat\ccbrd0.dat -rv
[Print the reset-command software log-file]----------------------------- This utility has selected an XDS560 class product. An error occurred while soft opening the controller.
[An error has occurred and this utility has aborted]-------------------- This error is generated by TI's USCIF driver. The value is '-250' (0xffffff06). The explanation is:
|
Detect the length of the scan chain
- We will use Dbgjtag to do this test
- In this example, we want to figure out the legnth of the JTAG scan chain. The result is that the JTAG instruction register legnth is 38 bits and that the bypass register length is 1 bit.
- The option "-S pathlength" asks the dbgjtag program to find the length of the JTAG path.
- You can check lengths here
C:\CCStudio_v3.3\cc\bin>dbgjtag -f brddat\ccbrd0.dat -rv -S pathlength -------------------------------------------------------------------------------- [Print the reset-command software log-file]----------------------------- This utility has selected an XDS560 class product. This utility will load the program 'bh560usbM.out'. This utility will operate on port address '0'. The controller does use a programmable FPGA. The old VHDL code has a version number of '1544' (0x0608). The new VHDL code has a version number of '1544' (0x0608). The emulator program is named 'bh560usbM.out'. The emulator program is version '35.24.0.3'. The controller has a version number of '4' (0x0004). The controller has an insertion length of '0' (0x0000). The cable+pod has a version number of '6' (0x0006). The cable+pod has a capability number of '9' (0x0009). The local memory has a base address of '0' (0x000000). The local memory has a word capacity of '32768' (0x008000). This utility will now attempt to reset the controller. This utility has successfully reset the controller. -------------------------------------------------------------------------------- [Print the reset-command hardware log-file]----------------------------- The scan-path will be reset by toggling the JTAG TRST signal. The software is configured to use all Nano-TBC VHDL features. The controller type is the Nano-TBC VHDL. The connection type is a 560-class revision-D multi-purpose cable. The controller will be software reset via its configure register. The controller will use rising-edge timing on output pins. The controller may use rising edge timing on input pins. The controller has a logic ONE on its EMU[0] input pin. The controller has a logic ONE on its EMU[1] input pin. The scan-path link-delay has been set to exactly '3' (0x0003). The support logic has not previously detected a power-loss. -------------------------------------------------------------------------------- [Perform the standard path-length test on the JTAG IR and DR]----------- This path-length test uses blocks of 512 32-bit words. The test for the JTAG IR instruction path-length succeeded. The JTAG IR instruction path-length is 38 bits. The test for the JTAG DR bypass path-length succeeded. The JTAG DR bypass path-length is 1 bits.
CCS v4
For CCS v4, you may want to issue the command as follows
"C:\Program Files\Texas Instruments\ccsv4\common\uscif\dbgjtag.exe" -f "C:\Program Files\Texas Instruments\ccsv4\DebugServer\bin\win32\BrdDat\ccBoard0.dat" -rv -S pathlength
- Change the path to the location appropriate to your installation.
- You may want to see Locating the board configuration
How to debug whether the JTAG scan path is broken
- In this example, we want to figure whether the JTAG scan path is broken.
- The option "-S brokenpath" asks the dbgjtag program to check the JTAG scan chain for breaks.
| C:\CCStudio_v3.3\cc\bin>dbgjtag -f brddat\ccbrd0.dat -rv -S brokenpath
[Print the reset-command software log-file]----------------------------- This utility has selected an XDS560 class product. [Print the reset-command hardware log-file]----------------------------- The scan-path will be reset by toggling the JTAG TRST signal. [Perform the Broken Path scan-test on the JTAG IR]---------------------- This test will use blocks of 512 32-bit words. Do a test using 0xFFFFFFFF. The JTAG IR Broken Path scan-test has succeeded. [Perform the Broken Path scan-test on the JTAG DR]---------------------- This test will use blocks of 512 32-bit words. Do a test using 0xFFFFFFFF. The JTAG DR Broken Path scan-test has succeeded. |
- The first run shows that the test succeeded, so the scan chain is OK.
- You can make the test run repetitively if you choose the "-S brokenpath,repeat=12" option to make it run 12 times. if repeat=0, then the test will run forever.
| C:\CCStudio_v3.3\cc\bin>dbgjtag -f brddat\ccbrd0.dat -rv -S brokenpath
[Print the reset-command software log-file]----------------------------- This utility has selected an XDS560 class product. An error occurred while hard opening the controller. [An error has occurred and this utility has aborted]-------------------- This error is generated by TI's USCIF driver. The value is '-183' (0xffffff49). The explanation is: |
- In this example, you can see that the Dbgjtag software has detected that the scan chain is broken. In this case, the emulator is simply not connected to the taget, so it says that the cable is broken.
- In addition, it is important to note that this error is returned by the lowest level of the JTAG scan software layer and may be seen in a pop-up dialog when CCS is invoked. It may also be seen when debug utilities such as xdsreset, xdsprobe, dbgjtag are run from the DOS command prompt, as in the case of this example
- As one of the first steps in the debug startup sequence, the low level scan software layer checks the state of the TDIS pin (pin 4 on the TI 14pin and 20pin header) to determine if the emulator cable is connected to the target board. If the cable is not connected it will generate the SC_ERR_CTL_CBL_BREAK_FAR error.
- If the cable is physically connected to the target and the error is still observed, then see the following to further debug the issue: http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide#TDIS_.28Target_Disconnect.29
JTAG scan chain integrity test
- You can test the integrity of the JTAG scan chain.
- Use the "-S integrity" option
| C:\CCStudio_v3.3\cc\bin>dbgjtag -f brddat\ccbrd0.dat -rv -S integrity
[Print the reset-command software log-file]----------------------------- This utility has selected an XDS560 class product. [Print the reset-command hardware log-file]----------------------------- The scan-path will be reset by toggling the JTAG TRST signal. [Perform the Integrity scan-test on the JTAG IR]------------------------ This test will use blocks of 512 32-bit words. Do a test using 0xFFFFFFFF. The JTAG IR Integrity scan-test has succeeded. [Perform the Integrity scan-test on the JTAG DR]------------------------ This test will use blocks of 512 32-bit words. Do a test using 0xFFFFFFFF. The JTAG DR Integrity scan-test has succeeded. |
How can I find out more about emulator error messages?
- You can use dbgjtag to find out more about error messages.
- For example, if I want to find out about error # -121, I could follow the sample below.
| C:\CCStudio_v3.3\cc\bin>dbgjtag -E single,number=-121
[The explanation of the error number '-121']---------------------------- This error is generated by TI's USCIF driver. The value is '-121' (0xffffff87). The explanation is: |
CCS suddently says my target is disconnected, what does this mean?
See Emulation Connect/Disconnect for details on connect/disconnect.
General things to try
1) Update CCStudio v3.3 to the latest service release. Support for certain devices require CCStudio to be updated to the correct level.
2) DSK/EVM specfic files, such as GEL files used in CCSetup are not always provided by TI in the CCStudio updates and are generally not supplied by the emulator vendor. They are usually provided by the board manufacturer. These files also need to be installed and usually accompany the DSK/EVM on CD, labeled something like "EVM target content". Please check with your board manufacturer.
3) Install the latest emulator drivers for the revision of CCStudio that you are using. You can check the emulator 3rd party site for the latest drivers. As TI releases new devices and DSK/EVM target boards you will see driver updates that include these imports either in the service release, chip support package. Most of the time, a new emulator driver is not needed, just a new CCS import configuraiton file (.ccs).
4) Add GEL files to the emulator setup for each CPU if not defined. If you change emulators, having the GEL files specified in a CCStudio import can cause problems because of a mismatch in emulator and board maufactuerer. Unless the emulator vendor is the same vedor that built the target hardware, they are not usually included or defined with driver updates. You can also email your emulator provider for the imports if they are not present.
5) Check the voltage levels that your JTAG pod can handle and what the target I/O voltage is. There are some older products which cannot handle newer targets with 1.8V I/O as they were designed to operate with 3.3V and 5V targets.
ARM 9 Targets
- If you are using a target with an ARM9 processor, you should review the section on Adaptive Clocking.
Code Composer Studio
- You may want to see Troubleshooting CCS topic for more information.
- For CCS v3.3 issues related to emulation drivers and service releases, you may want to see the CCS_3.3#Third_Party_Emulation_Drivers topic.
Using SDConfig to test JTAG connections
Basic Tests
- With SD Config, select your emulator from the list
- Select "Emulator->Test" This will provide the emulator model number and do a scan chain test. For a system with an XDS510USB+, the output looks like below:
Spectrum Digital Configuration and Diagnostic Utility Supports: Printer Port: XDS510PP, XDS510PP+, SPI515, eZdsp ISA Bus: SPI510, XDS510 PCI Bus: SPI525 USB Bus: XDS510-USB ** Using emulation application from directory c:\program files\texas instruments\ccsv4\emulation\drivers ** Checking for a valid emulator/eZdsp $$ You are connected to: $$ EmuProductName=XDS510USB $$ EmuPortAddr=0x510 $$ EmuPortMode=USB $$ ProductId=510 $$ ProductVersion=86 ** Checking emulator/eZdsp scan connection ** Emulator Test ** $$ EmuProductName=XDS510USB $$ EmuPortAddr=0x510 $$ EmuPortMode=USB $$ ProductId=510 $$ ProductVersion=86 ** Emulator Scan Test -- Found JTAG IR length of 6 -- Found 1 JTAG device(s) in the scan chain
- This information is useful for checking selected emulator version.
- Note the results of the scan test for support. If you are not connected, there may be no results returned form the scan test.
Emulator Reset
- With SD Config, select your emulator from the list
- Select "Emulator->Reset" in some cases to reset the emulator.
- To perform integrity tests, select "Emulator->Diagnostics" and select "Scan Verify" The results are as below.
** Checking for a valid emulator/eZdsp ** Running diagnostic scan on EmuProductName=XDS510USB ** Checking emulator/eZdsp scan connection Performed 1 test loops with 0 errors.
Scan Chain Testing
- With SD Config, select your emulator from the list
- To perform repetitive scan to test the integrity of a scan chain repetitivey, select "Emulator->Diagnostics" and select "Scan Pattern" and set up the loop count to a value.
- An example of a failure in diagnostic testing looks like the example below:
** Checking for a valid emulator/eZdsp ** Running diagnostic scan on EmuProductName=XDS510USB ** Checking emulator/eZdsp scan connection ERROR >> Diagnostic scan error Performed 1 test loops with 1 errors.
Leave a Comment
Comments
Comments on Debugging JTAG Connectivity Problems
Sp li said ...
DanRinkes said ...
Sp,
You are likely better off posting questions like this to the Forums, rather than posting on the Wiki. They may get answered in either place. But the Wiki is not routinely monitored for questions like the forum is. The forums are here https://community.ti.com/forums/Default.aspx.
With that being said, it's hard to tell where your problem is coming from. I suspect that it's possibly a problem with the board, but problems with the board shouldn't cause a dbjtag crash.
Have you tried other boards with these systems? The way the scan length check works is that the emulator scans in a number of patterns of bits into TDI and waits for those bits to show up on TDO. I don't have a good explanation of what could cause dbjtag to crash. Hopefully, if you find the answer to this question, you will post your findings back to this page.
--DanRinkes 15:14, 15 July 2009 (CDT)
I followed the instruction, and everything was fine until "Detect the length of the scan chain" - dbgjtag is simply crashed.
What does it imply? Something wrong in JTAG or board side?
xdsprobe did the same thing, and it crashed too.
I have tested this on 2 windows xp pro and both had same symptom.
--Sp li 00:55, 8 July 2009 (CDT)