Hi, bin gerade dabei mir einen Bootloader für meinen LPC1758 Prozessor zu schreiben, der die Applikation laden und über USB updaten kann. Momentan interessiert mich vor allem der Firmware-Update Vorgang über USB. Wie überträgt man die Daten am Besten vom Rechner auf den LPC - über ein HID Interface oder mittels DFU (device firmware upgrade)? Falls DFU eine gute Möglichkeit darstellt, benötigt man für diesen einen eigenen Treiber unter Windows, Linux oder Macintosh oder werden diese Treiber bereits mit dem OS mitgeliefert? Der Updatevorgang soll über eine entsprechende Rechnerapplikation vom Endanwender durchgeführt werden können; diese möchte ich gern in Qt programmieren, so dass ich sie für alle OS erzeugen kann. Von meiner IDE erhalte ich den Sourcecode u. a. als Hex-File. Dieses beinhaltet ja den Code, der im Flash vom LPC gespeichert werden muss. Um sicherstellen zu können, dass beim Updateprozess auch die richtige Datei ausgewählt worden ist, wollte ich gerne in diesem Hexfile noch eine Prüfsumme sowie ein Codewort integrieren. Mit welcher Software kann man das ohne viel Aufwand hinzufügen, sowie eine Prüfsumme bilden? Bis jetzt hab ich nur einen Hexeditor. Ein Programm welches mir die Prüfsumme eines Hexfiles direkt angibt, wäre super. Bei den meisten anderen USB-Produkten erhält man im Normalfall ein .exe oder .bin File für den Updateprozess und kein .hex File. Welche Schritte sind zusätzlich im µController notwendig, damit man aus einem .exe oder .bin File wieder den eigentlichen Code fürs Flash erhält? Sollte während des Updatevorgangs ein Stromausfall etc. passieren, so dass zwar der Bootloader geladen werden kann aber nicht die Applikation, sollte diese auch nicht gestartet werden. Dies wollte ich über eine Variable erreichen, die im Bootloadercode bei jedem Start aus einem externen Eeprom ausgelesen wird. Diese gibt an, ob die Applikation erfolgreich gespeichert worden ist, ein Updateprozess im Gange ist bzw. keine bootbare Applikation existiert. Ist das ein guter Ansatz oder gibt es bessere? Welche Punkte sind bei einem Update der Applikation noch zu berücksichtigen? Hatte noch vor, nach dem kompletten Schreibvorgang vom RAM ins Flash einen Verify durchzuführen anhand der Prüfsumme die ebenfalls mit übertragen worden ist. Gruß Lars
Ich kann nur einige der Fragen beantworten:
Prüfsummen von beliebigen Dateien erstellst du unter Linux mit dem
Befehl md5sum oder cksum (je nach gewünschtem Algorithmus). Unter
Windows kannst DU Cygwin instalieren, um diese Programme zu erhalten.
Diese Updates im exe Format enthalten sowohl das nötige PC-Programm, als
auch das Programm für das Ziel-Gerät. Sie entpacken sich selbst beim
Ausführen.
Die Dateien im bin Format enthalten Maschinencode des Ziel-Gerätes.
Diese Dateien werden in der Regel 1:1 am Stück in den Programmspeicher
übertragen. Dazu brauchst Du noch ein Hilfsprogramm, denn Windows kann
weder mit dem Dateiformat umgehen, noch weiß es, wie mit diem Zielgerät
zu kommunizieren ist.
Hex Dateien sind wiederum ein Container-Format für binäre Dateien. Sie
bieten den Vorteil, Prüfsummen zu enthalten und man kann mehrere
Speicherbereiche updaten.
> ...Ist das ein guter Ansatz oder gibt es bessere?
Ich würde sagen: ja. Oder du bettest die Prüfsumme in den Maschinencode
ein und der Bootloader überprüft sie bei jedem Power-Up, bevor die
Firmware ausgeführt wird.
Stefan schrieb: > Ich würde sagen: ja. Oder du bettest die Prüfsumme in den Maschinencode > ein und der Bootloader überprüft sie bei jedem Power-Up, bevor die > Firmware ausgeführt wird. das klingt sogar noch etwas besser. Vielleicht kann ich den Zugriff aufs Eeprom im Bootloader-Code ganz weglassen. Der Bootloader-Code beinhaltet eine globale Variable, die sich fest an einer Stelle im Flash befindet (immer die gleiche, wenn das über die IDE - Keil in meinem Fall - möglich ist) und überschreibt diese mit dem aktuellen Stand der Applikation: ob diese gestartet werden kann oder nicht.
Bei uns besteht das Update File aus einem zip, welches neben dem eigentlichen bin/hex noch eine XML beinhaltet. Darin sind z.B. die Hash vom bin/hex sowie Informationen für welche Zielhardware das Update ist. Dieses XML ist mit unserer Code Signing Signatur signiert und wird vom Update Programm gegen den im Updater gespeicherten public key getestet.
Hast du dir schon die AN10866 von NXP angeschaut? Das ist ein Beispiel für einen USB-Bootloader, welcher sich am PC als Massenspeichergerät anmeldet. Firmware-Updates sind dann so einfach wie das Verschieben einer Datei von einem Ordner in den anderen. Die Methode mit dem Massenspeicher mag vielleicht nicht sehr Praxisnah sein, ist aber dennoch ein sehr schönes Beispiel und beantwortet möglicherweise viele deiner Fragen. http://www.lpcware.com/content/nxpfile/an10866-lpc1700-secondary-usb-bootloader
Christian R. schrieb: > Bei uns besteht das Update File aus einem zip, welches neben dem > eigentlichen bin/hex noch eine XML beinhaltet. wie schickt ihr den Code über USB? Via HID Interface und Bulktransfer oder verwendet ihr das DFU Protokoll? Alexander B. schrieb: > mit dem Massenspeicher mag vielleicht nicht sehr Praxisnah sein Einen Massenspeicher möchte ich während des Updatevorgangs nicht angezeigt bekommen. Das Beispiel von NXP hab ich mir bereits angeschaut; allerdings ist die Anwendung eine völlig andere, so dass mir der Code keine großen Erkenntnisse bringt, wie man sinnvollerweise ein Firmwareupdate durchführt.
Lars schrieb: > Einen Massenspeicher möchte ich während des Updatevorgangs nicht > angezeigt bekommen. Das Beispiel von NXP hab ich mir bereits angeschaut; > allerdings ist die Anwendung eine völlig andere, so dass mir der Code > keine großen Erkenntnisse bringt, wie man sinnvollerweise ein > Firmwareupdate durchführt. Okay. Das Ding ist, dass es schwierig wird den Update-Vorgang zur Laufzeit durchzuführen. Der LPC hat nämlich nicht gerade viel RAM. D.h. du müsstest die Firmware scheibchenweise übertragen und in den Flash schreiben. Wenn da dabei die Verbindung abreist oder ein Paket korrumpiert ist ... naja. Die Alternative wäre die Firmware erst komplett in einen Bereich zu schreiben, der von der aktuellen Firmware definitiv nicht genutzt wird. Dann könntest die diese validieren und im Anschluss an die richtige Position im Flash kopieren bzw. extrahieren. Nachteil ist dann, dass du ein Teil des Flashes für Firmware-Updates immer frei halten musst. Ein Secondary-Bootloader, wie in der AN, hat den zuletzt genannten Nachteil nicht. Oder dein Gerät hat noch externen RAM/Flash für diesen Zweck. Das kannst uns nur du sagen ^^. Was die USB-Klasse angeht ist DFU doch eine schöne Sache. Immerhin soll es dafür standarisierte Programme bzw. Treiber auf PC-Seite geben. Da müsstest du keinen Aufwand investieren. Ein Vendor-Specific-Protocol wäre (zumindest aus meiner Sicht) auch eine Option, der hat dann aber doch mehr Aufwand zur Folge. Aber du kannst darüber auch noch andere Kommunikation abwickeln.
DFU ist vom Prinzip her eine feine Sache aber Win bis Vista hat keine Treiber ob es einen bei W7 oder W8 gibt kann ich nicht sagen. Das beteutet Treiber schreiben (mit allen Konzequenzen wie WHQL Zertifizierung und so weiter. Versuche das Ganze mit einem HID zu lösen und du bist das Treiberthema los. WinUSB wäre wohl auch noch eine Option. Ich habe damals mein eigenes Protokoll gebastelt und Update FW und Runtime FW strikt getrennt. Update und Firmware lagen dann in verschiedenen Flashpages. Ich konnte deshalb die FW Page jederzeit löschen un neubeschreiben wenn die Update software aktiv war. Etwas aufpassen muss man halt bei den Interupts. Thomas
Lars schrieb: >> Bei uns besteht das Update File aus einem zip, welches neben dem >> eigentlichen bin/hex noch eine XML beinhaltet. > > wie schickt ihr den Code über USB? Via HID Interface und Bulktransfer > oder verwendet ihr das DFU Protokoll? Über die normale USB Kommunikation. Das Gerät ist ohnehin über USB als Frontend angebunden. Ohne USB wäre es ein teurer Briefbeschwerer. Läuft bei uns mit WinUSB und BULK Modus, eigenes Protokoll. Der FPGA kann seinen SPI Flash selber updaten. Mit Multiboot und FallBack geht das auch risikoarm.
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.