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.
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.
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
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
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.
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.
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.
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
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 ?
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 ;)
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.
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
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.
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.
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"
Was ist, wenn das nächste Windows FAT12 nicht mehr unterstützt?
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.
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.
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.
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/
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.
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.
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 :-)
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
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.
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.
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.
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.