• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 83 subscribers
  • Views 214 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CCSTUDIO-THEIA: During debug, CIO appear to always be enabled.

CCSTUDIO-THEIA: Error state/“lock-up” between CCS and an external XDS110 debugger

Flemming Steffensen
Prodigy 140 points

Part Number: CCSTUDIO-THEIA
Other Parts Discussed in Thread: TMDSEMU110-U, TMS320F2800157-Q1

TLDR;

We see an intermittent “lock-up” between CCS and an external XDS110 (TMDSEMU110-U) when debugging F2800157 over cJTAG (1149.7) 2-pin advanced mode on Windows 11. When the lock-up happens, CCS can no longer start a debug session (often error -2131, sometimes -260) and “Test Connection” fails with SC_ERR_PATH_BROKEN (-233). Recovery consistently requires BOTH: (1) Windows Restart and (2) a full XDS110 power-cycle where BOTH USB and the cJTAG connector are disconnected. The lock-up is much more frequent in CCS 20.5.0 than in CCS 20.2/20.4/20.4.1. All tests across these CCS versions use the same XDS110 firmware: 3.0.0.41.

 

 

My colleagues and I are observing a problem with the TI XDS110 debugger on Windows 11 (not tested on other systems). The issue appears to have increased in recent months: it used to be very infrequent, but is now occurring several times a day for some of us.

We are working on two unrelated projects that both use the F2800157 MCU, but are otherwise independent. Our boards have independent power supplies, our computers are different brands, and we work from different locations.

Probe and setup notes:

  • External probe: TMDSEMU110-U (XDS110). The probe used for most of the tests is marked 518155-0001R Rev.A.

  • Target voltage has been verified with a scope and is a clean 3.3 V throughout the tests.

  • The PCB only supports cJTAG (1149.7) 2-pin advanced mode (no 4-wire JTAG option on this board).

  • All tests across CCS 20.2.0 / 20.4.0 / 20.4.1 / 20.5.0 use the same XDS110 firmware: 3.0.0.41 (confirmed with xdsdfu).

XDS110 firmware enumeration (CCS 20.5.0 installation) - used for all tests: 

USB Device Firmware Upgrade Utility 
Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved.

Scanning USB buses for supported XDS110 devices...

<<<< Device 0 >>>>

VID: 0x0451 PID: 0xbef3 
Device Name: XDS110 Probe with CMSIS-DAP 
Version: 3.0.0.41 
Manufacturer: Texas Instruments 
Serial Num: NOserial 
Mode: Runtime 
Configuration: Standard

Found 1 device.

 

Problem summary: 

After some number of successful debug sessions, CCS suddenly cannot properly communicate with the XDS110 anymore. This can happen:

  • when initiating a new debug session, OR

  • in between debug sessions (example: I can debug code, terminate the debug session, then try to re-load the same .hex for debugging again, and the lock-up has sometimes happened in between).

 

Recovery: 

Once the lock-up has occurred, recovery consistently requires:

  1. Disconnect the cJTAG connector between the XDS110 and target, AND disconnect the USB cable from the XDS110 (full XDS110 power-cycle).

  • Perform a Windows Restart. After this, debugging works again.

Simply restarting CCS, unplugging/replugging USB without doing the full sequence above, or power cycling only the target board has not been sufficient once the lock-up state has occurred.

 

 

CCS versions tested / observations

We have tested CCS 20.2.0, CCS 20.4.0, CCS 20.4.1, and CCS 20.5.0 (all downloaded from the TI web page).

CCS 20.5.0 is much more prone to the lock-up than older versions. Older versions almost never fail during normal use (we have seen the issue in the past, but much less frequently).

Also important: after the lock-up occurs in CCS 20.5.0, the “broken” state persist such that any other CCS version also fails to connect (until the Recovery sequence above is performed). This makes me believe the issue involve probe/driver/USCIF state, not only the CCS GUI. The XDS110 firmware remains the same (3.0.0.41) across all these CCS versions.

 

 

Target connection properties (.ccxml)

Both projects have these (preferred) connection properties:

Board Data File: auto generated
Debug Probe Selection: Only one XD110 installed
Power Selection: Target supplied Power
Voltage Level: Default
JTAG TCLK Frequency (MHz): Fixed default 5.5Mhz frequency
JTAG Signal Isolation: Do isolate JTAG signal at final disconnect
JTAG/SWD/CJTAG Mode: cJTAG (1149.7) 2-pin advanced modes   (This is the only mode available on the PCB)
Target Scan Format: OSCAN2 format - faster transisions
Auxillary COM Port Connection: Aux COM port is target UART port   (Note, not used)
UART Baudrate Threshold for DMA: 115200
 

