STM32 Bootloader: So stellen Sie sicher, dass nur unbeschädigte Firmware bootet

Das Booten in einen gelöschten Flash führt schnell zum Absturz

Dies kann passieren oder auch nicht – je nachdem, was geschrieben wurde und was nicht. Beachten Sie, dass abhängig davon, wie der Flash aktualisiert wird und wann, möglicherweise keine gelöschte Flash-Seite vorhanden ist – nur einige mit neuen und einige mit alten Daten.

anfänglicher PC/SP [...] Das kritische Fenster ist jetzt nur noch das Schreiben dieser beiden Wörter

Stimmt, aber es besteht immer noch die Möglichkeit eines Ausfalls - nicht gut genug für sicherheitskritische Anwendungen.

Beachten Sie, dass Benutzer versucht sein könnten, ein Standard-STM32-Flashing-Tool anstelle Ihrer Software zu verwenden - es würde mit dem ROM-Bootloader gut funktionieren, aber Ihre Migrationen vollständig zunichte machen.

Schreiben Sie einen benutzerdefinierten Bootloader in Flash

Ich empfehle diesen Ansatz dringend, wenn die Ergebnisse unter Fehlerbedingungen katastrophal sein könnten.

Ihre erste Option ist trivial, die Zeit, die Sie hier bisher auf eine Antwort gewartet haben, hätte ungefähr 30 verschiedene Bootloader schreiben können. Sie haben bereits die Frage beantwortet, ob Sie den einmal programmierten Bootloader einfach einen CRC ausführen lassen könnten, wenn Sie die Zeit haben, oder eine Prüfsumme, wenn Sie es eilig haben, und ihn entweder verwenden oder nicht. Handvoll Code, Minuten zum Schreiben. Nun, wenn nicht, okay, das könnte ein Forschungsprojekt oder zumindest einige Experimente sein, die ziemlich sicher sind, dass ST dokumentiert, wie der Bootloader gestartet wird, sollte so einfach sein wie eine Verzweigung zu einer hohen Adresse oder eher das Lesen der magischen hohen Adresse plus 4 und bx to diese Adresse. (Dann sind Sie im Werks-Bootloader und müssen keinen schreiben/ersetzen).

Das Erstellen Ihres eigenen uart-basierten Bootloaders ist nicht schwierig, in etwa 30-50 Codezeilen, vielleicht ein paar Handvoll mehr. Ich habe XMODEM-, SREC- und IHEX-basierte geschrieben, die einfach da sitzen und darauf warten, dass Sie Firmware herunterladen, muss nicht komplizierter sein als das. kann eine haben, die Sie zu einer Protokolladresse machen, Daten mit einem Rahmen wie srec/ihex, aber vielleicht anders. eine weitere halbe Stunde bis eine Stunde Entwicklung (zuzüglich der Zeit, um zu lernen, wie man in der Anwendung flasht, was ziemlich einfach ist, denke ich, dass st es buchstabiert).

Wenn Sie Ihren eigenen Loader schreiben möchten, der flashen kann, dann möchten Sie entweder ein Dual-Banking-Gerät und der Checker/Loader befindet sich in einer Bank und die Anwendung in der anderen. Oder Sie machen den Lader zum Trampolin rammen. Ich bin mir ziemlich sicher, dass die Löschgröße auf diesen Teilen nur einen Bruchteil des gesamten Flashs ausmacht, sodass Sie auch ohne einen Dual-Banking-Flash Trampolin springen und das löschen könnten, was Sie nur als Anwendungsbereich definiert haben.

Sie könnten den niedrigsten Löschblock so einrichten, dass die Vektortabelle mit Reset auf den Boot-Checker zeigt, Sie könnten Ihre Anwendung ab dem nächsten Löschblock live schalten, wenn dies Platz für den Boot-Checker lässt, um im Laufe der Zeit zu wachsen. Ich gehe davon aus, dass Sie die VTOR-Steuerung haben, sodass Sie sich nicht mit den anderen Vektoren herumschlagen müssen, sondern sie in einer Endlosschleife im Checker enden lassen.

Nun, das schnelle und schmutzige, nichts davon tun zu müssen, bietet immer noch ein gewisses Risiko, aber weniger. Wenn das vordere Ende der Vektortabelle gelöscht wird und der Bootloader aufgerufen wird, sollten Sie dies bereits mit jungfräulichen Teilen gesehen haben, dass Sie boot0 nicht mit einem neuen Teil bestätigen müssen. Ich denke, es sind nur die ersten vier Wörter, aber Sie können das experimentell herausfinden. Wenn Sie also neue Firmware herunterladen, ändern Sie Ihr Programm so, dass es zuerst den ersten Block mit der Vektortabelle löscht, was Sie wahrscheinlich bereits tun, aber schreiben Sie diesen Block zuletzt, löschen und schreiben Sie den Rest der Anwendung, schreiben Sie den ersten Block zuletzt und nur diesen Zeitraum Zeit besteht die Gefahr eines Stromausfalls, eines Resets oder eines anderen Ereignisses, das ein beschädigtes Bild verursacht.

Endlich könnten Sie perfekten Code schreiben, der niemals ein Firmware-Update benötigt ... grins ... das würde es lösen ...

Dies sind COTS-Teile, also wie erwähnt nicht sicherheitskritisch. Aber Sie könnten ein paar Stunden dieser zusätzlichen Anstrengung investieren, um einigen zu helfen.

Dies bedeutet nicht unbedingt, dass, wenn Sie die Stromversorgung verlieren oder zum richtigen Zeitpunkt zurücksetzen, das Teil Ihren Backup-Bootloader nicht beschädigt oder löscht, dass Sie die Flash-Handbücher nicht so genau gelesen haben, aber wissen, dass einige Eeproms früher so funktionierten, wenn Sie genau richtig ausgeschaltet haben oder zeitgesteuerte Dinge genau richtig, könnten Sie Daten verlieren. Das Testen würde nicht beweisen, dass es niemals eine Möglichkeit gibt, aber Sie könnten eine Testvorrichtung einrichten, um ein Herunterladen/Löschen zu starten und das Teil zu einem zufälligen Zeitpunkt auszuschalten, wiederholen Sie es. Wiederholen Sie kurz die angegebene Anzahl von Blitzzyklen für das Teil. Überprüfen Sie jedes Mal, ob der Boot-Checker gestartet wurde und funktionierte (oder die Anwendung). allenfalls ein warmes wuscheliges Gefühl, aber kein Beweis.