Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


Code::Blocks + mspgcc

This toolchain allows MSP430 development without restrictions. Installation consists of:

  • mspgcc compiler backend installation
  • mspdebug bridge to your msp430 debuging adapter
  • codeblocks installation

Mspgcc is not tied to any IDE. An important criteria of IDE is how well it handles project in subdirectory vs root directory of source tree.
Mspgcc before 20120311 had gdb problem of incorrect display of local variables. Use this release or most recent.

Code::Blocks uses stdin/stdout to interface to GDB debugger. The GDB/MI (machine interface) should be a more effective method of using GDB from an IDE. You will have better luck with eclipse_mspgcc, and feels much like TI CCS.
Please edit this wiki, If anybody knows why to use stdin/stdout to GDB from IDE instead of GDB/MI protocol.

Latest HowTo

Here is a HowTo, for Windows/Linux/Mac, that was inspired by the original instructions below. It is documented inline as and addendum to this wiki article.

MSPGCC Windows Install

Recommended to use these prebuilt packages.

MSPGCC Linux Install

Your linux distribution may have mspgcc in its repositories, but it may be too old to support cc430 devices, therefore it is recommended to follow these build instructions to build the current mspgcc toolchain for your linux installation. It is best to avoid mspgcc releases from 2011 (or prior), as they require extensive patching.


If your FET shows up as /dev/ttyUSB0 in linux (or CDC device in windows), then it is most likely running v2 firmware (use uif protocol). If your FET shows up as /dev/ttyACM0 in linux (or VCP device in windows), then it is running v3 firmware. Notes:

  • You may not be able to get mspdebug-0.18 working in Windows if your FET had old firmware. The solution is to use CCSv5 to upgrade the FET. You may do this with the free, 16KB-limited version of CCSv5, simply by loading a small example project. CCSv5 will update the FET before loading the program.
  • Once the FET is upgraded (see above), mspdebug can function with the FET (using tilib protocol), and you can –allow-fw-upgrade if it requests so.
  • Alternatives to the TI FET tool are the Olimex FETs, such as the MSP430-JTAG-ISO.

MSPDEBUG Windows Install

Follow these instructions for building mspdebug on windows.

  • Test-run mspdebug:
    mspdebug [-j] <driver> -d <COMn>
  • If you have a v2 FET, try uif driver, for v3 use tilib

MSPDEBUG Linux Install

  • If you have a FET with v2 firmware, try uif protocol with /dev/ttyUSB0, and dont concern with
  • If you have FET with v3 firmware, use tilib protocol and follow build instructions for
  • Recent linux distributions likely have in boost-devel package, requiring this small edit in the Makefile.

Special consideration for on x86_64 builds as 32bit at this time (as distributed, with -m32). Recommended to build 64bit for x86_64: remove -m32 from CFLAGS and then change size_t argument in FileFuncImpl::getTiFileBytes() to uint32_t.
reference: mailing list post

Linux udev

To allow accessing the programmer in user mode, create a file called 71-persistent-msp430.rules and write into it:

ATTRS{idVendor}=="2047", ATTRS{idProduct}=="0010", MODE="0660", GROUP="plugdev" #v3 FET
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE="0660", GROUP="plugdev"
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", MODE="0660", GROUP="plugdev" #v2 FET
ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="0008", MODE="0660", GROUP="plugdev"
ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="0031", MODE="0660", GROUP="plugdev"

To effect this change, as root (sudo):

udevadm control --reload-rules
  • If permissions of /dev/ttyACM0 (or ttyUSB0) arent allowing user access, mspdebug says “MSP-FET430UIF is already in use (error = 58)
  • use MODE=“0666” if you want access as any user

CodeBlocks IDE install


Download from codeblocks download page


The repository for your linux distribution likely has recent/usable codeblocks packages. apt-get or yum install as appropriate.

CodeBlocks setup for msp430

Open C::B, if a compiler named “GNU GCC Compiler for MSP430” does not exist in the list that pops-up, open the Settings → Compiler & Debugger menu, select the “GNU GCC Compiler”, press the COPY button, and name the new compiler “GNU GCC Compiler for MSP430”.

