• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 3425 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.

CCS/TMS320F28069F: Problem with XDS100v3 debugger connection.

Aaron Liebold
Intellectual 380 points
Part Number: TMS320F28069F

Tool/software: Code Composer Studio

I have custom hardware built around the TMS320F28069F and I have not been able to successfully debug/flash it.  I am using CCS 7.3.0.00019 with the XDS100v3 debugger. Below are the debugger settings and the schematic involving the JTAG connection. I keep getting short circuit errors ranging from NEAR to FAR or 'distance cannot be measured'.

What conditions can throw this error?

Debugger Test Results

[Result]


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

C:\Users\Aaron\AppData\Local\TEXASI~1\CCS\
TI\2\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 'jioserdesusbv3.dll'.
The library build date was 'Jul 21 2017'.
The library build time was '19:36:41'.
The library package version is '7.0.48.0'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
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 FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 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 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 '-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.

[End: Texas Instruments XDS100v3 USB Debug Probe_0]

Debugger Setup

JTAG Connection Circuit

All help is appreciated! 

  • 0
    TI__Guru**** 171044 points
    Hi,

    The first detail that grabbed my attention is the extreme low frequency you are using. Despite error 501 is usually related to a high TCLK frequency, the XDS100 is usually very robust when operating at its default 1MHz frequency.

    Also, according to the XDS Target Connection Guide, the pull up on TDO may be influencing your design - PUs/PDs are usually not recommended on those lines, but perhaps it is a feature of F28x devices.

    software-dl.ti.com/.../emu_xds_target_connection_guide.html

    In the same document above (section "TDIS Considerations"), check if the connection to the TDIS pin is solidly tied to GND - any fluctuation tends to cause cable break errors.

    I will try to think about other scenarios but, from the schematics diagram perspective, I don't see any additional problems. You can take into consideration any possible assembly/PCB errors as well.

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Intellectual 380 points
    Hi Rafael,

    Thank you for the response.

    The low frequency was actually part of my troubleshooting. I forgot to switch it back. I got them same issues at several different frequencies. I'll switch that back to 1Mhz.

    I'll double check the pull-up on TDO. That is part of how boot-mode (flash, serial, external memory) is determined on boot, but I could have missed something about that interfering with debugging. While I'm at it, I'll check that TDIS is well grounded too.

    Thanks for your help. I'll let you know how it goes.

    Aaron
  • 0 in reply to desouza
    Intellectual 380 points

    I changed the frequency back to the default 1MHz and everything worked! Previously I suspected that the processor was bad, and I replaced it. It is possible that it was the processor and then I forgot to change the debugger frequency back, causing a secondary problem.

    Thank you for the help,

    Aaron

  • 0 in reply to Aaron Liebold
    TI__Guru**** 171044 points
    Aaron,

    Thank you for reporting back your findings. Hopefully the processor was the root cause.

    Regards,
    Rafael