Thursday, April 30, 2009

Improving the MSP430 FET

by Travis Goodspeed <travis at>


To celebrate 4/30 day, I am happy to announce my own variant of the MSP430 FET debugger. My variant is compatible with a patched version of the original firmware, but my goal is to eventually have open firmware as well.

For an overview of the internal functioning of the original FET, see my three part series on Repurposing the EZ430, or torrent my 25C3 lecture on the same topic.

For the purposes of this discussion, a FET is any Flash Emulation Tool containing an MSP430F1612, including the FET UIF and EZ430 debuggers. The parallel-port FET operates differently and is outside the bounds of this discussion.

To follow along with this discussion, be sure to print the FET schematics from the relevant TI application notes. The FET UIF's schematic can be found on page 64 of SLAU138K. Version 1.0 of the EZ430U can found on page 12 of SLAU176B, while Version 2.0 can be found on page 13 of SLAU227B. As I've likely made a few mistakes in the write-up, please kindly inform me of them.

FT232 for TUSB3410

All present FETs use the TUSB3410 usb to serial converter. Support for this chip is a pain in Linux, with kernel module requirements varying often. It's so bad that I keep a script in my private svn repository for fixing support as quickly as possible, and despite the recent appearance of open FET clients, using them on an obscure operating system is impossible without kernel support.

Internally, the '3410 is an 8051 microcontroller with a USB 2.0 Full Speed (12Mb/s) peripheral and a single UART. The traditional FET and most other devices use this chip with its default usb/serial firmware, but the second-generation EZ430 firmware uses various tricks to make a second, bit-banged, asynchronous serial port to the debugging target. On Windows, this leads to reliability issues, and on Linux, this leads to utter incompatibility. The '3410 also requires several external components, complicated the design and making hand soldering less feasible.

The FT232R from FTDI is a perfect replacement. It is available in an SSOP28 package for easy soldering, every operating system on Earth supports it, and its only external components are decoupling capacitors.

Bootstrap Loader

The MSP430 Bootstrap Loader (BSL) and I have had some good times together. While I still consider it to be a security risk for locked devices, it's damned handy for an unlocked board such as the FET. Likely for historical reasons, the BSL runs on P1.1 and P2.2, rather than the hardware UART pins. It also requires a special reset sequence, in which the RTS and DTS serial lines are connected to the RST and TCK pins.

Early revisions of the FET did not connect the BSL I/O pins, making the software bootloader that I describe in my articles on the EZ430 necessary. (The FET and first-generation EZ430 share a flash bootloader, while the second-generation EZ430 has a different, larger bootloader.) While later hardware revisions of the UIF connect the BSL pins, I've not seen the masked-ROM BSL used in practice. My design supports the BSL, preventing bricking and allowing for TI's firmware and open firmware to be exchanged at a whim.

To program the board by BSL, use tos-bsl with the --invert-reset and --invert-test switches.


The MSP430F1612 was chosen for compatibility with the original FET. It has 55K of flash and 5K of RAM. Alternately, the MSP430F1611 with an identical footprint might be used for applications which require additional RAM but are willing to use less flash, at the expense of compatibility with the original chip. (MSP430 firmware grows upward from the bottom of flash memory, making it easy to port code from a device with less flash to a device with more, but difficult to port in the opposite direction.)

All custom firmware should be compiled to run in the intersection of memory of the two chips. In that way, most applications will run on either chip, with only those that need more stack depth requiring the 1611 and only those requiring more flash memory requiring the 1612.


The MSP430 supports both high-speed and low-speed crystals, with the low-speed crystal's frequency being multiplied. Stable timing is not necessary for synchronous protocols such as JTAG or Spy-Bi-Wire, but only for asynchronous serial communication. While the EZ430 and FET firmwares both demand high-frequency crystals for absurdly high serial baud rates, I expect to reduce the data rate and source an external low-frequency crystal to reduce the parts count.

