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
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
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.
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.