AT91RM9200: Data Abort im internen RAM

OP #715868
Lesenswert?
• ▲
▼
Hallo,

mich plagen sehr viele data aborts innerhalb des internen RAMs. Meinen 
Stack Ptr hab ich an der Adresse 0x00200798. Der interne RAM geht an 
sich bis zur Adresse 0x002FFFFF.

Oberhalb des Stacks treten häufig data aborts auf. Leider weiß ich nicht 
genau welcher Prozess auf diesen Bereich zugreift. Der Heap und der 
Stack laufen doch irgendwann zusammen - d.h. oberhalb des Stack Pointers 
befindet sich doch eigenltich gar nichts, oder?

Wenn ich versuche ein Pattern auf eine solche Addresse (z.b. 0x00205241) 
zu schreiben, bei der ein Data Abort erfolgt -> erhalte ich ebenfalls 
einen Data abort. Was könnte das Problem hierfür sein?

Zwischen Heap und Stack hab ich ebenfalls schon mal ein paar 
Speicherzellen vollgeschrieben und dadurch überprüft ob Stack und Heap 
zusammenlaufen -> ist aber nicht der Fall.

Laut Linkerfile befindet sich im internen RAM nur .ANY (+RW, +ZI)

Bernd
OP #715892
Lesenswert?
• ▲
▼
darf ich auf den speicherbereich oberhalb des Stack Pointers überhaupt 
nicht zugreifen? Oder ist es legitim, dass ich dort ein Pattern 
reinschreibe.

Ich meine der jetzige Data Abort passiert, weil ich da selbst über das 
Pattern versuche auf diese Address was zu schreiben. Nur warum darf ich 
das nicht?

Bernd
#715958
Lesenswert?
• ▲
▼
Bernd Schuster wrote:

> Der Heap und der Stack laufen doch irgendwann zusammen - d.h.
> oberhalb des Stack Pointers befindet sich doch eigenltich gar
> nichts, oder?

Ja und nein. Gibt beides. Es ist zwar ziemlich verbreitet, einen 
einzigen Stack vom oberen Rand des RAMs nach unten und den Heap 
andersrum dagegen laufen zu lassen, aber wetten würde ich nicht drauf. 
Schon garnicht bei ARMs, die oft mit einem separaten Interrupt-Stack 
arbeiten. In den üblichen Startup-Codes ist der dann nicht selten nur 
pro forma definiert, grad 4 Bytes gross, was eigentlich nur als 
Platzhalter für konkretere Angaben gedacht ist. Wer das vergisst...

> Wenn ich versuche ein Pattern auf eine solche Addresse (z.b. 0x00205241)
> zu schreiben, bei der ein Data Abort erfolgt -> erhalte ich ebenfalls
> einen Data abort. Was könnte das Problem hierfür sein?

Für solche Zwecke ist ein JTAG-Debugger recht hilfreich. Der kann dann 
nämlich einen Tip geben, wo genau das Problem auftrat. Geht aber auch 
anders, wenn der Abort-Handler das irgendwo mitteilt.

Und wenn man Worte auf eine ungerade Adresse schreibt...
OP #715975
Lesenswert?
• ▲
▼
ich hab einen Abort Handler, der mit die genau Addr sagt von dem Data 
Abort und ob es sich um einen Lese- oder Schreibzugriff handelte.

Der User-Stack ist bei mir 0x00000400, der IRQ stack ist 0x00000080 und 
die anderen alle 0x00000008 (FIQ - hab ich keinen installiert, oder ABT, 
Supervisor etc.). Das ganze Programm läuft auch im User-Mode.

Mein Stackptr zeigt auf jeden Fall zu Beginn auf die höchste Addr, die 
sich aus der Summierung der verschiedenen Stacks ergibt. Beim Heap ist 
die Adresse 0x00000000 eingetragen (sollte auch so stimmen, da es sonst 
auch funktionierte und die Einstellung von Keil gekommen ist). Hab ich 
auch in den anderen Bsp von Keil Projekten so gesehen.


D.h. der Speicherbereich über meinem Stack ist für alles frei 
zugänglich?


>Und wenn man Worte auf eine ungerade Adresse schreibt...

Stichwort: Alignement - hab ich auch gerade gemerkt.. d.h. aber im 
Umkehrschluss dass bei mir irgendwas auf genau so eine Addr zugreift.

Bernd

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren