Debugging JTAG Connectivity Problems

From Texas Instruments Wiki
Jump to: navigation, search

Introduction

This page talks about how to properly debug JTAG connection issues by providing a step-by-step method of narrowing down the problem based on the feedback Code Composer Studio provides.

The previous page with legacy information is still available at the Debugging JTAG Connectivity Problems legacy page.

References

http://support.spectrumdigital.com/guides/JTAG_Emulator_guide/
http://support.spectrumdigital.com/guides/troubleshooting_guide/
  • Blackhawk troubleshooting guides:
http://www.blackhawk-dsp.com/support/get.aspx?name=EMULATOR&type=appnote&subtype=TROUBLESHOOT
http://www.blackhawk-dsp.com/support/FAQ.aspx




Strategy for debugging JTAG connectivity problems

When having trouble with a connection, follow the steps below to identify what could be the most probable root cause for the problem.
Sometimes the entire connection process fails due to multiple reasons, therefore fixing one step may require revisiting the list more than once.

Was CCS device support installed?

Check if Code Composer was installed with the support for the device, board and JTAG debug probe. Check section 3 of the CCSv6_Getting_Started_Guide for install instructions.

  • In general this problem shows up when:
    • Trying to find a specific JTAG debug probe brand (Spectrum Digital, Blackhawk) or type (XDS100, MSP-FET, etc.) in the Connection drop-down box
    • Trying to find a specific device or device family on the Board or Device list
  • In case the support is not installed, it is possible that you have to:
    • Update the TI Emulators component or the device support package of CCS (details at the Updating CCSv6 page)
    • Contact your debug probe vendor to make sure it supports the CCS version or the driver is installed properly
    • Update CCS to the latest release. Support for certain devices require CCS to be updated to the correct level.
    • Ultimately reinstall your copy of CCS in case of file corruption

Is the Target Configuration File correct?

Check if the target configuration file (.ccxml) accurately describes your JTAG debug probe (Connection) and target (Device or Board) and use the Test Connection button to determine whether your JTAG connection is working at the lowest level.

An invalid configuration can spawn pretty much any of the errors shown at the section Common errors below, the most common being:

Is the issue happening when starting a debug session?

To isolate the issue between a specific step when starting a debug session, launch the debugger manually instead of using the Debug Active Project buttonCCSv5 Debugging green bug button.png.

By doing this step-by-step operation it is possible to precisely know where the issues are happening:

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 CCSv5 Debugging green bug button.png. For details please check item 8 of the next section
  • If the issue happens during loading code to the target, check the Troubleshooting CCS - Data Verification Errors page.
  • If the issue happens after the code loaded successfully but never reaches main(), the problem resides on 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.


Troubleshooting the connect phase

The items below are useful to double check all aspects involved with a good connection. Also, each item is followed with some common scenarios described in the Common Errors topic below.

1. Check that you are using high quality cables for connections and the connections are not loose.

  • Poor cable quality has resulted in failures during Windows/Linux device driver intialization or during a CCS debug startup/connect. Also, loose cable connections are more difficult to troubleshoot, as they may work fine at certain times.
  • In general this problem shows errors such as:


2. Determine whether the debug probe is correctly setup in the Host by checking either the Windows System Devices control panel or using Linux command line tools (details here). For XDS100, please check section 2.6 (troubleshooting) of the XDS100 page.

In case the drivers are not correctly installed, it is possible you have to update the TI Emulators component of CCS (details here), contact your debug probe vendor to make sure the driver is installed properly, or ultimately reinstall your copy of CCS.


3. Check all hardware - details are shown in the section Hardware checklist below.


4. Check if the target configuration file (.ccxml) accurately describes your JTAG debug probe (Connection) and target (Device or Board).

  • Invalid configuration can spawn any errors shown previously, including also:


5. Check if the target configuration file (.ccxml) is running at a clock speed compatible with the board and device. The youtube quick tip Experimenting with JTAG clock speed shows a strategy to determine a reliable TCLK speed.

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:
How to properly set the speed when using a Spectrum Digital XDS510USB emulator
How to properly correct a bug on the Debug Access Port designator (all emulators)


