• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 54 subscribers
  • Views 1088 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/TMS320F28379D: problem with debug probe connection

David Taylor
Prodigy 200 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: LAUNCHXL-F28379D

Tool/software: Code Composer Studio

I supervise a teaching lab that contains 8 Windows workstations, each of which is equipped with CCS 10.1.0.00010 and a USB cable connected LAUNCHXL-F28379D. Due to the pandemic, students use Remote Desktop Connection to log in to these workstations and conduct lab projects without anyone being physically present in the lab. This approach works fine most of the time, especially once the students have enough experience to use CCS in a "correct" way, but unfortunately students still sometimes encounter (too frequently) the following error when they initiate an XDS100v2 debug session:

"IcePick_C_0: Error connecting to the target: (Error -151 @ 0x0) One of the FTDI driver functions used during the connect returned bad status or an error. The cause may be one or more of: no XDS100 is plugged in, invalid XDS100 serial number, blank XDS100 EEPROM, missing FTDI drivers, faulty USB cable. Use the xds100serial command-line utility in the 'common/uscif' folder to verify the XDS100 can be located. (Emulation package 9.2.0.00002)"

None of the possible problems listed in this error message apply since (1) students do not have access to enter the lab physically, (2) there is just one device connected to each workstation, (3) the pairing of workstation and device never changes, and (4) I confirm proper operation with my own working code each week. Instead, I believe that the students' buggy code may sometimes be leaving the debug probe in a faulty state, thereby creating problems with the launch of the next debug session. Do you agree this could be the cause?

The remedy we've been using when this problem occurs is to remotely restart the workstation (one or more times); during the workstation reboot, the voltage on the USB cable drops temporarily so that the target hardware experiences a power reset. This approach seems to work most of the time, but sometimes I have to visit the lab to physically disconnect and reconnect the USB cable. Can you offer any better way of remotely fixing a failure to launch a debug session?

Thank you for any advice you may offer.

  • 0
    TI__Guru**** 475651 points

    David Taylor said:
    "IcePick_C_0: Error connecting to the target: (Error -151 @ 0x0) One of the FTDI driver functions used during the connect returned bad status or an error.

    This is a type of host connection error - an issue with communication between the debug probe and the debugger

    https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#host-connection-error

    David Taylor said:
    Instead, I believe that the students' buggy code may sometimes be leaving the debug probe in a faulty state, thereby creating problems with the launch of the next debug session. Do you agree this could be the cause?

    This could be possible but it would be an unlikely cause. Another root cause could be other applications running on the PC that can cause a conflict. But it is really hard to say without more details regarding when the error occurs. Does it happen after the code has been running for a while? Does it fail on the next attempt to start a debug session and connect to the target.

    David Taylor said:
    Can you offer any better way of remotely fixing a failure to launch a debug session?

    Unfortunately, the actions you are currently undertaking would be our recommended course of action. If the workstation reboot is not enough, try going into Device Manager and try disabling and then re-enabling the device that represents the XDS100 (typically it would appear under "Texas Instruments Debug Probes" but if the xds100 is not correctly recognized, it could appear under a different name. Perhaps you will need to reinstall the device driver. Hopefully this step will be enough to avoid having to physically come in and reconnect the cable.

    ki