the complete tutorial for stellaris ii

7/28/2019 The Complete Tutorial for Stellaris II

1/6

[http://3.bp.blogspot.com/-d8mhQFvRCtg/UK-

dh-y6_OI/AAAAAAAAAPY/RJ_Z_zyUW_Y/s1600/debug.png]

Did you follow my previous tutorial

[http://kernelhacks.blogspot.com/2012/11/the-complete-tutorial-for-stellaris.html] ? 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)

[http://scompoprojects.wordpress.com/2012/11/07/debugging-a-

program-on-the-stellaris-launchpad-board/] . You can follow it insteadof 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.

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. Butnow we will have to do it the long way:

1. Download the sources

cd ~/src/stellaris

git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

2. Install the required dependencies

sudo apt-get install libtool libusb-dev

3. Apply Spencer Oliver patches:

cd openocd

git pull http://openocd.zylin.com/openocd refs/changes/22/922/14

4. And build it:

./bootstrap

The complete tutorial for StellarisLaunchpad development with GNU/Linux

(II)

Building OpenOCD

search


2/6

. con gure --ena e-ma n a ner-mo e --ena e- - c

make

5. 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.

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 https://github.com/scompo/stellaris-launchpad-template-gcc.git

cd stellaris-launchpad-template-gcc

2. 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/

3. And build:

make

At last, it's time to start debugging!

First of all, you have to create a config file for openocd. Rickta59, a

Stellarisiti forum user [http://forum.stellarisiti.com/topic/309-icdi-

support-in-openocd/page__st__20#entry1152] , 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 http://pastebin.com/download.php?i=qXxeYsVx -O LM4F120XL.cfg

2. 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:

Avoiding Stellarisware obscure

licenses

Using the debugger


3/6

./openocd --file LM4F120XL.cfg

3. 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

4. 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

5. 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

6. 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:

000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000010000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000

It looks like there's a known bug in openocd causing this issue withsome 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

Troubleshooting


4/6

~/src/stellaris/stellaris-launchpad-template-gcc).

cd ~/src/stellaris/stellaris-launchpad-template-gcc

wget http://pastebin.com/download.php?i=0Lu3Bu0R -O target.xml

2. Start gdb as usual, but before issuing any other command,

write this one at the gdb prompt:

set tdesc filename target.xml

3. Continue writing commands as usual, hopefully the error

should be gone, and everything should work perfect now!

Posted 23rd November 2012 by doragasu

Replies

Reply

11 View comments

ntfreakDecember 6, 2012 at 1:40 PM

just a note that the latest icdi patchset is version 14 not 10:git pull http://openocd.zylin.com/openocdrefs/changes/22/922/14

Main improvements are error handling.

Reply

doragasu December 6, 2012 at 6:23 PM

Thanks. Updating right now...

James Kemp December 28, 2012 at 2:58 AM

I'm one of those people who got tripped up into theTroubleshooting section because I got the cryptic errormessage.

No problem, I can use the work around. The wget worked fineto download the target description file. However, when I used"set tdesc filename target.xml" inside gdb I get "warning: Cannot parse XML target description; XML support was disabledat 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 andlibexpat1-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" stringon 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 torebuild gdb? Have I edited the script in the right way to getXML support compiled in?

Thanks for any suggestions,Jim


5/6

Replies

Reply

Replies

doragasu December 28, 2012 at 11:26 AM

I used summon-arm-toolchain and didn't have tomodify the script to get XML support. I suppose itadds XML support automatically if you have thedependencies installed.

For the script to rebuild gdb, I suppose you have toclean the build. I haven't tried, but maybe deletingthe gdb-linaro-7.3-2011.10.build file inside thestamps directory will trigger the build. In the worstcase, you can delete everything and rebuildeverything again.

James Kemp December 28, 2012 at 9:09 PM

Yep, deleting the stamp file triggered a rebuild ofgdb.

There is good news and bad news. The good news isgdb rebuilt itself with XML support! The debuggerseems to work find so this is really good news. Thebad news is, I don't know if XML support was addedbecause 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

Anthony Sansone May 16, 2013 at 3:57 PM

I too was tripped up with the XML error and did nothave any luck with the recommendations steps inthe 'Troubleshooting' section. To expand on yourcomment, James, I was able to get it working by justinstalling the libexpat1 and libexpat1-dev packages.

I didn't have to modify the install script or recompilethe toolchain. Hopefully this clears up anyambiguity and isolates the steps that future usersshould take if encountering similar problems.

Tony

Andy Robson March 15, 2013 at 7:16 PM

got this working on ARCH Linux. used the arm packages fromyaourt. used your git openocd rather than arch linux repo

versions.had to change the makefile when building openocd. somemacro name needed moifying but that was mentioned in theerror.thanks again. have no clue how to use gdb from terminal, butwill read up on that.

Reply

Ludo6431 April 26, 2013 at 1:30 AM

openocd git moved to:git://git.code.sf.net/p/openocd/code

Reply

Ludo6431 April 26, 2013 at 1:34 AM

Can't apply Spencer Oliver patches, already appliedupstream?


6/6

Reply

Ludo6431 April 26, 2013 at 1:48 AM

The error mentioned in Troubleshooting seemsfixed in gdb (it didn't occur).

doragasu April 26, 2013 at 8:57 AM

Thanks for comments. It looks like patches for GDBwere applied upstream some months ago.

the complete tutorial for stellaris ii

Documents