10.7. Common JTAG Errors

Error messages are usually shown in the following format:

Core_<core number> Error message title: (Error code @ address) Error message body. (Emulation package version)

  • Core_<core number>. As the name says, this is the element that triggered the error. It may be a processor core (Cortex_M4, Cortex_A8, C28xx) or a JTAG entity (ICEPICK, CS_DAP) followed by the position of the element in the JTAG tree.
  • Error message title. This is the main title of the error message.
  • Error code @ address. The error code is a negative number that can be easily searchable. The address is only relevent if the error happens due to memory access error.
  • Error message body. This is the explanation of the error with some general suggestions to troubleshoot it. It is recommended to find additional information in this section.
  • Emulation package version. This is the version of the TI Emulators component installed with your IDE of choice.

Note

Minor variations were introduced to the error message format over the years. However, all elements are easily recognizable and can be searchable on this page.

10.7.1. Host connection error

The error below is thrown by Code Composer Studio 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:

  • First and foremost: Hardware. Check for faulty hardware.
  • The Windows device drivers are not properly installed or failed to initialize. Check the Windows Device Manager, the XDS100 troubleshooting, the XDS110 troubleshooting or the XDS200 troubleshooting.
  • 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 or the DTC_CONF page to see if it is in Safe Mode.
  • There is another user already connected to the JTAG debugger (Ethernet-based Debug Probes). For XDS560v2, check the DTC_CONF page to learn how to find which host is using the probe.
  • 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: This has two variants that may happen in alternate circumstances:

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.

Error connecting to the target:
(Error -2172 @ 0xD)
Unable to communicate with the emulator.
Confirm emulator configuration and connections, reset the emulator, 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.

10.7.2. 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 in the section References above for more information on the connection of these and other emulator signals.

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

The error below happens if a XDS110 is being used, the Power Selection setting is set to Probe supplied power but the hardware itself is not properly providing power to the target device. In this case, verify if all power connections or launchpad jumpers are correctly connected.

Error connecting to the target:
(Error -267 @ 0x0)
The controller could not detect valid target supply.
Check target JTAG connection and/or connection setting specifying voltage level.

10.7.4. 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, or improper firmware that causes the device to power cycle or reset, etc.).

This issue can also manifest itself if the Debug Probe senses the scan path is broken. Some troubleshooting tips can be found at the section Invalid data read back below.

In certain scenarios the loaded code may cause issues with the normal connection and/or execution. In this case, check the troubleshooting tips in the error Invalid device ID below.

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

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

  • A special case is applicable to CC32xx devices: in the Device or Board selection of the Target Configuration File, it is required to select the device with the suffix _SWD: CC3200_SWD, CC3220_SWD, CC3220S_SWD, CC3220SF_SWD and so on.

    • Technically speaking, the CC32xx devices feature the JTAG router called ICEPICK, which is not supported by the SWD protocol. In this case, when the tool detects that the ICEPICK is present in the scan chain configuration, it automatically falls back to the JTAG protocol, thus throwing this error.
    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.

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

Selected cores (C64x+, C674x, C66x) support a mechanism called Emulation Force Ready, which is a way for the Debug Probe to de-assert the RDY- signal and halt the CPU immediately. This preserves the entire state of the core/device except the core pipeline, which is flushed. Also, any memory access may cause the CPU to be hung again if it is misconfigured. Even still, halting the CPU allows to perform a deeper analysis of the root cause of the failure.

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.

Still in other circumstances, the device is either being held in reset due to an external factor (HW) or cannot recover from reset due to an internal factor (SW). Check the section Device is held in reset below.

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.

10.7.7. 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).

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

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

10.7.9. 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 Code Composer Studio or the JTAG debugger device drivers.

Tip

A common error happens in MSP432 and it is caused by invalid example code. Please check this e2e forum post for additional details and this e2e forum post for a way to recover the development board.

Tip

For TM4C (Tiva) devices, this error was reported with board routing issues. Please check the document Using TM4C12x Devices Over JTAG Interface - SPMA075 or this e2e forum post if using the ICDI or Launchpad interface.

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.

