AT91SAM7X256 Interupts gehen nicht im RAM

[Peter (Gast)]

Hi, ich versuche FreeRTOS 7.0.0 auf einem AT91SAM7X256 zum laufen 
zubringen.

Nach anfänglichen Problemen kann ich nun im RAM Debuggen und ein kleines 
Programm läuft auch.
Aber jetzt will ich FreeRTOS nicht nur mit compilieren sonder auch mal 
aufrufen.
Aber die Interrupts funktionieren nicht richtig und ich verstehe nicht 
was falsch ist.

Die Code Basis ist die Demo "ARM7_AT91SAM7X256_Eclipse".
Ich habe nur Ethernet und USB aus dem Makefile und er Main.c raus 
genommen.
Der erst ist von Code noch Original.

Abgehangen habe ich die Dateien in denen ich den Fehler vermute.

Ich hoffe Ihr seht was falsch ist.

Viele Grüße, Peter

[tom (Gast)]

lokierung der isr-vector tabelle richtig bzw. RAM in den richtigen 
speicherbereich dafür gemapped ?

builde doch mal die flash version und schau ob sie tut...

gruss, tom.

[Peter (Gast)]

Davon habe ich noch zu wenig Ahnung.
Ich fange erst mit dem ARM7 an und hatte gehofft das hier jemand rein 
sieht und gleich sieht was falsch ist.

Die Flashverison kann ich bauen, das war für heute Abend auch mal so 
eine Idee von mir. Obwohl mir die RAM Version lieber ist, da habe ich 
mehr Breakpoints.

Wenn in den Datein kein Fehler ist, kann es dann am GDB Skript liegen?

Ich hatte die nur nicht wieder gefunden, aber die finde ich noch.

Peter

[Andreas B. (Gast)]

Ich habe jetzt selber nur Erfahrung mit dem SAM7S, aber ich glaube der 
SAM7X ist in der Hinsicht nicht anders. Und das heißt, es wird das 
RAM-Mapping sein.

Der ARM7 führt Exceptions durch Sprung an die festen Adressen ab 0 aus. 
Da hängt per Default (nach jedem Reset) das Flash des SAM7, damit 
Programme im Flash dort ihre Exception-Einsprünge ablegen können. Das 
RAM muss an die Adresse 0 gemappt werden, damit die Vektoren deines 
Programms (und nicht die gerade im Flash liegenden) angesprungen werden.

Beim SAM7S schaltet man das in einem Register des Memory Controllers, 
wird beim SAM7X nicht anders sein.

[Peter (Gast)]

Ok Bit gefunden, ist nicht gesetzt!

Jetzt stellt sich nur die Frage was muss ich machen wenn ich es jetzt 
setze?

Und warum lief das Main Programm dann überhaupt?

VG, Peter

[Martin T. (mthomas) (Moderator)]

Peter schrieb:
> Ok Bit gefunden, ist nicht gesetzt!
>
> Jetzt stellt sich nur die Frage was muss ich machen wenn ich es jetzt
> setze?
Das Bit dient zum Umschalten, man tut also gut daran, den aktuellen 
Zustand vorher zu testen. Es gibt von Atmel gut vorgekauten Code zur 
Inspiration oder zum Übernehmen: Software-Package zum AT91SAM7X-EK bei 
atmel.com herunterladen, eines der Beispiele auspacken, darin die Datei 
board_memories, darin die Funktionen BOARD_RemapFlash() und 
BOARD_RemapRam() nebst Hilfsfunktionen.

> Und warum lief das Main Programm dann überhaupt?
Wenn der Startupcode bei 0x0 lag, wurde dieser ausgeführt und das 
Programm "lief" bis zur ersten Ausnahme (IRQ oder SWI für FreeRTOS 
Context Switch) wie geplant, da bis dahin kein Sprung in die 
Vectortabelle erfolgt ist.

[Andreas B. (Gast)]

Peter schrieb:
> Und warum lief das Main Programm dann überhaupt?

Dein Programm ist für Ausführung im RAM gelinkt und der Debugger mit dem 
du den Code geladen hast wird auch an diese Adresse springen. Das Remap 
an Adresse 0 ist nur eine zusätzliche Einblendung, Flash und RAM sind 
immer an ihren festen Adressen (0x100000 und 0x200000) sichtbar.

Auch wenn das Programm für Ausführung an Adresse 0 gelinkt ist, kann es 
bei Ausführung an Adresse 0x200000 funktionieren, wenn alle Sprünge und 
Speicherzugriffe PC-relativ statt absolut sind. Nur die Exceptions sind 
festverdrahtet an Adresse 0, deshalb kracht es dann.

[Peter (Gast)]

Habe es hin bekommen. Läuft jetzt im RAM und im ROM.
VG, Peter