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.
Ich stehe vor der gleichen Frage: Wie bekomme ich im "Embedded SRAM Boot mode" den Code ins SRAM geladen? Hat jemand Infos hierzu? Danke.
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.
Ich glaube, er meinte sowas wie über SPI/Dataflash oder externes I2C-EEPROM. Ich glaube das geht nicht.
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.
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.