Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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/TMS320F28377S: XDS110 Debugging Issues

Part Number: TMS320F28377S
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Hello,

I recently bought the XDS110 to test if it can debug the board I plan to build with the TMS320F28377S. For the test, I used the LAUNCHXL-F28377S Launchpad I already had. I took off the jumpers connecting the launchpad to xds100v2, and then supplied 3.3 V to the launchpad, effectively turning on the LED. I then soldered wires from U5 and U7, the digital isolators that had the JTAG signals I wanted to test with. After getting wires attached to TDI, TDO, TCK, TRST, and TMS, I attached the signals to a breadboard and made the following connections provided in the TMS320F28377S datasheet:

I then used the 14 pin adapter to connect the XD110 to the pinout above. I have tried to debug the sample programs on CCS, but I am receiving errors. I have tested the launchpad using its the onboard xds100v2, and I know it works. 

I went to the targetconfigurations ccxml file and changed the connection to the XDS110 probe. In the advanced settings, I have kept everything as the default choices, including using target supplied power as seen below:

When I try the test connection, however, I get this output:

EDIT:

I have rechecked my connections of  cables, and redone them much more cleanly. Luckily, I am not longer getting error -2131 in the test connection, but instead I am getting this:

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


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

C:\Users\TE313260\AppData\Local\TEXASI~1\
    CCS\Public\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 'May 23 2017'.
The library build time was '19:37:36'.
The library package version is '6.0.628.3'.
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]

From the debugging JTAG wiki, I do not believe it is a short to VCC or GND as the value is 0xffffff17. Other suggestions were loose connections or a high TCK speed. I have just redone my connections, so I am less convinced it is a connections problem. In the debugging configurations, I have set the TCK frequency to be 2.5 MHz. I was wondering if this was too high, or if the problem might be something else entirely.

I have included below other things I thought might point towards a solution:

1.) When using the TI Resource Explorer with the project, an error comes with I try debugger configuration with this message:

2.) Error message when I try to debug program:

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

I have reconnected by connections more carefully, so I want to believe it is not the connections that is creating the problem (but I could be wrong). From what I have read from the wikia, the most likely problems are from either poor connections or a TCK frequency that is too high. I used the default 2.5 MHz and was wondering if that was the fault.

Sincerely,

May

  • May,

    May Chen said:
    From the debugging JTAG wiki, I do not believe it is a short to VCC or GND as the value is 0xffffff17. Other suggestions were loose connections or a high TCK speed. I have just redone my connections, so I am less convinced it is a connections problem. In the debugging configurations, I have set the TCK frequency to be 2.5 MHz. I was wondering if this was too high, or if the problem might be something else entirely.

    Error 233 is mentioned in section 5.13 of the debugging page you referenced, and it is a common error when either there is a hard fault on one of the lines or the connections are too long and cause either reflections or delays that make the Debug Probe believe the datapath is broken. I would severely reduce the JTAG clock speed and retry. The value 0xFFFFFF17 is nothing more than -233 in hex.

    1) The error you are seeing in the Resource Explorer is caused by a problem in the original project - in the controlSUITE version I have here, the project does not define a specific device but instead uses a "Generic C28xx Device". At any rate, this error is not related to the previous one - you are probably trying to connect to your F28x board using a different .ccxml file.

    2) The IDE works at a higher level when compared to the Test Connection utility. When you try to connect to a hardware that shows error -233 but using the IDE, it is fooled into thinking the problem is at a higher level - thus you get error -2131 or the inability to access a specific Debug subsystem register. In nature both errors have the same root cause. 

    In this case, I would try to scope the output of the XDS110 and compare with the existing XDS100v2 to try and spot any anomalies. At a glance the schematics you sent are very close to section 71. of the following wiki:

    http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide 

    Hope this helps,

    Rafael