arm-elf-gdb load probleme

[Star K. (starkeeper)]

Hi,
ich habe ein zum besseren debuggen ein SRAM an meinen STR710 gehängt. 
Das SRAM läuft jetzt dank dieses Forums anstandslos. Ich habe das EMI 
initialisiert und kann in meinem Code das komplette SRAM beschreiben und 
auch ohne Fehler wieder auslesen. Das ganze sogar ohne wait cycles 
einfügen zu müssen.
Mein Verständnis sagt mir das es hardware mässig in Ordnung ist.

So nun will ich das ja zum debuggen benutzen, also meinen Code da rein 
laden. Dazu habe ich mein OpenOCD script erweitert, sodass vor dem Laden 
das EMI initialisiert wird:

# 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 0x80098009
monitor mdw  0x6C000004

Die mdw-Befehle zeigen mir das die entsprechenden Werte in die Register 
geschrieben wurden. Die Werte entsprechen dem Ist, als ich das EMI in 
meinem Code initialisiert hatte. Sollten also funktionieren...

Ich kann nun mit dem mww-Befehl auch einzelne werte in das SRAM 
schreiben und wieder auslesen. Führe ich allerdings den Load Befehl von 
GDB aus, gibt es probleme. Der geladene Code entspricht dann nicht mehr 
dem Code in dem file das auf meiner Platte liegt. Die Daten sind dann 
korrupt und es kann nicht sinnvoll ausgeführt werden. z.B. aus NOPs 
werden MOVS, allerdings willkürlich das könnte auch zu einem BX geworden 
sein.

Also sobald ich das load einsetze scheint mein SRAM nicht mehr die 
richtigen Daten zu speichern. Woran kann das liegen?

Natürlich habe ich mein linker-script angepasst, sodass der Code jetzt 
zu der Adresse 0x62000000 geladen wird, was die Startadresse meines 
SRAMs ist.

[Jörn K. (joern)]

So weit ich weis, mußt du das externe SRAM beim STR7 auf Adresse 0x0 
mappen. Von dort kann dann dein Code ausgeführt werden.

Gruß Jörn

[Star K. (starkeeper)]

Ich muss das externe RAM auf 0x00 mappen, wenn ich davon booten möchte. 
Da ich aber schon "gebootet" habe ist das normalerweise nicht nötig. 
Beim laden durch gdb wird der Programcounter auf die Startadresse des 
externen RAM gesetzt also 0x62000000. Die Ausführung des Codes beginnt 
also schon an der richtigen Stelle.

Mein Problem beginnt ja auch schon vor dem Booten, indem der code 
garnicht korrekt am SRAM ankommt bzw. ausgelesen werden kann.