10.7.10. 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 is shown in this e2e forum thread.

10.7.11. Library error

This error means the software and device drivers are not properly installed. The following tips are relevant:

  • A reinstall of the TI Emulators component (details at this link or Code Composer Studio may be required.
  • This issue happens if the installation directory is not accessible (if Code Composer Studio is installed in C::raw-latex:`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.
  • This e2e forum post reports that uninstalling/reinstalling the drivers directly from the Windows Control Panel can be an alternative to solve this issue.
  • This e2e forum thread reports that HW issues can cause this issue when XDS100 Debug Probes are being used.
  • This e2e forum post shows additional troubleshooting tips for XDS100 Debug Probes (which can be extended to other models).
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.

10.7.12. Invalid data read back

This error varies greatly depending on the type of fault and therefore both Code Composer Studio 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 e2e forum thread.

One example is a typical stuck-at-ones or stuck-at-zero fault, that can manifest in two ways:

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.

Error connecting to the target:
(Error -235 @ 0xffffff15)
The data scan-path cannot circulate bits, it may be broken.
An attempt to scan the JTAG data registers has failed.
The target's JTAG data 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.

  • Certain devices such as F28x suggest a resistor to pull the TRST pin low. However, if the resistor is too small this error may manifest itself. This is reported in this e2e forum post.

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

10.7.13. 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 e2e 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).

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

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

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 e2e forum threads below cover some possible root causes for this issue:

This error can also manifest when caused by the problems reported in the Invalid data read back section above.

10.7.16. 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 Code Composer Studio 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)

10.7.17. Generic FTDI failure

This is a very unusual error and its exact reason is not entirely characterized. It is reported on the following e2e forum threads:

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 CCSv7 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 CCSv7 target configuration tab → PASS

If the above procedure does not resolve the problem, another solution that has been effective on Windows installations is to force an update of the FTDI drivers. This can be accomplished by running the below command from a Windows Command Prompt and within the Code Composer Studio installation location shown below:

C:\ti\ccs2000\ccs\ccs_base\emulation\windows\DPInst64.exe /path .\ftdi_drivers

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

10.7.19. 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.
  • A procedure to try and unlock a Hercules device is described in this e2e forum thread.
  • For CC3200/CC3220 devices, a few issues can cause this:
    • If using a Launchpad, the SOP jumpers may be set to “Flash” and not JTAG or SWD. Check this e2e thread for a more thorough procedure.
    • The device may also be in production mode. Check this e2e thread for details.
    • The device may be locked due to firmware problems, either the Service Pack or the Application firmware. Check the Launchpad and SDK documentation for details.
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).

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

If the error happens continuously, this is very similar in nature as the Host connection error and similar workarounds mentioned there are applicable.

If the error happens suddenly, then noise or ground problems may be the root cause.

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.

10.7.21. 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 and the Security Error.

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.

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

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

10.7.23. 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 e2e forum thread. Also, power supply problems can lead to this issue as reported in this e2e forum thread.

If this error is originated in software, it can be either due to a problem with the configuration file (as mentioned in this e2e forum thread or potentially be recovered by accessing the DAP directly and trying to either reset the offending core, lock it or mass erase its flash memory.

Error connecting to the target:
(Error -242 @ 0x0)
A router subpath could not be accessed.
The board configuration file is probably incorrect.

10.7.24. 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 error might also be caused by mis-configured jumpers on the target board. This is very similar in nature to the errors Cable break or Device register.

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

10.7.25. Security Error

This error is caused by the inability of the debug probe to communicate with the device or core, despite the physical connection is fine. This can be caused by a large number of sources, but the most common are:

  • The device being used is in secure mode and requires a specific procedure to unlock it. Certain devices have a security module that prevents any intrusive access to its core (including JTAG) and require a specific unlocking mechanism on the running code on the board (MLO, u-boot, etc.). A solution to this forcefully demands having this specific code. Contact your TI representative for details.
  • The device or core is either powered down, incorrectly or does not have a valid clock. In these cases the JTAG debug probe can be fooled into thinking the device or core are secure but they are simply inaccessible. The solution to this is not unique but it requires thoroughly checking all clock and power signals on the target board. Some reported issues are:
  • The device is flashed with code that prevents JTAG access to the core. This is mostly common on microcontrollers (due to the presence of Flash memory).
  • For Launchpads, check if the TMS and TCK jumpers are in place.
Error connecting to the target: (Error -241 @ 0x0)
A router subpath could not be accessed.
A security error has probably occurred.

10.7.26. C28x Device Locked

This error is caused by the inability of the debug probe to communicate with the device. This can be caused by a number of sources but the most common are:

Error connecting to the target: (Error -1015 @ 0x0)
Device is not responding to the request.  Device may be locked, or the emulator connection may be unreliable.
Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board).
If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).

10.7.27. Device is held in reset

This error is caused by the inability of the debug probe to restore communications with the device or a core before or after a reset or power up was issued.

When the issue happens with corrupt pre-flashed code, the device or core may be continuously forced to reset itself before the Debug Probe is able to control it, in a similar scenario shown in the errors Invalid Device ID and Device Hung.

  • For CC32xx devices, this error is known to be caused also by an invalid or corrupt Service Pack. This requires re-flashing it via Uniflash.

When using multi-core devices, the slave core may be intentionally held in reset and thus requiring a configuration script to release it from this state. This is very similar in nature to the errors Cannot access the DAP and A router subpath cannot be accessed above but at a core level.

Also, external hardware problems can influence this, including invalid or missing pull up resistors on reset lines, power glitches, etc.

When the device has pre-flashed code that is faulty, the error messages below are usually shown:

Failed CPU Reset: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board.
If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).

Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. 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).

For C28x devices, the error message itself can manifest in various forms but the error code is common to all of them.

Failed CPU Reset: (Error -1137 @ 0x6)
Device is held in reset. Take the device out of reset, and retry the operation

Trouble Reading Register PC: (Error -1137 @ 0x0)
Device is held in reset. Take the device out of reset, and retry the operation

Trouble Reading Register ST1: (Error -1137 @ 0x6)
Device is held in reset. Take the device out of reset, and retry the operation

For multi-core devices, the error can manifest itself with the following error codes:

Error connecting to the target: (Error -1266 @ 0x0) Device is held in reset.
Take the device out of reset, and retry the operation.

Error connecting to the target: (Error -1180 @ 0x0) Device is held in reset.
Take the device out of reset, and retry the operation.

10.7.28. Device status

This error is caused by the inability of the debug probe to communicate with the device.

This can be caused by a number of hardware problems such as improper reset or power applied to the device, issues with clock (external crystal or oscillator). In this particular case, it is mandatory to verify all hardware details of your system.

This can also be caused by faulty software running on the device, which causes the core to be on an unstable state. For flash-based devices, you may need to unlock or mass erase the device.

This error usually happens together with the Cannot Access the DAP error above.

Trouble Halting Target CPU: (Error -2064 @ 0x0)
Unable to read device status. Reset the device and try the operation again.
If the error persists, check the configuration, power cycle the board,
and try to make JTAG settings more stable (for example, lower TCLK).

10.7.29. Device is locked

This error is caused by the inability of the debug probe to control the core if the loaded firmware causes it to throw a Hard Fault exception or if a NMI is being serviced but it never returns. The root cause for this issue is a runtime problem with the firmware or application loaded to the core. It can manifest either immediately after the program is loaded or after some time or some specific function is put to run.

The exact cause is entirely dependent on the application and no single root cause. A few articles and e2e threads can help:

Can't Run Target CPU: (Error -1268 @ &lt;address&gt;)
Device is locked up in Hard Fault or in NMI. 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).

10.7.30. Frequency out of range

The Stellaris In-Circuit Debug Interface (ICDI) is a legacy design currently used for Cortex M4 devices such as the TM4C and CC3200 devices and its diagnostics are very limited, thus leaving very little room for investigation of a root cause by means of error codes and messages, being the most common:

CORTEX_M4_0: Error connecting to the target

CORTEX_M4_0: Error connecting to the target: Frequency is out of range.

Diagnostic and correction procedures varies greatly and can be found in several e2e forum threads:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/365430 https://e2e.ti.com/support/microcontrollers/other/f/908/t/310876 https://e2e.ti.com/support/microcontrollers/other/f/908/p/684957/2530350#2530350 https://e2e.ti.com/support/microcontrollers/other/f/908/t/368828

10.7.31. PRSC errors

PRSC is a DLL that is loaded and used by the TI Emulation software and provides information about the status (power, clock, etc.) of a processor. In certain devices it requires to read some registers from the emulation circuitry inside the device. If it fails to read the registers or the registers contained unexpected values then this error can be triggered.

Historically all the PRSC reported errors are sourced in Hardware: either improper power applied to the device, or a device being held in reset or improper clock being routed to the device. Although this can happen with development kits and EVMs, it is mostly common in the initial prototypes of custom boards.

For processors, several e2e threads discuss these scenarios, where the most common error is PRSC error -6305. A few are shown below:

For mmwave radar devices, there is a chance the device is in Flashing mode and not Functional mode, as reported in the following e2e thread:

For selected Simplelink microcontrollers that use cJTAG, the error below can manifest itself if the Debug Probe is mistakenly configured to use 4-wire JTAG.

Filed to retrieve the Wait in Reset Mode: (Error -6311) PRSC module failed to write to a register.

10.7.32. Required dynamic library jscserdes not found

This error is caused when the target configuration file (.ccxml) is configured to use the XDS100 Debug Probe but the target board uses a XDS110 Debug Probe. The root cause is that, since these two debug probes have a great deal of common configuration files, the emulation software mistakenly assumes the correct probe is loaded but the file is missing.

To correct this error, simply change the target configuration file from XDS100 to XDS110. This is very common in the F280049C Launchpad boards and a misconfigured example code.

Error connecting to the target:
(Error -716 @ 0x0)
Required dynamic library jscserdes could not be located.
The library isn't on the search path.

10.7.33. Invalid response was received from the XDS110

As the name says, this error affects the XDS110 class of Debug Probes and reflects a sudden loss of communications between the Debug Probe and the host. Depending on conditions, this may be recoverable or not.

Unfortunately a clear root cause was never found, although it seems more common when more than one channel of the XDS110 is being used: either JTAG and UART, or JTAG and Trace, or JTAG and EnergyTrace.

This error manifests itself as:

CORTEX_M4_0: JTAG Communication Error: (Error -261 @ 0x0) Invalid response was received from the XDS110.

A few threads that discuss this particular error can be found below:

10.7.34. Invalid TCLK programming option

As the error says, the configuration is trying to pass invalid parameters to the Debug Probe driver. Although there is not much action to be done in most cases, there is a special case that involves the MSP432P devices and XDS200 Debug Probes.

In this particular case, this is caused by a bug in the MSP432 Device support component that is part of Code Composer Studio versions 10.0.0 and 10.1.0. The TCLK parameter set by default for these devices is clashing with the XDS200 Debug Probe settings (although it works well for the XDS110 Debug Probes).

To fix this issue, open the Target Configuration File (.ccxml), select the tab Advanced, locate the setting The JTAG TCLK Frequency (MHz) and set this to Adaptive with user specified limit. Then, set this option back to Fixed with user specified limit and save the file. This is enough to override the bug.

Error connecting to the target:
(Error -300 @ 0x0)
The requested TCLK PLL programming option is invalid.
The utility or debugger has requested a selection of
the JTAG PLL frequency or clock source that is invalid.
The value of USCIF.TCLK_PROGRAM is probably bad.

10.7.35. Device functional clock

This error is caused by the inability of the debug probe to detect a stable clock on the device or core, either before or after a reset or power up was issued.

This is very similar in nature to the error Device is held in reset above but where the clock itself is affected. Please check this error for troubleshooting tips.

Error connecting to the target:
(Error -2081 - (0:0:0))
Device functional clock appears to be off. Power-cycle the board.
If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).