Debugging with GDB, mspdebug and TI MSP430-GCC

It has been a while that I wanted to have the option of using gdb instead of mspdebug. Don’t get me wrong, mspdebug is excellent, but sometimes it helps to have a bit more powerful and mature debugging tools. When I first investigated using mspdebug along with gdb in a server/client setup, I ran into a connection problem which I did not have the time or the desire to solve. I pretty much just gave up, that is until [yeltrow] wrote to me and told me how he got it working. He even has a nice write-up about it here. I couldn’t resist, I had to try this out ASAP. So I got to work following his instructions but unfortunately ended up with the same error. I updated my compiler to the latest version – still no luck. Finally, I realized that my mspdebug was version 0.22 while his was 0.23. Could this be it? Well, turns out this latest version hasn’t been updated on the Ubuntu repositories. This time, I am not giving up. So I compiled it from source. Luckily it’s really quick and simple.

  1. Remove the old version of mspdebug
    sudo apt-get remove mspdebug
  2. Clone/download the mspdebug repository from here
  3. Install readline devel – this is for command line autocomplete, history etc…
    sudo apt-get install libreadline6-dev
  4. Compile
    make
  5. Install
    make install

After updating mspdebug to the latest version, success!!

Before you start debugging, you absolutely must modify the CFLAGS in the makefile to include the compiler flags [yeltrow] figured out worked. Those would be:

  • -O0: turn off optimizations
  • -g3: include the highlest level of debugging information
  • -gdwarf-2: set the debugging information format to dwarf 2
  •  -ggdb: produce debugging information for gdb

So now your CFLAGS should look like this:

CFLAGS:= -mmcu=msp430g2553 -mhwmult=none -c -O0 -g3 -ggdb -gdwarf-2 -Wall -Werror -Wextra -Wshadow -std=gnu90 -Wpedantic -MMD -I$(INC_DIR)

The makefile has been updated in the github repository so you can just pull and the changes will be there. Now we need to do a rebuild to make sure all the debugging information is included.

make clean && make

Start mspdebug as we normally do and program the the application to the board. Instead of running the program from mspdebug, you will start the gdb server by typing the command ‘gdb’. This starts the server on port 2000 of localhost. The job of the gdb server is to translate gdb commands into hardware actions and communicate these actions to the hardware. Mspdebug is no longer the debugger, it’s really just a translation layer. The client, which is gdb, is the debugger. As with the rest of the toolchain, we must run the cross-compiled version under /opt/msp430-toolchain/bin.

/opt/msp430-toolchain/bin/msp430-gdb build/bin/app.o

Passing the object file as an argument tells gdb to load the symbol table from that file. Now we can connect gdb to the mspdebug server and start running.

target remote localhost:2000
continue

The ‘continue’ command is the gdb equivalent to ‘run’ in mspdebug. Now you can start using gdb to debug your code. If you are unfamiliar with gdb, I would start here and work through the ‘breakpoint’ and ‘continuing and stepping’ sections. Enjoy!

5 comments

  1. Hi all,

    I use Code::Blocks in my work with MCU. Till now the compiling and loading programs was all I need. But the possibility of step-by-step debugging (like in Atmel Studio) was somewhere in my sight and my plans.
    Now I had a couple of days free to try step-by-step debugging of msp430 MCUs. And I’ve got my Waterloo. Here is my Capitulation Act:
    http://msp430-linux.blogspot.com/
    But nothing of our labors is in vain, IMHO. During my debug battle I used MSPDEBUG v.0.23, as Simply Embedded propose. I’ve noticed a little bug in MSPDEBUG and I have a honor of communication with the author of this piece of art, Mr. Daniel Beer. Now I help him with a patch testing. The bug is presented here:
    http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/479767
    I hope to report the result of Mr. Daniel Beer’s patching.
    And thanks a lot to Simply Embedded for their excellent tutorials!

    1. Thanks for the information! It makes sense that the bug affects the FRAM MCUs only. Please let us know when the patch is ready, I’m sure many people people reading this will run into the issue so it will be of great help 🙂

      1. Here is the last post from TI e2e community:

        The problem is solved in a canonical way. Daniel Beer found a bug in mspdebug v.0.23 and it’s fixed in the latest git version.

        So we can use PROG command as well as LOAD – the only difference is that mspdebug issues (on PROG) a warning not attempting erase of FRAM device. The command ERASE raises the same warning without any consequences.

        From my side only MSP430FR5726 served as a target in the process. But I think the result is OK for all FRAM MCU.

  2. 2 years later… The MSPDEBUG accepts the msp430fr59xx family now. Daniel helped me to add these MCUs to the database.
    And I do like MSPDEBUG, use it for loading programs mostly, but sometimes it helps to debug very specific problems. For example, I had to debug a program with the memory segments access – and TI CCS was really bad in the process. I changed Launchpad from eZ-FET to eZ-430 and MSPDEBUG helped me very nicely.
    Now I try to use CLion with msp-exp430fr5969 launchpad (eZ-FET) for full-scale development. So far compiling and loading are OK. But to work with that launchpad I had to use MSPFlasher, since MSPDEBUG does not support eZ-FET driver.
    My next step is debugging under CLion. Alas, without MSPDEBUG.

Leave a Reply

Your email address will not be published. Required fields are marked *