It is also possible to use bit-banged serial, or to call bit-banging serial routines from the bootloader (BSL) ROM. The BSL's code is particularly elegant because it resyncs the timing with the 0x80 SYN byte. This byte in 8/E/1 (8 bits, Event parity, 1 stop bit) appears as 8 marks surrounded by spaces, so rather than being read it is measured. The measured width is right shifted three times to get a bit's width, then once more for a half-bit. This measurement is used to bit-bang one transaction, then a new measurement is made for the next transaction. In this manner, even without a crystal, the BSL is able to perform fast, reliable serial communication in spite of clock drift. By calling this code--which is already resident in each chip--crystal-free operation is possible.

A high-frequency crystal is required to run unpatched variants of TI's firmware, but I've decided against including one in the design at this stage. Perhaps this will change in the future.

I/O Pins

The first four pins of P5 are used as JTAG and SBW I/O. Starting with P5.0 and continuing to P5.3, they are TMS, TDI, TDO, and TCK. I've chosen to omit the FET UIF's optical isolation in favor of the EZ430's simpler protection, which consists of 47K pull up resistors and 100R current-limiting resistors. Unlike the EZ430, which only support spy-bi-wire, my design has a full 14-pin JTAG connector.

Firmware, Old

EZ430U Memory Map
The above image is the firmware of an EZ430U FET, generated by msp430static. 0x0000 is the bottom left corner, 0xFF00 the top left, and 0xFFFF the top right. Blue represents the target of an immediate pointer, black is empty flash memory, red is potentially executable code, and grey is information which is certainly not executable.

The image is composed of two parts. The upper red region is a bootloader which is used to reflash the chip, while the lower region does the actual work. As compilers ship with firmware upgrades, it is not necessary to distribute any copyrighted code. A replacement bootloader could accept a firmware upgrade, then patch it, while retaining software compatibility. More information on the bootloader can be found in Part 3 of my series on repurposing the TI EZ430U.

Firmware, New

Ideally, replacement firmware will be written for various applications, beyond MSP430 debugging. The same hardware could program competing microcontrollers, serial eeproms, FPGAs, and all sort of other things in the same way that the Hackaday Bus Pirate does.

So far as replacement firmware for debugging MSP430 chips goes, documentation is slim. Enough of the JTAG protocol has been documented to implement programming, but the setting of hardware breakpoints and other advanced features are not described by any public documentation. Custom firmware is not yet functional, but that ought to change in the near future.

Second Serial

The red board variants of the EZ430, those shipping with the RF kits, use drastically different firmware to facilitate a second serial port that connects to the target board. This breaks Linux compatibility, requiring firmware of both the MSP430 and the CAT24 EEPROM of the board to be downgraded.

To support low voltage serial communications, I brought out the second UART of the board's MSP430 to test points. This might also be used for timing attacks or similar things. Series and pull-up resistors would be nice on these lines, but they were omitted in the first design.


I've ordered a panel of the first revision, GOODFET10, and I'll send a board to anyone who is willing to assemble the device and help construct its firmware. Schematics, gerbers, and construction details have been posted to, and "hello world" firmware has already been committed to the subversion repository.


johnie said...

"the second-generation EZ430 firmware uses various tricks to make a second, bit-banged, asynchronous serial port to the debugging target.
On Windows, this leads to reliability issues"

What exactly are these reliability issues?

Travis Goodspeed said...

As of year ago, I recall from a conference that the Windows demos of the EZ430RF2500 kits would crash at random. This was blamed on the unreliability of the USB-to-target-board port, which is bit-banged by the TUSB3410's 8051 core. There was no problem using the kit as a debugger, so long as that was done in Windows.

This might have since been fixed, and it probably doesn't happen at lower baud rates. For reliable communications, make an error-tolerant protocol or use a dedicated FTDI USB to TTL-level UART cable.

