Ich möchte mir einen Bootloader bauen, der es mir erlaubt, später die Firmware per USB-Stick upzudaten. Dazu habe ich mir zum Üben & Lernen dieses Projekt gezogen: https://github.com/rowol/stm32_discovery_arm_gcc/tree/master/STM32F4-Discovery_FW_V1.1.0 Ich arbeite unter Linux auf der Konsole. Ich konnte das Bootloader-Binary auch problemlos mit make im Ordner Projects/FW_upgrade/src bauen - es war unter anderem eine .bin-Datei mit ca. 35KB Größe. Wenn ich den Bootloader nun aber im dfu-Mode übertragen will, dann benötige ich eine .dfu-Datei. Diese ist in dem oben genannten Projekt auch als Binary vorhanden - sie ist ca. 18KB groß. OK - .bin != .dfu. Also gegoogelt und ein Python-Script namens "hex2dfu" gefunden. Dieses auf die .hex losgelassen - im Ergebnis eine .dfu :) Dummerweise ist diese sogar ein paar Byte größer als die ursprünglich erhaltene .bin - von den 18KB bin ich auf jeden Fall weit entfernt. Kann mir jemand auf die Sprünge helfen? Mit freundlichem Gruß Andreas
Wenn das Original größenoptimiert mit Keil oder IAR Compiler erstellt wurde, hat man mit GCC + newlib eher schlechte Karten. Wurde mit -Os optimiert? Bei außreichend Flash könnte man den Bootloader Bereich vergrößern.
Leider kann ich nicht mehr nachvollziehen, wie das Original gebaut wurde. Scheinbar nicht mit dem im Projekt enthaltenen makefile :( Ich bin wie gesagt hier auf Neuland: Ich habe noch nie einen Bootloader gebaut und in ein STM geflasht. Ich habe einfach Zweifel, ob mein Bootloader überhaupt lauffähig ist/wäre oder ob es einfach nur ein Haufen Binärschrott ist. Die Größe wäre nicht so das Problem - wenn ich erstmal den Weg verstanden habe und mich nicht verrenne... Ist diese Vorgehensweise richtig? - bootloader bauen (.hex, .elf, .bin - mit hex2dfu.py ein dfu erzeugen - dieses .dfu im dfu-mode auf den STM32F4 schieben oder anstelle der beiden unteren Punkte auch mit stlink-v2 das Binärfile flashen (dann bräuchte ich das dfu nicht zu erzeugen und auch den dfu-mode nicht benutzen). Wenn ich weiss, dass das der richtige Weg ist, dann wäre mir schon geholfen ;) Mit freundlichem Gruß Andreas
Andreas R. schrieb: > Ich bin wie gesagt hier auf Neuland: Ich habe noch nie einen Bootloader > gebaut und in ein STM geflasht. Ich habe einfach Zweifel, ob mein > Bootloader überhaupt lauffähig ist/wäre oder ob es einfach nur ein > Haufen Binärschrott ist. Ein Bootlader, der per USB-Stick funktioniert? Ich bin mir ziemlich sicher, daß das ein schlechtes Unterfangen ist. Dein Bootlader müßte ja zu allererst die volle Funktionalität eines USB-Hosts enthalten, dazu noch ein Filesystem, dazu noch den eigentlichen Bootlader, dazu noch ne Sicherung gegen unbeabsichtigtes Flaschen und so weiter. Das wird ein halbes oder sogar ganzes Betriebssystem! Normalerweise funktionieren Bootlader einfach über eine sinnvolle Schnittstelle (seriell, USB-CDC, SPI oder so ähnlich) und nur zusammen mit einem Gegenstück an Software auf dem PC. Sowas ist auch für dich machbar, du mußt eben bloß beide Parts planen und (extrem wichtig!) zuvor dir ein sinnvolles und robustes Protokoll auf dem Übertragungsweg ausdenken. Warum? Damit du bei beiden Teilen - dem PC-Programm und dem µC-Programm unabhängig vom jeweils anderen planen und entwickeln kannst und im Fehlerfall anhand des festgelegten Protokolls genau weißt, welcher Part das Karnickel ist. Vielleicht ist es für dich am einfachsten, den bereits im Controller eingebauten Bootlader zu benutzen. Soweit ich weiß, haben wohl alle STM32 einen im ROM eingebaut. Der muß bloß aktiviert werden über /Reset und /Boot W.S.
Klar haben die den! Das Projekt, um das es geht, nutzt zur einmaligen Behandlung den dfu-Mode und brennt damit ein knapp 50KB großes Progrämmchen. Die eigentliche Firmware kommt dann einen Block später. Wenn man bei Starten einen Affengriff macht, dann kommt man in dem Modus, mit dem man mit einem proprietären Programm die FW einspielen kann. Das o.g. Projekt macht im Prinzip das Gleiche - nur eben nicht via proprietäres Programm sondern via USB-Stick. Und Du hast Recht: es ist aufwändiger. FAT_FS ist mit drin etc. Das Ganze ist aber nur "35KB" groß... Das klingt gut - ich möchte damit experimentieren :) Es läuft auf dem Disco-Board, welches ich auch habe. Das endgültige Ziel ist dann ein SDR-Transceiver, der den STM32F4 als Kontroller einsetzt. Ich habe schon mit PICs gearbeitet und allem anderen, was mehr als 20 Beine hat - aber mit dem STM32F4 fange ich erst an und muß eben noch viel lernen :) Danke für die Hilfe - ich werde mal testen! Mit freundlichem Gruß Andreas
Hallo, muss es wirklich USB sein? Mit einer SD Karte ist die Sache sehr viel einfacher. Es gibt auch sicher schon fertige Projekte dazu. Kannst ja an Stelle eines USB-Sticks einen USB-SD-Stick + Karte ausliefern.
Es muß USB sein. Ich möchte die Hardware des Gerätes so wenig wie möglich (am Besten gar nicht) modifizieren. Zwei USB-Buchsen (OTG und Host) sind schon vorhanden. Aber das Projekt aus dem Link den ich in meinem Ursprungspost geschrieben habe ist ja exakt sowas und es ist von ST selbst mit Application Note und allem drum und dran. Ich denke, ich muss da einfach dran bleiben und verstehen, verstehen, verstehen... Mit freundlichem Gruß Andreas
Andreas R. schrieb: > Ich denke, ich muss da einfach > dran bleiben und verstehen, verstehen, verstehen... Brems dich mal damit ein wenig. Der ganze Krempel von ST ist mit deren ominöser ST-Lib derart aufgeblasen, daß man eigentlich ständig nur deren komische Strukturen jonglieren muß und zusätzlich auch noch sich um die eigentliche Hardware kümmern muß. Irgendwann ist da der Punkt gekommen, wo man all das von ST so promotete Zeugs in die Tonne treten muß und sich sein eigenes Zeugs für die unterste Hardwareebene schreibt. Ich denke mal, das ist bei dir jetzt Mode. Was benutzt du als Tools? GCC oder Keil oder IAR? Bei deiner Idee von Bootlader muß der Bootlader tatsächlich bereits ein fast vollwertiges Betriebssystem sein. Also liegt es nahe, es tatsächlich so zu tun: Ein Betriebssystem und dazu die Applikationen, die nachgeladen werden können. Das gibt nen Sinn. Guck mal in die Lernbetty (hier im Forum) rein, ich hatte dort eine Art System-Schnittstelle per SVC implementiert, die bei deinem Vorhaben von Nutzen wäre. Da können sich die Applikationen via API des Betriebssystems der Funktionen bedienen, die das BS so bietet, also in erster Linie die eigentliche Hardwarebedienung (Bildschirm, Tasten, sonstige E/A, Dateisystem usw.) Dann brauchst du bloß noch den Teil, der vermutlich im RAM laufend das Löschen und Beschreiben der hinter dem Betriebssystem liegenden Blöcke des Flash's organisiert. W.S.
Das klingt sehr vielversprechend. Danke für den Hinweis - das lese ich mir mal durch. Ich brauche auch andere Hardwarefunktionen wie Keyboard via USB etc. da macht diese Vorgehensweise in der Tat sehr viel Sinn... Mit freundlichem Gruß Andreas
Ich hatte dich nicht aus daffke nach deiner Toolchain gefragt. Der Keil kann SVC's sehr elegant implementieren, da bestehen die Funktionsaufrufe eben nur aus dem Laden der Argumente und dann einem Soft-Interrupt. Der GCC hingegen kann keine SVC's. Das ist doof, weil man da einen umständlicheren Wrapper in Assembler braucht. Beim IAR kenne ich mich nict aus, vermute aber, daß er ebenfalls SVC direkt kann. W.S.
W.S. schrieb: > Bei deiner Idee von Bootlader muß der Bootlader tatsächlich bereits ein > fast vollwertiges Betriebssystem sein. Also liegt es nahe, es > tatsächlich so zu tun: Ein Betriebssystem und dazu die Applikationen, > die nachgeladen werden können. Das gibt nen Sinn. Bevor man diesen Schritt geht, muss man sich ganz klar vor Augen halten, warum man einen Bootloader verwenden möchte: a) weil man als Entwickler oft neue Firmware ins Gerät laden möchte und das über die vom Bootloader angebotene Schnittstelle bequemer ist. Wenn man aber mal den Bootloader selbst ändern möchte oder was schief geht, ist das mit SWD etc. aber auch kein großes Problem. b) weil ein Gerät beim Kunden draußen auch vom Kunden aktualisiert werden können soll. Der Kunde hat keine Möglichkeit einen Debugger anzuschließen und ein Fehler im Bootloader bedeutet Gerät defekt mit Einsatz eines Servicetechnikers vor Ort oder Einschicken des Geräts. Für Fall b) würde ich den Bootloader so klein und einfach halten wie möglich, denn Du wirst den Bootloader selbst nicht ohne Risiko updaten können. Ein Bootloader als eine Art Betriebssystem mit ladbaren Modulen verbietet sich da dann eigentlich. Für Fall a) kann man natürlich solche Szenarien mit ladbaren Applikationsmodulen andenken. Aber vorher sollte man schon mit Linkerskripts, Startadressen etc. sattelfest sein.
:
Bearbeitet durch User
Ich hatte mal Embedded Linux zu tun. Da gab es eine Ebene, die solche Grundfunktionalitäten ermöglichte. Das ganze nannte sich uboot von der Firma Denx. http://www.denx.de/wiki/U-Boot Wie weit es für den STM32 Portierungen gibt weiß ich nicht. Würde abe genau in deiner Wellenlänge liegen.
Ich weiß es auch nicht so recht. Nach dem Post von W.S. habe ich mich mal an das Projekt gemacht und bin nach ein paar Stunden fertig gewesen. Das Beispiel lief ja auf dem Disco-Board - ich musste also die Beschaltung des vorliegenden Gerätes (Leuchtdioden, Taster etc.) anpassen und auch ein paar Adressen. War aber nicht wirklich wild. Das fertige Produkt möchte ich bei knapp 20kb Größe irgendwie nicht als "komplettes Betriebssystem" bezeichnen und es tut genau das, was es soll... Daher möchte ich den Thread gerne schließen, wenn das ginge, und Leute, die sowas auch machen möchten, auf das von mir erwähnte Projekt aufmerksam machen. Da ist alles drin, was man braucht. Die kleinen Fehlerchen (sichern der bestehenden Firmware NACH dem neuflashen...) kann man leicht selbst geradebiegen. Viele Grüße Andreas
René D. schrieb: > Ich hatte mal Embedded Linux zu tun. Da gab es eine Ebene, die solche > Grundfunktionalitäten ermöglichte. > > Das ganze nannte sich uboot von der Firma Denx. > http://www.denx.de/wiki/U-Boot > > Wie weit es für den STM32 Portierungen gibt weiß ich nicht. Würde abe > genau in deiner Wellenlänge liegen. gibt es hier als source: https://github.com/EmcraftSystems/u-boot und hier als binary: http://www.emcraft.com/stm32f429discovery#release-materials
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.