I’ve been thinking about making a small msp430fr5739 based breakout board. I was hoping to use the msp430 launchpad to program them. However, I hit a major snag in that the LP version 1.4 doesn’t seem to recognize the msp430fr5739 as a valid device. I could use an FRAM board, at about ~$35, to program them but not the $10 launchpad. As I was pondering all this, there was a lot of hubbub about the new msp430g2955 chips. Then it struck me, why should Texas Instruments devices be the only ones that can program my chips? I can do this myself.
I first looked at the boot strap loader BSL protocol built into some of the msp430 chips. I quickly got discouraged trying to find a client that works on windows, linux, and OSX. I really wanted to avoid writing and supporting any host side programs. BSL also had other issues. It isn’t supported on all the chips. Often the BSL serial pins are different than the normal UART pins. It takes 4 pins to use BSL so using low cost usb serial dongles would be a problem. My final conclusion was that using BSL would just end up being a hassle.
These issues lead me to thinking about using gdb and its Remote Serial Protocol (RSP). GDB is a mature program and binary versions are readily available for all host platforms. If you use msp430-gdb and mspdebug, you already use RSP. With mspdebug, it just happens to run over a local TCP/IP socket. However, an often unnoticed feature of the RSP protocol is that it can also be used with a regular serial port.
I have some experience with gdb remote serial protocol from working with the Stellaris Launchpad. The ICDI interface on that board provides a gdb stub server that uses usb endpoints as the ‘S’erial part of RSP. Unfortunately, gdb remote can’t use it directly as it doesn’t know anything about low level usb endpoints.
I decided to to take a simpler approach. I wanted something that is small and can stay resident on the msp430 chip. I decided it should use standard asynchronous serial so it could interface directly to gdb. I wanted to use as few pins as possible so it could be used with really dumb usb to uart modules. The logical choice was to implement a native gdb stub server that installs in high memory of the msp430 chip. Think of this app as a bootloader that happens to use the gdb’s RSP.
Once the stub is installed on the msp430 chip, new programs are loaded on the chip without the need for a launchpad or an expensive FET430-UIF programmer . All that is needed is a USB to serial port dongle. You can find these on ebay for about $2 to $10. They all go faster than the 9600 baud the virtual serial port the msp430 launchpad provides. It is likely you probably have one of these already. The one downside is that this scheme doesn’t allow you to debug using msp430-gdb. However, it does provide a way to load new code without having to deal with BSL or having to write any host side code. This scheme is used by the Arduino project quite successfully, in spite of its limitations.
First step is to load the gdb_bootloader on your chip one time. Once you have done this, you could remove the msp430 chip from your launchpad and throw it on a breadboard. All it needs is power, decoupling caps and a pull up resistor. Connect the TX and RX pins of the chip to the serial to USB converter (ftdi, cp2102, pl2303hx, etc..). For simplicity, we can just test with the launchpad itself and ignore the fact that there is an on-board FET and just use it as a serial device, /dev/ttyACM0 on linux or COM1: on windows.
At reset time, the code looks at the state of the P1.3 button on the msp430g2553. If you are holding it down, the code starts a gdb bootload/server running on the msp430g2553. On your linux box, just start up msp430-gdb to connect to the chip over a serial port. You can’t debug, but what you can do is erase your flash and load a new program. The gdb server code sits at memory 0xfa00 -> 0xfdff so you do lose some of your flash.
Loadable hex file:
The gdb_bootloader.hex file from the source tree must be loaded on an msp430g2553. To load the gdb_stub firmware ( do this one time )
$ mspdebug rf2500 "prog gdb_bootloader.hex" MSPDebug version 0.21 - debugging tool for MSP430 MCUs Copyright (C) 2009-2012 Daniel Beer <firstname.lastname@example.org> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Trying to open interface 1 on 057 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire fet: FET returned error code 4 (Could not find device or device not supported) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Sending reset... Device ID: 0x2553 Code start address: 0xc000 Code size : 16384 byte = 16 kb RAM start address: 0x200 RAM end address: 0x3ff RAM size : 512 byte = 0 kb Device: MSP430G2553/G2403 Number of breakpoints: 2 fet: FET returned NAK warning: device does not support power profiling Chip ID data: 25 53 Erasing... Programming... Writing 970 bytes at fa00... Writing 32 bytes at ffe0... Done, 1002 bytes total
OK. Once you have that installed, you no longer need to use your launchpad. To load programs on your chip now, just connect a USB to serial dongle up to the msp430g2553 directly and connect to that via msp430-gdb. Here are the steps to load a blink program using msp430-gdb via the serial port:
$ msp430-gdb -b 9600 -ex 'target remote /dev/ttyACM0' blink.elf Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home2/kimballr/github/msp430_code/fabooh/examples/basic/blink/blink.elf...done. Remote debugging using /dev/ttyACM0 _reset_vector__ () at ../../../gcc/gcc/config/msp430/crt0.S:103 103 ../../../gcc/gcc/config/msp430/crt0.S: No such file or directory. in ../../../gcc/gcc/config/msp430/crt0.S (gdb) erase Erasing all flash memory complete (gdb) load blink.elf Loading section .text, size 0x96 lma 0xc000 Loading section .vectors, size 0x20 lma 0xffe0 Start address 0xc000, load size 182 Transfer rate: 264 bytes/sec, 16 bytes/write. (gdb) quit A debugging session is active. Inferior 1 [Remote target] will be killed. Quit anyway? (y or n) y
Good, now there are two things on your msp430g2553 chip. At memory address 0xfa00 there is the bootloader, it is run first before your blink.elf code. At reset, it checks the button to see if you are holding it down. If not, then it runs the blink.elf code. If you are holding it down, it runs the gdb server instead and allows you to reload code. So just press reset to start the blink. Press and hold the P1.3 switch down and press reset to start the gdb stub server.
The code is written in C++ using the fabooh framework. I’ve been trying to find a good app to use as the fabooh debut project. I think this will be it. This type of code needs to be small but needs the flexibility to use various UART implementations. This code personifies what fabooh does well.
In future posts, I’ll use this application to describe the features of the different FabOoh template classes.
Note: The version of the code only works with the msp430g2553.
Pretty simple huh? I think so.