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.

XDS100v2 USB Debug Probe Failed 'Test Connection'

Other Parts Discussed in Thread: AM3351, LAUNCHXL-F28069M

Good evening,

I'm trying to use my XDS100v2 USB Debug Probe to program and debug a custom board using the AM3351 processor. I was able to define a Target Configuration and successfully pass the 'Test Connection' in the past using Code Composer 6.1.2, but after upgrading to 6.2.0 it fails every time with the following message. I've tried multiple boards, and even had a colleague test the same hardware setup (board and XDS100v2 debugger), and he was able to successfully pass the 'Test Connection'.

Could this be a problem with the XDS100v2 drivers? After struggling with this problem for several hours, I tried upgrading to 16.04 and reinstalling CCS but I still haven't found any success. Please let me know if you have any suggestions!

Best regards,

Chris

 

P.S. Here's the output from the 'Test Connection' logs.

[Start: Texas Instruments XDS100v2 USB Debug Probe_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)]------------------------------------

/home/clightcap/.ti/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 'libjioserdesusb.so'.
The library build date was 'Jul 27 2016'.
The library build time was '18:20:07'.
The library package version is '6.0.407.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 test for the JTAG IR instruction path-length failed.
The JTAG IR instruction scan-path is stuck-at-ones.

The test for the JTAG DR bypass path-length failed.
The JTAG DR bypass scan-path is stuck-at-ones.

-----[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
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG IR Integrity scan-test has failed.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

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
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG DR Integrity scan-test has failed.

[End: Texas Instruments XDS100v2 USB Debug Probe_0]

  • Hi Chris,

    It seems like driver issue. Did you check the device manager?

    Regards,
    Gautam
  • Hi Gautam,

    Thank you for the quick reply. I'm not sure if Linux has the equivalent of Windows device manager, but I've copied the output from lshw and lsusb below. It seems that my laptop is recognizing the XDS100v2 adapter. Is there a way to reinstall the XDS100 drivers?

    Thanks,

    Chris

    clightcap@hp-envy:~$ sudo lshw
    [sudo] password for clightcap:
    hp-envy
    *-core
    *-pci
    *-usb:0
    *-usbhost:1
    *-usb:0
    description: Generic USB device
    product: Texas Instruments Inc.XDS100 Ver 2.0
    vendor: SD
    physical id: 1
    bus info: usb@3:1
    version: 7.00
    serial: SDVQWAG7
    capabilities: usb-2.00
    configuration: driver=ftdi_sio maxpower=400mA speed=480Mbit/s

    clightcap@hp-envy:~$ lsusb -vv

    Bus 003 Device 012: ID 0403:a6d0 Future Technology Devices International, Ltd Texas Instruments XDS100v2 JTAG / BeagleBone A3
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    idVendor 0x0403 Future Technology Devices International, Ltd
    idProduct 0xa6d0 Texas Instruments XDS100v2 JTAG / BeagleBone A3
    bcdDevice 7.00
    iManufacturer 1 SD
    iProduct 2 Texas Instruments Inc.XDS100 Ver 2.0
    iSerial 3 SDVQWAG7
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 55
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0x80
    (Bus Powered)
    MaxPower 400mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass 255 Vendor Specific Class
    bInterfaceSubClass 255 Vendor Specific Subclass
    bInterfaceProtocol 255 Vendor Specific Protocol
    iInterface 2 Texas Instruments Inc.XDS100 Ver 2.0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x02 EP 2 OUT
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 1
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass 255 Vendor Specific Class
    bInterfaceSubClass 255 Vendor Specific Subclass
    bInterfaceProtocol 255 Vendor Specific Protocol
    iInterface 2 Texas Instruments Inc.XDS100 Ver 2.0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x83 EP 3 IN
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x04 EP 4 OUT
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Device Qualifier (for other device speed):
    bLength 10
    bDescriptorType 6
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    bNumConfigurations 1
    Device Status: 0x0000
    (Bus Powered)

  • Hi,

    I have same problem with CCS 6.2 on Windows. With same log output from 'test connection'. My board is new LAUNCHXL-F28069M. Board starting good with default project (flashing via leds and printing temperature info in to VCP). But debug connection to board has failed: via 'test connection' as is topic starter. Via programming attempt with "Error connecting to the target Error -1135" message.

    I think this is board level problem, because connection to LAUNCHXL-F28377S board on the same environment has succeeded.

    Regards,
    Artyom.
  • The drivers can be re-installed by re-running the CCS setup and check the Spectrum Digital Drivers while installation is in progress.
  • Hi Artyom,

    Did you check the Device Manager being Windows? Are the driver installed properly? Also, check the boot switch S1 - check whether configured to GET Mode.

    Regards,
    Gautam
  • Hi, Gautam,

    You can see, that connection to other board has succeeded. This is not driver problem. I think this is EM noise and need to push up on board debugger input to Vcc. Now I don't have time for this. Will check later...

    Thanks.
  • Thank you, I'll try reinstalling the drivers and also using another XDS100 debugger.

    Best regards,

    Chris

  • Chris - your failure type is documented in the link below:
    processors.wiki.ti.com/.../Debugging_JTAG_Connectivity_Problems

    The cause is usually not driver related but HW related (with either the XDS100 or the board/device). The weird thing is that it all worked in 6.1.2 for you so it is confusing. Can you try swapping out either the XDS100 or the board (or both) and see if any of that helps?

    Thanks
    ki
  • Hi Chris,
    Judging by the fact that you are able to start a debug session and connect to your target with 6.2.0 via an XDS100v2 in the below thread, did you resolve your issue?
    e2e.ti.com/.../1992153

    Thanks
    ki
  • Hi Ki,

    Yes I'm back online. As you suggested, it turned out to be a hardware problem. The input voltage to my POR chip was too close to threshold, so it some cases it would hold the chip in reset. It was difficult to troubleshoot as it happened to occur when upgrading to 6.2 so it led me to believe it was related to drivers.

    Thanks for your quick response!

    Best regards,
    Chris