Debug in external RAM

Development Boards MicroMod
1

Hi,

I have connected a external SRAM to my STR710. Now I want to load all my code and stuff into this ext. RAM and directly run and debug it from there.

The problem I’m experiencing is that the ARM starts executing from the correct address but after the first instructions it jumps to somewhere below the external RAM. Of course at that address is nothing to be executed.

I had already a debugging solution running from internal RAM. I thought that I just had to adjust the linker script for the new area, and tell OpenOCD to enable the external memory interface before loading the code.

I have disassembled the code made with the internal RAM script and with the external RAM script. I thought they should be the same but they are not! The only difference in the linker script is the RAM area and size!

Any suggestions? I have appended my linker script and just in case the startup.s and vector.s, all three are from STM.

http://www.gedankensindfrei.de/ARM/ext_ram71x.ld

http://www.gedankensindfrei.de/ARM/startup.s

http://www.gedankensindfrei.de/ARM/vector.s

Here is my OpenOCD script:

set complaints 1
set output-radix 16
set input-radix 16
file ./bin/main.elf
target remote localhost:3333
monitor reset
monitor sleep 500
monitor poll
monitor halt

# set boot mode to ext mem
monitor mww 0xA0000050 0x800B
# set P2.0-P2.3 to alternate function
monitor mww 0xE0005000 0x000F
monitor mdw 0xE0005000
monitor mww 0xE0005004 0x000F
monitor mdw 0xE0005004
monitor mww 0xE0005008 0x000F
monitor mdw 0xE0005008
# enable EMI Bank1
monitor mww 0x6C000004 0x8019
monitor mdw  0x6C000004

set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
set remote hardware-watchpoint-limit 2
set remote hardware-breakpoint-limit 2

load
monitor sleep 500
monitor poll

#monitor arm7_9 force_hw_bkpts enable
monitor arm7_9 sw_bkpts enable
#set breakpoint auto-hw on
break main
monitor sleep 500
monitor poll
Continue
2

Well I could figure out that it is not a compiler problem. It seems that the compiled binary is correct and is the same code as the code for the internal RAM.

But whenever I load the code via gdb into the SRAM it seems to get faulty. The memory dump shows after loading a different binary code than in the file on my disk.

The problem is now that my SRAM is working whenever I write to it and read from it in my code. It works even with zero wait cycles. I am able to write and read it with byte access and with word access.

I just can not figure out why it is not working correct with gdb!