Since you already (or now) have “GNU CC Compiler for MSP430”, open the Settings → Compiler & Debugger menu, and select the “GNU GCC Compiler for MSP430”. In the “Toolchain Executables” tab, fill in the fields as follows:

  Compiler's installation directory (such as c:\mspgcc or /usr/local)
  C Compiler                  msp430-gcc
  C++ Compiler                msp430-gcc
  Linker for Dynamic Links    msp430-gcc
  Linker for Static Links     msp430-ar
  Debugger                    msp430-gdb
  Resource Compiler           -
  Make Program                make

Save, you are now ready to launch a C::B project from your OT repository. You might additionally want to remove some toolbars from the main window (for example View→Toolbar→Code Completion) or download useful plugins (for code stasts, incremental search, etc). For the latter, Google is your friend…

Important : to keep editor compatibility with Linux, in Settings→Editor, set the end-of-line mode LF (this will keep all files in UNIX mode).


In the “Additional Path” tab, add path /usr/local/msp430.

If you have Environment Variables plugin installed into codeblocks:In Settings→Environment…→Environment variable, add (for bash)


or just put that in your .bashrc

The exact command may depend on your shell. You are now ready to launch a C::B project from your OT repository.

Codeblocks project creation and compiler flags

File → New → Project
Select template: Empty project
include path: Project → Build Options → Search directories

Custom Linker Script for MSP430

A custom linker script is required to place OpenTag filesystems at the correct location.

  • The common linker script msp430.x includes two files specific to the chip youre using: periph.x and memory.x
  • GNU ld manual states that INCLUDE command in linker script will load from current directory, which in this case is project directory. This means you can copy the default memory.x for your processor thats included with mspgcc, into your project directory.
  • memory.x in project directory will override the deafult. You can modify your memory.x in project directory to suit the needs of dash7 filesystems.
  • To see the sections placed correctly, and to see total size of code, add -Wl,-Map,<project>.map to project build options → linker options

mspgcc Compiler/Linker Flags

Project → Build Options →

  • -mmcu=<your-cc430> (cc430f6137 etc)
  • speed otimzations: -O1, or -O2 etc.
  • size optimzations: -Os
  • strip unused functions: -fdata-sections, -ffunction-sections to compiler, and to linker: -Wl,–gc-sections
  • to see stripped sections, add linker option to output map file instead of -Wl,–print-gc-sections cluttering build log.


Once you have installed all the mspgcc toolchain, including mspdebug and codeblocks, you are ready to compile and debug by executing the following steps:

  1. Open a C::B project and compile it
  2. Launch mspdebug in a terminal with the parameters of your programmer and for msp430-gdb: mspdebug [-j] <driver> “gdb” -d <device>. For example:
    mspdebug tilib gdb -d /dev/ttyACM0  # if your in linux with v3 USB FET 
    mspdebug tilib gdb -d COMn  # if your in windows with v3 USB FET

mspdebug will be connected to your FET and lisenting on local port 2000.

  1. Start a debug session (launch the debugger from the C::B debug toolbar). This will call msp430-gdb and display a logger window and a command prompt in the C::B main window. In the command prompt connect to mspdebug on localhost (or if you are accessing a distant machine, replace :2000 with ip_addr:2000) :
    target remote :2000

    careful about cursor focus into the command prompt.

  2. Now erase the flash and load your code:

Start the session by using the button of the toolbar or type:


To reset the target:

monitor reset

At this time flushregs is a workaround to update msp430-gdb after target reset. You could also have a breakpoint at main(), so when you continue after monitor reset msp430-gdb would know.
You may also debug the target by running msp430-gdb on the executable in your own console. gdb manual


by default, mspdebug quits after gdb closes connection. To keep mspdebug running, put into your ~/.mspdebug:

opt gdb_loop true

then you don't need to put gdb on mspdebug command line.


Probably not recommended at this time due to USB driver instability for MSPDEBUG. See discussion.

However, MSPGCC has been successfully demonstrated on certain Mac OS X systems. The best way to obtain it is via macports, which maintains a packages for mspgcc, mspdebug, and all other components.

Latest HowTo

User Yyrkoon from has spent time revising this Code::Blocks + MSPGCC setup, and there is a video-based set of HowTo instructions posted on the forums.

opentag/tools/codeblocks_mspgcc.txt · Last modified: 2013/05/27 20:14 by jpnorair