I bought myself a new toy – MSP-EXP430FR5739 experimenter board. It didn’t stay working long because I ran into the same trouble like the guy here. Mspdebug was complaining about blow fuses. Fix was quite easy thanks to my another toy MSP-EXP430G2 LaunchPad which I luckily bought together with the experimenter board.

First of all I was confused at the beginning by no ability to load any program at all. It failed on erasing the chip. Solution: do not use programming command

$ mspdebug rf2500 "prog test.elf"

but use

$ mspdebug rf2500 "load test.elf"

because FRAM chips don’t need erasing.

After few loading rounds the big trouble appeared. It took me some googling to find this discussion. This clever guy Donald created a simple program for LaunchPad to use BSL to mass erase the experimenter board. I tried to compile and load the program on my own but without success. The red LED always stayed on. I tried it with and without soldered crystal, both failed. Then I used Donald’s prebuilt binary with soldered crystal and it worked.

Now I will wait how long it will take to break again.

Update 2012-02-09

It didn’t take very long to jam again. Actually it took about 5 rounds of programming. My frustration was huge. After lots of another trials and failures I stumbled on a little code in mspdebug/drivers/fet.c:

/* This packet seems to be necessary in order to program on the
 * MSP430FR5739 development board.
 */
if (xfer(dev, 0x30, NULL, 0, 0) < 0)
  printc_dbg("fet: warning: message 0x30 failed\n");

At least in my case it is not neccessary. I removed the code, experimenter board programming works fine and it does not jam any more. What a lucky shot 🙂

Update 2012-02-12

Well, card is blocked again. But this time it takes much more programming cycles then before. Better than nothing. Stay tuned.