The TI MSP430 Launchpad is a cheap MSP430 development board – about £3 when they first came out, although a bit more now. I think mine was a freebie from a distie. Although I quite like the MSP430 I do tend to use either AVR or some kind of ARM for most of my projects, so it hasn’t really seen much use.
The built-in emulator consists of a TUSB3410 and an MSP430F1612, pre-programmed with TI’s own MSP430 “FET” debugger. My aim here is to end up with a debugger that I can use with TI’s CC1110 chips used in the Ciseco SRF. The GoodFET project can talk to these using its Chipcon module, and this has at some point in the past been made to run on the Launchpad.
Building GoodFET
The code for the TI Launchpad doesn’t work in GoodFET SVN HEAD (or any other version I tried). However, I was able to make it work, at least for the Chipcon application, with a couple of tweaks contained in this patch. It would be nice to get SBW support working as well so it can also be used as an MSP430 programmer, but this is a job for later. Apply the patch to revision 1558 of GoodFET as follows:
$ svn co -r 1558 https://goodfet.svn.sourceforge.net/svnroot/goodfet/trunk goodfet $ cd goodfet $ wget http://www.mike-stirling.com/files/goodfet-r1558-launchpad.patch $ patch -p0 <./goodfet-r1558-launchpad.patch
And build:
$ cd firmware $ board=tilaunchpad make
The output ‘goodfet.hex’ can be found in the current directory.
Programming
Reprogramming the 1612 could be done using another MSP430 debugger, such as another Launchpad board, but I only have the one and I wanted a quick solution. The 1612 includes TI’s Boot Strap Loader (BSL) in ROM. This can be accessed via a serial port on some random non-UART pins that don’t connect to anything on the Launchpad. They can be picked up from the chip itself with some thin wire and a steady hand. I terminated them on a 6-pin header for connection to an FTDI TTL-232R-3V3 lead. The ground can be picked up from a test point next to the USB socket.
This is the pinout:
Launchpad | FTDI pin |
---|---|
TP3 (GND) | 1 |
MSP430F1612 pin 22 (from PC) | 4 |
MSP430F1612 pin 13 (to PC) | 5 |
This is almost all that’s required, except for the secret handshake needed to actually enter the BSL in the first place. Most BSL software expects to do this for you by driving RTS and DTR, but the serial lead doesn’t have DTR in this case. Instead, the two buttons on the board can be used to invoke the BSL manually. One side of each button is grounded, the other is connected to the target socket. Connect one wire from the ungrounded side of one button to TP2 (/RESET), and the other button to TP4 (TCK). To invoke the BSL the following procedure is used (it may take a few attempts):
- Press and hold the button connected to /RESET
- Press and release the TCK button
- Press and hold the TCK button
- Release the /RESET button
- Release the TCK button
The GoodFET hex file can now be loaded into the 1612 via the serial port. I did this on Linux using the Python MSP430 tools (‘python-msp430-tools’ on Debian/Ubuntu-like systems). ‘mspdebug’ doesn’t seem to work because its BSL support is only for 5xx and 6xx series chips.
$ msp430-bsl -p /dev/ttyUSB0 -eEPV goodfet.hex
Once complete, reset the Launchpad and check that it enumerates as a USB serial port (/dev/ttyUSBx). On Linux Mint I had problems with modem-manager holding the port open and messing with the control lines. This is solved by adding the following rule in /etc/udev/rules.d/10-local.rules:
# Blacklist TUSB3410 for modem-manager ATTRS{idVendor}=="0451", ATTRS{idProduct}=="3410", ENV{ID_MM_DEVICE_IGNORE}="1"
To test GoodFET (using the tools in the GoodFET SVN working copy):
$ cd client $ ./goodfet.monitor info # DEBUG Warmstart GoodFET with f16c MCU Clocked at 0x0460
Chipcon
A CC1110 or CC1111 (or probably their 2.4 GHz cousins as well) can now be connected to the Launchpad programming header as follows:
Launchpad pin | Chipcon Debug pin |
---|---|
TEST | DC (debug clock) |
RST | DD (debug data) |
RXD | /RESET |
TXD | No connect |
Obviously the jumper links connecting the emulator to the target socket need to be removed for this, although leaving the Vcc jumper in place is a good idea as it allows target power to be drawn from the three pin header in the bottom corner.
You can check connectivity using:
$ ./goodfet.cc info # DEBUG Warmstart # DEBUG ccsetup # DEBUG done ccsetup # DEBUG ccsetup # DEBUG done ccsetup # DEBUG ccdebuginit Ident cc1111/r1103/ps0x0400 Freq 800.000 MHz RSSI 00
What to do next is a topic for another post!
Downloads