Hallo, ich hab die Frage schon bei at91.com gepostet, aber irgendwie kriegt man ewig keine sinnvolle Antwort :-( Also: Momentan verwende ich SAM-BA zum Ausführen meines Codes aus dem RAM. Weil SAM-BA 0x00200000 belegt, muss man den Code an 0x00202000 laden und dort wird er dann ausgeführt. Das was mir jetzt Probleme bereitet ist: Woher weiß der ARM7, dass an 0x00202000 (nach dem Remappen bei 0x00002000) eine Interrupt-Vektor-Tabelle steht, die er verwenden soll? Meiner Meinung nach wird die immer bei 0x00000000 erwartet. Kennt sich da jemand aus damit?
Gegenfrage: Wo steht geschrieben, dass an 0x00202000 eine Vektor-Tabelle steht?
Weil mein Compilierter und für 0x00202000 gelinkter Code an Adresse 0 eine Interrupt-Vektor-Tabelle hat, die ja mein Programm auch verwenden will.
Jeder ARM-Compiler wird der Tradition zuliebe an den Anfang des generierten Bytesalats eine Vektor-Tabelle stellen. Das heisst jedoch nicht notwendigerweise, dass der Prozessor das auch so sieht. Aus der Atmel-Doku geht hervor, dass der SAM-BA alles RAM ausser der ersten 8KB nutzen kann. SAM-BA läd deinen Code also nach +0200 und sagt dem Bootloader, er möge dorthin springen. Und das schöne an der ARM-Vektor-Tabelle ist, dass sie dabei nicht stört. Ob die übrigen Vektoren darin funktionsfähig sind, ist nirgends bei Atmel dokumentiert. Funktioniert die denn? Nun könnte es natürlich sein, dass der Bootloader pfiffig genug ist, seine ROM-Vektoren an 0x00000000+n mit Code auszustatten, die in eine solche sekundäre Vektor-Tabelle springen. Nichts in Atmels Doku legt das freilich nahe.
>Aus der Atmel-Doku geht hervor, dass der SAM-BA alles RAM ausser >der ersten 8KB nutzen kann. Nicht ganz. Der SAM-BA belegt die ersten 8k des RAMs. Er wird beim Start von Flash nach RAM kopiert, weil er sonst den Flash nicht flashen könnte. Im Anschluss der 8k kann SAM-BA dann "alles RAM" verwenden. >SAM-BA läd deinen Code also nach +2000 und sagt dem Bootloader, >er möge dorthin springen. Und das schöne an derARM-Vektor-Tabelle ist >dass sie dabei nicht stört. Das ist klar, da der erste Vektor der Tabelle der Reset-Vektor ist, der dann zur Initialisierung des Programms springt. >Ob die übrigen Vektoren darin funktionsfähig sind, ist nirgends >bei Atmel dokumentiert. Funktioniert die denn? Genau da liegt mein Problem. Ich kann es noch nicht einmal sagen ob es geht oder nicht, da es noch etwas dauert, bis ich die Interrupts überhaupt benötige. Ich möchte mir aber im Vorfeld darüber schon Gedanken machen um möglichen Problemen aus dem Weg zu gehen. Ich kann mir aber vorstellen, dass Atmel das Problem kennt und SAM-BA beim Programmstart des User-Codes einfach die Interrupt-Tabelle nach 0x00200000 kopiert und anpasst, also einen Offset von 8k draufaddiert. Damit würde alles funktionieren. Es gibt noch einen weiteren Grund, warum ich diese Fragen stelle. Und zwar gefällt mir die Recovery-Procedure überhaupt nicht und ich versuche herauszufinden, ob man seinen Code (wie beim RAM) an 0x00102000 flashen kann, wo der SAM-BA nicht überschrieben wird. Vermutlich wird aber bei Programmcode im Flash eben dann diese Tabelle nicht nach 0x0 kopiert (wie denn auch?) und die Vektoren funktionieren garnicht. Irgendwie werde ich das Gefühl nicht los, dass das ARM7-Zeugs ja ganz schön komplex ist ... :-)
Hehe - ja es ist deutlich komplexer. AVR ist kinderleicht, ARM nicht. Du wirst wohl mal verfolgen müssen, was in den ROM-Vektoren drinsteht. Wenn du Pech hast, dann hat Atmel beim Bootloader den Fall von RAM-Debugging schlicht nicht vorgesehen. Die Atmel'sche Bootloader-Technik ist schon etwas eigenwillig, aber gegenüber Philips hat sie immerhin der Vorteil, kein Flash zu verbraten. Wenn Du Glück hast, benötigt der Bootloader keine Interrupts/Exceptions und du kannst die Sprünge in deine Sekundärtabelle ins Flash braten, nur den Reset-Vektor solltest du dabei natürlich verschonen.
>Wenn Du Glück hast, benötigt der Bootloader keine Interrupts/Exceptions >und du kannst die Sprünge in deine Sekundärtabelle ins Flash braten, nur >den Reset-Vektor solltest du dabei natürlich verschonen. Das ist eine gute Idee. Ich kuck mir das mal an ... Ansonsten hab ich noch eine Lösung gesehen, bei der der Startup-Code etwas verändert wurde. Beim Starten wird überprüft, Port-Pin auf Lo-Pegel ist (Durch Tasterdruck). Wenn ja, wird der SAM-BA aus dem ROM [sic!] ins RAM kopiert und dann direkt angesprungen. Da entfällt dann die Recovery-Procedure vollständig. Der einzige Pferdefuß ist, dass die Einsprungsadresse in den BA anders sein kann. 7S64 und 7X256 sind zum Beispiel unterschiedlich. Bei meinem 7S256 stimmts mit dem 7S64 aber überein. Muss ich aber auch noch ausprobieren. Ist aber eine elegante Möglichkeit (eleganter als Recovery).
halo thomas, wie sagte schon weiland goethe: "jeder gedanke ist schon mal gedacht worden" scvhau mal unter folgendem link: http://www.at91.com/www/phpBB2_mirror/viewtopic.php4? t=1496 gruss gerhard
@gerhard: Auf diesen Beitrag hatte ich mich auch bezogen. Ich selbst wäre als SAM7S-Newbie wohl kaum auf so eine Möglichkeit gekommen :-)
>und was ist nun dein aktuelles problem?
@gerhard: Hmm ... da gibt's ja soviele davon ^^
- Funktionieren die Interrupt Vectoren meines Codes, wenn er von SAM-BA
nach 0x00202000 geladen wird? (ich glaube ja)
- Ist es möglich seinen User-Code nach 0x00102000 zu flashen und dort
funktionierende Vektoren zu haben? (ich glaube nein)
- und halt noch die anderen tausend Kleinigkeiten, an denen ich
momentan hänge :-) (ich glaube, das krieg ich auch noch in den Griff)
Aber es ist wohl wirklich so, dass SAM-BA wirklich nur als letzten
Ausweg verwendet werden sollte, wenn sonst garnichts mehr funktioniert.
Soweit mir bekannt, muessen die Interrupt-Vectoren beim AT91SAM immer ab 0x0 liegen. Man kann sie zwar zur "Ladezeit" auch am Beginn des RAM-Speichers ablegen, muss dann jedoch auch "remappen", so dass der Controller die Vectoren wieder bei 0x0 findet. Wo SAM-BA den code ablegt ist de-facto egal, solange im Startup-Code die notwendigen Initialisierungsfunktionen ausgefuehrt werden. Falls ich das Problem richtig verstanden habe, sollen die von der Anwendung genutzten Vektoren nicht ins Flash, sondern ins RAM. Dazu muessten dann die Vektoren beim Startup an den Anfang des RAM-Speichers kopiert und ein Remapping ausgeloest werden. Ich nutze selbst SAM-BA nicht, aber falls man damit den Programm-Counter auf eine beliebige Adresse setzten kann, kann man dort den Kopier/Remap-Code ablegen. Meine "Experimente" zu Remapping/Vektor "im RAM" finden sich in http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91uart_and_aic Vielleicht hilfreich. Martin Thomas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.