Forum: Mikrocontroller und Digitale Elektronik STM32 Bootloader mit USB Device Mass Storage


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

bei meinem kommenden Projekt möchte ich den µC per Mass Storage Device 
updaten können.

Ich verwende einen STM32F767.
Das Update soll ähnlich laufen, wie es bereits auf den Nucleo Boards 
läuft.
Massenspeicher wird erkannt und .bin Datei kann per Drap and Drop 
kopiert und geflasht werden.

Aber wie stellt man das an?
Den µC als Mass Storage Device ausgeben und Dateien annehmen funkniert 
bereits dank
https://www.youtube.com/watch?v=GjQqZd1keBo
Allerdings sind die erhaltenen Daten natürlich im NTFS Format. Ich 
benötige hier ja nur den Inhalt.

Meine Idee wäre einen Bootloader zu schreiben, welcher fast seinen 
gesamten Ram als Speichergerät freigibt.
Anschließend wird per NTFS Bibliothek von STM diese Datei geöffnet und 
in den Flash geschrieben.
Dies hat jedoch den Nachteil, dass die Firmware nur so groß wie der RAM 
sein darf. Außerdem wird die NTFS Bibliothek auf dem Bootlaoder 
benötigt, was bestimmt viel Platz Flash verbracht.

Bei NXP gibt es jedoch eine Application Note:
https://www.nxp.com/docs/en/application-note/AN4379.pdf
Diese realisieren dass über ein Pseudo Ram + Parser.

Hat jemand eine Idee, wie man das realisieren könnte?
Oder gibt so ein Pseudo Ram + Parser vielleicht bereits fertig?
Oder ein Beispiel?

Ich verstehe nicht, wieso man für dieses Thema kaum etwas im Internet 
findet, dabei kann man dies doch bei einer vielzahl von Projekten 
benötigen.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Ich verstehe nicht, wieso man für dieses Thema kaum etwas im Internet
> findet, dabei kann man dies doch bei einer vielzahl von Projekten
> benötigen.

Die meisten Bastler sind schon froh, wenn sie seriell kommunizieren 
können.

Dieses USB Storage Ding ist erheblich komplizierter und birgt daher eine 
Menge Fallstricke. In 5 Jahren habe ich dieses Feature nur ein einziges 
mal benutzt - zum Ausprobieren meines ersten Nucleo Boardes. So wirklich 
viel kann ich damit nicht anfangen.

Ich brauche ohnehin einen ST-Link zum Debuggen, um die Option Bytes 
einzustellen und um log Meldungen anzuzeigen. Und wenn ich ein fertiges 
Gerät aus der Hand gebe, dann ganz sicher nicht mit der Möglichkeit, 
beliebige Dateien per Windows Explorer zu installieren. Das gibt nur 
Ärger, wenn es wegen falscher Firmware "kaputt" geht.

von Hans W. (Firma: Dipl.-Ing. Johann Maximilian W) (hans-)


Bewertung
1 lesenswert
nicht lesenswert
Außerdem hat der STM32 schon von Haus aus einen USB-Bootloader.

Das DFU Tool ist auch nicht viel komplizierter als die Mass-Storage 
Lösung.

73

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
ich würde das MSD eher auf ein SPI Flash oder SD Card als Puffer 
schreiben lassen.
Mit Mbed ein zwei Zeiler: 
https://os.mbed.com/docs/mbed-os/v6.5/apis/usbmsd.html

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> ich würde das MSD eher auf ein SPI Flash oder SD Card als Puffer
> schreiben lassen.

Ich auch. Wobei SD Karten gleich die nächsten Fallstricke mit sich 
bringen. An embedded Geräten funktionieren noch lange nicht alle. Auch 
nicht alle Formatierungen.

