Der Bootloader erlaubt eine Aktualisierung der Knotensoftware über CAN im eingebauten Betrieb.
Die zu flashenden Daten werden aus dem erzeugten S19-File in einen Flashcontainer überführt. Im Flashcontainer (Dateiendung .cfc = CanathomeFlashContainer) liegen Infos über die Verwendung der Knotensoftware vor. Anhand dieser kann der PC prüfen, ob die ausgewählte Software auf einen bestimmten Knoten geflasht werden darf (Sicherheit vor unzulässigem/versehentlichem Überschreiben). Stimmen vorausgesetzter Softwarestand und Hardwarestand überein, so erlaubt HomeCentral das Flashen in den Zielknoten.
Flashablauf
In der Flashkomponente von HomeCentral wird der zu schreibende Flashcontainer ausgewählt. Daraufhin wird geprüft welche Knoten für diese Softwareversion in Frage kommen und zur Auswahl gestellt.
Zunächst werden die Laufzeitdaten (LiveConfif-Daten) vom Knoten ausgelesen und im PC zwischengespeichert. Daraufhin wird der zu flashende Knoten in den Bootloader geschickt, der Flash- und Eepromspeicher gelöscht und die neuen Programmdaten in kleine Pakete (max. 512Bytes – aufgeteilt auf viele CAN-Botschaften) an den Knoten geschickt. Anschließend werden die Programmdaten komplett zurückgelesen und im PC auf Korrektheit geprüft. Bei korrektem Flashverlauf, wird dann das ACA-Flag (ApplicationCodeAvailable-Flag) gesetzt, das aussagt, dass gültiger Applikationscode vorliegt und der Bootloader beim nächsten Reset in die Applikation verzweigen darf. Wird oder ist dieses Flag nicht gesetzt, so muss darf der Bootloader nicht in die Applikation aufsteigen. Hinweis: Das ACA-Flag muss so gross sein wie die kleinste zu löschende Flasheinheit.
Ein abschliessendes Resetkommando zwingt den Knoten zu einem Neustart, bei dem er dann in die Applikation durchstartet. Der gelöschte Eepromspeicher wird dann erkannt und mit ROM-Defaultwerten beschrieben.
Typischerweise werden dann noch die (zuvor ausgelesenen oder sowieso im PC vorliegenden) Konfigurationsdaten mit HomeCentral neu eingespielt.
Bootloaderkommandos
Die Bootloaderdaten und -kommandos werden in einem Telegramm des Typs TransportObjekt (TO) übermittelt. Folgende Kommandos zwischen steuerndem/flashenden PC und Knoten werden zur Updateprogrammierung verwendet:
| Code | Kommando | Parameter | Beschreibung |
| 0×01 | ClearBuffer | - | löscht den Puffer und setzt den Schreibpointer auf Pufferanfang |
| 0×02 | WriteInBuffer | 8 Nutz- datenbytes |
autoinkrement; merkt Daten vor, die später dann geflasht werden; Buffersize: 512Byte |
| 0×03 | FlashBuffer | u08 PPage; u16 Address; u16 Length | schreibt den Puffer ins Flash mit der angegebenen Länge; Flash muss zuvor per Kommando gelöscht worden sein (Maximallänge: 512) |
| 0×04 | ReadFlash | u08 PPage; u16 Address; u16 Length; u08 Zykluszeit |
fordert den zu flashenden Knoten auf, die Daten aus dem Flash zu lesen und zu übermitteln; Zeit zwischen zwei Antworttelegrammen ist im Parameter “Zykluszeit” [in 1ms] festgelegt. |
| 0×05 | Erase ApplicationFlash | - | Löscht den für die Applikation reservierten Flashbereich (nicht Eeprombereich) |
| 0×06 | - | - | - |
| 0×07 | Read BootloaderData | - | liest Statusinfos des Bootloaders aus (Versionsnummer) |
| 0×08 | Reset | - | Reset auslösen |
| 0×09 | ConfigureNode | u08 Knr | schreibt die gewünschte Knotennummer in den FixBereich des Eeproms; neue Knotennummer wird erst nach Reset übernommen |
| 0x0A | ReadEeprom | u16 Address | liest Eeprominhalt (4Bytes) ab gewünschter Adresse |
| 0x0B | WriteEeprom | u16 Address, u32 Data | schreibt 4Bytes ins Eeprom; auch in den FixBereich! |
| 0x0C | Erase Application Eeprom | - | löscht den Application-Bereich des Eeproms (FixEeprom bleibt unangetastet) |
| 0x0D | StartApplication | - | startet die Applikation OHNE vorheriges Setzen des ACA Flags (Rücksprung in Bootloader bei nächstem Reboot) |
Antworten vom zu flashenden Knoten:
| Code | Kommando | Parameter | Beschreibung |
| 0×20 | AliveMessage | 0×00 | wird alle 5s geschickt, um anzuzeigen, dass Knoten im Bootloader ist |
| 0×21 | RespClearBuffer | 0×00 | Antwort auf ClearBuffer |
| 0×22 | RespWrite InBuffer | 1 Statusbyte | Antwort auf WriteInBuffer; 0-254: Anzahl der in den Puffer geschriebenen 8Byte-Blöcke; 255: Fehler – Overflow |
| 0×23 | RespFlashBuffer | 1 Statusbyte | Antwort auf FlashBuffer; 0: kein Fehler; 1: Adressfehler (auf diese Adresse darf nicht geflasht werden) |
| 0×24 | RespReadFlash | 8 Nutz- datenbytes |
Antwort auf ReadFlash |
| 0×25 | RespErase ApplicationFlash | 1 Statusbyte | Antwort auf Erase ApplicationFlash; 0: kein Fehler; 1 Fehler aufgetreten |
| 0×26 | - | - | |
| 0×27 | RespRead BootloaderData | 2 Antwortbytes | Antwort auf ReadBootloaderData Byte0: Bootloaderversion (Highbyte); Byte 1: Bootloaderversion (Lowbyte) |
| 0×29 | RespConfigure Node | 1 Statusbyte | Antwort auf ConfigureNode; 0: kein Fehler; 1: Fehler aufgetreten |
| 0x2A | Resp ReadEeprom | u16 Address, u32 Data | Antwort auf ReadEeprom |
| 0x2B | Resp WriteEeprom | 1 Statusbyte | Antwort auf WriteEeprom; 0: kein Fehler aufgetreten; 1: Fehler (PVIOL, ACCERR); 2: Adressfehler |
| 0x2C | RespErase Application Eeprom | 1 Statusbyte | Antwort auf Erase Application Eeprom; 0: kein Fehler; 1: Fehler |
| 0x2D | Resp StartApplication | - | Antwort auf StartApplication |
MemoryMap
Das folgende Diagramm zeigt die Memorymap der Zielknoten. Hieraus ist ersichtlich, an welche Adressen die Applikation gelinkt werden muss, und wo im Speicher welche Informationen abliegen.