(The serial pins on my board are intended for operations where an FTDI chip alone won't suffice, such as odd baud rates and auto-detection of baud rates. For anything else, use a dedicated cable.)


X-Istence said...

Would it be possible for you to make a blog post so that people like me who are having trouble following along with the various pin descriptions and firm wares and software that is out there to use the device to program our MSP430's?

I am currently using the Windows software to program my EZ430RF2500 kit that I got for free at one of Ti's 430 days here in Phoenix, but would prefer to either do it in FreeBSD, Mac OS X or Linux so that I don't have the need to keep a Windows machine around.

If I am asking the wrong person, or such documentation already exists, please feel free to smack me over the head!

Thank you,
Bert JW Regeer

Travis Goodspeed said...

Howdy Bert,

I tried to write a tutorial on using the RF2500 kit in Linux, but it eventually became four articles and a lecture on reverse engineering it!

Your RF2500 kit is not compatible with Linux because of the way in which its TUSB3410 chip is abused. To get around this, you will need to reflash both the MSP430 and CAT24 I2C EEPROM with images from an EZ430F2013 programmer. Alternatively, $20 will get you an EZ430F2013 kit that can program the RF2500T target boards.

If you have an old Windows machine, you might consider running gdbproxy.exe on it, then do everything else (compiling, debugging) from a Linux machine. Just point gdb at the Windows host instead of localhost. This has the added advantages of working with the RF2500 and those which which are not yet supported by gdbproxy in Linux.

For a good introduction to designing and programming a simple device with the MSP430F2013 kit, see Leah Shanker's Calculator Project article. Her code is for IAR, but it's easily ported to GCC.

Google for a toolchain article, as plenty has been written on that subject. Just keep in mind that the TUSB3410 is very finicky, and that support for it breaks with every other Linux kernel revision.

Hope this helps,

Arash said...

Hi Travis,

Thanks for the great stuff that you have put up. I'm also playing with these ez430-rf2500 development kits and actually I don't mind programming them through a windows machine. I only need to use the serial interface to dump the data stream to the Linux machine.

My question is if I buy the EZ430F2013 kit will I be able to access the serial interface?

Thank you,

Travis Goodspeed said...


The EZ430F2013 kit does not support the serial port to the target board, even in hardware revisions with the pins to do so. Instead, use a 3V FTDI usb/serial cable.


Arash said...

Hi Travis,

Thanks for your response. I'm still struggling to get this thing working. I bought and installed a RS232 pccard on a Ubuntu desktop machine. I tried to connect the ez430-rf2500 usb connectors with the mote plugged in using few different usb to serial converters. I also needed to use couple of gender changers to connect things which shouldn't be a problem. The first thing I tried to test was to see if this setup will even power up the mote and it failed. I have a simple program which would turn on the LED when the button is pushed which works when I connect it to a regular usb port.

I'm not sure if these adapters are using ftdi chips so I have ordered a usb-serial converter with ftdi chip to test that as well. I'm not sure if that is the cause of my problems.

Do you have any hints of what I'm doing wrong? Any recommendations?

Thanks and best,

Travis Goodspeed said...

Howdy Arash,

RS232 uses the wrong voltages and inverts the signal. In RS232, a 1 is -10V and a 0 is +10 while the MSP430 requires a 1 to be +3.3V and a 0 to be 0V.

The cable you want is from FTDI, and it's part number is TTL-232R-3V3-PCB.


voidlizard said...


Is the GOODFET11 compatible with msp430-gdbproxy or msp430-jtag tools?

I faced the problem, that mspgcc toolchain does not support for 54XX MCU's, now I'm finding the way to work with them under Linux.

Is it realistic to use GOODFET for this purpose at the moment? At least just for uploading firmware into MCU's.

frogman said...

Here are some minor updates and corrections to the TI application note references:

FET UIF schematic - pages 64-67 of slau138k.pdf

EZ430U (rev. 1.1) - pages 10 & 11 of slau176b.pdf

EZ430U (rev. 2.0) - pages 16 & 17 of slau227e.pdf

laba xiao said...

this is very nice, however, I am wondering if the MSP430 launchpad can be really as hardware ported to be GoodFET JTAG, my question is how, because the chip MSP430F16x is already there, and TUSB3410 chip also there.

thanks for help anyway.

laba xiao said...
This comment has been removed by the author.