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.

MSP432-DEBUGGERS: CCS 11.2.0 (Error -260 @ 0x0) Firmware Update and Flash of MSP432 Fails

Part Number: MSP432-DEBUGGERS

I recently changed SSD drives in my laptop and installed Code Composer Studio 11.2.0 and updated Simplelink_SDK to work with an MSP432P401R board. On my prior SSD I had Code Composer Studio 9.3 installed. I can successfully build my projects on CCS 11.2.0, but attempting to flash the new executable to the MSP432 fails. The prior install was on openSUSE Leap 15.0 and then current install is on openSUSE Leap 15.4.

I can connect the MSP432 to my new setup and run the program on the MSP432 and see the terminal output in an Xterm running minicom. This works as it always has, so the USB cable, the XDS110 debug probe is fine and then MSP432's ability to communicate with the computer is fine.

However, when I attempt to flash from CCS 11.2.0, I receive the following error:

CS_DAP_0: Error initializing emulator: (Error -260 @ 0x0) 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 XDS110SupportReadMe.pdf file there for instructions. (Emulation package 9.7.0.00213)

I still have other CCS 9.3 installs under Windows, so I am unsure how to proceed here. If I blindly follow the manual and change the firmware and serial number as mentioned, will that break the ability to connect from my other CCS installs? Further, since I can connect through the XDS110 (as my normal user) just fine to run the program on the MSP432 -- why is CCS 11.2.0 failing to be able to flash the newly built program using it? The error message isn't at all clear what the problem is, it just mentions a handful of things it might be? I'd rather not make things worse by trying to fix the wrong problem.

How should I go about trying to fix this to ensure I don't make things worse?

  • The prior install was on openSUSE Leap 15.0 and then current install is on openSUSE Leap 15.4.

    Has the <ccs_install_root>/ccs/install_scripts/install_drivers.sh script been run for the new CCS 11.2 installation?

    Does running <ccs_install_root>/ccs/ccs_base/common/uscif/xds110/xdsdfu -e show the XDS110? This enumerates the connected devices and shows info.

  • Apparently the install_drivers.sh script was run, but there is a permission or udev problem accessing the XDS110 device. Specifically, as the normal user:

    $ /opt/ti/ccs1120/ccs/ccs_base/common/uscif/xds110/xdsdfu -e

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

    Scanning USB buses for supported XDS110 devices...


    Found 0 devices.

    But running as root:

    # /opt/ti/ccs1120/ccs/ccs_base/common/uscif/xds110/xdsdfu -e

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

    Scanning USB buses for supported XDS110 devices...


    <<<< Device 0 >>>>

    VID: 0x0451 PID: 0xbef3
    Device Name: XDS110 Embed with CMSIS-DAP
    Version: 3.0.0.15
    Manufacturer: Texas Instruments
    Serial Num: M4321005
    Mode: Runtime
    Configuration: Standard

    Found 1 device.

    I re-ran the install_scripts.sh anyway. Checking udev for the device, udev complains that the execute bit is set on:

    /etc/udev/rules.d/70-mm-no-ti-emulators.rules

    I fixed that issue (unrelated). After re-running the install_scripts and re-loading the udev rules -- it WORKS. (but I don't know which part fixed it)  Thank you for your help.

  • I re-ran the install_scripts.sh anyway. Checking udev for the device, udev complains that the execute bit is set on:

    /etc/udev/rules.d/70-mm-no-ti-emulators.rules

    I looked at my Ubuntu 18.04.6 LTS system in which CCS 11.2 had been installed, and the /etc/udev/rules.d/70-mm-no-ti-emulators.rules file also has execute permission, whereas none of the other files in the directory do.

    The ~/ti/ccs1120/ccs/install_scripts/ti_permissions_install.sh script is explicitly performing chmod 644 /etc/udev/rules.d/71-ti-permissions.rules but not sure why, and if this is what causes the issue with openSUSE Leap 15. openSUSE Leap is not a distribution listed in the CCS 11 Distribution Validation

  • The execute permission set on /etc/udev/rules.d/70-mm-no-ti-emulators.rules just looks like a fluke, it doesn't hurt anything, but will be flagged by a security conscious filesystem check.

    I still do not know how the udev rules were not installed as part of the CCS 11.2.0 install -- unless:

    1. The install of CCS simply places the install_drivers.sh script on the filesystem, and then
    2. It isn't executed until CCS is run for the first time.

    That would explain why my install of CCS as root to /opt/ti went fine, but then running CCS for the first time failed when it tried to write to /etc/udev/rules.d as a non-root user.

    As for openSUSE not being listed as a distro for CCS, there is really no reason it shouldn't be. I have successful installs on openSUSE Leap 42.3, 15.0 and 15.4 (from CCS 9.2 to the current 11.2.0 now). I Also have a successful install on Archlinux - not requiring any more or less to get working than the other.

    I haven't found a distro yet that CCS doesn't properly run on, and it does a good job identifying missing dependencies (a libncurses5 library was the only surprising dependency, as ncurses6 has been the stable version for quite some time -- but there are special packages from ncurses6 that provide the older ncurses5 library)

    I'll try and set up a virtualized install of openSUSE 15.4 and install fresh there since I now know what and where to look for the udev rules installed by the installer. I'll report any new findings back. Thank you for your help.