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.

Hi, Trying to connect to the TMS320C5535 target board using CCSv4 and XDS100v2 emulator. Error connecting to target

Other Parts Discussed in Thread: TMS320C5535

Getting the following error.

The emulator reported an error. Confirm emulator
configuration and connections, reset the emulator, and retry the operation.

What all to do to load and debug the code.

Am using ezdsp5535.gel file

Thanks and Regards,

Sangeeta Gunwani

  • Hi,

    Can you check the details mentioned in the below page ? Hope this information helps you..  

    http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#The_emulator_reported_an_error

    Also, you are using older version of CCS, Would it be possible to update it to a later version? CCS 6.1.x

    Regards

     Vasanth

  • Hi Vasanth,

    Thanks for the reply.

    Today I downloaded the latest CCS v6 and ran the Test Connection through that IDE.

    It gave the errro that "there is no hardware for programming the JTAG TCLK" and then it said "there is no hardware for measuring the JTAG TCLK".

    After that it gave the same cable break error once followed by confirm emulator configuration error.

    I checl the emulator VID and PID. That is 0403 and A6D0.

    I also tried to chaneg the JTAG frequency of operation from default 1Mhz to 500hz and then to 10Mhz but that too didnt help.

    What can be the issue?

     

    Thanks and Regards,

    Sangeeta Gunwani

     

     

  • When I test the connection it generates this file
    [Start: Texas Instruments XDS100v2 USB Emulator_0]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


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

    C:\Users\hjvaid\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 'jioserdesusb.dll'.
    The library build date was 'Sep 4 2015'.
    The library build time was '21:59:23'.
    The library package version is '6.0.14.5'.
    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).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 64 32-bit words.

    The JTAG IR instruction path-length was not recorded.

    -----[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

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

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

    The value is '-183' (0xffffff49).
    The title is 'SC_ERR_CTL_CBL_BREAK_FAR'.

    The explanation is:
    The controller has detected a cable break far-from itself.
    The user must connect the cable/pod to the target.

    [End: Texas Instruments XDS100v2 USB Emulator_0]

    Let me know what can be the issue?

    Thanks and Regards,
    Sangeeta Gunwani
  • HI Sangeetha,

      Will move this post to CCS forum for getting further help.

    Regards

     Vasanth 

     

  • Hi Vasanth,

    Thanks!

    Jus found out that the EMU0 and EMU1 pins were left unconnected on the target device. Trying to fix that. 

    Thanks and Regards,

    Sangeeta Gunwani

  • Sangeeta,

    Were you able to resolve the issue by getting emu0/1 connected?

    John
  • Hi John,
    We checked the trace and made the JTAG connections as per figure 1 of the following wiki document.
    processors.wiki.ti.com/.../XDS_Target_Connection_Guide

    The distance between TMS320C55xx pins and XDS100v2 controller is not more than 6 inches so we chose unbuffered arrangement. But we are still getting cable break error. We also tried using 2 different XDS100V2 emulator hardware.
    I also tried using dbgjtag_gui_test application to check the connections. But it also gives same error of cable break at far end. I tried using -U TEST460 custom command too.
    My hardware team also verified the connectivity.
    Can we scope some signals to figure out what is happening? Or do we need to add some 'gel' file but I think adding 'gel' file for initialization will happen only after pass the "TEST CONNECTION" test. In the target configuration file I have added ezdspc5535.gel file currently. I tried testing connection with and without thie gel file and got the same error.

    We had previously worked with MSP430 and were using MSP-FET430UIF with code composer v4.
    Now our next project is based on TMS320C5535 and therefore we changed to XDS100v2 from spectrum digital and upgraded code comper to v6 so that we can test the JTAG connections as we were not able to connect to our target device for programming it for the first time.

    Do we have emulators avaiable from TI or any other company apart from XDS100v2?

    An early guidance will be of great help.

    Thanks and Regards,
    Sangeeta Gunwani
  • Sangeeta,

    A quick question: is your target configuration file configured as XDS100v1 or XDS100v2? The reason is that one of the development kits for C5535 uses a XDS100v1, but as section 5.2 of the Troubleshooting page sent by Vasantha mentions, a misconfiguration can trigger this very same error.

    If that is not the case, certainly there is a connection broken somewhere between your XDS100v2 and the C5535 device. It means that either your board or the JTAG debugger is bad - It seems you already checked the ground connections as mentioned in the section above, therefore I would suspect the JTAG debugger may be defective.

    Given the XDS100 has full public schematics, the HW team can check the JTAG debugger itself for any problems. Obviously if you have an additional XDS100v2 you can also test it.

    Please give these suggestions a try.

    Hope this helps,
    Rafael
  • Thanks Rafael!
    Our TDIS line was not grounded properly. After doing that we ran the dbgjtag_gui_test utility and it gave the following error
    //////////////////////////////////////////////////////////////////////////////////////////////
    -----[Print the board config pathname(s)]------------------------------------

    C:\Program Files\Debug JTAG GUI\emulators\
    Board_Config\TIXDS100v2.dat

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

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Sep 4 2015'.
    The library build time was '21:59:23'.
    The library package version is '6.0.14.5'.
    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 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

    /////////////////////////////////////////////////////////////////////////////////////////////

    We tried reducing the JTAG frequency to 500Hz and running the "Test Connection" Application in CCSv6. It started giving cable break error.
    When we increased frequency to some 10Khz or so it again started giving JTAG IR and DR scan-path broken error till all higher frequencies.
    Looks like there are reflections on the board. I think we need to buffer the JTAG signals.
    Let me know your views on this whether our thinking is correct and shoud we try buffering the signals.

    Thanks and Regards,
    Sangeeta Gunwani