• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 5727 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

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

Archit Shah
Intellectual 410 points
Other Parts Discussed in Thread: TMS320F28379D, TMDSCNCD28379D, CONTROLSUITE

Hello All,

We have a custom made C2000 board with TMS320F28379D & FTDI 2232H. We have tried to mimic the Schematics from the "C:\ti\controlSUITE\development_kits\~controlCARDs\TMDSCNCD28379D_v1_0" files. That way we can make sure that we are not doing anything different and reinventing the wheel. On the new custom board manufactured, we configured the FT2232H using MPROG and the .ept file provided from the TI Wiki Page. We also configured GPIO Pins 72 and 84 to have the MCU in Wait Mode to stop the watchdog timer (which would otherwise reset C2000 at about 14.2 MSec.). Everytime I try to load the Blinky CPU01 code on the custom board using CCS, I would get this error:

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

We have 2 custom boards and I see the same behavior.

I also read the FT2232 configuration from one of the C2000 Control Card + Development Kit using MPROG to make sure that I have the correct configuration for FT2232. I have exhausted my search on TI reading forums and Wiki Pages such as http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide, http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems and http://processors.wiki.ti.com/index.php/XDS100.

So, based on the research, it seems that there is something wrong with the TDO line or the data present on the TDO line. C2000 is the originator of the data on TDO line and either its sending corrupted data or some error signals.

We have made sure that the power up sequence is according to the specs by probing some signals on the scope. There is an error pin on the C2000 which indicates of any error and it is logic low.

I am not a JTAG expert and have no understanding of the protocol. So, we used a logic analyzer to capture the traffic and I need your help to try to figure out whats going on. I have exhausted my knowledge and resources to solve this problem.

We are using TI XDS100v2 USB Debug Probe Setting. I also tried to use other options but then I receive an error that its not able to open FTDI port......

The first image is the aerial view of the capture and the following images are the zoomed in versions of the traffic from left to right in aerial view. I really appreciate your insight to help me figure out whats going on and solve the problem.

Also, if there is anything else that I can check, please let me know. Again, thanks for your help!


Regards,

Archit

  • 0
    TI__Mastermind 30255 points
    Hello

    An engineer is assigned and will follow up.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    TI__Guru 57255 points

    Hi Archit,

    Four thoughts:
    1) In the window where you configure your target configuration in CCS, there is a button labelled 'Test Connection'.  Can you press this button and provide its output results?
    2) How far is the emulator from the C2000 device?  Are both on the same board?
    3) Would it be possible for you to provide a snippet from your schematics containing the emulator section, its JTAG connection to the C2000 device, and any other places where the JTAG nets go?
    4) What is XRSn doing during this time & how are the boot-mode pins configured?

    Based on the error being thrown, and the fact that there appears to be some kind of signalling from the C2000 side, I feel the TCK's return signal is somehow involved.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 410 points
    1.) Somewhere down at the bottom of the whole message, I get "The controller has detected a cable break far-from itself. The user must connect the cable/pod to the target." I will post the whole message tomorrow.

    2.) Yes, they are on the same board and the traces are less than a couple of inches.

    3.) Yes, I can try to provide the snippet of the schematics, but its exactly the same as in the Control Card. We duplicated the emulation schematics (connections between FT2232H & TMS320F28379D) from TMDSCNCD28379D_v1_0 schematic files. Based on my understanding, JTAG signals does not go anywhere on the board. We do not even have a JTAG header. Its a one to one connection.

    4.) I will have to check the behavoir of XRSn. Is there anything particular you would want me to check?

    Also, can you please throw some light on TCK's return signal is somehow involved. I am not aware of any TCK return signal at all.....

    Thanks for your time,
    Archit
  • 0 in reply to Archit Shah
    TI__Guru 57255 points

    Hi Archit,

    Thanks.

    3) As you likely know, there are a fair amount of connections and components surrounding the FTDI chip.  My suspicion is that your board is missing something minor.  I may be able to spot it.
    4) If the device is in the boot mode, Get Mode, you should see periodic pulsing on the XRSn pin in an unprogrammed device (which highlights the device is getting reset by the watchdog timer).  This will prove the C2000 is alive, powered appropriately, etc.

    I don't understand the full design rationale of the immediate xds100v2 emulation circuit, but I've gathered some things over time.  I think A:R7 is responsible for feeding TCK back to the FTDI device as 'TCK return'.  If there was large distance between the FTDI chip and the C2000 device, I believe it would be correct to have that TCK signal go all the way to the C2000 and back before feeding into the FTDI chip at pin 24 (to compensate for skew).  For the distances you're working and the speeds being used, this likely shouldn't matter.  That being said, even in your case A:R7's equivalent, in your design, would need to exist.

    Hopefully this helps!


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 410 points

    Here is the log from "Test Connection" action:

    [Start]

    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\ashah\AppData\Local\TEXASI~1\CCS\
        ti\0\1\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 '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 '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]

    Here is the snippet from the FTDI2232H Config read using MPROG.

    We did notice that the C2000 was resetting at every ~14.2 milli-seconds. So, using GPIO 72 and 84, we changed the mode to Wait Mode as in the datasheet, there is a note that mentions to do so to prevent the CPU from resetting itself and preventing to enter to emulation mode.

    I am in the process of taking a snapshot of the schematics and will send it soon. Is there a way to communicate directly via email? Thanks.

  • 0 in reply to Archit Shah
    TI__Guru 57255 points

    Hi Archit,

    Ok.  Thanks for the details.  The C2000 looks to be alive then.

    I'd much prefer to do this over the forum, so that others can learn from our exchange.  If there are proprietary concerns, taking snapshots of the non-proprietary portions should be adequate for us (ie FT2232H + vicinity & its attach to the C2000).   Otherwise, you can 'add me as a friend' via the forum and we can proceed in that way.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 410 points

    Here are the partial schematics attached. Hopefully you can find something out...... I really appreciate your help!

    Regards,

    Archit

    Schematics, partial sanitized.docx

  • 0 in reply to Archit Shah
    TI__Guru 57255 points

    Hi Archit,

    It looks like you've done a pretty good job of reducing down the emulator schematics and following the C2000 device datasheet.

    I do notice that you seem to be missing some of the resistor pulls (circuitry) immediately surrounding the FT2232H - specifically a pulldown on pin 32 & a pullup on pin 28.  I believe the pulldown on pin 32 might be mandatory for the xds100v2 circuitry to work.

    Outside of this, I don't see too much else.  Let me know how the above works, and we can consider other avenues.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 410 points

    I think that was it! Thanks for your help. Can you please explain the functionality of pin 28 and 32 in detail? Thanks.

  • 0 in reply to Archit Shah
    TI__Guru 57255 points

    Hi Archit,

    That's great news!

    Unfortunately, I'm not the right person to ask this question to.  I'd recommend posting a question to the CCS forum (the xds100 design is managed by that group and they may be able to assist you).


    Thank you,
    Brett