6. Check if you have the proper license to work with the JTAG debug probe (details here)


7. Sometimes the JTAG debugger is completely at fault - i.e., not working at all or partially working. In this case, it is absolutely unpredictable what types of messages can be shown.


8. If you are unable to connect to a specific core of an SoC device (IVAHD, EVE, IPUSS, PRUSS, etc.), you may need to release it from reset.

Note: For some C6000 and SoC devices, you can inspect the status of each core individually by using the ICEPICK. Check the section Core Status at the GSG:Connecting to slave cores in SoC devices page.


9. If you are unable to connect to a flash-based device, keep in mind that pre-loaded code may prevent it from properly connecting.


Hardware checklist

The aspects below can trigger an unpredictable number of error messages, therefore making it very difficult to pinpoint the root cause.

1. Check if the connector is properly seated in the target board:

  • For most of the TI connectors (14 and 20 pin) that have a guide pin (pin 6), it is impossible to connect them in reverse. However, keep in mind they still may be connected displaced - i.e., only one row of pins is connected to the board.
  • All the ARM connectors (10 and 20 pin) do not have the guide pin, therefore check both the placement of the pin 1 and the displacement of the connector by an entire row.


2. Double-check the USB cable you are using: either if it is broken, loose or is a charger-only cable (no data, only 5V power).

3. 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, instructions for the Beaglebone White can be found here.


4. 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.

5. Review the Emulation FAQ

6. If experiencing sudden target disconnects, the cable between the JTAG debugger and the board may be loose or broken. Also, the JTAG clock speed may be too high.

7. 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.This typically manifests itself as the connection to CCS becoming unstable or intermittent.

In general using an isolated JTAG debugger or an adapter helps with this issue. [1]




Common errors

Host connection error

The error below is thrown by CCS when the device driver is unable to communicate with the JTAG debugger either via USB or Ethernet.

Due to the nature of the different debug probes, the error messages vary according to the XDS family.

This can have several sources:

  • The Windows device drivers are not properly installed or failed to initialize. Check the Windows Control Panel or the XDS200 known issues.
  • The Linux udev rules are not properly configured. Either check Linux lsusb and udev rules, run the install_drivers.sh script as shown here or check the XDS200 known issues.
  • The JTAG debugger failed to boot properly (XDS200 and XDS560v2). For XDS560v2, check the manufacturer's debug probe manual to see if it is in Safe Mode.
  • The JTAG debugger is not powered (some variants of XDS560 and XDS560v2). Check the external power supply.
  • The USB cable has loose contacts or not connected at all. Replace the USB cable and retest.
  • The USB is connected via an incompatible USB HUB or port. Connect the USB cable directly to the host PC or to a different port.
  • The debug probe firmware is incompatible with the OS. This is mostly applicable to XDS110 and XDS200. To verify this you can check the steps shown in the Firmware update section for XDS110 and XDS200.


XDS200, XDS560 and XDS560v2:

Error initializing emulator:
(Error -2083 @ 0x0)
Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.

The Test Connection button reports a different message, but it refers to the same problem:

E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)

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 or utilities.

The value is '-250' (0xffffff06).
The title is 'SC_ERR_ECOM_EMUNAME'.


XDS110:

This error is generated by TI's USCIF driver or utilities.

The value is '-260' (0xfffffefc).
The title is 'SC_ERR_XDS110_OPEN'.

The explanation is:
An attempt to connect to the XDS110 failed.
The cause may be one or more of: invalid firmware update, invalid 
XDS110 serial number, or faulty USB connection. The firmware and 
serial number may be updated using the xdsdfu utility found in 
the .../ccs_base/common/uscif/xds110 directory of your 
installation. View the ReadMe.txt file there for instructions.


XDS100:

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 or utilities.

The value is '-151' (0xffffff69).
The title is 'SC_ERR_FTDI_OPEN'.

