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.
Tool/software: Linux
I got these 'promo' msp430fr2433 launchpads.
The doc says that it comes pre-flashed with "OutOfBox", and when I power up the board, red LED should flash approx. once in 5 seconds. But in fact, it flashes fast, several times per second, and this pattern does not change when I press J1 or J2 or both. And nothing comes over the backchannel UART.
I try to communicate with it via `mspdebug tilib` on Linux. Mspdebug behaves as if everything goes all right, and the red LED 101 on the probe lights up. I flash the supplied BlinkLED_MSP430FR2433.txt, and it reports no error, but there is no change in the blink pattern.
$ mspdebug tilib --allow-fw-update MSPDebug version 0.22 - debugging tool for MSP430 MCUs Copyright (C) 2009-2013 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. MSP430_GetNumberOfUsbIfs MSP430_GetNameOfUsbIf Found FET: ttyACM0 MSP430_Initialize: ttyACM0 Firmware version is 4294967295 MSP430_VCC: 3000 mV MSP430_OpenDevice MSP430_GetFoundDevice Device: (id = 0x0000) 0 breakpoints available MSP430_EEM_Init Chip ID data: 03 00 55 Available commands: = erase isearch power save_raw simio alias exit load prog set step break fill load_raw read setbreak sym cgraph gdb md regs setwatch verify delbreak help mw reset setwatch_r verify_raw dis hexout opt run setwatch_w Available options: color gdb_loop enable_bsl_access gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet gdb_default_port Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog BlinkLED_MSP430FR2433.txt Erasing... Programming... Writing 218 bytes at c400... Writing 8 bytes at ff80... Writing 38 bytes at ffda... Done, 264 bytes total (mspdebug) regs ( PC: 00000) ( R4: 00000) ( R8: 00000) (R12: 00000) ( SP: 00000) ( R5: 00000) ( R9: 00000) (R13: 00000) ( SR: 00000) ( R6: 00000) (R10: 00000) (R14: 00000) ( R3: 00000) ( R7: 00000) (R11: 00000) (R15: 00000) 0x0000: 00000: d0 38 JL 0x01a2 00002: ab 97 fc 7f CMP @R7, 0x7ffc(R11) 00006: 00 00 BRA @PC 00008: 01 00 MOVA @PC, SP 0000a: 00 00 BRA @PC 0000c: 00 00 BRA @PC 0000e: 00 00 BRA @PC (mspdebug) regs ( PC: 00000) ( R4: 00010) ( R8: 00000) (R12: d368da60) ( SP: 00000) ( R5: 00000) ( R9: 00000) (R13: da4cce00) ( SR: 97ab33a8) ( R6: 00000) (R10: 00000) (R14: 00000) ( R3: 97ab3440) ( R7: 6884cb94) (R11: d368d560) (R15: 00010) 0x0000: 00000: d0 38 JL 0x01a2 00002: ab 97 fc 7f CMP @R7, 0x7ffc(R11) 00006: 00 00 BRA @PC 00008: 01 00 MOVA @PC, SP 0000a: 00 00 BRA @PC 0000c: 00 00 BRA @PC 0000e: 00 00 BRA @PC (mspdebug) regs ( PC: 00000) ( R4: 00010) ( R8: 00000) (R12: d368da60) ( SP: 00000) ( R5: 00000) ( R9: 00000) (R13: da4cce00) ( SR: 97ab33a8) ( R6: 00000) (R10: 00000) (R14: 00000) ( R3: 97ab3440) ( R7: 6884cb94) (R11: d368d560) (R15: 00010) 0x0000: 00000: d0 38 JL 0x01a2 00002: ab 97 fc 7f CMP @R7, 0x7ffc(R11) 00006: 00 00 BRA @PC 00008: 01 00 MOVA @PC, SP 0000a: 00 00 BRA @PC 0000c: 00 00 BRA @PC 0000e: 00 00 BRA @PC (mspdebug) run Running. Press Ctrl+C to interrupt... ^C ( PC: 00000) ( R4: d368da60) ( R8: 97ab38d0) (R12: 00000) ( SP: 6884d065) ( R5: da4cce00) ( R9: 00001) (R13: 00000) ( SR: 46505845) ( R6: d368da60) (R10: d366ee00) (R14: 00002) ( R3: d368d560) ( R7: 00001) (R11: d324db8c) (R15: 00000) 0x0000: 00000: d0 38 JL 0x01a2 00002: ab 97 fc 7f CMP @R7, 0x7ffc(R11) 00006: 00 00 BRA @PC 00008: 01 00 MOVA @PC, SP 0000a: 00 00 BRA @PC 0000c: 00 00 BRA @PC 0000e: 00 00 BRA @PC (mspdebug)
I got two boards and they behave the same way.
This all works with the old G2 launchpad and rf2500 driver.
Am I doing anything wrong? What's going on?
Thanks!
Of course I tried to load different programs, self-compiled and shipped with the examples, in ELF and TXT form, including a self-compiled `blink` example with modified delay value. Even after `erase`, LED continues to blink the same way.
As I said, my main problem is that mspdebug does not work (but pretends to). So I cannot load anything.
I get behavior described in my original post with mspdebug 0.22. Since then I tried the current mspdebug (0.25), with the same libmsp430.so built from slac460w.zip. The new version of mspdebug insisted on updating the FET firmware, failed, and now the board does not blink, shows as USB type 2047:0203 and I still cannot load any programs (bricked? I still have another board).
Bruce, you seem to get the board working, which version of mspdebug and which version of slac460 source did you use?
I cannot run CSS (TI says "does not work with this version of glibc, we are looking into this issue"), and I would rather not use GUI tools if I can help it.
I found "native TI" command-line tool www.ti.com/.../MSP430-FLASHER, that comes with its own (binary) copy of libmsp430.so. If I run it with it's included libmsp430, I have some better results:
- On the "fresh" board, MSPFlasher suggests to upgrade FET firmware, I do *not* agree, and then it works and can successfully load programs. Yay?
- I am reluctant to let it upgrade FET firmware lest my second board gets borked.
- When I run MSPFlasher with the slac460w copy of libmsp430, it cannot upgrade FET FW and cannot load programs.
- On the board that the slac460w copy of libmsp430 unsuccessfully tried to upgrade, MSPFlasher (with own libmsp430) tries to upgrade firmware, but fails. The board still does not work:
* -----/|-------------------------------------------------------------------- *
* / |__ *
* /_ / MSP Flasher v1.3.16 *
* | / *
* -----|/-------------------------------------------------------------------- *
*
* Evaluating triggers...done
* Checking for available FET debuggers:
* Corrupted USB FET firmware detected. Starting recovery.
# Exit: 49
# ERROR: MSP-FET / eZ-FET recovery failed
*
* ----------------------------------------------------------------------------
* Driver : closed (No error)
* ----------------------------------------------------------------------------
*/
UPDATE:
MSPFlasher_1.3.16 borked my second board (I accidentally allowed it to upgrade the FET firmware).
I installed MSPFlasher-1.3.16-linux-x64 downloaded from the TI site on a new Linux box (Ubuntu 16.04.3 LTS) without any pre-existing msp430 related software. I was able to load a few example programs to the launchpad, answering 'N' to MSPFlasher's prompt to upgrade the firmware. They worked. Then, I accidentally ran it with `-s` flag, it tried to upgrade the firmware, failed, and now fails to recover it.
First run:
* -----/|-------------------------------------------------------------------- * * / |__ * * /_ / MSP Flasher v1.3.16 * * | / * * -----|/-------------------------------------------------------------------- * * * 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. * Skipped firmware update prompt. ********************************************************* * * Initializing Update Bootloader. * Programming new firmware: * |||||||||||||||||||||||||||||||||||||||||||||||||| 100%# Exit: 49 # ERROR: MSP-FET / eZ-FET core(communication layer) update failed * * ---------------------------------------------------------------------------- * Driver : closed (No error) * ---------------------------------------------------------------------------- */
Subsequent attempts:
* -----/|-------------------------------------------------------------------- * * / |__ * * /_ / MSP Flasher v1.3.16 * * | / * * -----|/-------------------------------------------------------------------- * * * Evaluating triggers...done * Checking for available FET debuggers: * Corrupted USB FET firmware detected. Starting recovery. # Exit: 49 # ERROR: MSP-FET / eZ-FET recovery failed * * ---------------------------------------------------------------------------- * Driver : closed (No error) * ---------------------------------------------------------------------------- */
I even installed CCS on this box (it's an old distro so it did install), it also tries to recover the firmware, and also fails.
This time no self-compiled or third-party software was involved, only tools downloaded directly from ti.com.
TI support, please help!!!
FYI, there is a beta of CCS 7.4 which does work with newer distros:
http://processors.wiki.ti.com/index.php/Code_Composer_Studio_Beta_Downloads
I also ran into the corrupted FET firmware when I was going back and forth between Energia, CCS, and CCS Cloud. One of them was able to recover it, but I honestly can't remember which. So hopefully that means your board is not permanently bricked.
**Attention** This is a public forum