I got an MSP430 Launchpad in the mail a couple of days ago. So I’ve been playing with that the last couple of days. The first day I went through the tools on the wiki and grabbed both IDE’s and all the downloadable links I could. This had to be done on Windows since it’s the only platform they support. Being a Linux user 99% of the time, I wasn’t too pleased with this situation, so I investigated the tools available for Linux, and that’s what I did all of yesterday.

First, I searched the Arch Linux repos (including AUR) for MSP430 related tools. I used yaourt and searched for both msp & msp430. I compiled and installed the compiler, the C library, and two debuggers (more on this later.) After these were installed I grabbed the source to the temperature demo that comes preloaded on the chip. First thing I had to do was change the source in order for it to build with msp430-gcc. The changes were trivial and it didn’t take too long to get it compiled. What took me the longest time was trying to figure out if I needed to define what mcu I’m using. After a bit of research I fired up the debugger, erased the flash, reflashed, and did some light debugging.

Now, for how it’s done. The packages you’ll need are as follows: Updated 2012-06-13

binutils-msp430 2.21.1-2
gcc-msp430 4.6.3-1
msp430-gdb 7.2-3
msp430-libc 20120224-2
msp430mcu 20120406-2
mspdebug 0.8-1

If you’re using a distro other than Arch, it’s up to you to figure out how to get and/or build the programs from the source. If you’re using Arch, you can obviously use the AUR packages with ABS. If you’re an i686 user you can grab my prebuild binaries if you’d like from here1. Now that you have a toolchain, I’m sure you’ll want to test it out. Grab my “ported” temperature demo2.UPDATE The here’s the fully working temperature demo.3 You’ll need to extract it, fire up a terminal, go to that directory, and you should be able to just type: make. If all goes as planned, you’ll have main.elf in that directory. So now it’s time to try it out, fire up mspdebug. The actual command is probably going to be something like: sudo mspdebug -R. Permissions on the USB device might be able to be changed so it doesn’t have to be run as root, but for me and for now, it’s not too big of a deal. You should get something like this:

sudo mspdebug -R
MSPDebug version 0.8 - debugging tool for MSP430 MCUs
Copyright (C) 2009, 2010 Daniel Beer daniel@tortek.co.nz
This is free software; see the source for copying conditions.  There is NO
Trying to open interface 1 on 027
FET protocol version is 30066536
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
Device ID: 0xf201
Device: MSP430F2013
Code memory starts at 0xf800
Available commands:
    =        erase    hexout   mw       read     run      sym
    cgraph   gdb      isearch  opt      regs     set
    dis      help     md       prog     reset    step
Available options:
Type "help topic" for more information.
Press Ctrl+D to quit.

You’re now ready to do some damage!. First, let’s just erase the flash. Just type: erase.

(mspdebug) erase

If you’d like to check that the flash is indeed erased, try this:

(mspdebug) dis 0xf800 2048
    f800: ff ff ff ff         AND.B   @R15+,           0xffff(R15)
    f804: ff ff ff ff         AND.B   @R15+,           0xffff(R15)
    f808: ff ff ff ff         AND.B   @R15+,           0xffff(R15)
    fff4: ff ff ff ff         AND.B   @R15+,           0xffff(R15)
    fff8: ff ff ff ff         AND.B   @R15+,           0xffff(R15)
    fffc: ff ff ff ff         AND.B   @R15+,           0xffff(R15)

As you can see, the entire 2kb of flash is erased. So, now that it’s all gone, and the original demo lights turned off (because the program that was running was toasted) we’ll want to load our built program into flash:

(mspdebug) prog main.elf
Writing 128 bytes to fc00...
Writing 128 bytes to fc80...
Writing 128 bytes to fd00...
Writing 128 bytes to fd80...
Writing 128 bytes to fe00...
Writing   8 bytes to fe80...
Writing  32 bytes to ffe0...

As you can see, erasing the first time was most likely not needed. Now we’re ready to fire up GDB:

(mspdebug) gdb
Bound to port 2000. Now waiting for connection...

At this point you’ll want to fire up another terminal, browse back to the source directory, and do:

msp430-gdb main.elf
GNU gdb (GDB) 7.0.1
Copyright (C) 2009 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:
Reading symbols from /home/harley/Source/msp430/MSP-EXP430G2-Launchpad/main.elf...done.
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
0x0000fc00 in _reset_vector__ ()

Basically, start up msp430-gdb with main.elf, set the target to a remote machine (in this case localhost at port 2000), and msp430-gdb and mspdebug do some magic, and you’re ready to start debugging. Since you’re debugging a remote target, remember you “continue” instead of “run.”

There you have it, you should be in pretty good shape to start experimenting with the MSP430 Launchpad on Linux.

Addendum: Big thanks to Henry von Tresckow (hvontres) who fixed the temperature demo to fully work with mspgcc. I’m yet to test it, but his changes look convincing enough. I’ve tested the changes and they seem to work fine. Here’s the [updated temperature demo][3] (updated 2012-06-13.)

Update: Added msp430mcu as a required package. Thanks Frankie Robertson for pointing that out in the comments. 🙂

  1. broken link ↩︎

  2. broken link ↩︎

  3. broken link ↩︎