Und dann versuche mal, 10 Jahre später eine kompatible Karte zu 
empfehlen. Ich habe eine Kamera, in der maximal 128 MB funktionieren. 
Wenn die kaputt geht, war's das.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
Da kann ich dir noch eine Handvoll 64 MB Karten schenken.
Bei den SDC wird ja oft die Elm Chan Implementierung benutzt, und da 
gibt es einige Stellschrauben. Bei den STM32F4/F7 habe ich bisher keine 
Karte gehabt die nicht funktionierte, bis bisher 32 GB SDHC.
Aber die kleinen 8 Pin Flash IC bieten ja auch mehrere MB für unter 1 
Euro.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Da kann ich dir noch eine Handvoll 64 MB Karten schenken.

Zwei Stück könnte ich wirklich gut gebrauchen. Ich bezahle dir natürlich 
das Porto und einen Kaffee. Ich schicke dir meine Adresse per PN.

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Hans W. schrieb:
> Außerdem hat der STM32 schon von Haus aus einen USB-Bootloader.

Ich weiß, dieser wird in einem vorherigen Projekt bereits verwendet.
Allerdings ist das immer ein riesen Theater mit der separaten 
Update-Software.
Manche Kunden wollen das wohl einfach trotz Handbuch nicht 
verstehen.....

Außerdem reizt mich der Mass Storage Bootlader mehr :P



Auf meiner Platine wird es ein SDRAM geben.
Dieses wird für den Framebuffer eines Displays benötigt.
Hier könnte der Bootloader wahrscheinlich die Firmware ablegen.
Das würde ich als nächsten Schritt einmal ausprobieren, allerdings muss 
ich mich noch in die STM32 FATFS Bibliothek einlesen.

Ich kenne jedoch ein Fremdgerät welches mit NXP µC läuft und das Update 
auf diese weise umsetzt. Hier ist auf der Platine kein seperater 
Speicher vorhanden.
Wie gesagt muss ja auch der STLink auf den Nucleo Boars so arbeiten.
Es muss also irgendwie gehen :P

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Allerdings ist das immer ein riesen Theater mit der separaten
> Update-Software.
> Manche Kunden wollen das wohl einfach trotz Handbuch nicht
> verstehen.....

Du wirst dich natürlich an den Wünschen deiner Kunden orientieren.

Ich musste mich schon mit einer angeblichen Senior Java Consulterin 
(schreibt man das so?) herum schlagen, die nicht einmal den Windows 
Explorer bedienen konnte. Für die wäre ein spezielles Flash-Tool 
einfacher gewesen.

Aber das ist hoffentlich nicht der Regelfall.

> Es muss also irgendwie gehen

Das denke ich auch. Die Cube HAL enthält dafür ja sogar ein rudimentäres 
Beispielprogramm.

Diese Diskussion sieht vielversprechend aus: 
https://community.st.com/s/question/0D50X00009Xkejt/need-usb-mass-storage-device-example-code-for-stm32f4-discovery-board 
?

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Allerdings ist das immer ein riesen Theater mit der separaten
> Update-Software.
> Manche Kunden wollen das wohl einfach trotz Handbuch nicht
> verstehen.....

Wie willste denn absichern, dass die Kunden dann kein falsches bin 
draufbügeln?
Man könnt jetz nen Versions und Hardwaredescriptor als Header 
davorhängen und der Bootloader wertet das aus vorm Update.
Aber hat das Gerät denn ein Display zum Anzeigen einer solchen 
Fehlermeldung?

Sobald "Kunde" ins Spiel kommt wirds kompliziert ;)

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Wie willste denn absichern, dass die Kunden dann kein falsches bin
> draufbügeln?

Entweder über den Dateinamen oder gar nicht xD

Der Bootloader welcher von Haus aus drauf ist kann das ja auch nicht 
prüfen.

Wichtig ist nur, dass der Booloader nicht überschrieben wird und das 
kann bei einer falschen Datei nicht passieren.
Der Bootloader soll sich stehts über einen Tastendruck beim einschalten 
starten.

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Diese Diskussion sieht vielversprechend aus:
> 
https://community.st.com/s/question/0D50X00009Xkejt/need-usb-mass-storage-device-example-code-for-stm32f4-discovery-board
> ?

