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.

  • TI Thinks Resolved

Can't connect XDS200! Possible Windows 10 driver issue

Expert 1320 points

Replies: 6

Views: 526

Hi.

I know is that ccs7.2 is "old" but anyway I have to use it.

I didn't use xds200 debug probe for 2 weeks, then I start to see strange effects like sometimes debug session success, sometimes it fails... and now it doesn't work at all.
I go through instructions and fail on testing ti\ccsv7\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0

I'm getting "Error : test failed"
I also follow "To reinstall the Windows device driver" but no success..
I also make driver uninstall and repeat install procedure but no success..
This is screenshot:

I get some warnings: "Device not migrated". Could be that issue??? Did you have any similar experience? 

Best Regard,

Mare

  • Guru 147965 points
    Mare,

    Please apologize for the delay. With such intermittent functionality, the first suspicion falls into USB connection or hardware problems.

    In this case, I would certainly follow the procedure detailed at the section "Hardware Checklist" our Troubleshooting page below, which is a methodical strategy to isolate the issue.

    dev.ti.com/.../

    Hope this helps,
    Rafael

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    Hi,

    I forgot to mention that on other computers debugger work.

    Ok.. I follow a steps from your link:
    When I make "Test Conection" in .ccxml first time I get:

    [Start: Texas Instruments XDS2xx USB Debug Probe_0]
    
    Execute the command:
    
    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity
    
    [Result]
    
    
    -----[Print the board config pathname(s)]------------------------------------
    
    C:\Users\Mare\AppData\Local\TEXASI~1\CCS\
        ti\0\0\BrdDat\testBoard.dat
    
    -----[Print the reset-command software log-file]-----------------------------
    
    This utility has selected a 560/2xx-class product.
    This utility will load the program 'xds2xxu.out'.
    The library build date was 'Sep 28 2018'.
    The library build time was '16:56:12'.
    The library package version is '8.0.803.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 '13' (0x0000000d).
    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]-----------------------------
    
    This emulator does not create a reset log-file.
    
    -----[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.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.
    
    The JTAG IR Integrity scan-test has succeeded.
    
    -----[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.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.
    
    The JTAG DR Integrity scan-test has succeeded.
    
    [End: Texas Instruments XDS2xx USB Debug Probe_0]
    

    It looks good but just on the first try...
    If I run "Test Connection" again I get:

    [Start: Texas Instruments XDS2xx USB Debug Probe_0]
    
    Execute the command:
    
    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity
    
    [Result]
    
    
    -----[Print the board config pathname(s)]------------------------------------
    
    C:\Users\Mare\AppData\Local\TEXASI~1\CCS\
        ti\0\0\BrdDat\testBoard.dat
    
    -----[Print the reset-command software log-file]-----------------------------
    
    This utility has selected a 560/2xx-class product.
    This utility will load the program 'xds2xxu.out'.
    E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
    Failed to open i/o connection (xds2xxu:0)
    
    An error occurred while soft 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 '-250' (0xffffff06).
    The title is 'SC_ERR_ECOM_EMUNAME'.
    
    The explanation is:
    An attempt to access the debug probe via USCIF ECOM has failed.
    
    [End: Texas Instruments XDS2xx USB Debug Probe_0]
    

    Also when I try to run Debug:

    Error initializing emulator:
    (Error -2083 @ 0x0)
    Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
    (Emulation package 8.0.803.0)


    I found on forum ->  issues about hubs. I change the USB port on the computer and upper story repeat (first-time success connection then debugger fails to connect...)

    I'm researching further...

  • In reply to Marko Kastelic:

    Update:

    When I change port I get one-shot chance for connecting (but it seens that it work just in case when port has never been connected with debugger before), and try:

    C:\ti\ccsv7\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0
    boardRev=1
    ipAddress=0.0.0.0
    ipConfig=dhcp
    ipGateway=0.0.0.0
    ipNetmask=0.0.0.0
    productClass=XDS2XX
    productName=XDS200
    serialNum=00:0E:99:04:3E:BD
    swRev=1.0.0.8
    hostCPU=AM1802
    emuCtrlType=Bit bang
    extMemType=SDRAM
    portUSB=true
    portENET=false
    portWIFI=false
    portRS232=false
    EnableUSBSerial=false
    CurrentMeasure=false

    Then I try to run debug in CCS and it works! After I Terminate....

    C:\ti\ccsv7\ccs_base\common\uscif\xds2xx>xds2xx_conf get xds2xxu 0
    Error : test failed

    Does it smell like windows/driver issue? 

  • Guru 147965 points

    In reply to Marko Kastelic:

    Mare,

    Please apologize for the delay; I missed your past replies.

    The first scenario certainly seems odd, given that it seems the dbgjtag utility (that runs under the "Test Connection" function) is holding control over the XDS200. By extension, it seems the first process that accesses the XDS200 holds control over it, preventing any other utilities from accessing the device. The wide span across versions (CCSv7.2.0 and TI Emulators component 8.0.803.0) may explain this, but at this point I can't tell further.

    If I understood correctly the last scenario, it sounds very familiar; once CCS accesses the probe once, it tends to hold control until CCS is fully closed. That was the subject of a discussion a while ago but it was never moved forward due to other priorities.

    I am out of the office at the moment but will try these scenarios later today and report back. I am using Windows 10 Pro Build 1709 and have a few versions of CCS installed, including 7.2.0 and later.

    Regards,
    Rafael

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

  • In reply to desouza:

    Hi,

    Now I made reinstal of CCS.
    Version: 7.2.0.00013 
    Emulation package: 6.0.628.3.

    Problem is NOT resolved.

  • Guru 147965 points

    In reply to Marko Kastelic:

    Mare,

    I just returned from vacation today; I tested both Windows 10 1709 and 1809 running CCS 7.2.0 with both emupacks 7.0.188.0 and 8.0.803.0 but unfortunately I can't reproduce this issue here. CCS releases the CDC serial port after it finishes working with it. 

    To that effect, I searched around but couldn't find a utility that was effective in identifying which process is using a given CDC device such as the XDS200. The old Sysinternals' Portmon does not work in 64-bit systems and, despite I got other leads to serial port monitors such as the Serial Port Monitor, none of them identify the processes that locked up the port. Also, although the Process Explorer can skim very thoroughly through the system processes, iI could not find a way to actually find the Serial Port itself.  

    Therefore I am quite at a loss as to what should be tried in this scenario. At this moment I can only suggest you to double-check other running applications for security, monitoring or even drivers from other manufacturer's JTAG debug probes (I vaguely recall that something similar was reported many years ago).  

    Hope this helps,

    Rafael


    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

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.