The explanation is:
One of the FTDI driver functions used during
the connect returned bad status or an error.
The cause may be one or more of: invalid XDS100 serial number,
blank XDS100 EEPROM, missing FTDI drivers, faulty USB cable.
Use the xds100serial command-line utility in the 'common/uscif'
folder to verify the XDS100 can be located.


XDS510 Spectrum Digital:

** BoardFilePath: C:\Users\user\AppData\Local\TEXASI~1\CCS\CCSV6_~3\0\0\BrdDat\testBoard.dat
** Resetting Emulator
     ERROR -- XDS510-USB Emulator not connected/enumerated


XDS510 (not Spectrum Digital):

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 or utilities.

The value is '-118' (0xffffff8a).
The title is 'SC_ERR_OCS_PORT'.

The explanation is:
The hardware or software support only limited values of port addresses.




Cable break

This error means the JTAG debugger is sending data to the device via the TDI pin but is not receiving anything back on the TDO pin.
This error can either have two variants: near or far from itself, which means the JTAG circuit is broken close to the JTAG debug probe or close to the board.

Note: in the specific case of XDS100 debug probes, this error may happen also if the wrong variant is selected: for example, a XDS100v2 is configured but a XDS100v1 is present on the target.

Technically a cable break is detected by a pin that is grounded when the cable is plugged in. If the pin is on the connector that plugs into the target board, it is often called Cable Break Far or sometimes just Cable Break. If the pin is on the connector that plugs into the debug probe (e.g. the cable pod of an XDS560v2), that is called Cable Break Near.

Error connecting to the target:
(Error -183 @ 0x0)
The controller has detected a cable break far-from itself.
The user must connect the cable/pod to the target.


Another possible cause of a "cable break far-from itself" could be that the TVRef signal (pin 5) is pulled up to the IO voltage, or TDIS (pin 4) is pulled-down to ground. TVRef should be connected to the IO voltage through a small current limiting resistor. TDIS should be connected directly to ground. See XDS Target Connection Guide for more information on the connection of these and other emulator signals.



Power loss

This error means the JTAG debugger is unable to sense the presence of a power supply voltage on the target - the TVRef pin.

Error connecting to the target:
(Error -180 @ 0x0)
The controller has detected a target power loss.
The user must turn-on or connect the power supply for the target.


Device register

This error means the JTAG debugger is unable to access the core or device on the board.

Technically speaking, this happens if the JTAG debugger fails to access an ICEPick register (exceptions are MSP430, Stellaris and some C2000 Wireless connectivity and Digital Power MCUs, which do not have an ICEPICK). If the ICEPick driver reports this error immediately upon connect, it's likely a hard fail with the JTAG connection itself (loose cables or connections, etc.). However, if the error happens later in the debug session the reasons are different (perhaps the reliability of the JTAG connection due to noise, etc.).
To properly debug and correct this error please refer to the section Troubleshooting the connect phase above.

Error connecting to the target:
(Error -2131 @ 0x0)
Unable to access device register. Reset the device, and retry the operation. If
error persists, confirm configuration, power-cycle the board, and/or try
more reliable JTAG settings (e.g. lower TCLK).




SWO/SWD and cJTAG

This error means the JTAG debugger is configured for SWD but is connected to a target that does not support it. Correct the target configuration file.

IcePick_C_0: Error connecting to the target: (Error -611 @ 0x0)
A request was received to control the JTAG state or to execute a
JTAG scan while the debug probe is in SWD mode. JTAG operations
over SWD are not supported.




Invalid license

This error means you are trying to connect to a JTAG debugger unsupported by the Free Evaluation License.
The error message is pretty self-explainable.

License cannot be acquired.

The Code Composer Studio license that you are using only allows the following
connection types:
- XDS100 class emulators
- MSP430 connections
- simulators
- EVMs/DSKs/eZdp kits with onboard emulation

Examples of restricted connections includes:
- XDS200, XDS510 and XDS560 emulators


Device hung

