Hallo,
da ich jetzt nach 5 Wochen endlich mein DEV-Board von Futurlec bekommen
habe, werde ich nun reichlichst die Register durchgehen. Dabei werden
natürlich sehr viele (und vor allem sehr kleine!!!) Programmmversionen
fällig, die ich, wenn möglich, aus Verschleißgründen nicht immer ins
Flash programmieren will. Das hält zwar laut Datenblatt mindestens
10.000 Zyklen aus, muß ja aber nicht sein, zumal der STM32 ja das booten
aus dem SRAM unterstützt (über die Bootpins 0 und 1). Der Grund ist ja
aber eigentlich auch egal.
Im Manual (13902) konnte ich nun unter 2.4 "Boot configuration" aber nur
folgendes finden:
When booting from SRAM, in the application initialization code, you have
to relocate the vector table in SRAM using the NVIC exception table and
offset register.
Der offset vom SRAM beträgt 0x20000000, soweit ganz gut. Aber mehr Infos
konnte ich nicht finden, wie man das machen soll. Auch Google war
diesmal nicht mein Freund (außer das der GCC gerade hierbei irgendwie
eine 17 byte offset-Fehler hatte ...). Das ganze sollte daher wohl eher
am Ende meiner Übungen angesiedelt sein, nur ist es dann ja schon zu
spät.
Einfach mal im Linker-File den ROM-Bereich ab 0x20000000 setzen und
probieren?
Auch die Vector Table auf die Adresse verschieben (die .s Datei der
FW-Lib), dann sollte es klappen...
Das andere Problem ist das Laden, da manche GDB Server automatisch den
Flash-Bereich 0x08000000 kennen und einen Offset beim Schreiben machen.
Wenn der nach 0x28000000 schreiben möchte, muss man lesen in der Doku
des GDB Servers wie man dem die andere (richtige) Adresse beibiegen
kann.
Ich hatte noch nicht das Bedürftnis, ist also nur geraten.
M. G. schrieb:> Wie bekomme ich im "Embedded SRAM Boot mode" den Code ins SRAM geladen?
Grad auf die gleiche Weise wie beim Flash. Nur eben andere Adresse.
Markus Müller schrieb:> Ich glaube, er meinte sowas wie über SPI/Dataflash oder externes> I2C-EEPROM. Ich glaube das geht nicht.
Klar geht das, nur nicht direkt ab Werk. Eigenen Bootloader ins Flash.
Während der Entwicklungsphase lass ich auch oft meinen Code im SRAM
laufen. Ich kann allerdings nur erzählen, wie das unter IAR geht:
Dass das Linker File angepasst werden muss, ist klar und wurde schon
gesagt. Als nächstes muss man dafür sorgen, dass die Interrupt Vektoren
an der richtigen stelle gefunden werden. Dazu muss die richtige Adresse
in SCB->VTOR geschrieben werden, BEVOR ein Interupt ausgeführt wird.
Dies erledigt man in den ersten Zeilen des Programmcodes. Wenn man die
ST-Lib verwendet, geht das ganz einfach über SystemInit() per #define
VECT_TAB_SRAM.
Beim laden auf den Controller darf dann natürlich kein Flashloader
verwendet werden - die Bytes müssen halt einfach 1:1 an die
entsprechende Adresse geschrieben werden.
Wie nun der Start des Programms abläuft kann ich auch nicht sagen. Aber
es funktioniert ganz einfach. Ich vermute, dass IAR einen JTAG soft
reset auslöst und den Controller einfach zwingt, an der angegebenen
Adresse zu starten - die Bootpins können ja per JTAG nicht umgeschalten
werden. (Das könnte der knifflige Teil beim GDB werden....)
Ach ja: Nicht vergessen sollte man, dass der Code im internen SRAM mit
anderer Geschwindigkeit läuft. Bei den F10X schneller, bei den F2XX
erstmal langsamer (der Flash Accelerator funktioniert wirklich
erstaunlich gut)
Dann hoffe ich mal, das hilft Dir ein wenig. Und wünsch Dir viel Spaß
mit diesen wirklich gelungenen Controllern.
Bei Keil geht das auch. In den Projektoptionen einfach bei IROM einen
Teilbereich des SRAM eintragen. Bei IRAM einen anderen Teilbereich des
SRAM eintragen. Dann teilen sich Programm und Daten den SRAM.
Vectortabelle wie oben schon gesagt noch in den SRAM legen. Mache ich
so:
1
NVIC_SetVectorTable(NVIC_VectTab_RAM,0x0);// RAM Vector Table ab 0x20000000 (Beispiel STM32F103RB)
Zum testen ideal, natürlich nur begrent nutzbar, wenn das Programm klein
ist.
Wie kann man dann bei Keil den Code ins SRAM übertragen?
Normalerweise verwendet der uLink2 ja einen passenden Flash-Algorithmus,
hier bräuchte man ja aber nur eine Kopierfunktion.
Hallo,
bitte beachtet beim STM32F das Problem des LDRD Befehls, ich weiss nicht
ob der Fehlerfrei aus dem RAM ausgeführt wird ?
Die Ausführungszeiten sind aus dem RAM auch anders !
Normalerweise ist das einspielen ins RAM kein Problem, man braucht ja
noch nicht einmal einen Flashloader. Mit ST-Link oder JLink oder
ähnlichem über JTAG kein Problem, denn der Flashloader wird ja auch
zuerst ins RAM eingespielt. Bei IAR gibt es sogar einen Flashloader der
ins RAM einspielt.
Klar beim Linkerscriptfile einfach die neue Adresse angeben und die
Register die noch geändert werden müssen übernimmt auch der Debugger,
hierfür gibt es auch eine Art Scriptfile.
Gruß Sascha
Sascha schrieb:> bitte beachtet beim STM32F das Problem des LDRD Befehls, ich weiss nicht> ob der Fehlerfrei aus dem RAM ausgeführt wird ?
Was hat denn das mit ROM/RAM zu tun? Der dokumentierte LDRD Bug kann
auftreten, wenn darin das Basisadressregister auch in der Registerliste
aufkreuzt und er mittendrin unterbrochen wird. Wo der Befehl steht
erscheint mir dabei ziemlich irrelevant.
Der LDRD Bug tritt nur auf, wenn der Befehl über den System Bus geladen
wurde. Das ist beim SRAM der Fall und da wäre es folglich möglich. Beim
Flash wird er über den I-Bus geladen, da kann er also nicht auftreten.
Ich vertraue jedoch mal auf die Aussage, dass die Compiler die
Befehlssequenz sowieso nicht mehr generieren.
Irrtum, habe vorgestern einige Routinen des IAR Compilers
disassembliert, genau wegen dieser Frage, der Befehl wird weiterhin
verwendet.
Weil es gibt ja auch andere Cortex M3 CPUs.
Ich denke die gehen nicht davon aus, dass die Application jemals SRAM
oder DRAM sieht, sonder nur Flash !!!
Gruß Sascha
Sascha schrieb:> Irrtum, habe vorgestern einige Routinen des IAR Compilers> disassembliert, genau wegen dieser Frage, der Befehl wird weiterhin> verwendet.
In der kritischen Art und Weise? Der Befehl ist nicht grundsätzlich von
Übel. Richtig angewendet ist er harmlos.
