ARM7: RAM Run einstellen - wie?

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.