This error means the JTAG debugger is unable to either put the core in debug mode (case of ARM cores) or the core did not acknowledge the JTAG debugger's requests.
Technically, in certain circumstances the CPU may be hung waiting for a resource or a bus to become available, thus possibly preventing the JTAG debugger or the normal processing flow to occur. In this case it is possible that the application made some access that caused memory bus to hang (bus contention).
Also, when the driver's attempt to HALT the core fails, it checks to see whether it is due to memory-hang condition. If so, it tries to clear that condition and returns a warning (a ready-hang condition) and proceeds. If it still can't access the core after that, then it means the bus stayed locked up as subsequent memory accesses continue to fail and it gives up.
In other circumstances the JTAG debugger could not precisely determine the cause of the memory bus error ("may be hung"), therefore it is very difficult to define where this issue is originated. Similarly as above, a bus may be hung range from either an invalid instruction that can misconfigure the memory interface; a bus locked by another core, a peripheral or DMA (bus contention) or even a power supply dip when a specific piece of hardware is accessed.
This error manifests itself in several messages:

  • These are unrecoverable errors during connection that prevent the JTAG debugger from gaining control over the core. They will require either issuing a System Reset, a board Hardware reset or power cycle.
Error connecting to the target: (Error -1144 @ 0x0) Device core is hung.
The debugger attempted to recover debug control, but was unsuccessful. Power-cycle the board.
If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). 
Error connecting to the target: (Error -1060 @ 0x0) Device is not responding to the request.
Reset the device, and retry the operation.
If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
  • These are variations of the above error that happen after a successful connection, where the code is put to run but any attempts to halt it are being blocked by a memory bus contention. This is an unrecoverable error that prevents the JTAG debugger from halting the core. It will require either issuing a System Reset, a board Hardware reset or power cycle.
Trouble Halting Target CPU: (Error -1205 @ 0x80006FE8) Device memory bus has an error and may be hung.
Trouble Halting Target CPU: Error 0x80001820/-2062 Fatal Error during: Execution, Timeout, Target, Cannot halt the processor
  • This is an error that was recovered but the code integrity is unknown. At this point it may be possible to dump memory and try to find the source of the error.
Error connecting to the target: (Error -1143 @ 0x0) Device core was hung. 
The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt.
You should have limited access to memory and registers, but you may need to reset the device to debug further.
  • This is a recoverable warning that indicates something is preventing the CPU from accessing memory. At this point the code integrity is ok and it gives the most chances to find the source of the error.
Warning: Error 0x40000202/-1205
Warning during: Memory, OCS, The memory bus has encountered a 'ready-hang' condition.




Lost control of device execution state

This error means the device is free running and the JTAG debugger lost control of its core and status. Both a disconnect and power cycle will be required, but there is a possibility the running firmware on the device may be preventing the JTAG debugger from properly connecting (if the device has flash memory). In these cases, consult the documentation of your device to find out how to unlock it.

Error: (Error -2134 @ 0x0)
Unable to control device execution state. Reset the device, and retry the operation. 
If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).


Device blocked

This error means the device is free running and the JTAG debugger lost control of its core and status. Both a disconnect and power cycle will be required, but there is a possibility the running firmware on the device may be preventing the JTAG debugger from properly connecting (if the device has flash memory). In these cases, consult the documentation of your device to find out how to unlock it.

Trouble Reading Register PC: (Error -1142 @ 0x0)
Device blocked debug access because it is currently executing non-debuggable code.
Choose 'Rude Retry' to disable polite mode and force the operation.


Invalid device ID

This error is caused by the inability of the JTAG debugger to read the unique device identifier code in one of its registers. This is usually caused by either a hardware failure on the board, severe interference or noise on the JTAG channel or, in flash-based devices, a faulty application that disrupts the device regular operation either by issuing continuous resets, hard faults, power outages, etc. In more unusual circumstances it may also be required to update the device support in CCS or the JTAG debugger device drivers.

Note: a common error happens in MSP432 and it is caused by invalid example code. Please check this post for additional details and this post for a way to recover the development board.
Error connecting to the target: (Error -1063 @ 0x0)
Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver.


Low power run mode

These errors mean the device is in low power run mode. Depending on the severity of the condition, the JTAG debugger may or may not be able to bring it out of this mode.

