AT91SAM7X256 Interupts gehen nicht im RAM

Peter Gast #2163544
Lesenswert?
• ▲
▼ 
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
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter Gast #2164352
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas B. Gast #2164368
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin T. Moderator Persönliche Seite #2165700
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas B. Gast #2165838
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren