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.

MSP432E401Y: Launchpad is bricked, unlock sequence does not work

Part Number: MSP432E401Y

I've got a MSP432E401Y Launchpad setup I've been using for some weeks, that has suddenly lost XDS110 connectivity to my PC.  When I plug in to the PC now, there is a delay of several seconds, then Windows says the USB device is not recognized.

The only thing that has changed is I recently (successfully) revised (in CCS) the software running on the device, and it ran fine after upload.   My problems began at the next power-on.

I've bricked one of these boards before, and eventually stumbled across the procedure "Executing Unlock Sequence" described in 5.3 of SLAA777A,  In my prior experience, this solution worked for me.

However, it is not working in the current situation.  When I try to run the dbgjtag procedure, I see this:

C:\ti\ccs930\ccs\ccs_base\common\uscif>dbgjtag -f @XDS110 -Y unlock,mode=msp432e4

Executing the unlock procedure.

Assert and hold reset while powering up the device.
Press any key to continue.


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 XDS110SupportReadMe.pdf
file there for instructions.

As I mentioned, I have successfully used this procedure before so I am confident that I am doing it correctly.  (I can also confirm that xdsdfu does not work - it reports that there are no devices.)  And I don't see how it could be any of the four issues mentioned in the error message, since all was well at last power-down.

I also even tried swapping USB cables, even though the cable I was using has been working fine for several months.

Other then the lack of connectivity, the board seems fine.  The green LED by the XDS110 is on, and I can tell by the flashing User LEDs that my application is running.

Any ideas on how to restore connectivity?

