Hallo, die Rowley Umgebung bietet die Möglichkeit eines RAM Debug und einen RAM Release. Ich nehme mal an, dass damit gemeint ist, dass das Programm aus dem internen Ram heraus läuft, solange es nicht zu gross ist. Nun weiss ich allerdings nicht was ich alles einstellen muss, damit das auch funktioniert. Was passiert da genau? Kopiert der uC dann das Flash ins Ram hinein beim Starten und springt dann rüber? Könnte mal jemand eine kurze Übersicht geben, was alles eingestellt werden muss und auch was das bringt? Hat jemand eine Ahnung wie oft man den uC überhaupt neu programmieren kann? Da kommen beim Testen ja schnell einige hundertmal zusammen, da bei jedem Programmtest ein Brennvorgang stattfindet. Gruss, Christian
Christian J. schrieb: > Hallo, > > die Rowley Umgebung bietet die Möglichkeit eines RAM Debug und einen RAM > Release. Ich nehme mal an, dass damit gemeint ist, dass das Programm aus > dem internen Ram heraus läuft, solange es nicht zu gross ist. Soweit richtig, wie es den Unterschied RAM/ROM betrifft. Der Unterschied zwischen Release/Debug betrifft die Ausstattung des Programms mit Symbolen für den Debugger. > Nun weiss ich allerdings nicht was ich alles einstellen muss, damit das > auch funktioniert. Was passiert da genau? Kopiert der uC dann das Flash > ins Ram hinein beim Starten und springt dann rüber? Im Idealfall macht das Entwicklungssystem die passenden Einstellungen um dein Programm auf deinem Target im RAM auszuführen. Dazu gehört u.a. eine angepasste Linkerkontrolldatei (linker control script LCS) und ein angepasster Startupcode ("der Teil ab Reset bis main()"). > Könnte mal jemand eine kurze Übersicht geben, was alles eingestellt > werden muss und auch was das bringt? In dem LCS steht, wie gross bestimmte Speicherabschnitte sind und unter welchen Adressen sie erreichbar sind. Da sind natürlich bei ROM und RAM Unterschiede. Im Startupcode muss u.a. das sog. Remap behandelt werden. Ich bin seit dem Artikel Beitrag "Re: Platinen mit GPS - Empfänger bei ebay" und GPS-Platine mit Tyco-Modul etwas raus aus der ARM7 Geschichte und mehr drin in der AVR Sache. Ich empfehle dir http://www.embedded.com/design/opensource/200000632 und die weiteren Folgen... "Bringen" tut es einen etwas schnelleren Entwicklungszyklus (RAM laden statt ROM flashen) und einfachere Möglichkeiten das Programm zu debuggen (RAM Code ist zur Laufzeit patchbar, ROM Code nicht) > Hat jemand eine Ahnung wie oft man den uC überhaupt neu programmieren > kann? Da kommen beim Testen ja schnell einige hundertmal zusammen, da > bei jedem Programmtest ein Brennvorgang stattfindet. Das spielt IMHO keine Rolle. Das Flash-ROM ist dafür robust genug.
Hallo, mein neues Board ist zwar noch nicht da aber ich habe mal Luftübungen gemacht. Die Linkercontrolldatei heisst bei Rowley sram_placement.xml oder flash_plascement.xml. Je nachdem was man anwählt nimmt er sich einer dieser Dateien und tatsächlich steht der .text Segment Code auch nachher im Sram drin. Das Flash kennt er nicht mehr. Nun gibt es dieses Register MEMMAP, das mit 0,1,2 beschrieben werden kann. Er muss ja wissen woher er seine IRQ Einsprungadresse holen muss. Diese steht bei 0x0000 00018 normalerweise für IRQs. Im Falle eines Ram Starts wäre es dann bei 0x4000 0018. Sehe ich das richtig, dass er durch das Beschreiben dieses Memmap registers das Ram, bzw 64 Byte davon für die ISR Tabelle, einfach umklappt und auf 0x0000 0000 abbildet? Nehmen wir mal einen Reset an, er rennt bei 0x0000 0000 los und springt von dort aus in seinen Boot-ROM rein. Dieser wird laut Manual immer ausgeführt. Dieser sucht nach einem gültigen Programm, wie immer er das auch macht und verzweigt dann ins Flash. Im Flash steht dann in meiner setup Routine irgendwann der Memmap Befehl. Wie geht es dann weiter, wenn ich dieses setze? Er befindet sich ja immer noch im Flash. Zitat Manual: ---- The portion of memory that is re-mapped to allow interrupt processing in different modes includes the interrupt vector area (32 bytes) and an additional 32 bytes for a total of 64 bytes, that facilitates branching to interrupt handlers at distant physical addresses. The remapped code locations overlay addresses 0x0000 0000 through 0x0000 003F. A typical user program in the Flash memory can place the entire FIQ handler at address 0x0000 001C without any need to consider memory boundaries. The vector contained in the SRAM, external memory, and Boot ROM must contain branches to the actual interrupt handlers, or to other instructions that accomplish the branch to the interrupt handlers ---- So richtig verstehen tue ich das noch nicht.... edit: Wie er ein gültiges Programm erkennt habe ich gefunden, er nimmt 0x0000 0014 und berechnet eine Checksumme (ob der Compoiler das automatisch macht weiss ich nicht) Gruss, Christian
Hallo Christian, der SAM7S64/128/256... hat seinen ROM/FLASH ab der Adresse 0x1000 0000 und nach einem PowerUp auch gleichzeitig auf Adresse 0x0000 0000 "gemapt". Das RAM befindet sich auf der Adresse 0x2000 0000. Nach dem Remap Befehl (ist ein einfacher toggle) wird die Adresse vom RAM auf die Adresse 0x0000 0000 "gemapt". Somit steht dann ein RAM an Adresse 0x0000 0000 zur Verfügung. Sinn macht der Remap, da der Flash etwas langsamer ist und somit ständig ein Wait-Zyklus durchlaufen wird und das Programm langsamer abgearbeitet werden kann. Zusätzlich macht der Remap auf RAM in dem Moment Sinn, wenn man mehr als 2 Breakpoints beim Debuggen benötigt. Zusätzlich ist es sinnvoller, für ein Debugging einfach den RAM zu füllen als jedesmal ein Flash zu beschreiben. Die Interrupt-Tabelle wird damit auch dynamisch und kann während der Programm Laufzeit geändert werden, was im ROM nicht oder nur sehr schwer möglich ist. Wie Rowley das "Mapping" durchführt, entzieht sich meiner Kenntnis, aber bei den einschlägigen GNU-GCC Dokumentationen ist eine Erklärung des "StartUp" (die Datei nennt sich in den meisten Fällen cstatup.c) nach zu lesen. In dem StartUp werden zusätzliche Dinge wie Stack laden und Variablen setzen, durchgeführt. Man kann natürlich auch Programmteile aus dem ROM ins RAM kopieren um die Prozessorzugriffe zum Speicher zu beschleunigen, macht aber nur in bestimmten Fällen wirklich Sinn. Ich hätte fast vergessen zu erwähnen: Nach einem PowerUp und einem Remap-Befehl im ROM kann man in Probleme laufen, da dann ab der Adresse 0x0000 0000 kein "Boot" in dem eigentlichen Sinne mehr möglich ist, ohne definiert wieder ein "Remap" Befehl auszuführen.
Hallo, ich werde das mal life austesten sobald ich wieder ein Board habe. Die Rowley Oberfläche nimmt einem sehr viel ab, glücklicherweise! Man kann für jedes Modul einzeln die GCC Parameter einstellen. Der Ram Run Mode ist natürlich vorbei, sobald man Reset drückt oder den Szrom wegnimmt denke ich mal, da der Jasg direkt ins Ram schreibt. Ich habe nur einen Flow Chart gesucht, der den Boot Prozess beim Arm etwas erklärt.
Bitte 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.