www.mikrocontroller.net

Mikrocontroller.net Forum WinARM / Yagarto / ARM-GCC > OpenOCD/gdb init - question about memory setup

Posted by Dan Miller (gorlash)
on 05.06.2008 01:40
I've tested the startup scripts from Yagarto's STR9Test application; it
works quite well on my comStick test device.  However, I have a couple
of questions regarding the implementation, that I hope someone can
clarify here:

1. If I just load the .elf file into insight, it starts as I would
expect, at address 0, the reset vector.  That's what I want, because I
want to trace through our startup code.  However, if I run the
str912_rom.gdb script from STR9Test, insight starts me at the first
instruction in main(), having already executed my startup code!  Why is
this happening?  There's no explicit breakpoint command in the gdb
script, this appears to be some indirect behavior.  Can some explain?

2. the script executes the following commands:
# Set SRAM size to 96 KB
monitor mww 0x5C002034 0x0197
monitor mdw 0x5C002034

and some other scripts that I've seen set up *more* registers and
settings beyond that.  However, my startup.s script *already* configures
all the required registers.  Why is this done again in the gdb script??
Do I actually have to do this?

Thanks for all the help you've all given me here!!
Posted by Spencer Oliver (ntfreak)
on 06.06.2008 19:29
Dan Miller wrote:
> I've tested the startup scripts from Yagarto's STR9Test application; it
> works quite well on my comStick test device.  However, I have a couple
> of questions regarding the implementation, that I hope someone can
> clarify here:
> 
> 1. If I just load the .elf file into insight, it starts as I would
> expect, at address 0, the reset vector.  That's what I want, because I
> want to trace through our startup code.  However, if I run the
> str912_rom.gdb script from STR9Test, insight starts me at the first
> instruction in main(), having already executed my startup code!  Why is
> this happening?  There's no explicit breakpoint command in the gdb
> script, this appears to be some indirect behavior.  Can some explain?
> 

The gdb str912_rom.gdb has the following lines:
break main
continue

this is setting a breakpoint and running your target as instructed to.
if you want to step through the startup code then replace the continue 
with a step. remove the breakpoint aswell if not required.

> 2. the script executes the following commands:
> # Set SRAM size to 96 KB
> monitor mww 0x5C002034 0x0197
> monitor mdw 0x5C002034
> 
> and some other scripts that I've seen set up *more* registers and
> settings beyond that.  However, my startup.s script *already* configures
> all the required registers.  Why is this done again in the gdb script??
> Do I actually have to do this?

These are not required, some people do it if they ram debug.
as at reset the str9 does not know about the flash or the ram size.

Cheers
Spen
Posted by Dan Miller (gorlash)
on 06.06.2008 19:41
Spencer Oliver wrote:
> The gdb str912_rom.gdb has the following lines:
> break main
> continue

Oh, for heaven's sake!!  I read that file several times, and never saw
"break main" ... duh...
Sorry for pointless question!!

> 
> this is setting a breakpoint and running your target as instructed to.
> if you want to step through the startup code then replace the continue 
> with a step. remove the breakpoint aswell if not required.
> 
>> 2. the script executes the following commands:
>> # Set SRAM size to 96 KB
>> monitor mww 0x5C002034 0x0197
>> monitor mdw 0x5C002034
>> 
> These are not required, some people do it if they ram debug.
> as at reset the str9 does not know about the flash or the ram size.

Thank you for that clarification, Spen!!
I appreciate the help...