2013-12-04 22:34:26
转自：http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems
Contents[hide] |
Strategy for debugging JTAG connectivity problems
1. 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. )
2. 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 section 2.5 (troubleshooting) of the XDS100 page.
3. 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.
4. Check your Code Composer configuration and launch the debugger manually instead of using the Debug Active Project button. Check the short clips Launching a project target configuration manually or Launching a shared target configuration manually at the Quick Tips page.
The reason is to perform a connection step-by-step and precisely know where the issues are happening:
- If the issue happens during the Debugger Launch phase, check the Troubleshooting CCS page.
- If the issue happens during connect phase, keep reading.
- If the issue happens during loading, the most common issue is trouble writing to memory. This can be caused by a GEL file not properly initializing the EMIF peripheral - keep reading. Another cause can be due to a mismatch between the memory configuration of the application and the physical memory - in this case the application needs to be fixed.
- If the issue happens while running to main(), the problem is with the application code (bad initialization of the device, watchdog timers not being refreshed, invalid memory accesses, etc.) - in this case the application needs to be fixed.
- Note: If using SoC and multicore devices, it is always a good idea to manually launch the target configuration and connect to each core individually instead of clicking on the Debug Active Project button. For details please check GSG:Connecting to slave cores in SoC devices
- Note: For some C6000 and SoC devices, you can inspect the status of each core individually by using the ICEPICK. Check the short clip Using ICEPICK at the Quick Tips page.
If using Spectrum Digital emulators
Spectrum Digital contains a great troubleshooting page that covers the SDConfig usage at:
- http://support.spectrumdigital.com/guides/JTAG_Emulator_guide/
- http://support.spectrumdigital.com/guides/troubleshooting_guide/
- Note: Do not use Spectrum Digital utilities to debug XDS100 emulators
If using BlackHawk emulators
Blackhawk has a good troubleshooting guide and a FAQ at:
- http://www.blackhawk-dsp.com/support/get.aspx?name=EMULATOR&type=appnote&subtype=TROUBLESHOOT
- http://www.blackhawk-dsp.com/support/FAQ.aspx
- Note: Do not use Blackhawk utilities to debug XDS100 emulators
Check your hardware JTAG connection
1. Check your schematic to see whether the JTAG header is correctly connected on the PCB. Details can be found on the JTAG Connectors page.
- If you are using one of the newer boards that do not have the JTAG connector populated (BeagleBone, AM3359 ICE, AM3358 SK, etc.), keep in mind they usually need additional hardware changes other than simply populating the JTAG header. An example for the Beaglebone can be found here.
2. Is the voltage the same on all your JTAG pins?
3. Does your emulator support the target I/O voltage? 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. Contact your emulator manufacturer for details.
4. Review the Emulation FAQ
5. If experiencing sudden target disconnects, see Emulation Connect/Disconnect for details.
6. 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.
Check your software configuration
1. Check the JTAG clock settings. Due to PCB and device design the speed of the connection may have to be limited to guarantee reliability.
- Check the short clip Changing the Target Configuration Properties at the Quick Tips page
- If you are using a target with an ARM9 processor, you should review the section on Adaptive Clocking.
- If you are using a XDS560 or XDS560v2 emulator you can configure its clock settings. Check their pages at XDS560 and XDS560v2 System Trace.
- If you are using a Stellaris device with a XDS emulator, please check the page Stellaris Emulator Compatibility
- If you are using a TMS570 development board, please check the following two threads:
2. DSK/EVM specfic files, such as GEL files used in CCSetup or the target configuration file (.ccxml), are not always provided by TI 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. Add GEL files to the emulator setup for each CPU if not defined. If you change emulators, having the GEL files specified in a configuration file can cause problems because of a mismatch in emulator and board manufacturer. Unless the emulator vendor is the same vendor 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.
4. Install the latest emulator drivers for the revision of CCS that you are using. You can check the emulator 3rd party site for the latest drivers (CCSv4 and CCSv5 have options to install device drivers for XDS100, MSP430, ICDI, Blackhawk and Spectrum Digital). 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 configuration file (.ccs) or target configuration file (.ccxml).
5. If using CCSv4 and CCSv5 you may want to see Troubleshooting CCS topic to inspect IDE and Debugger issues.
6. Update CCS to the latest release. Support for certain devices require CCS to be updated to the correct level.
7. 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.
Location of files and utilities
New for Code Composer Studio v4 and v5 (Windows)
The DBGJTAG utility has a GUI that can be downloaded from the page below:
Code Composer Studio v5
Code Composer Studio v5.1 features a useful Test Connection button at the target configuration editor that automatically executes various low-level JTAG tests on the configured connection. This turns it unnecessary to open a Command Prompt or Shell and look for the utility and the <ccBoard0.dat> files as in the previous versions, however if you need to perform specific tests, the location of the utilities is still provided.
To get this button simply create and save a target configuration (.ccxml) in the target configuration editor and click on the Test Connection button.
- Note: this button does not work for Spectrum Digital XDS510 emulators. Use the SDConfig instead (shown above).
 |
 |
