• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 3666 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.

CCS/TMS320F28069: XDS110 - Was Working - Isn't Now - XDS-100v2 and XDS-200 work fine; WIN 10 Driver Issue???

John Westmoreland43
Guru 13875 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: SEGGER

Tool/software: Code Composer Studio

Hello All,

I've looked at the threads on this - but I do see the XDS-110 listed in Device Manager - CCS doesn't see it though.

Also - the xdsdfu tool does not find it - and I have to wonder if this is a Win10 driver issue at this point.

Interesting - the XDS-200 does work - but when I connect with CCS - it tries to do a driver(firmware) update - the update *fails*; then connects to the target.

This seems to happen every time with the XDS-200.

Is this a possible driver issue with Win10?

Why would the XDS-110 be working OK; the USB drivers are loaded under device manager; but CCS no longer finds the XDS110?  I received this XDS-110 about 1 week ago.

Thanks,
John W.

  • 0
    TI__Guru**** 169754 points
    John,

    Another user reported a similar scenario, but in his case it was with Linux/macOS.

    I have been testing the Debug Probes with Windows 10 without issues - this OS has been changing steadily fast and I have been quite busy trying to keep up with all the changes, but I didn't see issues with versions 1597, 1605 and 1709.

    It is quite strange the device driver is fine but the tool is not able to properly "find" the Debug Probe - what is the CCS and the Ti Emulators component version? Also, are you using the standalone or a Launchpad?

    Some older firmware versions of the XDS200 had issues with USB3.0 ports and when put to work in Linux, but this was fixed a very long time ago. Can you try to update your probe from the command line and see if it works better? Check section 7 of the following page:
    processors.wiki.ti.com/.../XDS200

    One additional detail that just occurred to me: are you an admin or a regular user on the trouble PC? That may be an untested scenario (especially in Windows, where only a tiny fraction of users are, in fact, regular users)

    Regards,
    Rafael
  • 0 in reply to desouza
    Guru 13875 points

    Hello Rafael,

    What is/was the solution to this:
    Another user reported a similar scenario, but in his case it was with Linux/macOS.

    Maybe there is a hardware issue with the last batch of XDS110's that shipped?
    The XDS110 worked fine for ~1 week. As in my OP - XDS-100v2 and XDS-200 both work fine with the target. I had been using the XDS-100v2 on this target board; switched to the XDS-110 when I received it; and then tested with the XDS-200 when the XDS-110 no longer connected.

    I agree - I can see the driver in the driver window and also the COM Ports - I thought that could be an issue - seeing both the driver and both COM Ports - but I disabled the 'aux' COM port and get the same results.

    CCS - 7.4.0.00015
    TI Emulators 7.0.100.1 com.ti.emulation.pack.win32.feature.group Texas Instruments
    Standalone

    I'm an admin on the PC; I ran everything in admin mode; including re-installation of 7.4 - and get the same results.

    I updated the firmware on the XDS-200 (same PC); and it is working fine - don't get the annoying update issue inside CCS; makes me think something could be related here to the XDS-110.

    I used the following directory for the update:
    F:\Texas_Instr-New-Install-7p4\ccs_base\common\uscif\xds2xx>

    Thanks,
    John W.

  • 0 in reply to John Westmoreland43
    Guru 13875 points

    Rafael,

    OK - here's the post you are referring to:
    e2e.ti.com/.../657865

    My problem is similar; but I'm not sure if this happened immediately after a firmware update with CCS and the XDS110. I used it for around 1 week - I suppose it could have done a firmware update when I was distracted by something maybe; and I clicked OK not realizing that.

    Other than that - my experience appears to be identical to what's in this thread:
    e2e.ti.com/.../657865

    I wonder now if it worked and then failed on the next reboot of this PC after a firmware update.

    This is what I get when running the dbgjtag command:

    F:\Texas_Instr-New-Install-7p4\ccs_base\common\uscif>dbgjtag -f @xds110 -S integrity

    An error occurred while hard 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 '-260' (0xfffffefc).
    The title is 'SC_ERR_XDS110_OPEN'.

    The explanation is:
    An attempt to connect to the XDS110 failed.
    The cause may be one or more of: no XDS110 is connected, invalid
    firmware update, invalid XDS110 serial number, or faulty USB
    cable. The firmware and serial number may be updated using the
    xdsdfu utility found in the .../ccs_base/common/uscif/xds110
    directory of your installation. View the ReadMe.txt file there
    for instructions.



    Thanks,
    John W.

  • 0 in reply to John Westmoreland43
    Guru 13875 points
    OK - and now for something completely different:

    The Win10 version I was running I had running in test mode since the '69 USB drivers aren't signed; well; had another issue and had to reinstall the OS and CCS; and now I am getting this:

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


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

    C:\Users\john\AppData\Local\TEXASI~1\CCS\
    TI_CCS~1\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 'jioxds110.dll'.
    The library build date was 'Nov 6 2017'.
    The library build time was '10:36:36'.
    The library package version is '7.0.100.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 '5' (0x00000005).
    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 XDS110 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for XDS110 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).

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

    F:\TI_CCS_7P4\ccsv7\ccs_base\common\uscif\xds110>xdsdfu -e

    USB Device Firmware Upgrade Utility
    Copyright (c) 2008-2015 Texas Instruments Incorporated. All rights reserved.

    Scanning USB buses for supported XDS110 devices...


    <<<< Device 0 >>>>

    VID: 0x0451 PID: 0xbef3
    Device Name: XDS110 Probe with CMSIS-DAP
    Version: 2.3.0.11
    Manufacturer: Texas Instruments
    Serial Num: 00000000
    Mode: Runtime

    Found 1 device.

    F:\TI_CCS_7P4\ccsv7\ccs_base\common\uscif\xds110>

    Hmmm, so, it would appear that something is going on with the USB drivers???

    Regards,
    John W.
  • 0 in reply to John Westmoreland43
    Guru 13875 points
    Hello All,

    Could the serial number showing up as '0' be an issue possibly?

    Thanks,
    John W.
  • 0 in reply to John Westmoreland43
    TI__Guru**** 169754 points
    John,

    Thank you for sending the additional details. Although the OS reinstall is quite radical, it was obviously the final solution for this problem.

    One thing that intrigued me was the safe mode - we don't test our drivers for operation in this scenario, but I really can't think of anything bad this mode could trigger. If anything, it reduces the problems by removing additional layers of verification.

    At any rate, the null serial number is not really a problem unless you have multiple XDS110s connected to the same PC at the same time (which is also a problem on every other Debug Probe out there). I personally have multiple XDS110 probes lying around and had no issues.

    John Westmoreland43 said:

    Other than that - my experience appears to be identical to what's in this thread:
    e2e.ti.com/.../657865

    I wonder now if it worked and then failed on the next reboot of this PC after a firmware update.

    As you can tell, that thread is not yet solved (the bug is still outstanding) and this was verified to happen on other OSes. Perhaps your case may be one example of this happening on Windows as well, but to confirm this we would need to find a way to consistently reproduce this here for analysis.

    One detail I forgot to mention: in past versions of the firmware, the XDS110 (and the XDS200, for that matter) needed a complete power cycle to make the bootloader re-load the flashed firmware. This is not common nowadays as the manufacturing house uses newer firmware versions, but it is possible that older batches of XDS110s were shipped with firmware that required this. However, I can see that happening if somehow the firmware flashing was not done properly - the bootloader would try to load but fail and the device would most probably be stuck in DFU mode.

    Unfortunately at this time I can't do much other than keep an eye on other customer reports and get back to you in case something relevant shows up.

    All in all, thank you for taking the time to do such detailed report and I apologize for the troubles.
    Rafael
  • 0 in reply to John Westmoreland43
    TI__Guru**** 450031 points

    John Westmoreland43 said:
    Could the serial number showing up as '0' be an issue possibly?

    Is it just '0'? Or is it '00000000'?

    There is a known dependency where the serial number must be 8 characters long

  • 0 in reply to Ki
    Guru 13875 points
    Hello Ki,

    It is what is reported:

    VID: 0x0451 PID: 0xbef3
    Device Name: XDS110 Probe with CMSIS-DAP
    Version: 2.3.0.11
    Manufacturer: Texas Instruments
    Serial Num: 00000000
    Mode: Runtime

    But the unit has a serial number on the label/sticker on the back; so I have to wonder why the serial # is missing in the driver/firmware check and also wonder how a 'null' serial number could be a problem.

    Thanks,
    John
  • 0 in reply to desouza
    Guru 13875 points
    Rafael,

    Don't worry; this PC has a 'sacrificial' boot drive since the latest Win10 update is a little scary; to say the least. I had an entire /user/ Profile directory get deleted. After that; believe me; measures have been taken. Reminds me of 'the old days' of Windows; seems they're back.
    Absolutely no warning whatsoever either. I've seen some posts (not here of course) about having user profiles in non-standard locations;
    and I certainly did; so I think that led to losing the user profile(s); but at the same time to have NO MESSAGE whatsoever from the Win10 updater; well, like I said; seems the old days are back and people are going to let others lose data during the updates before they update like it used to be once-upon-a-time. Some of the younger folk that are reading this may think I'm off my rocker; but I've seen plenty of people online complaining about this; so be careful and back up everything you don't want to lose. With the cloud storage we have nowadays - that certainly makes things a little easier. I guess when Microsoft says they are making it 'easier to operate in an online world' I guess that means you absolutely don't care that we can blow away any aspect of your user profile without you complaining. Ok, enough.

    Anyway; I was a little surprised but suspected there could be a problem and I am not running the test mode of Windows right now but will probably enable that again shortly. The XDS-110 is working fine but I'm a little worried about the serial number being blank; or to be exact, 00000000 - which is more than likely 'NULL' in the computing world; so I may try changing the serial number to what's on the sticker.

    I do have a question; I have a Segger JTAG I/F, if I run into trouble; can I use a Segger to program the internal TIVA that's on the XDS-110?

    Also - even though I'm showing this in the CCS I have (re)installed:
    TI Emulators 7.0.100.0 com.ti.emulation.pack.win32.feature.group Texas Instruments

    CCS wants me to download an update that has:
    TI Emulators 7.0.100.1 com.ti.emulation.pack.win32.feature.group

    I'm reluctant to do this since I think this is where the trouble began with the XDS-110.

    I wonder why if it's installed already that the downloader/installer wants to install it again?

    I'm not going to let it install that update until I hear your response on this as I don't want to get back into the situation I was just in.

    Also, I just got this XDS-110 a few weeks ago now; so it's new.

    No need to apologize.

    Thanks!
    John W.
  • 0 in reply to John Westmoreland43
    Guru 13875 points
    Rafael,

    OK - so there's a *slight* update - anyway; I'll wait to hear what you say:
    7.0.100.0
    7.0.100.1

    Thanks,
    John
  • 0 in reply to John Westmoreland43
    TI__Guru**** 450031 points

    John Westmoreland43 said:
    Serial Num: 00000000

    That is ok then

    John Westmoreland43 said:
    But the unit has a serial number on the label/sticker on the back; so I have to wonder why the serial # is missing in the driver/firmware check and also wonder how a 'null' serial number could be a problem.

    No, "00000000" is a valid serial number as far as CCS is concerned. As long as there are not multiple debug probes of the same type with the same serial number, it is fine:

    http://software-dl.ti.com/ccs/esd/documents/sdto_ccs_multi-probe-debug.html#xds110

  • 0 in reply to Ki
    Guru 13875 points
    Ki,

    OK - thanks.

    So that you and Rafael know - I'm running under the Win10 test build again; and so far, so good.

    For the history of this thread - the details are:
    Test Mode
    Windows 10 Pro
    Build 16299.rs3_release.170928-1534

    Thanks,
    John
  • 0 in reply to John Westmoreland43
    TI__Guru**** 169754 points

    (first of all, sorry. I clicked on the wrong button when I marked one of your posts as "Ti thinks answered")

    John,

    Thanks for the additional information. The changes between build 100.0 and 100.1 should not influence this particular scenario.

    John Westmoreland43 said:
    The XDS-110 is working fine but I'm a little worried about the serial number being blank; or to be exact, 00000000 - which is more than likely 'NULL' in the computing world; so I may try changing the serial number to what's on the sticker.

    I don't recall the serial number causing any problems for me. Initial releases of the XDS110 were shipped with a NULL S/N but there was a problem that disallowed any changes to it - IIRC a bootloader update was required but I can't find the thread. However, since your XDS110 is quite new, you most probably have a newer batch. To test this, issue a xdsdfu -s 0xDEADBEEF -r and see if the setting "sticks" - if so, your pod should be ok. 

    John Westmoreland43 said:
    I do have a question; I have a Segger JTAG I/F, if I run into trouble; can I use a Segger to program the internal TIVA that's on the XDS-110?

    Certainly. Check the discussion below where another user does that as well:

    https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/610305/2257436

    Hope this helps,

    Rafael

    P.S. Your rant about Win10 matches what I observed here as well; when it says that "All your files are exactly where you left them" after an update, this is not always true. That and other things made me switch back to 7 in my home computer.

  • 0 in reply to desouza
    Guru 13875 points
    Rafael,

    OK - I'll give that a try (setting the serial #).

    Thanks for the help,
    John