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 LaunchPad: Error connecting to the target since upgrading CCS 6.1

Other Parts Discussed in Thread: MSPWARE

I was working with the MSP432 LaunchPad without any issues, I then noticed a number of recommended updates (sorry, cannot remember them all). I then followed the suggested updates, but now receive the following error when trying to program the MSP432 LaunchPad.

Connection is: Texas Instruments XDS110 USB Debug Probe [Default]

I am using CCS Version: 6.1.0.00104 

Compiler: TI v5.2.3  (Which was one of the updates) - Tried earlier versions.

Error connecting to the target:
(Error -1063 @ 0x0)
Device ID is not recognized or is not supported by driver. Confirm device and debug probe configuration is correct, or update device driver.
(Emulation package 5.1.641.0)

Glenn.

  • Glenn,

    What does the Test Connection show? Does it complete successfully?

    BTW, the compiler does not influence the ability to connect to a target.

    Regards,
    Rafael
  • Thanks Rafael,

    Below is the output from the Test....looks like everything was successful.

    Yes, I am aware the compiler will make no difference, but I did install other things in my update process....sorry, do not remember them all.

    [Start: Texas Instruments XDS110 USB Debug Probe]

    Execute the command:

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

    [Result]


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

    C:\Users\glenn\AppData\Local\TEXASI~1\CCS\
    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 'jioxds110.dll'.
    The library build date was 'Feb 18 2015'.
    The library build time was '23:56:50'.
    The library package version is '5.1.641.0'.
    The library component version is '35.34.40.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 512 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 512 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 XDS110 USB Debug Probe]

    Glenn.
  • I have just had another MSP432 delivered to me and when testing with it, everything works. This is not an issue with the CCS, but with the MSP432 device! The upgrade process was just a coincidence, I will close this case and talk with the MSP432 forum.

    Glenn.
  • Glenn,

    Thanks for reporting back your findings. I would also double check the firmware revision of your XDS110 (perhaps the board you have has an older firmware, I don't know).

    To do this:

    - open a command prompt and go to the directory that hosts the xdsdfu utility:

    C:\Users\user>cd C:\ti\ccsv6\ccs_base\common\uscif\xds110

    - run xdsdfu -e to enumerate the attached devices. The output of my working Launchpad is shown below:

    C:\ti\ccsv6\ccs_base\common\uscif\xds110>xdsdfu -e

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

    Scanning USB buses for supported XDS110 devices...

    <<<< Device 0 >>>>

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

    Found 1 device. 

     - If you need to update, check the file Readme.txt in the directory above.

    Hope this helps,

    Rafael

  • Thanks Rafael,

    I have worked with to determine the cause, which was a coding error on my part.

    I had accidentally commented out the following line in the msp432_startup_ccs.c when I was attempting to make changes to the startup.

    //#pragma DATA_SECTION(interruptVectors, ".intvecs")

    The #pragma directive is necessary to place the interrupt vector table into 0x00 (".intvecs").

    To fix the issue, you will need to follow the below steps to factory reset the launchpad

    1. Connect the failing LaunchPad/unit to your PC.
    2. Open CCS, assume you already have at least one MSP432 project open.
    3. Go to View > Target Configuration.
    4. Within Target Configuration navigate to your MSP432 project > the .ccxml file.
    5. Right Click > Launch Configuration
    6. Under Debug window you should now see some tree structure starting with the .ccmxl file being the root > something_CORTEX_M4_something (unknown)
    7. Right Click > Show all hidden cores.
    8. Connect only to the Non-Debuggable Devices > DAP.
    9. Go to Script > Factory Reset.
    10. Power cycle and try to restart debug.

    Glenn.
  • Repaired the connection with my MSP432. This issue was caused by the recent CCS update.
    Thanks!
  • I'm getting this error anytime I load the examples from MSPWare (like the OutOfBox or the BlinkLED projects) onto my LaunchPad. I have to do this factory reset of the MSP432 to get the connection back.

    Gregory do your example projects work now? I never changed any of the code like the OP did, and I suspect you never did either.

    When I begin a debug session, the code loads, and then the debugger starts flashing quickly between executing - resetting. The debugger never settles at the beginning of main() ready to debug, and never enables the "pause" button (only the "stop" button). Then I have to stop that session (or it eventually has a connection failure), and all future sessions give the error described by the OP (until I do the factory reset of the MSP432).

    Any help? I'd love to get some example code up and running. It always accelerates the learning process for me.

    Thanks,

    Jeff

  • Jeff Tenney said:
    I'm getting this error anytime I load the examples from MSPWare (like the OutOfBox or the BlinkLED projects) onto my LaunchPad. I have to do this factory reset of the MSP432 to get the connection back.

    This is a known issue, please see this related thread for root cause and workaround details.
    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/460430/1663082#1663082

  • Thank you AartiG, I should have searched the forum more carefully.

    I can confirm that fix works for me.

    Jeff

  • Glenn Vassallo said:
    Thanks Rafael,

    8. Connect only to the Non-Debuggable Devices > DAP.
    9. Go to Script > Factory Reset.
    10. Power cycle and try to restart debug.

    I'm running into some trouble here.  I'm not sure what the "> DAP" part means, when I chose show hidden the XDS110 debug probe became a child of "Non-Debuggable Devices".  Is DAP an option that I'm supposed to choose or is it what the name of the target is supposed to be?  After connecting to the non debuggable devices there are no options in the script menu with non-debuggable devices highlighted.  With the XDS110 probe highlighted there a bunch of options under MSP432 Debug Clock Control, but I get an error saying target is not connected if I try to run them.

  • I figured out what I was doing wrong. I assumed when I chose "show hidden" it would automatically expand "Non-Debuggable Devices," so I was never seeing the "Debug Probe/CS_DAP_0" that was its child. I connected and factory reset and now it's working.
  • THIS SOLUTION WORKS WELL; SADLY, THIS SITUATION HAPPENS OFTEN; CAN'T IT BE SOFTWARE RESOLVED?