Hallo, ich habe da mal eine Frage? Ich möchte einen Can-Bootloader für den STM32F4 schreiben. Der Bootloader muss ja im Speicher an die Stelle 0x8000000. Das wenn ich den Bootloade schreibe. muss ich ein ganz normales Projekt erstellen ohne etwas am Linker zu ändern etc. Für die User Application sieht das ja etwas anders aus. Was muss ich da alles ändern? Die nächste Frage wäre: Nachdem eine Spannung angelegt wird, startet der Chip immer an 0x8000000 und ich muss aus dem Bootloader in die Userapplication springen? Oder startet der Code in der Stelle der User Application und man muss von dieser in de Bootloader springen...Das wäre mir nämlich lieber. (Mod.: Tippfehler in Topic korrigiert)
>Die nächste Frage wäre: Nachdem eine Spannung angelegt wird, startet der >Chip immer an 0x8000000 und ich muss aus dem Bootloader in die >Userapplication springen? Oder startet der Code in der Stelle der User >Application und man muss von dieser in de Bootloader springen...Das wäre >mir nämlich lieber. Der Bootloader startet. DU ganz alleine bist dafür verantwortlich in die Applikation zu springen. Wann und warum ist deine Sache. Und DU bist auch dafür verantwortlich hinter dir aufzuräumen und alle Ressourcen die der Bootloader benutzt abzuschalten bevor du in die Applikation springst. >Für die User Application sieht das ja etwas anders aus. Was muss ich da >alles ändern? Du musst ein Linker Script erstellen was den Bootloader berücksichtigt. Die können ja nicht im selben Speicher liegen. Damit ist deine Frage beantwortet.
Nur ergänzend und evtl. auch für den Anwendungsfall überflüssig: Es gibt auch die Möglichkeit, den Bootloader in einen anderen Adressbereich zu legen, indem man die Einsprungadresse im zweiten Eintag der Cortex M3 Vektortabelle (Reset) auf die Startadresse des Bootloaders zeigen lässt. Beim Schreiben der Nutzeranwendung merkt sich der Bootloader die Startadresse der Anwendung (zweites DWORD), schreibt diese zur späteren Verwendung in einen reservierten Bereich und "biegt" vor Beschreiben des Flash-Speichers die Resetadresse wieder auf sich selbst um. Ist die Startbedingung für den Bootloader nicht erfüllt, liest der Bootloader die vorher gespeicherte Startadresse der Nutzanwendung, beschreibt die bis dato veränderte Register mit "reset defaults", setzt den Stackpointer auf den Intialwert der Anwendung (erster Eintrag Vektortabelle) und verzweigt in das Anwendungsprogramm. Einen Bootloader so zu implementieren ist etwas schwieriger (initale Flashprogrammierung, Stackpointer, Vektortabelle des Bootloaders...). Vorteil ist jedoch, dass die Nutzanwendung ohne Änderung mit und ohne Bootloader funktioniert (vergleichbar mit der üblichen Vorgehensweise bei AVR/BOOTRST/IVSEL). Der Entwickler der Endanwendung muss lediglich den durch den Bootloader reduzierten Speicherplatz berücksichtigen, Flashen, Debuggen, Linker- und Compileroptionen bleiben ansonsten wie gehabt.
Hat vielleicht jemand ein Minimalbeispiel eines Bootloaders für mich?
Peter P. schrieb: > startet der Code in der Stelle der User > Application und man muss von dieser in de Bootloader springen...Das wäre > mir nämlich lieber. Nein, das wäre dir nicht lieber. Dann ist nämlich dein Chip "Tot" wenn das Flashen der User-App aus irgendwelchen Gründen mal nicht klappt oder die User-App sich wegen eines Softwarefehlers "äufhängt".
Hi nochmal, ich bin jetzt schon etwas weiter... ich kann soweit Flash löschen und beschreiben. Als Protokoll möchte ich mein altes benutzen und anpassen, welches ich auch schon für die AVRs genutzt habe. Jetzt möchte ich mir zum testen eine Blinky UserApp erstellen, welche ich zum Testen nutzen kann. Ich benutze CooIDE und habe in den Configurations unter Link bei IROM1 0x8004000 eingestellt und in der System_stm32f4xx.c #define VECT_TAB_OFFSET 0x4000 laut Beispiel von ST ist das Alles, was nötig ist. Wenn ich die App jetzt flashe und mit dem Debugger in den Speicher schaue, steht alles an 0x8000000 und nicht wie gewollt an 0x8004000. funktionieren tut die App natürlich auch nicht, weil die Vectortabelle an der falschen stelle sitzt.... wenn ich die Vectortabelle zurückstelle und die linker Einstellung beibehalte gehts wieder... Also scheint die Linkereinstellung ja keinerlei Auswirkung auf die Speicherposition zu haben... Oder funktioniert das einfach nur nicht, weil mein ST-Link einfach immer an die Stelle 0x800000 schreibt?
In Map-File und evtl. Disassembly nachgeschaut, ob das erwartete Speicherlayout dort wiederzufinden ist?
Angehängte Dateien:
-
disas.PNG
21 KB
Martin Thomas schrieb: > In Map-File und evtl. Disassembly nachgeschaut, ob das erwartete > Speicherlayout dort wiederzufinden ist? Habe ich jetzt mal gemacht... Das Setzen der Vectortabelle klappt. Aber der Programmcode schaut merkwürdig aus (siehe Anhang) wenn die Startadresse im Linker nicht ändere sieht alles ganz norml aus!
Peter Pan schrieb: > Martin Thomas schrieb: >> In Map-File und evtl. Disassembly nachgeschaut, ob das erwartete >> Speicherlayout dort wiederzufinden ist? > > > > > Habe ich jetzt mal gemacht... Das Setzen der Vectortabelle klappt. Aber > der Programmcode schaut merkwürdig aus (siehe Anhang) > > wenn die Startadresse im Linker nicht ändere sieht alles ganz norml aus! Disassembly-Ansicht in Eclipse bringt nicht so wirklich weiter. Gemeint war das Map-File, das vom Linker erzeugt werden kann (vgl. Option -Map der Dokumentation zum Linker) und das Disassembly, das per objdump (vgl. Dokumentaiton zu Binutils) erzeugt wird. Kenne die IDE nicht und daher auch nicht die dafür notwendigen Einstellungen in den Dialogboxen aber die erforderlichen Werkzeuge sind Teil der von CoIDE genutzten GNU Toolchain, also auf dem Entwicklungsrechner vorhanden.
hier mal beide map files im anhang.. ich kenne mich damit nicht sonderlich gut aus, wie der ein oder andere an dieser stelle sicher schon gemerkt hat, aber für ich sieht das relativ plausiebel aus.
Scheinbar ein Problem mit dem integriertem Flashloader von CooIDE. http://www.coocox.org/forum/topic.php?id=2553#post-7097 kann das jemand bestätigen?
Die Bootloader AppNote kennen wir aber oder? https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf
Kenne ich aber mein stm hängt an nem 1 mbps can der onboard bootloader arbeitet default mit 125 kbps Habe jetzt meine app mit cooflash an 0x8004000 flashen können an 0x8000000 habe ich meinen unfertigen bootloader gepackt, der nur an 0x8004004 springt... Und es blinkt!!! Nur wenn ich die .elf flashe gehts nicht..... Die .bin funktioniert Etweder ich durchblicke da was nicht oder es scheint tatsächlich einen bug zu geben
Hallo Peter! Ich habe vor eine ähnliche Projekt zu realisieren, wo ich über CAN meinen uC flashen kann, ohne den onboard Bootloader zu benutzen. Hat es bei dir geklappt? Wie weit stehst du jetzt? Hat wer vielleicht ein ähnliches Beispielprojekt wo ich Informationen finden kann?
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.