Re: gdb for AT91SAM7

[Michael Snyder <msnyder@specifix.com>]

On Wed, 2008-05-14 at 00:42 -0700, Roman Mashak wrote:
> Hello.
> 
> My question concerns to debugging of embedded code on AT91SAM7
> targets. Briefly about the background of the problem:
> 1) I'm using gdb-6.8.50.20080308-cvs
> 2) toolchain is based on gcc-4.2.2 for Windows
> 3) JTAG is by Segger, they also provide GDB server
> 
> What I'm trying to do is to debug step-by-step the C-startup, written
> in ARM assembly language in order to clearly understand the process of
> chip initialization, peripheral setup and other low-level stuffs.
> 
> I compiled C-startup and my simple application (printing string out of
> the USRT), with "-gdwarf-2 -O0" options as recommended. Then I run
> gdb, attach to the target. Since the application is linked to 0x100000
> I set breakpoint on this address:

When you say the application is linked to 0x100000, 
do you mean that that is the start address?

> #arm-elf-gdb main.elf
> #target remote localhost:2331
> #break *0x100000
> #continue
> Continuing.
> ...
> 
> At this point it hangs and doesn't step over. But if I do "jump
> *0x100000" right after setting up the breakpoint, it works! This is
> kind of strange, isn't it?

Before you say "continue", or "jump *0x100000", if you 
ask gdb for the current instruction pointer (presumably
"info reg pc"), what does it say?

I've had somewhat similar problems in the past.  The
start address is special in many ways, and so is the 
whole start-up process.

Can you try setting your breakpoint at the 2nd or 3rd
instruction after the start address?