Thanks,
Brad

  • Hi Brad

    Braden Hines said:
    The only thing that has changed is I recently (successfully) revised (in CCS) the software running on the device, and it ran fine after upload.   My problems began at the next power-on.

    That seems it related with CCS update. Could you re-install the latest version of the CCS too see if it works?

  • Hi,

    Thanks for your reply.

    I am pretty sure that this is much lower level than that.  The other Launchpad I have continues to work just fine.  And to be more clear, I have not updated CCS.  I simply made a small change to my MSP432 application, as I typically do a dozen times a day.  I just wanted to let you know that I am using CCS as my toolset.  

    The problem is that Windows doesn't even recognize the Launchpad when I plug it in, so there's nothing for CCS to talk to.

    However, I have made a tiny amount of progress.  In the time since I wrote the last note, I found the instructions at http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html#flashing-the-bootloader 

    xdsdfu once again reports "device not found".  I tried repeating again and got the same result.

  • Weird, the last part of my last reply got cut off.

    I mentioned that I tried one other thing.  I decided to repeat the short-TDO-to-GND technique again, and this time I used  xdsdfu -f to flash the firmware file, and it likewise appeared to flash successfully, but there was no change in behavior. Device still not recognized in Windows.

    Thanks for any additional tips,

    Brad

  • Here's one last bit of information. 

    To simplify the setup as much as possible, I removed the 10 jumpers that couple the XDS110 part of the board to the MSP432 part of the board and tried repeating the process.

    Indeed, as expected, the MSP432 does not power on.  But in every other way, the result is the same.  Device unrecognized by Windows.

  • Hi Braden

    Braden Hines said:
    xdsdfu once again reports "device not found"

    Does that mean your computer can't show the items below when you plug in?

    If it not show, dose it show the Stellaris DFU entry on the Control Panel as below

  • Hi Gary, that's correct, it does not show those things. Thanks so much for taking the time to help me dig into this.

    Here are the particulars.

    When I plug in the Launchpad, first I see this in the corner, after about 10 seconds:

    Then in Device Manager, you see this:

    When you open up the device properties, the Device Status is "Windows has stopped this device because it has reported problems. (Code 43)".

    However, if I plug i the Launchpad while keeping TDO shorted to GND, then I do see the Stellaris DFU device, and xdsdfu sees it as well:

    C:\ti\ccs930\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: 0x1cbe PID: 0x00ff
    Device Name: Tiva Device Firmware Update
    Manufacturer: Texas Instruments Incorporated
    Serial Num: 00000000
    Mode: DFU

    Found 1 device.

    And from there, I appear to be able to flash things - I can flash the bootloader with xdsdfu -b, or the firmware with xdsdfu -f.  But after doing either of those things, when I unplug and plug back in, I'm right back where I started - USB device unrecognized.

    As an aside, I still have the 10 jumpers that connect to the MSP432 removed.  I figured let's just diagnose the XDS110 first.  If I should put them back in let me know.

    Thanks,
    Brad

  • FWIW, here are the current versions of all the files in my xds110 folder.  I have tried re-flashing both 3.0.0.11 and 3.0.0.13.

    Directory of C:\ti\ccs930\ccs\ccs_base\common\uscif\xds110

    05/31/2020  04:26 PM   <DIR>          .
    05/31/2020  04:26 PM   <DIR>          ..
    05/08/2020  09:23 AM           73,152 boot_loader.axf
    05/08/2020  09:23 AM            6,182 boot_loader.bin
    05/08/2020  09:23 AM            3,227 eZ_FetDcdcController.txt
    11/25/2019  04:58 PM          251,880 firmware.bin
    02/13/2020  06:29 PM          252,784 firmware_3.0.0.11.bin
    05/08/2020  09:23 AM          253,532 firmware_3.0.0.13.bin
    05/08/2020  09:23 AM          141,824 xds110reset.exe
    05/08/2020  09:23 AM          176,023 XDS110SupportReadMe.pdf
    05/08/2020  09:23 AM          177,152 xdsdfu.exe
                   9 File(s) 1,335,756 bytes

    I noticed that the instructions at the end of the ReadMe PDF match the instructions I found on the web, but I also saw that there is a variant that discusses using an external JTAG probe to  "erase the entire flash of the XDS110" prior to flashing boot_loader.bin. 

    I don't see a way to do that with xdsdfu.  Does that happen automatically when using xdsdfu -b?  Or do I need to find a way to erase the flash before burning the bootloader?  It feels to me like that full erase step is likely not happening, given how quickly the bootloader flashes (less than a second).

    I'm wondering if I should try a full erase somehow, but I don't know how to try that.

     

  • Hi 

    Have you try the command below to update the XDS110?

    xdsdfu -m
    xdsdfu -f firmware.bin -r

    When you re-plug in the device(after execute the command above), your computer can't find the device?(Don't need to pull down the TDO pin to GND this time)

  • Yes, I've tried that (with the exception that I didn't have to do xdsdfu -m because the device already comes up in DFU mode when I start it using the TDO shorting technique, as verified by xdsdfu -e).

    That's what I meant when I wrote that "I can flash the bootloader with xdsdfu -b, or the firmware with xdsdfu -f. "

    I've tried flashing the bootloader with xdsdfu -b, I've also tried flashing the firmware with xdsdfu -f.

    Both operations appear to succeed, but in either case, the computer fails to find the device when I plug it back in.

  • Gary,

    My apologies, I did not follow your instructions exactly before.

    I assumed I was supposed to flash the latest firmware, so I had tried

    xdsdfu -f firmware_3.0.0.13.bin -r

    and even the previous version

    xdsdfu -f firmware_3.0.0.11.bin -r

    I had not tried exactly what you wrote:

    xdsdfu -f firmware.bin -r

    When I tried the last one, it worked and the device was recognized once again.  Then when I connected to the device in CCS, it did the update to the latest version.

    I must say, I was quite surprised that using xdsdfu to flash the latest firmware was the wrong thing to do.

    At any rate, my issue is resolved.  I am unbricked.  Thanks for your help.

    Brad

  • For what it's worth, the way I discovered this was that I got out a brand new Launchpad and connected it.

    I figured it was probably out of date, so I went right into xdsdfu and checked its version.  Sure enough it was out of date, so I used xdsdfu to flash 3.0.0.13.  Instant brick #2.

    THEN I went back and tried flashing just "firmware.bin" and that worked.  Then going in to CCS it updated to the latest version, and it worked.

**Attention** This is a public forum