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:
- Download the sources
cd ~/src/stellaris git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
- Install the required dependencies
sudo apt-get install libtool libusb-dev
- Apply Spencer Oliver patches:
cd openocd git pull http://openocd.zylin.com/openocd refs/changes/22/922/14
- And build it:
./bootstrap ./configure --enable-maintainer-mode --enable-ti-icdi make
- 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-bingdb 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:- Download the project
cd ~/src/stellaris git clone https://github.com/scompo/stellaris-launchpad-template-gcc.git cd stellaris-launchpad-template-gcc
- Edit the makefile to set the path to the StellarisWare library. Change this line:
STELLARISWARE_PATH=~/stellaris/stellaris/
to this:
STELLARISWARE_PATH=~/src/stellaris/stellarisware/
- And build:
make
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.
- Download the config file:
cd ~/src/stellaris/openocd-bin wget http://pastebin.com/download.php?i=qXxeYsVx -O LM4F120XL.cfg
- 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
- 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
- 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 load monitor reset init
- 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 c
- 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!
Troubleshooting
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: 000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000010000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000
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:
- 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 http://pastebin.com/download.php?i=0Lu3Bu0R -O target.xml
- Start gdb as usual, but before issuing any other command, write this one at the gdb prompt:
set tdesc filename target.xml
- Continue writing commands as usual, hopefully the error should be gone, and everything should work perfect now!
just a note that the latest icdi patchset is version 14 not 10:
ReplyDeletegit pull http://openocd.zylin.com/openocd refs/changes/22/922/14
Main improvements are error handling.
Thanks. Updating right now...
DeleteI'm one of those people who got tripped up into the Troubleshooting section because I got the cryptic error message.
ReplyDeleteNo 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."
and
"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,
Jim
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.
DeleteFor the script to rebuild gdb, I suppose you have to clean the build. I haven't tried, but maybe deleting the gdb-linaro-7.3-2011.10.build file inside the stamps directory will trigger the build. In the worst case, you can delete everything and rebuild everything again.
Yep, deleting the stamp file triggered a rebuild of gdb.
DeleteThere 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,
Jim
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.
DeleteTony
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:
Delete~/src/stellaris/stellaris-launchpad-template-gcc $ make
Copying...
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.
Thanks
got this working on ARCH Linux. used the arm packages from yaourt. used your git openocd rather than arch linux repo versions.
ReplyDeletehad 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.
openocd git moved to:
ReplyDeletegit://git.code.sf.net/p/openocd/code
Can't apply Spencer Oliver patches, already applied upstream?
DeleteThe error mentioned in Troubleshooting seems fixed in gdb (it didn't occur).
DeleteThanks for comments. It looks like patches for GDB were applied upstream some months ago.
DeleteI'm using fedora 16.
ReplyDeleteI 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.
It works just restarting the computer.
Delete