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.

Reply to
hikari
Loading thread data ...

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 -

formatting link
Real-time and Embedded System Modeling with Sequence Diagrams

Reply to
EventHelix.com

You might want to take a look at some of the prebuilt Win32 tools. I am using

formatting link
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.

formatting link

Reply to
Richard

"hikari" escribió en el mensaje news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

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

Reply to
Josep Durán

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.

Reply to
Scott Moore

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)

Reply to
slawc

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.

Reply to
David

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
 Click to see the full signature
Reply to
Tauno Voipio

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.

Reply to
pmastroianni

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.