Hallo,
bevor jetzt alle meckern, ja ich kenne die AN von Microchip bzgl.
Bootloader über UART sowie über CAN.
Ich würde aber gerne mein Applikationsupdate über die normale
Applikation mit einem Protokoll welches ich schon für andere Kommunktion
zwischen einem PIC und Rechner nutze durchführen.
Auch erfolgt aus diversen Sicherheitsgründen (u.a. DIN EN 51508) eine
spezielle Autorisierung und Überprüfung des Firmwareupdates.
Meine Idee wäre erstmal, dass ich aus der normalen Applikation das
Firmwareupdate in einem SRAM oder Flash abspeichere. Danach erfolgen
meine Sicherheitsprüfungen, Checksummenvergleich, etc. Erst wenn dieses
erfolgreich war, boote ich in den Bootloader und lasse von dort die
Daten aus dem SRAM/Flash in den PROM des Pic18 kopieren.
Als Vorteil von einem Flash könnte ich auch dort mehrere Applikationen
ablegen. Im Gedanken bin ich da aktuell bei einem Golden Image oder halt
"Werkseinstellung". Die Flashs haben ja keine große Anforderung an Speed
oder Größe. Dachte da z.B. an einen SST25VF020B mit 2MB oder als RAM an
einen IS62WVS2568.
Gibt es Gründe die gegen so eine Vorgehensweise sprechen?
Die meisten Beispiele und AN gehen davon aus, dass ich mit einem
speziellen Protokoll direkt im Bootloader update.
Ich sehe da u.a. den Nachteil, dass ich entweder ein stark vereinfachtes
Protokoll nehme und meine Sicherheitsfunktionen für unerlaubtes Flashen
drumherumstricke. Das bläht den BL Code unnötig auf, da ich dieses eh
schon in der Applikation habe. Auch muss ich erst den Adressbereich mit
der Applikation erst löschen und dann neu schreiben. Sprich sollte es
zwischen dem Update ein fehlerhaftes auftreten wird dies erst beim CRC
festgestellt und lässt sich nur mit einem erneuten Durchlauf des Updates
beheben. Sprich ich könnte den inkonsisten Fall ohne Applikation auf dem
Gerät hinterlassen.
Oder kann ich einen PIC18 auch direkt aus einem ext. Flash booten
lassen? Ich vermute mal nein.
Viele Grüße
PIC18 kann Code ausschließlich aus dem internen Flash ausführen.
Ich habe extra für solche Updatezwecke in vielen Boards ein SPI-SRAM
verbaut, sowas wie das hier:
https://www.microchip.com/wwwproducts/en/23LCV1024
oder
https://www.microchip.com/wwwproducts/en/23LC1024
128kB reichen für PIC18 ja meist aus. Das ist stromsparend und schnell
und einfach anzusprechen. Irgendwelche Pages oder Warten auf das Ende
von Flashzyklen gibts nicht - einfach reinschreiben und gut. Eventuell
kannst Du das dann noch für andere Dinge verwenden.
fchk
Freddy schrieb:> Auch muss ich erst den Adressbereich mit> der Applikation erst löschen und dann neu schreiben.
Das hat Flash so an sich, man muß ihn immer zuerst löschen.
Es würde aber auch nichts bringen, wenn man halb eine neue und halb noch
die alte App hat.
Nimmt man einen RAM als Zwischenspeicher, muß man beten daß kein
Stromausfall kommt. Aus einem Flash könnte der Bootloader weiter
programmieren.
Enthält der Bootloader nicht auch die Kommunikation, sollte der Flash
mindestens noch eine Not-App enthalten. Man braucht dann eine
Möglichkeit (Taster), um dem Bootloader zu sagen, daß er diese zurück
flashen soll, wenn die neue App buggy ist.
Peter D. schrieb:> Nimmt man einen RAM als Zwischenspeicher, muß man beten daß kein> Stromausfall kommt. Aus einem Flash könnte der Bootloader weiter> programmieren.
Ich habe das damals so gelöst, dass ich einen 23LCV1024 mit VBAT
verwendet habe und VBAT mit an die MCP79411 RTC-VBAT angeschlossen habe.
Nach dem Hochladen einer Firmware habe ich eine bestimmte Signatur im
RTC-RAM hinterlassen und einen Reset ausgeführt. Der Reset hat einen
kleinen Bootloader aufgerufen, der auf die Signatur in der RTC geschaut
hat und im Bedarfsfall in die Flash-Routine gesprungen ist. Die
Flash-Routine hat die in der RTC hinterlegte Prüfsumme mit dem
SRAM-Inhalt abgeglichen und dann das Flash programmiert, verifiziert,
und erst wenn alles ok war RTC-Prüfsumme und Signatur gelöscht.
Das ganze war ziemlich idiotensicher gegen Fehlbedienung. Klar,
mutwillig bekommt man alles kaputt, aber das ist immer so.
fchk
Das geht sicherlich, so wie Du Dir das vorstellst. Ok, die App muss
soweit fertig sein, wenn Du die PICs zum letzten Mal über den Programmer
flashst.
Würde ich als Schlingel Dir das externe Ram/Flash mit meinem
Lieblingsprogramm vollmachen und mich freuen, wenn Du es völlig
ungeprüft übernimmst.
Hab ich so ähnlich mit einem PIC32 gemacht.
Externes EEPROM, in dem die Firmware (nur fürs Update) verschlüsselt
hinterlegt wurde.
Dem Bootloader wurde per Flag mitgeteilt, dass er ein Update machen
sollte.
Der Bootloader hat dann zuerst versucht das Update im EEPROM zu
entschlüsseln. Wenn das geklappt hat, hat er die Firmware upgedated. Und
wenn das geklappt hat, hat der BL das Update-Flag gelöscht.
Wenn die Entschlüsselung nicht geklappt hat, wurde ein Flag gesetzt
"falsche Firmware" und das noch nicht gelöschte alte Programm gestartet.
Das ganze war an beliebiger Stelle unterbrechbar ohne dass was
passierte.
Mach das Image so, dass du auch mehrere verschieden große Teile an
beliebigen Stellen updaten kannst. Gut für Konstanten.
Allerdings war es mühsam das alles in dem Bootbereich unterzubekommen,
mit nur 12 K.
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