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.

MSP-FET: MSP430Flasher promptly bricked MSP-FET programmer

Part Number: MSP-FET
Other Parts Discussed in Thread: MSP-FLASHER

I recently purchased an MSP-FET programmer to use under Linux (16.04.1-Ubuntu). To get started, I downloaded MSPFlasher from TI, and ran it as:

MSP430Flasher -i ttyACM0

* -----/|-------------------------------------------------------------------- *
*     / |__                                                                   *
*    /_   /   MSP Flasher v1.3.20                                             *
*      | /                                                                    *
* -----|/-------------------------------------------------------------------- *
*
* Evaluating triggers...done
* Checking for available FET debuggers:
* Found USB FET @ ttyACM0 <- Selected
* Initializing interface @ ttyACM0...done
* Checking firmware compatibility:
* The firmware of your FET is outdated.
- Would you like to update it? (Y/N): Y

*********************************************************
*                                                        
*  Initializing Update Bootloader.                       
*  Programming new firmware:                             
*  |||||||||||||||||||||||||||||||||||||||||||||||||| 100%* Update failed. (R)etry/(C)ancel? R
* Update failed. (R)etry/(C)ancel? C
# Exit: 49
# ERROR: Could not find MSP-FET430UIF on specified COM port
* * ----------------------------------------------------------------------------
* Driver      : closed (No error)
* ----------------------------------------------------------------------------
*/

Google turned up this bug report from 2018 which is more-or-less identical to what I'm seeing:

https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/706568?Linux-MSP-EXP430F5529LP-CCS-8-1-bricks-MSP-FET-during-firmware-update-on-Linux

I don't have easy access to a Windows machine to update the bricked device from there. Any suggestions on getting it going again?

  • Hi Todd, I don't have experience on MSP programming on Linux environment. I searched this topic on E2E. Could you please help to check if the information on this thread is useful on you. At the same time, could you please consider installing Linux version CCS have a try? Thanks!

  • Hi Xiaodong,

    No, unfortunately that thread was not useful.

    However, I did manage to unbrick the programmer by installing 'mspdebug' and attempting a firmware update from there. Initially, it also failed:

    >mspdebug tilib --allow-fw-update
    MSPDebug version 0.25 - debugging tool for MSP430 MCUs
    Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Chip info database from MSP430.dll v3.15.0.1 Copyright (C) 2013 TI, Inc.

    Using new (SLAC460L+) API
    MSP430_GetNumberOfUsbIfs
    MSP430_GetNameOfUsbIf
    Found FET: HID_FET
    MSP430_Initialize: HID_FET
    FET firmware update is required.
    Starting firmware update (this may take some time)...
    tilib: MSP430_FET_FwUpdate: MSP-FET / eZ-FET recovery failed (error = 73)
    tilib: device initialization failed

    But then it dawned on me that the failures might be privilege related. It would have been nice if instead of "error=73", something more meaningful was output from the TI library. Anyway, I became 'root', and tried again:

    MSPDebug version 0.25 - debugging tool for MSP430 MCUs
    Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Chip info database from MSP430.dll v3.15.0.1 Copyright (C) 2013 TI, Inc.

    Using new (SLAC460L+) API
    MSP430_GetNumberOfUsbIfs
    MSP430_GetNameOfUsbIf
    Found FET: HID_FET
    MSP430_Initialize: HID_FET
    FET firmware update is required.
    Starting firmware update (this may take some time)...
    Initializing bootloader...
    Programming new firmware...
         0 percent done
        34 percent done
        67 percent done
       100 percent done
    Update complete
    Done, finishing...
    MSP430_VCC: 3000 mV
    tilib: MSP430_VCC: Internal error (error = 68)
    tilib: device initialization failed

    Still not quite there, but a definite improvement. So, I tried again:

    MSPDebug version 0.25 - debugging tool for MSP430 MCUs
    Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Chip info database from MSP430.dll v3.15.0.1 Copyright (C) 2013 TI, Inc.

    Using new (SLAC460L+) API
    MSP430_GetNumberOfUsbIfs
    MSP430_GetNameOfUsbIf
    Found FET: ttyACM0
    MSP430_Initialize: ttyACM0
    FET firmware update is required.
    Starting firmware update (this may take some time)...
    Initializing bootloader...
    Programming new firmware...
        13 percent done
        16 percent done
        19 percent done
        22 percent done
        25 percent done
        25 percent done
        28 percent done
        31 percent done
        34 percent done
        37 percent done
        40 percent done
        43 percent done
        43 percent done
        55 percent done
        58 percent done
        61 percent done
        64 percent done
        67 percent done
        67 percent done
        85 percent done
        88 percent done
        91 percent done
        94 percent done
        97 percent done
       100 percent done
    Update complete
    Done, finishing...
    MSP430_VCC: 3000 mV
    MSP430_OpenDevice
    MSP430_GetFoundDevice
    ...

    Now the MSP-FET appears to be once again functional. The takeaways for TI should be to better report error messages (error codes are not terribly useful for end users). If MSP-Flasher had reported privilege issues, I'd have solved this with a lot less frustration. Further, if the TI library code had performed a preemptive check to make sure it had the correct privileges BEFORE bricking the MSP-FET, that would have been helpful.

**Attention** This is a public forum