Friday, November 23, 2012

The complete tutorial for Stellaris Launchpad development with GNU/Linux (II)

Did you follow my previous tutorial? We set up the toolchain, built StellarisWare libraries, compiled lm4flash tool and flashed an example to the Stellaris LaunchPad. So... you are brave and even started writing your own code. That's great news! Unfortunately programs have a nasty tendency to fail, and debugging using LEDs and traces is not convenient for big projects. Don't worry, in this chapter we will learn how to set up a full debugger (gdb + openocd). This way you will be able to debug the code setting up breakpoints and watching variable values. This tutorial is based on this tutorial by Mauro Scomparin (scompo). You can follow it instead of this one, I just wanted to write it again to have all the tutorials in one place, and to fit the directory structure I'm using. But there are almost no differences between both tutorials.

Building OpenOCD

At the time of writing this tutorial, there is not official support in OpenOCD for the ICDI protocol used in the Stellaris LaunchPad integrated debugger. But don't worry, Spencer Oliver has patched it to add support. When this patch is pushed into the main OpenOCD branch, it will not be necessary to follow this tutorial. Just install it using the repository of your distro, and it's done. But now we will have to do it the long way:
  1. Download the sources
cd ~/src/stellaris
git clone git://
  1. Install the required dependencies
sudo apt-get install libtool libusb-dev
  1. Apply Spencer Oliver patches:
cd openocd
git pull refs/changes/22/922/14
  1. And build it:
./configure --enable-maintainer-mode  --enable-ti-icdi
  1. To install it I have also followed scompo's suggestion about not executing make install but copying the required files manually:
