Beim ATmega konnte man einen eigenen Bootloader installieren, der den ATmega mit Code von einer externen Quelle wie SD re-programmiert hat. Geht das mit dem STM32 auch? Was wäre sonst die einfachste Möglichkeit, einen STM32 zu programmieren? Flash Loader Demo oder DfuSe?
Die einfachste Möglichkeit wäre, den STM über den Boot Mode seriell zu programmieren. Benötigt natürlich aber einen externen Host dafür. Sich selbst "programmieren" kann der STM32 natürlich auch über einen selbstgeschriebenen Bootloader. Schau mal in diesem Thread: Beitrag "Bootloader STMF413VGT6"
lars schrieb: > Geht das mit dem STM32 auch? Was wäre sonst die einfachste Möglichkeit, > einen STM32 zu programmieren? Flash Loader Demo oder DfuSe? Was spräche gegen SWD?
Torsten R. schrieb: > Was spräche gegen SWD? Daß man zusätzliche Software und ggf. zusätzliche Hardware benötigt.
lars schrieb: > Torsten R. schrieb: >> Was spräche gegen SWD? > > Daß man zusätzliche Software und ggf. zusätzliche Hardware benötigt. Naja, irgend eine Form von Adaptierung / Kabel wirst Du für (fast) jeden Bootloader auch brauchen... Und SWD hätte den Vorteil, dass man den auch zum debuggen nutzen kann.
:
Bearbeitet durch User
Torsten R. schrieb: > Naja, irgend eine Form von Adaptierung / Kabel wirst Du für (fast) jeden > Bootloader auch brauchen... Die kann aber deutlich einfacher ausfallen, z.B. einfach nur ein USB Kabel, was eh jeder rum liegen hat. Manche STM32 haben USB Bootloader eingebaut, man kann sich aber auch selber einen programmieren. Tatsächlich ist die Bootloader Programmierung bei den ARM einfacher als bei den AVR, denn die unterscheiden gar nicht zwischen Bootloader und Hauptprogramm, wodurch man mehr Flexibilität erhält. Im Wesentlichen muss man nur zum Starten des Programms einen bestimmten Sprung ausführen und das VTOR sowie SP setzen. Beide Programme können auch problemlos Teile des jeweils anderen aufrufen/nutzen.
Man möge an eine industrielle Entwicklung denken. Soll der Kunde dann einen ST-Link kaufen und bedienen können? Nein, USB Kabel rein, Updatesoftware starten und los gehts - ohne irgendwelche zusätzlichen Treiber etc.
Nils N. schrieb: > Man möge an eine industrielle Entwicklung denken. Soll der Kunde dann > einen ST-Link kaufen und bedienen können? Nein, USB Kabel rein, > Updatesoftware starten und los gehts - ohne irgendwelche zusätzlichen > Treiber etc. Naja, wir kennen die Anforderungen des OPs nicht. Er fragte nach "einfachste Möglichkeit, einen STM32 zu programmieren".
Torsten R. schrieb: > Naja, wir kennen die Anforderungen des OPs nicht. Er fragte nach > "einfachste Möglichkeit, einen STM32 zu programmieren". Es geht um den Hobbybereich, und meine Frage war, ob (und wie) der STM32 sich selbst programmieren kann. Der Grund dafür ist, daß ich niemandem zumuten möchte, ein komisches Flash-Programm, welches es sowieso nur für Windows gibt, suchen und herunterladen zu müssen. Wenn er es aber nicht kann, dann hätte mich die einfachste Art Interessiert - offensichtlich UART, Flash-Programm nur für Windows oder selberschreiben.
lars schrieb: > Flash-Programm nur für Windows oder selberschreiben. Dann wirf einen Blick auf: Beitrag "STM32CubeProgrammer"
Die meisten (oder gar alle?) STM32 Mikrocontroller enthalten einen Bootloader der zumindest die UART Schnittstelle unterstützt - bei den größeren Modellen auch USB und CAN. Ein USB-UART oder RS232 Adapter muss natürlich noch besorgt werden werden, um das Ding mit einem PC zu verbinden, denn normale PC's habe keine einfache UART Schnittstelle. Die Software zum seriellen Bootloader heisst "Flash Loader Demonstrator".
OK, danke für alle Antworten. Und wie macht man das jetzt, wenn man einen eigenen Bootloader schreiben möchte, der Daten bspw. von einer SD-Karte liest und die Anwendung auf dem STM32 überschreibt? Habe dazu mit Google keinen brauchbaren Link gefunden.
Dazu solltest du mal einen Blick in Referenzhandbuch der jeweiligen STM32 Serie werfen und vielleicht vom Stm32Duino Bootloader abgucken. https://github.com/rogerclarkmelbourne/STM32duino-bootloader
lars schrieb: > Der Grund dafür ist, daß ich niemandem zumuten möchte, ein komisches > Flash-Programm, welches es sowieso nur für Windows gibt, suchen und > herunterladen zu müssen. Also erstens kann sich kein einziger µC auf dieser Welt SELBST programmieren, denn er braucht immer die Daten, die in seinen Programmspeicher kommen sollen, von woanders her. Nun haben m.W. eigentlich alle Cortex-Controller von NXP (außer Freescale) und ST einen eigenen Bootlader im ROM intus. Damit reduziert sich das ganze Programmieren darauf, diesem eingebauten Bootlader die entsprechenden Daten in geeigneter Weise zu verpassen. Ob diese Daten nun von einem Windows-PC oder von einem grünen Marsmännchen herkommen, ist schnurzegal - solange man mit dem Bootlader so umgeht, wie der es braucht. Jetzt ist es an dir, ne Überlegung anzustellen, wie du es hinkriegst. Der Windows-PC ist m.E. die sinnfälligste Lösung, denn sowas ist wirklich am weitesten verbreitet, wenn man all die anderen "Kästchen" beiseite läßt, die kein für diesen Zweck geeignetes Interface aufweisen. Also mach dich mit dem Gedanken vertraut, entweder ein Brennprogramm, das unter Windows läuft, zu verwenden oder dir was Passendes selbst zu schreiben. Stefan U. schrieb: > Die Software zum seriellen Bootloader heisst "Flash Loader > Demonstrator". Oder "STM32Prog" oder eben ein anderer Eigenbau. W.S.
lars schrieb: > Und wie macht man das jetzt, wenn man einen eigenen Bootloader schreiben > möchte, der Daten bspw. von einer SD-Karte liest und die Anwendung auf > dem STM32 überschreibt? Habe dazu mit Google keinen brauchbaren Link > gefunden. Nun, wenn du dir die hier geteilten Links und Anregungen durchgelesen und zu Gemüte geführt hast, dann machst du das, wie bei jeder sonstigen Anwendung auch: du schreibst ein Programm, welches mittels einer entsprechenden Bibliothek für den Zugriff auf eine SD-Karte die Datei (also das Anwendungs-Image) von der Karte einliest, an die gewünschte Stelle im Flash schreibt und darauf den Wechsel zu eben dieser Anwendung durchführt. Wie dieser Wechsel dann auszusehen hat, kannst du in den dir gegebenen Links nachlesen oder bei einer Suche nach dem Begriff "In-Application Programming" (z.B.). Gruß
Ich wähne mich zu erinnern, dass die mbed-Entwicklungsboards das über USB als Massenspeicher mit Drag&Drop machen. Der Mikrocontroller erscheint als tragbarer Speicher im PC und die neue Firmware wird einfach drauf kopiert. Das ist das mit Abstand einfachste was mir begegnet ist.
Der ST-Link in Version 2.1 meldet sich am Linux/Window PC wie ein USB Speicherstick an. Man kopiert einfach die Firmware-Datei auf diesen "Stick" und fertig. Das ist sehr Angenehm für nicht-Techniker. Daher könnte man erwägen, einfach einen fest ins Endprodukt einzubauen. Bei Ali Express bekommt man diese Adapter für weniger als 10 Euro, ich bin allerdings nicht sicher, ob da die Firmware in Version 2.1 drauf ist bzw. installierbar ist.
Stefan U. schrieb: > Bei Ali Express bekommt man diese Adapter für weniger als 10 Euro Da ist zu 99% die V2.0 drauf, ohne die Massenspeicherunterstützung. Auch bedient dieser ja den Programmieradapter, welcher wiederrum den µC wie SWD oder seriell programmiert. Das ist dann halt auch wieder kein reines IAP. Aber wie oben bereits erwähnt: Ein USB-CDC in den Bootbereich schieben, und sich dann selbst eine Anwendung dafür schreiben, dann klappt das auch mit reinem USB Kabel zum Flash beschreiben. Auf einem STM32 hab ich dies selbst noch nicht gemacht, weil die drei SWD Pins anzustöbseln hat mich noch nicht weiter gestört. Bei einem MEGA32u4 hab ich dies aber bereits umgesetzt. Via USB-CDC ein definierten String gesendet, welcher den Mega32 in Bootbereich schickte und dann von dort halt die Daten entgegengenommen und in den Flash geschrieben. Interrupts wieder auf die neue Startadresse gelegt und von der Adresse gestartet... Fertig war der USB-IAP. Beim STM32 dürfte das dann das gleiche werden. Klingt zumindest interessant und werde ich mir wohl auch mal machen.
DraconiX schrieb: > Aber wie oben bereits erwähnt: Ein USB-CDC in den Bootbereich schieben Warum dann nicht gleich ein USB-MSC oder DFU? Oder ein ganz eigenes Protokoll mit eigener PC-Software, das geht auch ohne extra Treiber und ist unwesentlich komplizierter als Zugriff auf Serial Port, dafür aber stabiler/anwenderfreundlich (muss keinen Port auswählen).
bla schrieb: > Ich wähne mich zu erinnern, dass die mbed-Entwicklungsboards das über > USB als Massenspeicher mit Drag&Drop machen. Das machen die aber über einen zweiten uC auf dem Board. Viele uC von NXP haben einen Bootloader der selber USB MSD im ROM hat, das hilft dem TO aber auch nicht.
Ich habe mal so einen Bootloader für einen STM32F407 geschrieben, mit einer kleinen Logik sozusagen. Mehr aber als Machbarkeitsanalyse und Erfahrung für mich für die Zukunft, habe den Bootloader bislang aber noch nicht bei mir eingesetzt, weil meine Hobbyprojekt es nicht erforderten :) Funktioniert hat er aber in meinen Tests, wie geplant - so viel schon mal vorweg :) Genau war der Ablauf aber so: Der Bootloader liegt im Bereich 0x08000000-0x08000FFF des Flash und hat die FatFS- und eine schlanke Crypto-Bibliothek mit an Bord. Der verbleibende Flash bietet Platz für ein Anwendungsimage und ein paar Statusinfos. Sobald der Controller startet, schaut der Bootloader zunächst nach einer bestimmten Datei (einem Anwendungs-Image) auf der SD-Karte und geht wie folgt vor: a) Kein Image gefunden Der Bootloader deaktiviert alle Interrupts, deinitialisiert sämtliche Peripherie, führt die notwendigen Kommandos zur Relokation der Vektortabelle aus und springt schließlich zur Anwendung ab 0x08001000. b) Image gefunden Das Anwendungs-Image ist ein zuvor ganz normal geschriebenes Programm, wie jedes andere auch, nur die Startaddresse wurde entsprechend in der Linker-Datei geändert. Zusätzlich dazu habe ich über ein Post Build-Skript eine Signatur dem Image vorangestellt. Der Bootloader liest nun dieses Image ein, verifiziert die Signatur, schreibt das Image im Erfolgsfall ab Addresse 0x08001000 in den Flash und fährt wie unter a) fort. Bei fehlgeschlagener Signaturprüfung wird ein Fehler gelogt, welcher bei Ausführung des alten Images gemeldet wird. Soweit der grobe Ablauf eines solchen möglichen Bootloaders. Nun kann man diesen ganzen Prozess beliebig komplex oder einfach gestalten. Denkbar ist z.B. das alte Image im Flash beizubehalten und stattdessen das neue Image an eine weitere Addresse zu schreiben und dann zu wechseln. So hat man ein funktionierendes Image immer vorhanden und kann immer noch ein Rollback durchführen, wenn irgendwann doch etwas nicht laufen sollte. Das halbiert natürlich den verfügbaren Platz für die Anwendung, das ja nun zwei davon in den Flash passen müssen. Nur mal als Idee. Natürlich kann man sich auch den Zauber mit einer Signatur sparen, ich habe das lediglich in meinen Bootloader eingebaut, um, wie bereits gesagt, für die Zukunft zu wissen, wie ich es anstelle, dass nur von mir erstellter und signierter Code ausgeführt wird. Ich hoffe, meine Ausführung kann dem ein oder anderen noch als Anregung zu dem Thema dienen. Gruß
:
Bearbeitet durch User
A.. P. schrieb: > Genau war der Ablauf aber so: Danke, das war jetzt hilfreich. Ich meine, Leute, ich weiß, was ich machen muß, ich weiß nur nicht wie! Also ganz konkret: 1. Wie schreibe und installiere ich einen Bootloader? (Insb. wie sieht das Linker-Script dafür aus?) 2. Wie kann ich Zeug ins Flash schreiben? (Wird ja kein memcpy sein, oder?) Links genügen.
lars schrieb: > 2. Wie kann ich Zeug ins Flash schreiben? Das steht im Reference Manual für deinen Controller, für einen F407 wäre das z.B. www.st.com/resource/en/reference_manual/dm00031020.pdf Dort unter Kapitel 3 "Embedded Flash memory interface" lars schrieb: > 1. Wie schreibe und installiere ich einen Bootloader? (Insb. wie sieht > das Linker-Script dafür aus?) Installieren musst du den ganz genau so wie ein "normales" Programm. Das Linker-Script des BL selbst ist auch nicht unterschiedlich, lediglich das für die Applikation, die der BL dann ausführen soll muss angepasst werden (Ursprung des Flash != 0x8000000 sondern versetzt um die Größe des BL, d.h. in etwa 0x08001000 wie im Beispiel von arnonym). Wie man den schreibt: 1. Auf irgendeiner Schnittstelle lauschen ob etwas geschrieben werden soll 2. Wenn etwas geschrieben werden soll "Zeug ins Flash schreiben" 3. Wenn nicht, dann die Applikation starten, welche bereits geschrieben wurde
lars schrieb: > Danke, das war jetzt hilfreich. > > Ich meine, Leute, ich weiß, was ich machen muß, ich weiß nur nicht wie! Dann hast du irgendwie die falschen Fragen gestellt oder dein Problem nicht genau beschrieben. In meiner obigen Beschreibung steckte doch das "Wie" und das "Was" mit drin. Oder war dein einziges Problem jetzt, zu verstehen, dass der Bootloader auch nur ein Stück Programm ist, dass irgendwo im Flash des Controllers liegen muss und am besten nicht da, wo dann ein anderes Programm hin soll? Dass ich nicht beschrieben habe, dass du für diesen Bootloader eine Entwicklungsumgebung deiner Wahl bedienen und danach das Programm flashen musst, war irgendwie selbstverständlich aufgrund der Art deiner Frage. Die notwendigen Infos, wohin und wie, hab ich dir doch in Form von Beispieladdressen oder dem Hinweis auf die Änderung der Addresse im Linker-File gegeben.
Die Königsklasse ist dann einen Bootloader zu schreiben der auch sich selbst updaten kann ;-)
Eric B. schrieb: > Die Königsklasse ist dann einen Bootloader zu schreiben der auch > sich > selbst updaten kann ;-) Dazu muss der sich lediglich in den RAM kopieren und von da laufen. Das ist auch bei "normalen" Bootloadern nicht verkehrt, um auch während des Flashens reagieren zu können. Allerdings steigt dadurch die Gefahr des "Brickens" deutlich an, weshalb man sich das gut überlegen sollte!
Dr. Sommer schrieb: > Eric B. schrieb: >> Die Königsklasse ist dann einen Bootloader zu schreiben der auch >> sich >> selbst updaten kann ;-) > > Dazu muss der sich lediglich in den RAM kopieren und von da laufen. Dazu müste er ins RAM passen. Einfacher ist es, keine einfache eine Applikation zu schreiben, die, wenn sie läuft, den neuen Bootloader installiert.
Torsten R. schrieb: > Dazu müste er ins RAM passen. Wenns nicht gerade einer der allerkleinsten STM32 mit 2kB RAM ist, müsste der Bootloader schon ziemlich ineffizient programmiert sein, damit er nicht passt! Bei den STM32 mit nur einer Flash-Bank (das sind die meisten) wird der Bootloader blockiert während des Schreibens (z.T. für > 1sec), sodass er nicht mehr auf das Protokoll o.ä. reagieren kann. Wenn das ein Problem ist, muss man den BL sowieso in den RAM kopieren... Torsten R. schrieb: > Einfacher ist es, keine einfache eine > Applikation zu schreiben, die, wenn sie läuft, den neuen Bootloader > installiert. Das ist auch gut. Dabei aber aufpassen dass nicht bei jedem Start neu geflasht 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.