To test, I have been using these variations for a while, and it is still the same problem:

JTAG Signal Isolation: Don't isolate JTAG signal at final disconnect
Target Scan Format: OSCAN1 format - non adaptive scans
 

 

 

Normal behavior

Typically, when starting the debug, some “Configuring the Debugger...” notification popups appear, and soon after that the GEL output window shows:

RAM initialization done

Memory Map Initialization Complete 

... DCSM Initialization Start ... 
... DCSM Initialization Done ... 
... DCSM Initialization Start ... 
... DCSM Initialization Done ... 
... DCSM Initialization Start ... 
... DCSM Initialization Done ...

.. and debugging will comence.

 

 

CCS error messages when lock-up occurs

After a random number of debug sessions, the “Configuring the Debugger...” notifications stop appearing, and after a after a long while, CCS reports this error:

IcePick_C_0: 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). (Emulation package 20.5.0.3902)

If I at this point disconnect the target board, it instead report the beloe error, till the target board is re-attatched, then it goes back to the first error.

IcePick_C_0: Error initializing emulator: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed. The cause may be one or more of: no XDS110 is connected, invalid firmware update, invalid XDS110 serial number, or faulty USB cable. 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 XDS110SupportReadMe.pdf file there for instructions. (Emulation package 20.5.0.3902) 

I notice that the error messages sometimes appear in notifications and then in either the GEL output window or the Debug Output Window, but once in a while it only appear as a notification.

 

 

Test Connection logs (good vs lock-up)

To debug the issue I opened TMS320F2800157-Q1.ccxml in CCS and pressed “Test Connection” (Advanced section).

If the connection is working (CCS 20.5.0 example), I get:

-----[Print the board config pathname(s)]------------------------------------

C:\Users\DKfls\AppData\Local\TEXASI~1\CCS\
ccs2050\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Mar 4 2026'.
The library build time was '18:13:05'.
The library package version is '20.5.0.3902'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will 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 controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 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 64 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.
 
 

When the lock-up occurs (CCS 20.5.0 example), “Test Connection” fails with SC_ERR_PATH_BROKEN (-233):

-----[Print the board config pathname(s)]------------------------------------

C:\Users\DKfls\AppData\Local\TEXASI~1\CCS\
ccs2050\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Mar 4 2026'.
The library build time was '18:13:05'.
The library package version is '20.5.0.3902'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will 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 controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[An error has occurred and this utility has aborted]--------------------

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

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
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.

 

 

Test workflow that sometimes triggers the loc-up: disconnect / query / reconnect

Disconnect the target board from the XDS110 and verify communications, then reconnect the board and verify communication. In that context it is expected and correct that:

  • If the cJTAG connector is disconnected, “Test Connection” reports that no valid target supply is detected (SC_ERR_XDS110_TARGET_SUPPLY, -267).

  • After reconnecting the cJTAG connector, “Test Connection” passes again.

 

In CCS 20.2.0 and CCS 20.4.0, this expected behavior appears reliable. In CCS 20.5.0, the same kind of usage (normal debug sessions, and occasionally disconnecting/reconnecting the target and running “Test Connection”) sometimes appears to trigger the lock-up state described above, after which only Windows Restart + full XDS110 power-cycle recovers. 

Example from CCS 20.5.0 when the target is disconnected (this output itself is expected, but in CCS 20.5.0 similar operations sometimes correlate with entering the persistent lock-up state):

 -----[Print the board config pathname(s)]------------------------------------

C:\Users\DKfls\AppData\Local\TEXASI~1\CCS\
ccs2050\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Mar 4 2026'.
The library build time was '18:13:05'.
The library package version is '20.5.0.3902'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.

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

The value is '-267' (0xfffffef5).
The title is 'SC_ERR_XDS110_TARGET_SUPPLY'.

The explanation is:
The controller could not detect valid target supply. Check target
JTAG connection and/or connection setting specifying voltage level.

 

 

 

Lock-up state persists across CCS versions until recovery

After an error in one CCS version, other CCS versions can not recover the connection.

Likewise, disabeling and enabeling the debug device through the Device Manager, have no effect on the error.

 

