Usefulness of GDB on embedded systems

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am a newcomer to Embedded Systems.
I have an Atmel AT91EB40A and an EB55.
After building GNU toolchain following the procedure described in
"Embedded System Design on a Shoestring", I was disappointed to
find that GDB does not seem to work too well.
Using GDB 5.2/Cygwin 1.3.16, I can download and run a program and
set breakpoints. But that is as far as I got. I could not
not single step the program.
I've tried other combinations of more recent versions of
GDB and Cygwin. They were even worse.

target rdi com1         => hang
target rdi /dev/ttyS0   => could not open device

I also tried using a Wiggler with ocdremote.
Most of the time, it failed to download the program. When it did,
it is painfully slow.

Then I tried moving to a Linux machine and repeat the whole thing
No luck there either. Postings here back in 2003 described similar
But there were no answers.

Am I missing something here? Or is it just hopeless and I'll have to
spend a few thousand dollars to get a commercial tool? Thanks.

Re: Usefulness of GDB on embedded systems
Did you check the GNU compiler options and compatability?

Need to make sure that debug information is included in the build.

EventStudio 2.5 -
Real-time and Embedded System Modeling with Sequence Diagrams

Re: Usefulness of GDB on embedded systems

Quoted text here. Click to load it

You might want to take a look at some of the prebuilt Win32 tools.  I am
using tools with little problems.  As far as the GDB
(Insight actually), ocdlibremote, wiggler setup goes the only real problem I
have is that the 'registers' window cannot be used in Insight - the
registers can be viewed however using the Insight console so this is no real

I know of people having problems with newer versions of ocdlibremote and
wiggler clones - but this was resolved.  Also I had a problem with making a
connection with ocdlibremote but this turned out to be a power up sequence

The LPC2106 FreeRTOS port documentation page (see link below) has some
instructions on using this setup.  May be useful to you but perhaps won't
tell you anything new.


Re: Usefulness of GDB on embedded systems

Quoted text here. Click to load it

This is Insight problem. You have to patch it, it works afterwards
without problems. Check out the gnuarm list for link to the update (I
have 3.4.3 version for Windows and I didn't try 4.0 yet).

But I do have a problem with dwarf-2 debug info and assembler files (I
tried crt0.S only though with ASFLAGS += -gdwarf2). Using stabs is OK.
Dwarf-2 with C is also OK. Posted this problem to the gnuarm list and
got no reply.
Does anyone know what is the problem here -> 'Internal error: pc 0x0 in
read psymtab, but not in symtab'?


(remove j in email address)

Re: Usefulness of GDB on embedded systems
For the Atmel Part look at WinAVR, which includes gcc, gdb ... very

Further, it has a makefile generator which includes all the necessary
switches for building debug infor into your builds.

Re: Usefulness of GDB on embedded systems

Quoted text here. Click to load it

I used to have similar problems when I was using the EB55.
The problem seemed to be an unreliable conection between
GDB and the ANGEL monitor.

I solved the problem installing Redboot on the board. Except for
some minor problems with code in thumb mode, GDB worked

Good luck.

Josep Duran

Re: Usefulness of GDB on embedded systems
Quoted text here. Click to load it

GDB is fairly awful at assembly language debugging, it mostly concentrates
on high level source debugging. Even embedded apps that use HLL often
need to go hunting through the machine code. I suspect GDBs limited
usefulness in embedded is going to lessen the support for that application
(a vicious circle).

See for example the linux assembly site for comments on using GDB for

Re: Usefulness of GDB on embedded systems

Quoted text here. Click to load it

Awful compared to what?  I've not used ARMs, but I've used gdb for a fair
number of other embedded processors (6, I think), and find it is better
than many commercial debuggers I have tried (at least in some respects).
It's not perfect, and shows clearly its heritage as a non-embedded
debugger (for example, the "run" command should never be used).  Sometimes
it helps to use other tools with it - often I find that seperate
downloader tools are much faster than trying to program flash
microcontrollers via gdb.  But I've used it happily for C and assembly
debugging, both with and without a gui.

Re: Usefulness of GDB on embedded systems
Quoted text here. Click to load it

The RDI serial communication is flaky at its best. You need
a GDB stub instead of the Angel monitor. The monitor was
good enough for writing the stub into the user half
of the evaluation board Flash.

Another question (which may be the one biting you) is
the fact that a standard GDB for ARM is built to use
hardware breakpoints, but the hardware breakpoint unit
on an Atmel chip is available to the JTAG interface only.
The GDB is configurable to use software breakpoints
instead. The backside is that software breakpoints work
for RAM-run code only, cannot break at Flash addresses.



Tauno Voipio
tauno voipio (at) iki fi

Site Timeline