If there are no other external factors that are holding this device in low power, the JTAG debugger will most probably be able to successfully bring the device out of this mode:

Error: (Error -1156 @ 0x0) Device may be operating in low-power mode. Do you want to bring it out of this mode?

However, if there is a more severe power outage on the device, the JTAG debugger is unable to bring it out of this mode:

Error: (Error -1155 @ 0x0) Device may be operating in low-power mode. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). 

The solution to this error message is usually more involving. A good troubleshooting e2e forum thread is here.

Library error

This error means the software and device drivers are not properly installed. A reinstall of the TI Emulators component or CCS will be required.
Also, this issue happens if the installation directory is not accessible (CCS is installed in C:\Program Files or other protected area by Windows).
This error could also happen if the "Connection" and "Board" selected in the Target Configuration are not the correct selections for the target board.
Note: Additional troubleshooting tips can be found at this e2e forum post

This error is generated by TI's USCIF driver or utilities.

The value is '-600' (0xfffffda8).
The title is 'SC_ERR_LIB_ANY_LOCATE'.

The explanation is:
A required dynamic library could not be located.
The library isn't on the search path.




Invalid data read back

This error varies greatly depending on the type of fault and therefore both CCS and the Test Connection can return different results.

Common to all scenarios is when the integrity scan-test fails with invalid data - something mentioned in this thread.
One example is a typical stuck-at-ones or stuck-at-zero fault:

Error connecting to the target:
(Error -233 @ 0x0)
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.
  • If the data read back is all ones (0xFFFFFFFF), it is possible that one of the JTAG lines has a short to VCC.
  • If the data read back is all zeros (0x00000000), it is possible there is a power failure on the circuit or one of the JTAG lines has a short to GND.
  • If using an isolated JTAG debug probe, it is possible that both scenarios may happen if the target board or device is powered down. In this case, make sure power is properly applied across the system.
    • Most of the F28x development kits return 0xFFFFFFFF if the device section of the kit is powered down (if the kit has an isolated JTAG), if the jumper settings disable JTAG access or if the bootmode is set to anything other than JTAG. Please carefully review the documentation of your kit.
  • If the data read is garbage such as in the example below, probably reflections on the JTAG line, loose target cables or connectors or problems on the PCB routing are most probably the root causes. Also, invalid configurations such as cJTAG/JTAG or a very high TCLK speed can cause garbled data to be read back.