Ist leider nicht ganz dasselbe.
Die verwenden hier einen separaten Speicher.
Die Links auf der Seite gehen leider größtenteils auch nicht mehr.

Aber ich hab inzwischen meine Frage auch mal im ST Forum gestellt :P

von uf2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hans W. schrieb:
> Außerdem hat der STM32 schon von Haus aus einen USB-Bootloader.
>
> Das DFU Tool ist auch nicht viel komplizierter als die Mass-Storage
> Lösung.
>
> 73

doch, man muss einen DFU Treiber installieren unter Windof.

Es gibt das UF2 Format (https://github.com/microsoft/uf2) (benutzen wir 
auf Prototypen):
Dort nutzt man die Packetierung des (Fake-) FAT12 Dateisystems aus um 
das Parsing und Handling auf Controllerseite sehr leicht zu halten.
Sowohl falsche Dateien als auch Firmwares für andere Geräte werden 
robust ignoriert. Somit sehr viel sicherer als naive Implementierungen 
die .hex files (oder sogar .bin) flashen können.


Nachteile:

- kann kein .hex/.bin Dateien, sondern Dateien müssen konvertiert werden 
(machen wir per makefile).
- keine checksum für gesamte Firmware vorgesehen. Dies haben wir selbst 
hinzugefügt, bei uns wird eine Checksumme beim konvertieren ans Ende der 
Firmware angefügt.


FAT12 ist mindestens 65kB groß, d.h. unter 65kB RAM geht gar nichts, 
wenn man wirklich .hex und .bin files flashen will. UF2 umgeht das 
Problem mithile eines Fake Dateisystems, das geht aber nur weil es ein 
spezielles Dateiformat benutzt.

von uf2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Habe gerade festgestellt, dass das Problem der fehlenden Checksum für 
die gesamte Firmware mittlerweile über Extension Tags gelöst wurde.
Damit hat es fast keine Nachteile mehr.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:

> Meine Idee wäre einen Bootloader zu schreiben, welcher fast seinen
> gesamten Ram als Speichergerät freigibt.

Warum würdest Du das machen wollen? Der Bootloader muss doch nur das 
entsprechende Protokoll sprechen und nicht die Daten mit dem 
Protokoll-Overhead ablegen. Ich hatte das mal für fat12 implementiert 
(auch für einen Bootloader für einen STM32) und nur für sehr kleine 
Dateien, die z.B. OS/X anlegt, das RAM verwendet. Sobald das USB Kabel 
getrennt wurde, sind Dateien dann weggeworfen worden.

> sein darf. Außerdem wird die NTFS Bibliothek auf dem Bootlaoder
> benötigt, was bestimmt viel Platz Flash verbracht.

> Hat jemand eine Idee, wie man das realisieren könnte?
> Oder gibt so ein Pseudo Ram + Parser vielleicht bereits fertig?
> Oder ein Beispiel?

Für USB Mass Storage kannst Du die Bibliotheken von ST nehmen. Zumindest 
FAT12 ist relativ einfach implementiert. Meine Recherche zu dem Thema 
hatte ich "damals" hier im Forum gestartet: 
Beitrag "welches Filesystem"

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Was ist, wenn das nächste Windows FAT12 nicht mehr unterstützt?

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Was ist, wenn das nächste Windows FAT12 nicht mehr unterstützt?

Dann würden wahrscheinlich sehr viele, alte USB-Sticks und SD-Karten 
nicht mehr funktionieren.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du MSD Device verwendest braucht es irgendeinen Speicher der deine 
Firmware vor dem Flashen komplett aufnehmen kann.  Das kann ein SPI 
Flash sein. Alles andere wäre mir persönlich zu frickelig.

