Friday, September 4, 2009

State of the GoodFET

by Travis Goodspeed <travis at>

GoodFET20 in Black

I shipped the last of the American GoodFET20 requests today. Please contact me if yours hasn't arrived. Orders to Europe will be sent next week, while I'm in Paris, Besançon, and Stockholm.

I'm now using the MSP430F2618 for GoodFET development, as it will run at 16MHz without a crystal. There are some bit errors on a few of these boards, owing to the accidental erasure of Info Flash by the bootloader. Until rebroadcasts are implemented, continue to construct your boards with the 1612 or 1611. The upcoming GoodFET30 will migrate the project entirely to the 2xx series, breaking compatibility with TI's firmware.

The Python clients are presently being refactored at the same time as the command structure is combined. Please contact me if you are interested in building a client for C# or Cocoa that will be easier to distribute.

Thanks to a generous EVK donation, MSP430X2 support is underway, which will allow such chips as the MSP430F5438 and the CC430 Zigbee SoC devices to be programmed. I've got the basics working, and full support for writing Flash memory ought to be ready rather soon.

I'm considering a plugin architecture that loads new modules into RAM, a GoodFET iPhone attachment, and all sorts of other crazy things. Comment with any feature requests below.


X-Istence said...

Hey Travis,

We spoke at Black Hat and DefCon, I was telling you about the MSP430F2418 which is what I am currently using.

I had the issue that the bsl program written in Python was overwriting Flash segment A which means that all of the calibration data that Ti programmed in when they shipped the chips is gone.

How have you solved that issue? As far as I am aware the 2618 and the 2418 are practically the same ...

For now I have just added a routine to my code that initializes the DCO against the 32 kHz crystal. However if I could do without the crystal and still get a stable clock speed of 1 Mhz or more I could lower the cost of my design significantly.

I look forward to the new improvements made to the GoodFET's, I have my GoodFET 1.1 built, I still need to check that GoodFET 2.0 you gave me. The permanent marker did not come off the board with the nail polish remover I had, so I am not sure if all the parts will work when soldered to the board, and I don't want to use chemicals that are too abrasive for fear of damaging the board!

Bert JW Regeer

Travis Goodspeed said...

Howdy Bert,

For the 2618, I've hard-coded the DCO calibration from an early unit when the Info flash is missing, and I've been saving Info flash images to later plot the deviation and mean timing values. All 2618/F chips seem to be compatible at 16MHz and 115,200 baud with the hardcoded values. (An article on that subject is nearly ready, expect it here within a week.)

You can dump a TI Text file of your FET's Info flash using `make dumpinfo` in the goodfet/trunk/firmware directory. Run this before erasing the chip, and you'll be able to reflash it before the GoodFET firmware to keep things compatible.

If you email me your mailing address, I'll send you some of the fresh GoodFET20 boards that have just arrived. An LF crystal calibration routine for the 2xx chips would also be handy; consider sending a patch to msp430x2618.c.


Travis Goodspeed said...

The one argument against the 2274 is that it hasn't got enough RAM to support loadable modules. The 2618 and 1611 can run all of the GoodFET application from RAM.


X-Istence said...


Have you had any issues by using the values from a different chip? When I went to the MSP430 day here in Phoenix I was under the impression that they tested and everyone and wrote the specific values into the flash segment A.

As for the DCO calibration, for now I have just taken the sample code that Ti has available on their website and taken just the DCO initialization routine, without the Flash A writing. I was thinking of maybe putting that back in, so that my chip only has to run the calibration once so I can ship the design without the crystal, but that makes re-programming harder for future flash upgrades for the customer as now they need to solder in a crystal for the board to work right...

I don't mind adding in the code to re-flash Flash segment A with the appropriate bits, and sending a patch.

Loadable modules sounds like an interesting addition to the GoodFET firmware. Within the following weeks when I get some time I will svn up to the latest version of the repo and start hacking away.


Travis Goodspeed said...

Howdy Bert,

The Info values are unique to each chip, but within a chip model number and revision the variance seems to be low enough to allow for reliable communication. I have a small collection of Info backups on which I intend to run some simple statistical tests, but in practice, my hardwired values have worked for every MSP430F2618 Rev. F chip that I've tried.

To extract the Info values from a programmed GoodFET, run "goodfet.monitor peek 0x1000 0x10FF". Very soon, I'll have the upgrade tool check for this information by the BSL.


Tenta said...

Hey Travis,
These boards look great! Who did you use for the PCB manufacturing?

Blogger said...

There is a chance you are eligible to receive a Apple iPhone 7.