Questions to TI

  1. Is this a known issue with CCS 20.5.0 / emulation package 20.5.0.3902 when using XDS110 with cJTAG (1149.7) 2-pin advanced mode (OSCAN1/OSCAN2), and can it explain the persistent SC_ERR_PATH_BROKEN (-233) state after several debug sessions or after normal disconnect/reconnect usage?

  • Is there a recommended way to reset the USB controller/USCIF/XDS110 state without requiring a Windows Restart + full XDS110 disconnect (USB + cJTAG)? We are aware of xdsdfu.exe, but we have not found a procedure that clears the lock-up without the Restart + full disconnect.

 

  • 0
    Prodigy 140 points

    Note: I have several times attempted to fix the formatting issues of this post, but each time I try to commit/post a fixed version, the page hangs forever with the wait bubbles shown. :-(

    Note2: It would be really nice if the editor for reporting issues, and the editor to edit issues, were identical.

  • 0 in reply to Flemming Steffensen
    TI__Mastermind 34423 points

    Hi Flemming,

    Thank you for the extremely detailed report – this level of documentation is very helpful for diagnosing the issue. Based on your symptoms and testing across multiple CCS versions, I believe we're seeing a combination of factors that may include a regression in CCS 20.5.0's emulation package when handling cJTAG (1149.7) 2-pin advanced mode on Windows 11.

    Key Observations

    The fact that:

    • CCS 20.2.0 / 20.4.0 / 20.4.1 are stable with the same XDS110 firmware (3.0.0.41)
    • CCS 20.5.0 exhibits the lock-up much more frequently
    • The lock-up state persists across all CCS versions until full recovery
    • Recovery requires BOTH Windows restart AND full XDS110 power-cycle

    ...suggests the issue is deeper than just the CCS GUI – it appears to involve the emulation package (20.5.0.3902), USCIF driver state, or USB stack interaction with Windows 11.

    Recommended Troubleshooting Steps

    1. Windows 11 USB Power Management (High Priority)

    Windows 11's USB selective suspend and Fast Startup features are known to cause persistent XDS110 communication issues:

    Disable USB Selective Suspend:

    • Settings → System → Power & battery → Additional power settings
    • Change plan settings → Change advanced power settings
    • USB settings → USB selective suspend setting → Disabled

    Disable Fast Startup:

    • Control Panel → Power Options → Choose what the power buttons do
    • Uncheck "Turn on fast startup (recommended)"
    • Restart your PC after making these changes

    2. USB Connection Best Practices

    • Use a direct rear-panel USB 2.0 port (avoid USB 3.0 hubs and front-panel ports)
    • Ensure you're using a high-quality, shielded USB cable
    • Verify the XDS110 is not sharing a USB hub with high-bandwidth devices

    3. Alternative Reset Methods (Avoiding Full Restart)

    Before performing the full Windows restart + XDS110 disconnect, try these methods to reset the USCIF/XDS110 state:

    Method A: XDS110 Reset Utility

    # Run Command Prompt as Administrator
cd "C:\ti\ccs2050\ccs\ccs_base\common\uscif\xds110"
xds110reset.exe -reset

    Method B: Restart USCIF Driver Service

    # Run Command Prompt as Administrator
sc stop USCIF
sc start USCIF

    Method C: USB Root Hub Reset

    1. Disconnect the XDS110 from the PC
    2. Open Device Manager → Universal Serial Bus controllers
    3. Right-click "USB Root Hub (USB 3.0)" (or the hub the XDS110 is attached to) → Uninstall device
    4. Click "Scan for hardware changes" or reconnect the XDS110
    5. Re-launch CCS

    4. Firmware/Emulation Package Compatibility Check

    Check for CCS 20.5.0 Updates:

    • CCS → Help → Check for Updates
    • Install any available Emulation Package updates

    Consider Firmware Rollback to 3.0.0.40:

    There may be a compatibility issue between firmware 3.0.0.41 and emulation package 20.5.0.3902. Try rolling back:

    1. Navigate to: C:\ti\ccs2050\ccs\ccs_base\common\uscif\xds110
    2. Run xdsdfu.exe and reflash to firmware 3.0.0.40
    3. Reboot the PC after flashing

    5. cJTAG Configuration Adjustments

    Try reducing the TCLK frequency for more reliable operation:

    In your .ccxml connection properties:

    • JTAG TCLK Frequency: Try Fixed 2.5MHz or Fixed 1.5MHz (instead of 5.5MHz)
    • Keep: Target Scan Format = OSCAN1 format (non-adaptive)
    • Keep: JTAG Signal Isolation = Don't isolate

    Diagnostic Data Collection

    If the issue persists after trying the above, please collect the following for further analysis:

    1. CCS Debug Server Log during a failed connection attempt

      • View → Debug Server Log (capture output when SC_ERR_PATH_BROKEN occurs)

    2. Windows Build Number

      • Run winver and provide the full version number

    3. CCS Log Files

      • Help → About → Log Files → Save ccs.log from a session where the lock-up occurred

    4. Windows Event Viewer Logs

      • Windows Logs → System → Filter for "XDS110" or "USB" events around the time of lock-up

    Next Steps

    Given the significant difference in behavior between CCS 20.4.1 and CCS 20.5.0 with identical hardware and firmware, I recommend:

    Short-term workaround:

    • Continue using CCS 20.4.1 for production work (since it's stable)
    • Apply the Windows 11 USB power management fixes above

    For investigation:

    • Install the Windows 11 power management fixes and test if CCS 20.5.0 improves
    • Try the firmware rollback to 3.0.0.40 with CCS 20.5.0
    • If the issue persists, I'll escalate this to the CCS development team with your detailed logs

    This appears to be a regression that warrants investigation by the emulation package team, especially given your thorough testing showing the problem is specific to CCS 20.5.0.

    Please let me know the results after trying the Windows 11 power management changes and the alternative reset methods. If the issue continues, we'll work on getting detailed diagnostic logs to the development team.

    Note on your formatting issues: I apologize for the editor difficulties you experienced. For future posts, I recommend composing in a plain text editor first, then pasting into the E2E editor to avoid those hanging issues.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 140 points

    Thank you for an excellent answer, Zackary.


    #1, I have verified that both settings are already disabled.

    Unfortunately I do not have the exact same settings paths and options as you you pointed out available on my Windows (Win11 Enterprise, 24H2 26100.8246).

    Just to make sure I verified the settings from cmd:

    c:\ti\ccs2050>powercfg /q SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226
Power Scheme GUID: fb5220ff-7e1a-47aa-9a42-50ffbf45c673 (HP Optimized (Modern Standby))
Subgroup GUID: 2a737441-1930-4402-8d77-b2bebba308a3 (USB settings)
Power Setting GUID: 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 (USB selective suspend setting)
Possible Setting Index: 000
Possible Setting Friendly Name: Disabled
Possible Setting Index: 001
Possible Setting Friendly Name: Enabled
Current AC Power Setting Index: 0x00000001
Current DC Power Setting Index: 0x00000001


c:\ti\ccs2050>reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
HiberbootEnabled REG_DWORD 0x0

(0x0 means Disabled)

    #2 The debugger is connected to motherboard mounted USB 2.0/3.0 ports on our laptops. Different laptops have been used for testing. No desktop PC's are available for testing. However the same issues have been observed across both Dell and HP machines.

    #3 and onwards, I will test out these alternative reset methods, and further debug options as asson as possible (currently traveling wihout hardware).

    Finally, comments on your note about the formatting issues.
    I'm already using an external text editor (NotePad++), but unfortunately the forum does (appear to?) not use standard tags (Such as BB, markup, etc.) for formatting, requiring a lot of editing to happen in the online editor. Additionally the posing editor and the editing editor (after first posting) for both initial posts and comments are not identical (both with regards to features and layout), and allow for slightly different methods for contents formatting.

    In my current case it appear I was able to insert something in the posting editor for the initial post, that the editing editor does not accept, making it impossible for me to post an edit to the initial post.

    (This ought to be turned into a completely separate topic.)

  • 0 in reply to Flemming Steffensen
    TI__Guru**** 483601 points
    Flemming Steffensen said:
    We see an intermittent “lock-up” between CCS and an external XDS110 (TMDSEMU110-U) when debugging F2800157 over cJTAG (1149.7) 2-pin advanced mode on Windows 11
    Flemming Steffensen said:

    After some number of successful debug sessions, CCS suddenly cannot properly communicate with the XDS110 anymore. This can happen:

    • when initiating a new debug session, OR

    • in between debug sessions (example: I can debug code, terminate the debug session, then try to re-load the same .hex for debugging again, and the lock-up has sometimes happened in between).

    I assume this lockup happens during a debug session where a successful debug session was launched, debugger connection to the CPU was also successfully establish, and a program loaded. Is there any particular sequence of steps that can reliably trigger this "lock up" or is it pretty random? It looks like it is the latter.

    Regardless, it sounds like once this happens, the debug probe is in a bad state, which can cause the variety of errors that you are encountering.

    Flemming Steffensen said:
    Is this a known issue with CCS 20.5.0 / emulation package 20.5.0.3902 when using XDS110 with cJTAG (1149.7) 2-pin advanced mode (OSCAN1/OSCAN2), and can it explain the persistent SC_ERR_PATH_BROKEN (-233) state after several debug sessions or after normal disconnect/reconnect usage?

     I am not aware of such an issue.

    Flemming Steffensen said:
    Is there a recommended way to reset the USB controller/USCIF/XDS110 state without requiring a Windows Restart + full XDS110 disconnect (USB + cJTAG)? We are aware of xdsdfu.exe, but we have not found a procedure that clears the lock-up without the Restart + full disconnect.

    I assume you tried "xdsdfu -r" and it did not help. There is the xds110reset utility in the same folder, however that is for an actual system/board level reset for the target in addition to the xds110 reset. In most cases the "xdsdfu -r" should suffice. However it looks like the probe is getting into a bad state requiring the power cycle. I have never seen a Windows reset required. This is odd. I will see if I can produce this. I assume you are using the standalone XDS110 whith a custom board?

  • 0 in reply to Ki
    Prodigy 140 points

    Hi Ki, and sorry for my delayed response.

    Unfortunately it is absolutely random when it happens, but it's certain some part of the debug probe is in a very locked state when it happens. I did try "xdsdfu -r" but not "xds110reset", I tried a lot of combinations disabling/enabling/uninstalling/reinstalling the windows driver, switching to different USB ports etc. and in all cases it just refuse to work.

    What I haven't tried it to move the XDS110 while in a locked state to another PC, and see if it transfers the error.

    Likewise I haven't tries connecting a fresh XDS110 to my "locked" up PC. I've just today received a new XDS110, so this I can soon test.

    And yes, I'm using a standalone XDS110 with a custom board.

  • 0 in reply to Flemming Steffensen
    TI__Guru**** 483601 points
    Flemming Steffensen said:
    I've just today received a new XDS110, so this I can soon test.

    Please keep me posted how it goes.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 140 points

    Over the weekend I've tested many times:

    Once the PC is in fault mode, the lockup error stays regardless of changing to a fresh XDS110.  Neither xdsdfu -r nor xds110reset.exe are able to clear the lockup. Likewise temporary disabling the XDS110 USB device in the Windows Device Manager, or reinstalling the XDS110 device driver (Forced uninstall and delete from Windows Device Manager) has any effect.

    Rebooting the PC with a locked up XDS110 connected, clears the lockup error in perhaps 2/3 of the tries.

    Rebooting the PC with a fresh XDS110 connected always clears the lockup error.

    Power-cycling the locked up XDS110 while the PC reboots always clears the lockup error.

  • 0 in reply to Flemming Steffensen
    TI__Guru**** 483601 points

    I understand the issue is sporadic but would it be possible to provide some sort of test case? I asssume it can just happen while the program is running normally. Would it be possible to provide the program (via E2E private message if your wish)?

  • 0 in reply to Ki
    TI__Guru**** 483601 points

    or is a program even needed at all if:

    Flemming Steffensen said:
    Disconnect the target board from the XDS110 and verify communications, then reconnect the board and verify communication. In that context it is expected and correct that:

    then it sounds like a series of disconnect and reconnects can potentially trigger the lockup?

  • 0 in reply to Ki
    Prodigy 140 points

    Unfortunately, we do not have a specific program/firmware that is more likely to trigger the problem - the firmware we have is three separate firmwares, used at three geographical different locations and with different custom boards, so it does not seem firmware-dependent from what we have seen. The lock-up can occur during normal debug use, but it is random and we do not have a reliable software sequence that reproduces it.

    It may be possible that repeated disconnect/reconnect cycles of the cJTAG connection, followed by “Test Connection”, can help provoke the issue, but I cannot say that this is a deterministic test case either. In CCS 20.2/20.4 this workflow usually behaves as expected: disconnected target gives the target-supply error, reconnecting passes again. In CCS 20.5 the same general workflow sometimes seems to correlate with entering the persistent lock-up state.

    I'm sorry I can't be of more help.

  • 0 in reply to Flemming Steffensen
    TI__Guru**** 483601 points

    Thanks for additional details. I'll see if I can put together some test case locally to reproduce this. It looks like some firmware update from 20.5 causes this to manifest.