cd ~/src/stellaris
mkdir openocd-bin
cp -r openocd/tcl/* openocd-bin
cp openocd/src/openocd openocd-bin
gdb is already built. We built it in the previous chapter, when we built the toolchain. So we can start using it, but before, we must build something to debug.

Avoiding Stellarisware obscure licenses

As I wrote in previous chapter, there's no problem with StellarisWare library license, but the examples that come bundled with it use a more obscure license terms, including the startup code, the linker scripts and the makefiles. So to avoid problems with this license, you should not use these files. Again, scompo comes to rescue us. He wrote a template project, including a makefile, startup code and a linker script you can use in your own projects. You just have to preserve the header in the files (with the copyright notice) and everything should be fine. Let's build this template project:
  1. Download the project
cd ~/src/stellaris
git clone
cd stellaris-launchpad-template-gcc
  1. Edit the makefile to set the path to the StellarisWare library. Change this line:
to this:
  1. And build:
At last, it's time to start debugging!

Using the debugger

First of all, you have to create a config file for openocd. Rickta59, a Stellarisiti forum user, wrote one working perfect. Then you'll only have to start both openocd and gdb.
  1. Download the config file:
cd ~/src/stellaris/openocd-bin
wget -O LM4F120XL.cfg
  1. With the Stellaris LaunchPad debug port connected to the PC, and the power select switch in the "debug" position, run openocd. Before starting it, make sure you created the udev rule for the Stellaris LaunchPad as written in the previous chapter, to avoid having to run openocd with root privileges:
./openocd --file LM4F120XL.cfg
  1. openocd should be running without problems. If it fails, try running it as superuser (with the sudo prefix). If it works with sudo, maybe you have not properly created the udev rule! If it's working, now you'll only have to start gdb. Open another terminal and type:
cd ~/src/stellaris/stellaris-launchpad-template-gcc
arm-none-eabi-gdb main.axf
  1. gdb should have started, and you should be greeted by the (gdb) prompt. At this prompt you should start writing some commands. The first one will connect gdb to openocd, and the following ones will load the program and initialize the debug process:
target extended-remote :3333
monitor reset halt
monitor reset init
  1. You can enable some breakpoints and watch the contents of the count variable. Then continue execution with the 'c' command:
b main.c:51
b Timer1A_ISR
display count
  1. The execution will hit a breakpoint, and the line at which the code is stopped will be printed, along with the value of the count variable. You can type 'c' command several times to continue execution and watch the contents of the count variable each time the program stops at a breakpoint. When you finish debugging, you can exit gdb with the 'q' command. To exit openocd, just switch to it and hit [CTRL] + C.
And that's all. Now you can build and debug anything you want for your StellarisLaunchpad using GNU/Linux. What did you say? You don't like command-line debugging? Me neither! So stay tuned, because in the next chapter, you'll learn how to set-up an Eclipse project, using its full code building and debugging capabilities!

Happy hacking and stay tuned!


You followed the steps without changing a single thing, and got to step 4 of the "Using the debugger" sub-chapter. But then something went wrong and when trying to connect to openocd with the target command, you received this cryptic error message:
Remote 'g' packet reply is too long:
It looks like there's a known bug in openocd causing this issue with some versions of gdb. Until this bug gets fixed, you can workaround it:
  1. Download this target description file to the directory where the project you want to debug is (in this case, to ~/src/stellaris/stellaris-launchpad-template-gcc).
cd ~/src/stellaris/stellaris-launchpad-template-gcc
wget -O target.xml
  1. Start gdb as usual, but before issuing any other command, write this one at the gdb prompt:
set tdesc filename target.xml
  1. Continue writing commands as usual, hopefully the error should be gone, and everything should work perfect now!


  1. just a note that the latest icdi patchset is version 14 not 10:
    git pull refs/changes/22/922/14

    Main improvements are error handling.

  2. I'm one of those people who got tripped up into the Troubleshooting section because I got the cryptic error message.

    No problem, I can use the work around. The wget worked fine to download the target description file. However, when I used "set tdesc filename target.xml" inside gdb I get "warning: Can not parse XML target description; XML support was disabled at compile time".

    So, how to compile in XML support into gdb?

    Inside the README file, which is located inside "summon-arm-toolchain", I see a couple of references to XML support.

    "For XML support in gdb you may want to install expat too. And add the
    --with-expat parameter to the GDB target."


    "For XML support in gdb you may want to install libexpat1 and libexpat1-dev too."

    The apt-get of the two expat1 packages was easy enough.

    Now, how does one add --with-expat to the GDB target?

    My first (and only) guess was to add the "--with-expat" string on line 168 of the summon-arm-toolchain" script so it reads "GDBFLAGS=--with-expat". However, running the script again does not recompile gdb. Is there a trick to coerce the script to rebuild gdb? Have I edited the script in the right way to get XML support compiled in?

    Thanks for any suggestions,

    1. I used summon-arm-toolchain and didn't have to modify the script to get XML support. I suppose it adds XML support automatically if you have the dependencies installed.

      For the script to rebuild gdb, I suppose you have to clean the build. I haven't tried, but maybe deleting the file inside the stamps directory will trigger the build. In the worst case, you can delete everything and rebuild everything again.

    2. Yep, deleting the stamp file triggered a rebuild of gdb.

      There is good news and bad news. The good news is gdb rebuilt itself with XML support! The debugger seems to work find so this is really good news. The bad news is, I don't know if XML support was added because of my edits to the script or because I simply had added the libexpat packages.

      Oh well, at least I'm back in the hunt.

      Thanks again for all the great info,

    3. I too was tripped up with the XML error and did not have any luck with the recommendations steps in the 'Troubleshooting' section. To expand on your comment, James, I was able to get it working by just installing the libexpat1 and libexpat1-dev packages. I didn't have to modify the install script or recompile the toolchain. Hopefully this clears up any ambiguity and isolates the steps that future users should take if encountering similar problems.


    4. I deleted the file in Stamp as mentioned but I still get the XML error. I have tried running all the "make"s again but still no luck. The last make gives me this:

      ~/src/stellaris/stellaris-launchpad-template-gcc $ make

      arm-none-eabi-objcopy -Obinary main.axf main.bin
      make: arm-none-eabi-objcopy
      make: arm-none-eabi-objcopy: Command not found
      make: *** [main] Error 127

      Also when I look in the folder /~src/stellaris/summon-arm-toolchain/stamps the build file is not being recreated. Any help would be awesome.


  3. got this working on ARCH Linux. used the arm packages from yaourt. used your git openocd rather than arch linux repo versions.
    had to change the makefile when building openocd. some macro name needed moifying but that was mentioned in the error.
    thanks again. have no clue how to use gdb from terminal, but will read up on that.

  4. openocd git moved to:

    1. Can't apply Spencer Oliver patches, already applied upstream?

    2. The error mentioned in Troubleshooting seems fixed in gdb (it didn't occur).

    3. Thanks for comments. It looks like patches for GDB were applied upstream some months ago.

  5. I'm using fedora 16.
    I have created the new udev rule but when i tried to access to /dev/ttyACM* i got the following message: /dev/ttyACM0: Permission denied.

    The same happens when i access as root. But lm4flash runs with no error. It can find the device.