Ich würde einen anderen Weg gehen. Schalte deinen USB Port in den 
Hostmode und enumeriere einen USB-Stick.
Der Kunde braucht dann nur ein OTG Adapter für den Stick. Fast immer 
sind Sticks mit fat32 formatiert und wenn du dich darauf beschränkst 
wird die Auswertung ziemlich einfach.
Ein weiterer Vorteil ist, du kannst mit einer CRC Prüfung feststellen ob 
ein Flashen überhaupt notwendig ist.
Neben dem FAT Code brauchst du eigentlich nur noch eine FileSearch und 
eine FileOpen Funktion danach kannst du Sektor für Sektor vom Stick 
lesen. Du bekommst dann immer einen Block (512 Bytes) mit dem du machen 
kannst was du willst. Denn Filenamen würde ich nur in 8.3 zulassen dann 
braucht es auch kein LFS Support, was die Sache weiter vereinfacht.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Dann würden wahrscheinlich sehr viele, alte USB-Sticks und SD-Karten
> nicht mehr funktionieren.

Ich habe nicht den Eindruck, das dies bei Microsoft Mitleid erregen 
würde.

von Til S. (Firma: SEGGER) (til_s)


Bewertung
1 lesenswert
nicht lesenswert
Matthias F. schrieb:
> bei meinem kommenden Projekt möchte ich den µC per Mass Storage Device
> updaten können.

Kommerzielles Projekt? Dann könntest du vielleicht was fertiges 
einsetzen:
https://www.segger.com/products/field-upgrades/emload/

von René F. (therfd)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Was ist, wenn das nächste Windows FAT12 nicht mehr unterstützt?

Halte ich ebenfalls für unwahrscheinlich, implementiert ist es ja schon 
und Microsoft möchte seit vielen Jahren Windows stärker im Embedded 
Bereich platzieren, wo FAT12 vermutlich noch lange eine Rolle spielen 
wird, sei es nur abwärtskompatibilität. Selbst heute versucht Microsoft 
Visual Basic 6.0 Programme unter Windows 10 lauffähig zu halten. Gab vor 
einiger Zeit (Herbst 2019) ein Update, welches diverse VB6, VBA und 
VBScript Programme unbrauchbar machte, das haben die Leute aus Redmond 
ziemlich schnell gefixt.

Alternativ gäbe es, sollte es wirklich so weit kommen bestimmt freie 
Implementierungen von FAT12 für Windows. Windows lässt sich die 
Unterstützung anderer File-Systeme beibringen. Beispiel wäre Paragons 
ext2/3/4 Implementierung die die Implementierung von Apple, welche es 
BootCamp Installationen ermöglichte auf das Mac Dateisystem zuzugreifen.

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Matthias F. schrieb:
> bei meinem kommenden Projekt möchte ich den µC per Mass Storage Device
> updaten können.

Matthias F. schrieb:
> Ich verstehe nicht, wieso man für dieses Thema kaum etwas im Internet
> findet, dabei kann man dies doch bei einer vielzahl von Projekten
> benötigen.

Wenn man sowas für sich selbst gebraucht, dann ist das ja auch in 
Ordnung - vorausgesetzt, der µC bietet es von hause aus an. Einige 
LPCxxx können das, aber im Grunde sind es relativ wenige µC, die einen 
Bootlader mit derartigen Fähigkeiten enthalten.

Und warum es kaum jemand mit eigener Software tut? Ganz einfach: Man 
braucht es eigentlich selbst nicht, es ist kompliziert selber zu 
schreiben, es läßt sich nicht gut kontrollieren und es macht Probleme, 
weil so ein Bootlader nicht in einem eigenen Speicher steht, sondern im 
Anwendungs-Flash vorgehalten werden muß, deshalb auch auf irgend eine 
Weise vor dem Löschen geschützt werden muß und so weiter.

Kurzum, ich halte so einen Bootlader bei Geräten, die an Kundschaft 
herausgehen, überhaupt nicht für erstrebenswert.

