PIC18 Update der Applikation

[Freddy (Gast)]

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

[fchk (Gast)]

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 (Gast)]

Hi,

ok danke für die Info. Scheinbar bin ich doch nicht einzige, der den 
Umweg Update über SRAM/Flash durchführt.

Viele Grüße

[Peter D. (peda)]

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.

[fchk (Gast)]

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

[fop (Gast)]

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.

[Nick M. (Gast)]

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.