• State TI Thinks Resolved
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 38 subscribers
  • Views 183 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMDSEMU200-U: XDS200 Test Connection fails in CCS 2020, while XDS110 works with same setup

Vilceanu Mihaela
Prodigy 10 points

Part Number: TMDSEMU200-U

Hello,

I am experiencing a connection issue with an XDS200 debug probe in CCS 2020.
 
### Setup:
- XDS200 (issue)
- XDS110 (working for comparison)
- ARM20 adapter (same for both)
 - Windows 11 64-bit
- Target: AWR2x44P
 
### Issue:
XDS200 is detected (CDC ports visible in Device Manager), but "Test Connection" in CCS fails.
Using the exact same setup with XDS110, the test passes successfully.
 
### Notes:
- Same ARM20 adapter used (delivered with XDS200)
- Original TI USB cable
- Target powered correctly
 
### Questions:
- Is this a known issue with XDS200?
- Could this indicate a hardware or adapter issue?
- Any recommended checks or updates?
  • 0
    TI__Mastermind 35123 points

    Hi Vilceanu,

    Yes, this is a known issue. Your XDS200 most likely has outdated firmware that is incompatible with your CCS version. The fact that Windows detects the CDC ports but CCS "Test Connection" fails is the classic symptom — the USB interface works, but the debug protocol communication fails due to a firmware mismatch [1].

    Since your XDS110 works with the identical setup (same adapter, cable, target), this confirms the problem is isolated to the XDS200 probe itself — not your adapter, cable, or target board.

    Recommended Fix: Manual Firmware Update

    The XDS200 requires firmware version 1.0.0.9 to work with modern CCS versions. Older firmware (e.g., 1.0.0.5) will cause exactly the behavior you're seeing [1]. The automatic update mechanism in CCS often fails, so a manual update is needed [2].

    Step 1 — Check current firmware version:

    Open a Command Prompt and navigate to your CCS installation's utility directory:

    cd C:\ti\ccs<version>\ccs\ccs_base\common\uscif\xds2xx
    xds2xx_conf get xds2xxu 0
    This will display the current firmware revision.

    Step 2 — Update firmware (run in exact order):

    xds2xx_conf update xds2xxu 0 xds200_firmware_v1009.bin
    xds2xx_conf program xds2xxu 0 xds2xx_cpld_v1009.xsvf
    xds2xx_conf boot xds2xxu 0

    Step 3 — Verify:

    xds2xx_conf get xds2xxu 0

    Confirm the output shows fwRev = 1.0.0.9 and cpldRev = 1 [1].

    If your "CCS 2020" is actually CCS v11.1, there's a separate known bug (EXT_EP-10638) where the XDS200 can pass "Test Connection" but then fail to load programs. The workaround is to set symbol_loader=1 in the Expressions view after connecting [3]. This was fixed in CCS v11.2.

    Summary

    Check
    Action
    Firmware version
    Run xds2xx_conf get xds2xxu 0
    Update firmware
    Flash v1009 bin + CPLD files
    Hardware issue?
    Unlikely — CDC detection confirms USB HW is fine
    Adapter issue?
    Ruled out — XDS110 works with same adapter

    To help refine this recommendation, it would be helpful to know:

    • The exact error message from the "Test Connection" failure log in CCS
    • Your exact CCS build version (e.g., 11.0, 11.1, 10.x)
    • Whether this is a standalone TMDSEMU200-U probe or an onboard emulator
    • Whether this is a TI EVM or a custom board for the AWR2x44P
    1. FAQ: How to update XDS200 firmware (C6657 EVM example, applicable to all XDS200)
    2. FAQ: TMDSEMU200-U - Update firmware in XDS200 emulator
    3. CCS 11.1 XDS200 program loading bug and workaround

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 10 points

    Hello Fleenor,

    Thank you for your response and recomandations.

    I have checkd the firmware version and it is 1.0.0.9, so the firmware is most likely not the cause of the issue.

    Please find below the answers to your questions:
    1. I am attaching/providing the error (see below).
    2. CCS:
    • Version: 20.2.0.12__1.8.0
    • Default VS Code API: 1.96.0

    3. I am using a standalone TMDSEMU200-U probe.

    4.It is a custom board for the AWR2x44P.

    BR, 

    Mihaela

  • 0 in reply to Vilceanu Mihaela
    TI__Mastermind 35123 points

    Hi Mihaela,

    Since the firmware is confirmed at version 1.0.0.9, we can rule out the firmware mismatch as the cause. Because the XDS110 works with the same hardware setup, the physical layer (cables, adapter, and target power) is functional. The issue is likely isolated to the software configuration or signal integrity at higher speeds.

    Please perform the following steps to narrow down the cause:

    1. Analyze the Error Log

    The specific error message provided in your attachment is the most important diagnostic data point. Please confirm if the error indicates a USB/Driver failure (e.g., Error -1000) or a JTAG/Target failure (e.g., Error -245).

    2. Verify Target Configuration (.ccxml)

    Ensure that the Target Configuration file being used is explicitly configured for the XDS200.

    • Open the `.ccxml` file in CCS.
    • Confirm Connection is set to Texas Instruments XDS200 Emulation.
    • Confirm the Board or Device is correctly selected for the AWR2x44P.
    • Run the "Test Connection" directly from the Target Configuration editor and note if the failure occurs during the "JTAG Scan Chain" phase.

    3. Reduce JTAG Clock Frequency

    The XDS200 operates at significantly higher speeds than the XDS110. On custom boards, high-speed JTAG signals can encounter signal integrity issues (impedance mismatches or crosstalk) that the slower XDS110 avoids.

    • In the `.ccxml` editor, navigate to JTAG TCLK Frequency Settings.
    • Change the setting to Fixed with user specified value.
    • Set the frequency to a low value, such as 1.0 MHz or 500 kHz.
    • Attempt the "Test Connection" again. If this succeeds, the issue is related to the signal integrity of the JTAG traces on your custom board.

    4. Clarification on CCS Version
    The version number provided (20.2.0.12) does not match standard TI CCS versioning (which is currently in the v12.x range). Please confirm if you are using a specialized toolchain or a specific SDK-integrated version of CCS, as this may affect driver compatibility.

    Summary of required information for next steps:

    • The exact text/screenshot of the "Test Connection" failure log.
    • The results of the low-frequency JTAG test.
    • Confirmation of the specific CCS build/toolchain.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 10 points

    Hi,

    Thank you for your guidance. Please find below the requested information and test results:

    1. Error Log Analysis
    The error code I am receiving is:

    Error -233 (0xffffff17) - please see the next screenshot

    2. Target Configuration (.ccxml)
    The target configuration has been verified with the following settings:

    • Connection: Texas Instruments XDS2xx USB Debug Probe
    • Device: AWR2x44P

    I also ran “Test Connection” from the Target Configuration editor.
    The failure occurs during the connection process (consistent with the -233 error), suggesting an issue in JTAG communication.

    3. JTAG Clock Frequency Test
    I attempted reducing the JTAG TCLK frequency as suggested:

    • Tested at 1.0 MHz
    • Tested at 500 kHz

    The connection issue still persists at both lower frequencies, so it does not appear to be related to signal integrity at higher speeds.

    4. CCS Version Clarification

    Please let me know if you would like me to provide additional debug details.

  • 0 in reply to Vilceanu Mihaela
    TI__Mastermind 35123 points

    Hi Mihaela,

    Thank you for providing the detailed screenshots and test results. The error code and your test results now give us a much clearer picture.

    Key Finding: This is NOT an XDS200 Hardware or Firmware Problem

    The error -233 (SC_ERR_PATH_BROKEN) with title SC_ERR_PATH_BROKEN has a specific meaning:

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

    This error means the emulator itself is communicating correctly, but it cannot see a valid JTAG scan chain on the target side. The probe is working — the target JTAG path is not responding correctly.

    Critical Observation

    Since the XDS110 works but the XDS200 fails with the same adapter, cable, and target, and since reducing JTAG frequency had no effect, the most likely explanation is one of the following:

    Most Probable Causes

    1. JTAG Voltage Level Mismatch (Most Likely)

    The XDS200 uses the VTREF pin on the ARM20 connector to sense the target voltage and adapt its I/O levels. If VTREF is not being driven correctly:

    • The XDS200 may drive signals at the wrong voltage level
    • The XDS110 has different internal voltage handling and may be more tolerant

    Action:

    • Measure the voltage on Pin 1 (VTREF) of the ARM20 connector at the custom board side
    • Confirm it is at the expected logic level (typically 1.8V or 3.3V depending on AWR2x44P I/O bank)
    • Verify the XDS200 ARM20 adapter is correctly passing VTREF through to the probe

    2. JTAG Pin State on Custom Board

    On a custom board, the following conditions cause SC_ERR_PATH_BROKEN:

    Condition
    Effect
    TDO pin floating or pulled incorrectly
    Stuck-at-zero or stuck-at-one
    TDI/TMS/TCK not reaching the device
    No scan chain response
    Reset (nTRST or nSRST) held asserted
    Device not exiting reset, JTAG inactive
    Missing pull-up/pull-down on JTAG pins
    Signal levels not meeting threshold

    Action:

    • Verify your custom board schematic for correct JTAG termination on the AWR2x44P:
      • TMS — requires pull-up (typically 10kΩ to VDDIO)
      • TDI — requires pull-up (typically 10kΩ to VDDIO)
      • TDO — should not be pulled high or low aggressively
      • TCK — requires pull-down (typically 10kΩ to GND)
      • nTRST — must not be held low; requires pull-up if used

    3. AWR2x44P JTAG Security/Boot Configuration

    The AWR2x44P has configurable boot modes and security states that can disable or restrict JTAG access:

    Action:

    • Confirm the device boot pins are set to a JTAG-accessible boot mode
    • If the device has been programmed with a security policy that locks JTAG, the scan chain will appear broken regardless of the probe used

    4. Why XDS110 May Appear to Work

    This is an important diagnostic point. The XDS110 passing "Test Connection" does not necessarily confirm the JTAG chain is fully functional. The XDS110 "Test Connection" in some configurations performs a less strict check. It is possible that:

    • XDS110 is also not fully connecting to the AWR2x44P, but passes the probe-level check
    • The XDS200 performs a more thorough scan chain verification and correctly reports the failure

    Action:

    • With the XDS110, attempt to go beyond "Test Connection" — try to actually connect and halt a core
    • Confirm whether XDS110 can successfully load and run a program, or if it also fails at a later stage

    Immediate Recommended Steps

    Step 1 — Measure VTREF voltage: Using a multimeter, measure Pin 1 of the ARM20 connector on your custom board with the board powered. Confirm the voltage matches the AWR2x44P JTAG I/O supply.

    Step 2 — Check nRESET/nTRST state: Confirm these signals are not being held asserted on your custom board. Measure Pin 15 (nTRST) and Pin 10 (nRESET) of the ARM20 connector.

    Step 3 — Verify XDS110 actually connects to a core: In CCS with XDS110, attempt a full debug session, not just Test Connection. Report whether it successfully halts the R5F or DSP core.

    Step 4 — Review AWR2x44P boot mode pins: Consult the AWR2x44P datasheet and confirm the SOP (Safe Operating Procedure) pin configuration on your custom board is set for functional/debug mode.

    Summary

    Finding
    Conclusion
    Error -233 SC_ERR_PATH_BROKEN
    Target JTAG scan chain not responding
    Firmware v1.0.0.9 confirmed
    XDS200 probe is functioning correctly
    Low JTAG frequency did not help
    Not a signal integrity/speed issue
    XDS110 passes Test Connection
    Needs verification of full debug capability
    Custom board
    JTAG pin configuration must be verified

    The most productive next step is to verify VTREF voltage and JTAG pin states on your custom board, and to confirm whether the XDS110 can perform an actual debug session beyond the Test Connection check.

    Please share your findings from the VTREF measurement and the XDS110 full connection attempt.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 10 points

    Hello,

    Thank you for the detailed explanation — it helped narrow things down further. I’ve gone through the checks you suggested, and here are my findings:

    1. and 2.  VTREF Measurement and Signal Comparison
    I measured VTREF, TMS, nRESET, and TCK on the custom board using both debuggers:

    • XDS110 (working)
    • XDS200 (failing)

    XDS110:

    XDS200: 

    I have also attached a picture indicating exactly which pins were measured:

    Additional Observation

    During testing, I noticed a consistent difference in behavior between the two debuggers when performing a hard reset of the power supply:

    • With the XDS110 connected:

      • The consumption remains around 1.5 V
      • TMS stays at ~3V+

    • With the XDS200 connected:

      • The consumption drops to approximately 0.6 mV
      • TMS drops to 0 V

    This difference appears consistently and may indicate a variation in how the two debuggers drive or hold the JTAG lines during reset.

    3. 

    Regarding the SOP (boot mode) pins:

    • The configuration on the custom board is set to debug mode
    • This is validated by the fact that full debug sessions work with the XDS110 (not just Test Connection, but actual core control and execution)

    4. XDS110 Debug Capability (Full Connection Test)
    With the XDS110, I can successfully go beyond "Test Connection":

    • I can connect to all three cores
    • Each core can be brought into HALTED state
    • I can reach and stop at breakpoints

    This confirms that:

    • The JTAG chain is functional
    • The target device is fully accessible
    • Debug functionality is working correctly with XDS110

    At this point, the discrepancy appears to be specific to the XDS200 interaction with this setup, despite identical hardware conditions.

    Please let me know if there are any additional checks you would like me to perform.

    Best regards,
    Mihaela

  • 0 in reply to Vilceanu Mihaela
    TI__Mastermind 35123 points
    Hi Mihaela,
    Thank you — this new data is extremely revealing. The voltage behavior you observed is the key to diagnosing the root cause.

    Critical Finding: XDS200 is Loading Down Your VTREF / Power Rail

    The symptom you captured is diagnostic:
    Condition VTREF / Supply TMS
    XDS110 connected ~1.5V (normal) ~3V+ (normal)
    XDS200 connected ~0.6 mV (collapsed) 0V (pulled low)
    When you connect the XDS200, VTREF (Pin 1 of ARM20) collapses to near zero. This is not a firmware or software issue — the XDS200 is drawing excessive current from your VTREF line, causing the voltage to collapse entirely. This immediately explains the SC_ERR_PATH_BROKEN error: the probe cannot establish JTAG levels because its own voltage reference has been pulled to ground.

    Root Cause Analysis

    1. VTREF Is Sourced from an Underpowered Net on Your Custom Board

    The XDS200 uses VTREF (Pin 1, ARM20) to:
    • Sense the target I/O voltage
    • Power its internal level-translation buffers
    Unlike the XDS110 (which has lower VTREF current requirements), the XDS200 draws more current from VTREF to power its internal I/O buffers. If your custom board's VTREF supply is:
    • A divided-down or filtered reference (not a true supply rail)
    • Protected by a weak resistor or current-limiting circuit
    • Shared with other loads that leave insufficient headroom
    ...then the XDS200's load will collapse it.

    2. ARM20 Pin 1 (VTREF) Must Be a Low-Impedance Supply

    This is the most common custom board JTAG design error. The VTREF pin must be connected to a low-impedance voltage supply (direct connection to VDD_IO or equivalent), not:
    • A voltage divider output
    • A weak pull-up
    • A filtered/RC-decoupled node
    The XDS110 likely works because it has a higher input impedance on its VTREF pin or does not rely on it as heavily for its internal buffer supply.

    Immediate Action Items

    Step 1 — Measure VTREF Source Impedance

    With the board powered and no debugger connected, measure the voltage on Pin 1 of your ARM20 connector. It should read the full target I/O voltage (1.8V or 3.3V depending on AWR2x44P I/O bank configuration).
    Then, with the XDS200 connected but before pressing Test Connection, measure again. If it drops immediately upon physical connection, this confirms excessive loading.

    Step 2 — Check Your Custom Board Schematic for ARM20 Pin 1

    Trace where Pin 1 (VTREF) of your ARM20 connector is connected on your custom board. Verify:
    • It is connected directly to a power supply rail (VDD_IO or 3.3V/1.8V)
    • It is not behind a current-limiting resistor (any resistor > ~100Ω will cause significant voltage drop under XDS200 load)
    • It is not a divided reference

    Step 3 — Check for Series Resistor on VTREF

    Some board designs inadvertently place a protection resistor (e.g., 10Ω–100Ω) in series with VTREF. Under the XDS200's VTREF current draw (~10–20 mA), even a 10Ω resistor can cause a meaningful drop. A 100Ω resistor with 10 mA draw would collapse the voltage entirely on a low-current source.

    Step 4 — Temporary Workaround to Confirm

    If you have access to a bench power supply or a strong 3.3V/1.8V rail on your board, try directly wire-bodging Pin 1 of the ARM20 connector to that rail to bypass any impedance in the current path. If the XDS200 then connects successfully, this confirms the supply impedance is the root cause.

    Why XDS110 Works and XDS200 Doesn't

    Factor XDS110 XDS200
    VTREF current draw Low (~1–2 mA) Higher (~10–20 mA for I/O buffers)
    VTREF dependency Less critical Required to power internal level translators
    Tolerance to weak VTREF Higher Lower — collapses under load
    This is a known design consideration for XDS200 on custom boards — the VTREF supply must be robust enough to supply the probe's internal buffers.

    Summary

    Finding Conclusion
    VTREF collapses to ~0.6 mV with XDS200 VTREF source on custom board is too high impedance
    TMS drops to 0V Direct consequence of collapsed VTREF (level translators unpowered)
    XDS110 doesn't cause collapse XDS110 draws negligible current from VTREF
    Error -233 SC_ERR_PATH_BROKEN Expected result when VTREF = 0V (no JTAG signals possible)
    Firmware, frequency, boot mode all ruled out Confirmed hardware supply design issue
    The fix is on your custom board — Pin 1 (VTREF) of the ARM20 connector must be driven by a low-impedance power supply rail capable of supplying the XDS200's I/O buffer current.
    Please check your schematic for how VTREF is sourced and share what you find — this will allow us to confirm the exact fix needed.
    Best Regards,
    Zackary Fleenor