- The dbgjtag utility is typically located at:
- Windows:
- <CCS_INSTALL_DIR>ccsv5ccs_basecommonuscifdbgjtag.exe
- Linux:
- <CCS_INSTALL_DIR>/ccsv5/ccs_base/common/uscif/dbgjtag
- The configuration file <ccBoard0.dat> is located inside a directory named .TI in the user area. Typically it is located at:
- Windows XP systems:
- C:Documents and Settings<username>Local SettingsApplication Data.TI<
- Windows Vista and 7 systems:
- C:Users<username>AppDataLocal.TI
- Linux systems:
- /home/<username>/.TI
Notes:
- Change the <username> above to the name of your user.
- To help locating the configuration file <ccBoard0.dat> check the page Locating the board configuration
Code Composer Studio v4
1.If using CCSv4.1.2 or older:
- The <dbgjtag.exe> utility is typically located at:
- <CCS_INSTALL_DIR>ccsv4commonuscifdbgjtag.exe
- The configuration file <ccBoard0.dat> is located at:
- <CCS_INSTALL_DIR>ccsv4DebugServerinwin32BrdDatccBoard0.dat
- Therefore a typical command would be issued as:
- "C:Program FilesTexas Instrumentsccsv4commonuscifdbgjtag.exe" -f "C:Program FilesTexas Instrumentsccsv4DebugServerinwin32BrdDatccBoard0.dat" -rv -S pathlength
Notes:
- Change the path to the location appropriate to your installation.
- To help locating the configuration file <ccBoard0.dat> check the page Locating the board configuration
2.If using CCSv4.1.3 and newer:
- The <dbgjtag.exe> utility is located in the same place as above
- The configuration file <ccBoard0.dat> is inside a directory named .TI in the user area. Typically it is located at:
- Windows XP systems
- C:Documents and Settings<username>Local SettingsApplication Data.TI<
- Windows Vista and 7 systems:
- C:Users<username>AppDataLocal.TI
- Notes This change is required to accomodate the requirements of Windows Vista and 7 that prevent access to sensitive areas of the system.
Code Composer Studio v3
- The <dbgjtag.exe> utility is typically located at:
- <CCS_INSTALL_DIR>ccindbgjtag.exe
- The configuration file is located at:
- <CCS_INSTALL_DIR>ccinrddatccbrd0.dat
- Therefore a typical command would be issued as:
- C:CCStudio_v3.3ccindbgjtag.exe -f brddatccbrd0.dat -rv -S pathlength
Useful tests
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. For an illustration of a physical set-up, see the picture on the side.
- We will use Dbgjtag to do this test. Dbgjtag can be used with TI emulators and all XDS100 emulators. IMPORTANT! All other Spectrum Digital emulators must use the utility called "SDconfig", which can perform very similar functions. Please refer to the section If using Spectrum Digital emulators.
- 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 brddatccbrd0.dat" selects the emulator currently configured in CCS setup.
- The option "-rv" attempts to reset the emulator
| C:CCStudio_v3.3ccin>dbgjtag -f brddatccbrd0.dat -rv
-------------------------------------------------------------------------------- [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'. Connect failure 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 title is 'SC_ERR_ECOM_EMUNAME'. The explanation is: An attempt to access the named emulator via USCIF ECOM has failed.
|
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.3ccin>dbgjtag -f brddatccbrd0.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.
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.3ccin>dbgjtag -f brddatccbrd0.dat -rv -S brokenpath [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 Broken Path scan-test on the JTAG IR]---------------------- This test will use blocks of 512 32-bit words. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 All of the values were scanned correctly. 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. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 All of the values were scanned correctly. 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.3ccin>dbgjtag -f brddatccbrd0.dat -rv -S brokenpath [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). 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 title is 'SC_ERR_CTL_CBL_BREAK_FAR'. The explanation is: The controller has detected a cable break far-from itself. The user must connect the cable/pod to the target. |
- 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.3ccin>dbgjtag -f brddatccbrd0.dat -rv -S integrity [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 Integrity scan-test on the JTAG IR]------------------------ This test will use blocks of 512 32-bit words. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 Do a test using 0xFE03E0E2. Scan tests: 3, skipped: 0, failed: 0 Do a test using 0x01FC1F1D. Scan tests: 4, skipped: 0, failed: 0 Do a test using 0x5533CCAA. Scan tests: 5, skipped: 0, failed: 0 Do a test using 0xAACC3355. Scan tests: 6, skipped: 0, failed: 0 All of the values were scanned correctly. 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. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 Do a test using 0xFE03E0E2. Scan tests: 3, skipped: 0, failed: 0 Do a test using 0x01FC1F1D. Scan tests: 4, skipped: 0, failed: 0 Do a test using 0x5533CCAA. Scan tests: 5, skipped: 0, failed: 0 Do a test using 0xAACC3355. Scan tests: 6, skipped: 0, failed: 0 All of the values were scanned correctly. 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.3ccin>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 title is 'SC_ERR_CMD_HANDLE'. The explanation is: A bad controller handle has been given to a function, either before attempting to open the controller, or after having opened the controller and ignored its error status. Valid controller handles are generated when attempts to open the controller return a clean error status. |
 |
For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Debugging JTAG Connectivity Problems here. |
Comments
Comments on Debugging JTAG Connectivity Problems
Contents |
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)
Slavica said ...
Is there a tool to diagnose connectivity problems with Spectrum Digital XDS100v2 USB JTAG with? I have CCS v4.2.1 running on Windows XP. Only SD tool installed is SDConfigEx, but it only provides XDS510USB option.
--Slavica 18:00, 12 January 2011 (CST)
Ali Bahar said ...
re: Slavica 18:00, 12 January 2011 (CST) Hi Slavica, I don't work on Windows, but I _have_ tested the XDS100v2 from a linux host. The ccsv5 distribution has these two utilities ./ccsv5/ccs_base_5.0.1.00036/common/uscif/xdsprobe ./ccsv5/ccs_base_5.0.1.00036/common/uscif/xdsreset which are installed under /usr/local/CCSv5/. I don't know what the equivalent paths may be in Windows. Never the less, these utilities seem to be wrappers around the DbgJtag utility -- which your ccs ought to have, or which you may find elsewhere for Windows. (The Spectrum utility is AFAIK the same thing as this.) There are also
http://www.urjtag.org/ and openwince-jtag, elsewhere.
--Ali Bahar 22:25, 2 March 2011 (CST)
Ali Bahar said ...
Here's another link for JTAG utilities: http://elinux.org/JTAG#Tools
--Ali Bahar 09:30, 3 March 2011 (CST)
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)