Usefulness of GDB on embedded systems

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
above.
No luck there either. Postings here back in 2003 described similar
problems.
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.

Did you check the GNU compiler options and compatability?

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

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Real-time and Embedded System Modeling with Sequence Diagrams

"hikari" <cjchen@eden.rutgers.edu> wrote in message
news:1115550071.314660.61790@f14g2000cwb.googlegroups.com...
> 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.


You might want to take a look at some of the prebuilt Win32 tools.  I am
using http://www.gnuarm.com 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
problem.

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

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.

Regards,
Richard.

http://www.FreeRTOS.org

"hikari" <cjchen@eden.rutgers.edu> escribi&#4294967295; en el mensaje
news:1115550071.314660.61790@f14g2000cwb.googlegroups.com...
> I have an Atmel AT91EB40A and an EB55.
>
> I was disappointed to
> find that GDB does not seem to work too well.
>


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

Good luck.


Josep Duran

hikari wrote:
> 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
> above.
> No luck there either. Postings here back in 2003 described similar
> problems.
> 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.
> 

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

Richard wrote:

> You might want to take a look at some of the prebuilt Win32 tools.  I am
> using http://www.gnuarm.com 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
> problem.
> 

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'?

BR,
Slawc



(remove j in email address)

On Mon, 09 May 2005 13:01:43 -0700, Scott Moore wrote:

> hikari wrote:
>> 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
>> above.
>> No luck there either. Postings here back in 2003 described similar
>> problems.
>> 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.
>> 
> 
> 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
> assembly.

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.

hikari wrote:
> 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
> above.
> No luck there either. Postings here back in 2003 described similar
> problems.
> 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.
> 

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.

HTH

-- 

Tauno Voipio
tauno voipio (at) iki fi

For the Atmel Part look at WinAVR, which includes gcc, gdb ... very
inclusive.

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