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.

CCS/DRV8301-69M-KIT: XDS110 debug probe connection error -233

Part Number: DRV8301-69M-KIT
Other Parts Discussed in Thread: CONTROLSUITE, TMDSCNCD28069ISO

Tool/software: Code Composer Studio

We have just bought XDS110 debug probe to connect with JTAG connector on DRV8301-69M-KIT, but testing the connection results in an error. The in-built XDS100 of a control-card proved to be working with no issues.

Environment configuration:

- DEBUG port on XDS110 connected to JTAG 14-pin header on the kit via appropriate adaptor (the debug probe connected to the PC with originally provided USB cable)

- CCS version: 7.2.0.00013

- Changes in target configuration file: connection set to "Texas Instruments XDS110 USB Debug Probe"

- JTAG TCLK Frequency set to 1.0MHz (tried 100.0 kHz too with no difference).

The result I get after running the "Test Connection" button:

C:\Users\Jakub\AppData\Local\TEXASI~1\CCS\
    ti\0\0\BrdDat\testBoard.dat

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Dec 11 2017'.
The library build time was '12:04:14'.
The library package version is '7.0.100.1'.
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.

[End: Texas Instruments XDS110 USB Debug Probe_0]

Attaching my target configuration file below:

/cfs-file/__key/communityserver-discussions-components-files/81/TMS320F28069_5F00_xds100v2.ccxml.txt

I have already found a few topics touching this issue, but the clues already given don't make any difference to me. For reference:

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/228782

https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/t/614015 

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/628509/2333828#2333828 

https://e2e.ti.com/support/microcontrollers/c2000/f/902/t/607495 

  • Jakub,

    Usually the path broken is caused by hardware connections or extreme TCLK speeds, but in this case I suspect you may be running into a problem with the switch configurations. I don't have this kit, but page 7 of the manual mentions that switch SW3 (TRSTn) of the controlCARD must be on the ON position.

    One additional detail is the possibility that ground loops or noise are affecting your ability to connect - a common issue with these HV kits. A few reference threads:
    e2e.ti.com/.../633709
    e2e.ti.com/.../1827308

    I will try to think about additional details that may be causing this issue and report back.

    Hope this helps,
    Rafael
  • Thank you Desouza,

    I remember about the switches, tried different positions just in case but it doesn't change anything.

    100nF capacitor for TRSTn line didn't change anything too (as proposed in one of the threads).

    I'm thinking about the GND loop you've mentioned... did you mean some internal loops inside the kit, or the one caused by connecting the kit (powered from 12V power supply) to the PC - maybe an opto-isolation of USB cable would help in such case? What other measures can I take otherwise?

  • Jakub,

    Quick question: does your F28069 controlcard have an isolated XDS100 on it? If so, this reply brought me an old recollection: this controlCARD does not have JTAG signals exposed to the DIMM-100 bus, therefore you can't use your XDS110 with it. 

    I can confirm this by looking at its schematics diagram under:

    C:\ti\controlSUITE\development_kits\~controlCARDs\TMDSCNCD28069ISO_v1_1\R0_4

    If this is a different controlCARD, please let me know.

    Just to answer your question about GND loops, I meant the outer ring comprised of the host PC, the USB interface, the board, its power supply and the ground pin on the outlet. To mitigate that there are some ISO adapters available for purchase (such as the BH-ADP-ISO14), but I haven't tested this with the XDS110.

    Hope this helps,

    Rafael

  • Yes, I do have the control card with isolated XDS100. Thank you for this remark, it saved me a lifetime of trying to figure out what's wrong!

  •  again,

    We've just received the first release of our custom PCB (based on DRV8301-EVM design), which doesn't include Control Card and has the MCU connected directly to JTAG (I double checked path's continuity to make sure). But the same error appears when I try to connect with XDS110!

    There's one thing I noticed, though. The following screenshot comes from TMS320F2806x datasheet (SPRS698F) and it clearly states that the EMU0 and EMU1 of JTAG header should be pulled-up to VDD. But those pins are NC on EVM-kit (as well as our PCB)! Do you think this might create some issues?

    And there's another issue - no signal is seen on TRST when I run the connection test (constant 0). But I guess it should go high to make the MCU enter internal reset, right? I checked it with logic analyzer, don't have an oscilloscope right now to confirm what's exactly going on there.

    There should be a pull-down resistor (we used 2k7 Ohm) between TRST and GND. But measuring the resistance between those two pins show me more or less 0.3 Ohm! Can it be that the measurement signal goes through MCU internal circuits which show that little resistance, or do we have a faulty resistor or short-circuit somewhere?

  • Jakub,

    It is certainly strange the TRST is "silent". Can you check two things?
    - Measure the resistance of the TRST and GND with the XDS110 disconnected. It should be around 10k or less (but not zero).
    - Measure the resistance of the PD resistor itself - maybe someone assembled the wrong resistor.

    Also, check the thread below; another user found the PD resistor recommendation on the datasheet is too low for the XDS110.

    e2e.ti.com/.../2333828

    Ideally the EMU pins should be tied to Vdd, but I don't think they would exert such serious consequence to the connection process.

    Hope this helps,
    Rafael
  • OK, I managed to connect!

    It seems that we had a faulty resistor, as the measurement between TRST and GND shown very low value (below 1Ohm). I replaced it with an external 10kOhm resistor and now the integrity scan-test succeeded! Thank you for all the help.
  • Jakub,

    Thanks for reporting the outcome of this. It can help other developers in the future.

    Best regards,
    Rafael