Hallo alle zusammen, ich experimentieren gerade mit einem STM32F429. Ich benutze CoIDE. Jetzt würde ich gerne, um den Flash zu schonen, meine Programme ersteinmal im RAM ausführen. Leider kann ich nicht herausfinden, wie das mit CooCox funktioniert. Gibt es da irgendwo Infos? Gruß Sam
Moin, in den Einstellungen kann man zwischen Flash und RAM wählen. Der Rest sollte dann automatisch gehen. mfg Moritz
du musst: - linker-file anpassen (dein Programm in den RAM linken) Ich weiß nicht ob Coocox da nachgebessert hat, in den Versionen die ich benutzt habe waren Speicher-Anpassungen etwas tricky (ich habe mir eine kopie des linkerfiles gemacht und dann in dieser Einstellungsseite umgeändert). Evtl reicht bei dir die Anpassung auf der Einstellungsseite aus... - bootpin richtig setzen (BOOT0, BOOT1; bitte im Datenblatt / Refman. die richtige Beschaltung nachlesen)
Den Standard Radiobutton "Debug in RAM" habe ich schon auf alle erdenklichen weisen ausprobiert, hat leider nur zu Müll auf dem Display und sonst nichts geführt. Phantomix Ximotnahp schrieb: > du musst: > > - linker-file anpassen (dein Programm in den RAM linken) > Ich weiß nicht ob Coocox da nachgebessert hat, in den Versionen die ich > benutzt habe waren Speicher-Anpassungen etwas tricky (ich habe mir eine > kopie des linkerfiles gemacht und dann in dieser Einstellungsseite > umgeändert). Evtl reicht bei dir die Anpassung auf der Einstellungsseite > aus... > > - bootpin richtig setzen (BOOT0, BOOT1; bitte im Datenblatt / Refman. > die richtige Beschaltung nachlesen) Auch eine Anpassung des linker-files hat zu keinem anderen Ergebnis geführt, es kam genau das selbe dabei heraus. Ist die Beschaltung der Bootpins zwingend, auch wenn ich nicht resetten können will? (Nur Debuggen am Rechner auswählen)
:
Bearbeitet durch User
Samuel C. schrieb: > Ist die Beschaltung der Bootpins zwingend, auch wenn ich nicht resetten > können will? (Nur Debuggen am Rechner auswählen) Du hast Code, Metadaten, Interruptvektoren, usw. im Flash. Woher soll der Controller wissen, wo er die Dinge findet und von wo gestartet wird? Bootpins sind die Lösung.
Ok, dann zieh ich die Boot-Pins mal hoch. Kannst du mir erklären, was dann passiert? Was macht der µC dann? Eben mit Interruptvektoren usw.
Die Interruptvectoren stehen immer am Anfang. Beim Linken im RAM werden die an Adresse 0x20000000 gelinkt, durch die Boot-Pin Konfiguration "RAM" wird der RAM Bereich mit der Adresse 0x20000000 auch an Adresse 0x00000000 gespiegelt, denn nach dem Reset liest die CPU ab Adresse 0x00000000 in der Vectortabelle. Man könnte das Programm also auch ab Adresse 0x00000000 linken und in das Ram ab Adresse 0x20000000 rein schreiben, das würde genau so laufen.
Das hab ich jetzt ehrlich gesagt nicht ganz verstanden. Ich hab die Bootpins beschalten, der Effekt ist leider der selbe.
Die Boot-Pin Beschaltung ist hier beschrieben: http://www.mikrocontroller.net/articles/STM32#Bootmodi oder in der Doku. Der gelinkte Code müsste dann mit der Vector-Tabelle ab Adresse 0x20000000 sein, das kann man in der .map Datei kontrollieren. Ich habe das noch nie genutzt, ich flashe immer meine Controller. Bisher ist mir noch keiner Kaputt gegangen.
Markus Müller schrieb: > Die Boot-Pin Beschaltung ist hier beschrieben: > http://www.mikrocontroller.net/articles/STM32#Bootmodi > oder in der Doku. Habe ich schon aus dem Datenblatt geholt, aber danke :) > Der gelinkte Code müsste dann mit der Vector-Tabelle ab Adresse > 0x20000000 sein, das kann man in der .map Datei kontrollieren. Ja, ist er auch, war er ständig. Habe gerade etwas im Forum der IDE ausgegraben, scheint ein Bug in der derzeitigen Version zu sein. Dann hoffe ich mal, dass es nach dem nächsten Update anders aussieht. > Ich habe das noch nie genutzt, ich flashe immer meine Controller. Bisher > ist mir noch keiner Kaputt gegangen. Habe ich bisher auch, aber die Flashzellen des STM32F4 halten scheinbar nur 100 Zyklen, und da ich doch einige male am Tag flashen würde will ich lieber auf Nummer sicher gehen :)
>Habe ich bisher auch, aber die Flashzellen des STM32F4 halten scheinbar >nur 100 Zyklen, Woher hast du das denn? Häng noch mal zwei Nullen dran.
100? Das kann sicher nicht sein. Mein STM32F417 flashe ich schon lange ständig mit einem neuen Programm. Im Datenblatt steht "10 kcycles" unter 5.3.12 in der Tabelle 40 (Datenblatt vom STM32F417xx/Rev. 3)
>Im Datenblatt steht "10 kcycles" unter 5.3.12 in der Tabelle 40
Und das ist Minimum. Einige Zeiten sind für 100k Erasecycles angegeben.
Zum Booten steht im Datenblatt noch: >Note: >When the device boots from SRAM, in the application initialization >code,you have to relocate the vector table in SRAM using the NVIC exception >table and the offset register. Weiß zwar nicht was das heißt aber hört sich wichtig an ;=)
Tur mir leid, ich meinte 1000 Zyklen :) Ich finde den Punkt gerade nicht im Datenblatt, aber dann glaube ich mal die 10k. Solang es heißt, dass es an einem Bug in der IDE liegt werde ich mich auch nicht weiter darum kümmern. Vielen Dank an alle :)
Markus Müller schrieb: > denn nach dem Reset liest die CPU ab Adresse > 0x00000000 in der Vectortabelle na, na, na, da fehlt doch noch der Stackpointer. ;-D Also, ab 0x00000000 kommen 4 Byte Stackpointer und dann ab 0x00000004 die Interruptvektortabelle. Nur mal so ganz genau. ;-D
Aus system_stm32f4xx.h :
1 | /* Configure the Vector Table location add offset address ------------------*/
|
2 | #ifdef VECT_TAB_SRAM
|
3 | SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */ |
4 | #else
|
5 | SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */ |
6 | #endif
|
7 | }
|
Vector table offset register (VTOR): 0xE000ED08
Kann mir noch jemand sagen, wo die Lebensdauer des Flash im Rev5-Datenblatt steht? Ich finde es einfach nicht, ich hatte noch nie dermaßen Probleme mit einem Datenblatt :)
Bei mir sieht die Vectortabelle so aus:
1 | const intvec_elem AppVectors[] __attribute__ ((section(".vectors"))) = |
2 | {
|
3 | {(intfunc) STACK_TOP}, // stack pointer |
4 | {(void *)main}, |
5 | {NMIException}, |
6 | {HardFaultException}, |
7 | {MemManageException}, |
8 | : : : |
Und im Linker-Script steht wohin die section .vectors hin kommt. Der Stack-Pointer steht da natürlich auch gleich mit drin. Ich gehe mal davon aus, dass Coocox das von alleine macht, wenn man es entsprechend konfiguriert. Bei Coocox ist das wohl in einer Startup-Assembler Datei, ich habe das in C geschrieben und nutze kein Coocox. Ich habe in meinem Programm gleich 2 solche Vector-Tabellen, eine für den Bootloader und eine für die Applikation, beides in einem Projekt. Ist ein wenig kniffelig, aber geht.
Datenblatt: "DM00035129" Rev. 4 Seite: 107 Abschnitt 5.3.12 Tabelle 41
Markus Müller schrieb: > Und im Linker-Script steht wohin die section .vectors hin kommt. Der > Stack-Pointer steht da natürlich auch gleich mit drin. > > Ich gehe mal davon aus, dass Coocox das von alleine macht, wenn man es > entsprechend konfiguriert. > Bei Coocox ist das wohl in einer Startup-Assembler Datei, ich habe das > in C geschrieben und nutze kein Coocox. > Ich habe in meinem Programm gleich 2 solche Vector-Tabellen, eine für > den Bootloader und eine für die Applikation, beides in einem Projekt. > Ist ein wenig kniffelig, aber geht. Ich werde wohl einfach warten müssen, bis der STM32F429 offiziell unterstützt wird^^
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.