Mach es lieber anders, USB ist ok, aber eher als VCP. Dort ist 
Kommunikation angesagt und damit ein Protokoll zwischen PC und µC. Das 
macht es leicht, die Nutz-Firmware in Stücke aufzuteilen, 1K bis 16K 
oder so je nach Gusto, diese Stücke ordentlich zu verpacken (Frame und 
Adler32) und auch das an die Kundschaft herausgehende Update-File nach 
Gusto zu packen - aber nicht Zip, Rar und so, die kennt ja jeder. Und 
man kann es auf der PC-Seite auch so halten, daß man ein simples 
GUI-Tool dazuliefert, was eben nicht installiert werden muß, was eine 
Vorprüfung des Updatefiles erledigen kann und was auch für eine 
Bürokauffrau geeignet ist. Also so ziemlich das Gegenteil von ST's 
Dfütools.

W.S.

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Wenn du MSD Device verwendest braucht es irgendeinen Speicher der deine
> Firmware vor dem Flashen komplett aufnehmen kann.

Sorry für die späte Antwort.

Ich hab mich jetzt mal dran versucht.
Inzwischen läuft der Bootloader, mit dem SDRAM als Zwischenspeicher :-)

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
uf2 schrieb:
> Es gibt das UF2 Format (https://github.com/microsoft/uf2) (benutzen wir
> auf Prototypen):
> Dort nutzt man die Packetierung des (Fake-) FAT12 Dateisystems aus um
> das Parsing und Handling auf Controllerseite sehr leicht zu halten.
> Sowohl falsche Dateien als auch Firmwares für andere Geräte werden
> robust ignoriert. Somit sehr viel sicherer als naive Implementierungen
> die .hex files (oder sogar .bin) flashen können.

ok, vielen dank das werde ich mir dann als nächstes ansehen :-)
Aber bis ich das verstanden habe wird bestimmt noch etwas zeit 
draufgehen xD

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Til S. schrieb:
> Kommerzielles Projekt? Dann könntest du vielleicht was fertiges
> einsetzen:
> https://www.segger.com/products/field-upgrades/emload/

Für den Preis bekomme ich das leider nicht vom Vorgesetzen genehmigt.

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
Thomas Z. schrieb:
> Ich würde einen anderen Weg gehen. Schalte deinen USB Port in den
> Hostmode und enumeriere einen USB-Stick.
> Der Kunde braucht dann nur ein OTG Adapter für den Stick. Fast immer
> sind Sticks mit fat32 formatiert und wenn du dich darauf beschränkst
> wird die Auswertung ziemlich einfach.
> Ein weiterer Vorteil ist, du kannst mit einer CRC Prüfung feststellen ob
> ein Flashen überhaupt notwendig ist.
> Neben dem FAT Code brauchst du eigentlich nur noch eine FileSearch und
> eine FileOpen Funktion danach kannst du Sektor für Sektor vom Stick
> lesen. Du bekommst dann immer einen Block (512 Bytes) mit dem du machen
> kannst was du willst. Denn Filenamen würde ich nur in 8.3 zulassen dann
> braucht es auch kein LFS Support, was die Sache weiter vereinfacht.

Wenn ich dich richtig verstanden habe willst du einen USB Stick 
verwenden, welcher bereits die Firmware beeinhaltet?
Oder habe ich dich falsch verstanden?

Bei dem Projekt ist der USB B Type bereits fest gesetzt. Das heißt ich 
kann keinen USB Stick einstecken.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Wenn ich dich richtig verstanden habe willst du einen USB Stick
> verwenden, welcher bereits die Firmware beeinhaltet?
> Oder habe ich dich falsch verstanden?

Genau so bedingt allerdings dass dein Gerät eine separate 
Stromversorgung hat.

> Bei dem Projekt ist der USB B Type bereits fest gesetzt. Das heißt ich
> kann keinen USB Stick einstecken.

Typ B ist ein ein Problem dafür gibt's meines Wissens keine OTG Adapter.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.