AT91SAM7SE-512, SAM-BA, J-LINK, Adressenproblem

[Florian F. (e-lore)]

Hallo!

Nach einiger Zeit, in der ich mit meinem Problemen allein zurecht kam, 
melde ich mich nun wieder zurück.
Meine Diplomarbeit wächst und über die anfänglichen Schwierigkeiten bin 
ich hinweg gekommen.

Mittlerweile habe ich mit der Kombination eclipse - J-LINK GDB - SAM7SE 
prima im RAM debuggen können und schon einiges an Code geschrieben. 
Jetzt wollte ich einmal via SAM-BA meinen code in den Flash schreiben.

Mein Programm hat dabei zunächst auf einem Beispielprogramm aufgebaut, 
dessen Makefile mir gleich 3 Dateien liefert: eine für SRAM, eine für 
SDRAM und eine für Flash. Das programmieren des Flash lief einwandfrei 
und mein Programm lief ebenfalls ohne weitere Probleme. Als ich jetzt 
aber wieder wie gewohnt im RAM debuggen wollte, so wie 1000ende Male 
zuvor, ging es nicht mehr. Das Programm landet wiederholt im prefetch 
abort handler und irgendwann bleibt es im unexpected IRQ handler in der 
while(1); Schleife hängen.

Der GDB gibt dabei folgendes aus: WARNING: Failed to read cacheable 
memory @ address 0x9D3131B0. Nach neuem programmieren ist er bei 
ähnlichen Addressen gelandet.

Jetzt funktioniert das übertragen in den Flash einwandfrei. Hat mir 
SAM-BA da irgendwelche Einstellungen verbastelt?

Ich habe leider noch nicht so viel erfahrungen mit ARM und langsam setzt 
die Phase ein, in der der an Nervennahrung denke.... ;)

Danke schonmal überhaupt fürs durchlesen


Grüße


Florian

[Florian F. (e-lore)]

Hallo!

Falls es von Interesse ist, ich habe jetzt jemanden gefunden, der mir 
den Wink in die richtige Richtung gegeben hat, auch wenn er keine 
Erfahrung mit dem SAM7SE hat. Das Beispielprogramm von IAR Systems, 
welches ich vor dem Start von meinem Projekt auf den Flash geladen habe, 
hat offensichtlich irgendwelche Answeiseungen drin stehen, die es 
ermöglichen, daß auch Programme im RAM ausgeführt werden können.

Als ich jetzt mein Programm eingespielt habe, gings nicht mehr. Ich 
musste mit dem Programm von IAR Systems das alte USART / USB 
Beispielprogramm kompilieren und eine raw-binary Datei erzeugen. Diese 
hat die Endung A79 (nicht werwechseln, da ist noch eine Datei mit der 
Endung D79 gewesen). Diese hab ich in BIN umbenannt und mit SAM-BA in 
den Flash kopiert und siehe da: RAM debugging ging wieder!!

Jetzt ist diese Lösung natürlich doch etwas zu Fuß, deswegen wäre es 
toll, wenn jemand mir noch erklären könnte, wie ich meinem Programm 
beibringe, daß es auch RAM Debugging erlaubt, wenn es sich im Flash 
befindet.


Grüße


Florian

[Dominic R. (dominic)]

> daß es auch RAM Debugging erlaubt, wenn es sich im Flash befindet

Das ist eigentlich ein wenig widersprüchlich. Bei uCs dieser Grösse 
möchte man meistens das Programm im Flash ablaufen lassen, um das onehin 
knappe RAM für Daten nutzen zu können. Allenfalls zeitkritische 
Routinen, die durch die Zugriffszeiten des Flash gebremst werden 
könnten, werden in's RAM kopiert und dort ausgeführt.

Falls du deine Anwendung zwar im Flash ablegen, dann aber komplett in's 
RAM kopieren willst, muss sie für die Ausführung im RAM gelinkt werden. 
Dein Startup File kopiert dann das Image vom Flash in's RAM und spring 
dann an die neue Adresse im RAM.

Wie das bei IAR gehandhabt wird weiss ich leider nicht - unter anderem 
ein Grund, warum ich keine fertigen IDE Lösungen möchte, sondern lieber 
mit den GNU Tools arbeite.

Gruß,

Dominic

[Florian F. (e-lore)]

Ich muss eben mit mehreren Breakpoints arbeiten können bei der 
Entwicklung. Ab und zu will ich aber auch mal einen Test im Flash machen 
können...beim Flash Debugging kann ich aber leider nur maximal 2 
Breakpoints definieren. Eine weitere Möglichkeit wäre auch das Programm 
in den SD-RAM zu packen, der auf dem EK Board hier alles andere als 
knapp ist (32MB!).

Wie das mit dem mapping funktioniert hab ich leider noch nicht 
verstanden und leider hab ich bis jetzt auch keine vernünftige 
Beschreibung dazu gefunden..Schande über mein Haupt, wenn ichs 
überblättert habe..nach der Mittagspause mach ich mich nochmal über die 
Dokumentation von ATMEL her...