-----[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.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0xFFFFFFC1.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0x0000003F.
Scan tests: 2, skipped: 0, failed: 2
Do a test using 0xFE03E0E2.
Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0x80F83880.
Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0x80F838BF.
Test 3 Word 2: scanned out 0xFE03E0E2 and scanned in 0x80F838BF.
Test 3 Word 3: scanned out 0xFE03E0E2 and scanned in 0x80F838BF.
Test 3 Word 4: scanned out 0xFE03E0E2 and scanned in 0x80F838BF.
Test 3 Word 5: scanned out 0xFE03E0E2 and scanned in 0x80F838BF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 3, skipped: 0, failed: 3
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 4
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 5
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 6
Some of the values were corrupted - 66.7 percent.

The JTAG IR Integrity scan-test has failed.

-----[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.
Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 2: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 3: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 4: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 5: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 6: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
Test 3 Word 7: scanned out 0xFE03E0E2 and scanned in 0xFC07C1C5.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 3, skipped: 0, failed: 1
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 2
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 3
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 4
Some of the values were corrupted - 66.7 percent.

The JTAG DR Integrity scan-test has failed.




Pipeline stalled

This error is shown when the JTAG debug probe tries to connect to a core that is locked pending a pipeline operation to complete. This is usually caused by a excessive number of interrupts or by a peripheral or bus contention - all these are caused by the running application.

This situation cannot be easily recovered, but some useful tips are shown at this forum post.

Trouble Halting Target CPU: (Error -1323 @ 0xB10002C) Device failed to enter
debug/halt mode because pipeline is stalled. Power-cycle the board. If error persists,
confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).


Dead JTAG clock

This error is shown when the JTAG debug probe does not receive a clock signal on the RTCK pin. It can have many reasons:

  • The speed of TCLK is configured for a rate too high for the board and device
  • The type of TCLK is configured for either fixed or adaptive but is unsupported by the device
  • The board PCB or device does not tie the TCK pin to the RTCK pin
Error connecting to the target:
(Error -181 @ 0x0)
The controller has detected a dead JTAG clock. 
The user must turn-on or connect the JTAG clock for the target.


C28x the debug probe reported an error

This error is commonly associated with C28x devices and is usually associated with a range of hardware or firmware problems that prevent the JTAG debugger to connect to the core.

  • Differently than most other errors, this issue only manifests when attempting to connect to the target using CCS, but the Test connection returns successfully.
C28xx: Error connecting to the target:
(Error -1135 @ 0x0)
The debug probe reported an error.
Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. 

The discussions below cover some possible root causes for this issue:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/270397
https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/180790/653247
https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/564965

Invalid parameters or command

This is a very rare error and indicates the version of the JTAG debugger device drivers are incompatible with the version of CCS used.
In this case, it is necessary to contact the JTAG debugger manufacturer to provide updated device drivers.

Error connecting to the target:
(Error -120 @ 0x0)
This error number is used when a command is invalid.
It is likely a problem with `SC_CMD' in SMG_call()
selecting a function that has not been implemented.
(Emulation package 5.1.450.0)


Generic FTDI failure

This is a very unusual error and its exact reason is not entirely characterized. It is reported on this thread, this thread and this thread.

This error is generated by TI's USCIF driver or utilities.

The value is '-150' (0xffffff6a).
The title is 'SC_ERR_FTDI_FAIL'.

The explanation is:
One of the FTDI driver functions used during
configuration returned a invalid status or an error.

In this case, a procedure of resetting the JTAG debugger using dbgjtag was reported to being effective to restore communications.

  1. run the 'Test Connection' script in the CCSv6 target configuration tab --> FAIL with log shown in previous post (error code -150)
  2. run dbgjtag tests WITH reset (integrity, broken, path length, given data) --> all tests FAIL with same failure code (error code -150)
  3. run dbgjtag tests WITHOUT reset (integrity, broken, path length, given data) --> all tests PASS
  4. run dbgjtag tests WITH reset (integrity, broken, path length, given data) --> all tests PASS
  5. run the 'Test Connection' script in the CCSv6 target configuration tab --> PASS


The emulator reported an error

This is an error common to C28x devices and XDS100v1 or XDS100v2 debug probes and usually manifests when the debug probe has trouble communicating with the target device (the USB connection is fine).

Error connecting to the target: (Error -1041 @ 0x0)
The emulator reported an error. Confirm emulator configuration and connections, reset the emulator, and retry the operation.

This can be caused by several sources of errors: a problem in the FTDI chip, bad I/O pins on the debug probe, issues on the circuit between the FTDI chip and the JTAG header, or a problem with the target device.
You can try to workaround or solve this issue by swapping the JTAG debug probe and/or target device or board. In rare cases the FTDI device on the XDS100 debug probe may be broken.

Cannot access the DAP

This error is caused by the inability of the JTAG debugger to access the DAP or one of its ARM subcores. This is usually caused by either a hardware failure on the board or invalid code on the subcore that causes it to reset itself continuously.

If this error is originated in software, it can potentially be recovered by accessing the DAP directly and trying to either reset the offending core, lock it or erase its flash memory via a GEL script (some microcontrollers have pre-loaded routines to allow that).

Notes:
  • Some users reported this error also happens in conjunction with the Invalid device ID error above.
  • For certain devices such as CC13xx and CC26xx, the GEL script is directly available on the menu Scripts → <device name> → MassErase.
Error: (Error -1170 @ 0x0)
Unable to access the DAP. Reset the device, and retry the operation.
If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). 


FTDI driver function error

This error happens whenever the JTAG scan manager software has sent a command to the FTDI chip in the XDS100, and the FTDI driver returned either an error code or the wrong amount of data (usually an embedded error code in the data). This can be caused by either an unreliable USB connection (data is corrupted going to or from the FTDI chip), hardware problems (the FTDI chip in the XDS100 is not responding properly) or a software bug in the scan manager software.

This error is very similar in nature as the Host connection error and similar workarounds mentioned there are applicable.

IcePick: Error connecting to the target: (Error -154 @ 0xFFFFFF66)
One of the FTDI driver functions used to write data returned bad status or an error.


Target timeout

This error happens whenever the JTAG tries to read a target device but it does not respond to the requests after an arbitrary number of retries. This is usually caused by similar conditions as the lost control of the device execution state.

IcePick_C: Error connecting to the target: (Error -275 @ 0x0)
The attempt to poll a target device exceeded its timeout limit.
The utility or debugger has requested that a target device be repeatedly accessed for a specific data or status value. 
This has failed because the built-in limit for the maximum number of attempts when polling the JTAG scan-path has been exceeded. 


Path measure

This error happens whenever the JTAG cannot find a consistent number of bits when trying to determine the length of the JTAG scan chain. This error varies depending on the target device configured, its status (locked, halted, running without control) or if the configured TCLK is too high.

The message below is displayed when the TCLK is too high. This can be solved by reducing the TCLK speed as mentioned at this section

This error is generated by TI's USCIF driver or utilities.

The value is '-501' (0xfffffe0b).
The title is 'SC_ERR_TEST_MEASURE'.

The explanation is:
The built-in scan-path length measurement failed.
The built-in scan-path reliability tests cannot be
performed without knowledge of the scan-path length.
Try specifying the scan-path lengths in the command-line
options or board configuration file of this utility or debugger.


The error below is reported in two scenarios:

  • If using CC13xx/CC26xx devices, they are possibly locked. This is usually solved by unlocking/unbricking the device as mentioned in this FAQ. This e2e thread also discusses this scenario.
  • If using a XDS510-class debug probe, this means the device configured in the target configuration file (.ccxml) is different than the one attached to the debug probe. This is solved by matching the device chosen in the target configuration editor to the device present in the board.
This error is generated by TI's USCIF driver or utilities.

The value is '-230' (0xffffff1a).
The title is 'SC_ERR_PATH_MEASURE'.

The explanation is:
The measured lengths of the JTAG IR and DR scan-paths are invalid.
This indicates that an error exists in the link-delay or scan-path.

A router subpath cannot be accessed

This error is caused by the inability of the JTAG debugger to access any of the subpaths of either the ICEPICK or the DAP. This is usually caused by either a hardware failure on the board or invalid code on the subcore that causes it to reset itself continuously. This is very similar in nature to the error Cannot access the DAP above but at a higher level.

If this error is originated in hardware (custom hardware or faulty board or connections), please check this relevant e2e discussion. Also, power supply problems can lead to this issue as reported in this e2e discussion.

If this error is originated in software, it can be either due to a problem with the configuration file (as mentioned in this e2e discussion) or potentially be recovered by [https://youtu.be/-yGmq_VKvTQ accessing the DAP directly and trying to either reset the offending core, lock it or erase its flash memory via a GEL script (some microcontrollers have pre-loaded routines to allow that).

Notes:
  • For certain devices such as CC13xx and CC26xx, the GEL script is directly available on the menu Scripts → <device name> → MassErase.
Error connecting to the target:
(Error -242 @ 0x0)
A router subpath could not be accessed.
The board configuration file is probably incorrect.

Incorrect SWD header

This error is caused by the inability of the debug probe to communicate with the device that uses SWD as the protocol. This is usually caused by a hardware failure or unreliability of the board. This is very similar in nature to the errors Cable Break or Device Register.

Notes:
  • For Launchpads, check if the TMS and TCK jumpers are in place.
Error connecting to the target: 
(Error -615 @ 0x0)
The target failed to see a correctly formatted SWD header.
The connection to the target may be unreliable.
Try lowering the  TCLK setting before trying again.