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.
Eine eigene Frage?
Dieser Thread ist über 13 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
