-
Gebiet der Erfindung
-
Die Erfindung betrifft ein Verfahren zum selektiven Verwenden eines Bootloaders zum Ändern von Code in mindestens einer Applikation einer softwaregesteuerten Vorrichtung, insbesondere eines Aktuators in einem Fahrzeug.
-
Weiterhin betrifft die Erfindung ein Verfahren zum selektiven Durchlaufen einer Codesequenz eines Bootloaders infolge eines Unterbrechungsereignisses, insbesondere eines Resets einer Applikation einer softwaregesteuerten Vorrichtung in einem Fahrzeug.
-
Hintergrund
-
In Fahrzeugen werden oftmals verschiedene Geräte über einen gemeinsamen Bus (Daten-Bus), insbesondere einen LIN-Bus, betrieben. Die Geräte können z.B. Aktuatoren für verschiedene Anwendungen sein und dabei über unterschiedliche Softwareapplikationen sowie unterschiedliche Hardware verfügen. Üblicherweise besitzen die Geräte aber den gleichen Bootloader, auch wenn sich die Anwendungssoftware unterscheidet. Es besteht jedoch gelegentlich die Notwendigkeit Softwareapplikationen einzelner Geräte zu aktualisieren (updaten). Eine Möglichkeit besteht darin, die Geräte/ oder einzelne Geräte über den Lin-Bus unter Verwendung des LIN-Protokolls zu aktualisieren. In der Praxis ist dies jedoch nachteilig, weil durch das LIN-Protokoll in den Geräten viel Speicherplatz in Anspruch genommen wird. Eine weitere Möglichkeit besteht darin, Aktualisierungen (Updates) der Softwareapplikationen mittels des Bootloaders auf die Geräte zu übertragen. Allerdings hat dies zum Nachteil, dass nur alle Geräte gleichzeitig aktualisiert werden können.
-
Die Erfindung macht es sich zur Aufgabe, ein Verfahren bereitzustellen welches das selektive Updaten einzelner Geräte durch einen Bootloader erlaubt.
-
Diese Aufgabe wird durch die in den unabhängigen Ansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausgestaltungen sind den Unteransprüchen zu entnehmen.
-
Kurzbeschreibung der Erfindung
-
Gemäß einem ersten Aspekt der Erfindung ist ein Verfahren der eingangs genannten Art geschaffen, wobei eine Mehrzahl der softwaregesteuerten Vorrichtungen über einen gemeinsamen Daten-Bus, insbesondere einen LIN-Bus, betrieben wird, das Verfahren umfassend:
- a) Adressieren, durch ein Daten-Bus, der Vorrichtungen, wobei das Adressieren durch Zuordnen einer Bus-Adresse zu jeder Vorrichtung an dem Daten-Bus erfolgt;
- b) Festlegen mindestens einer Codierung zu jeder Bus-Adresse, wobei die Codierung einen ersten Codeabschnitt umfasst, der die Bus-Adresse repräsentiert;
- c) Festlegen, mittels der Codierung, insbesondere mittels eines zweiten Codeabschnittes, eines gemeinsamen Speicherbereiches, wobei der Speicherbereich für den Bootloader und die Applikation zugänglich sind;
- d) Erzeugen, in Reaktion auf ein Auslöseereignis, durch die Applikation, mindestens einer ersten Indikation, insbesondere einer Bootloader-Flag, wobei die erste Indikation der Vorrichtung zugeordnet wird, deren Applikation Code enthält der geändert werden soll;
- e) Speichern, durch die Applikation, der Codierung und der ersten Indikation in den gemeinsamen Speicherbereich;
- f) Abrufen, durch den Bootloader, der Codierung und der ersten Indikation; und
- g) Ändern, durch die Applikation, des Applikationscodes der durch die Codierung indizierten Vorrichtung in
-
Reaktion auf das Abrufen der ersten Indikation durch den Bootloader.
-
Das Verfahren hat den Vorteil, dass alle Vorrichtungen an einem Bus (Daten-Bus), vorzugsweise einem LIN-Bus, individuell adressierbar sind. Durch das Zuordnen einer Indikation, vorzugsweise einer Bootloader-Flag, zu den individuellen Adressen, kann erreicht werden, dass serielles, individuelles Überschreiben (Flashen) der Vorrichtung, bzw. des Applikationscodes der Vorrichtungen unter Verwendung ein und desselben Bootloaders ermöglicht wird. Im Sinne der Anmeldung wird unter Flashen/Überschreiben, das Überschreiben gespeicherter Software, also das Ändern von Code der Software verstanden. Mit anderen Worten können alle Vorrichtungen, also auch verschiedene Geräte mit verschiedenen Applikationen selektiv durch denselben Bootloader upgedated (=durch Aktualisieren von Code, also Überschreiben, auf einen aktuellen Stand gebracht) werden. Die Erfindung beruht auf der Erkenntnis, dass a) eine eineindeutige Zuordnung der physikalischen Adressen der Vorrichtzungen auf dem LIN-Bus erforderlich ist, jedoch b) diesen Adressen ein weiterer Indikator, die Indikation, zugeordnet werden muss um zu erreichen, dass einzelne Vorrichtungen von dem Bootloader erkennbar sind. Dazu wird ein gemeinsamer Speicherbereich festgelegt, in dem diese Indikation ablegbar und durch den Bootloader abrufbar ist. Der Speicherbereich kann festgelegt werden, indem die individuelle LIN-Adresse „umcodiert“ wird, d.h. der Bus-Adresse (beispielsweise einer LIN-Adresse) wird ein weiterer Code zugeordnet, der zwei Codeabschnitte umfasst. Die Codeabschnitte dienen zur Codierung der Adresse und zur Codierung des gemeinsamen Speicherbereiches. Auf diese Weise kann der Bootloader bei Abruf der Bus-Adresse auch einen Adressbereich eines gemeinsamen Speicherbereiches abrufen. In diesem Adressbereich kann dann die Indikation, z.B. eine Flag, hinterlegt sein, anhand derer der Bootloader erkennen kann, dass eine bestimmte Vorrichtung eine Update-Routine zu durchlaufen hat.
-
In einer Ausgestaltung der Erfindung umfasst das Ändern ferner das Bewirken, durch den Bootloader, dass die Applikation eine Update Routine durchläuft. Der Bootloader bzw. dessen Code, ist selbst nicht veränderlich. Die Funktion des Bootloaders besteht darin, das Durchlaufen der Update-Routine durch die Applikation zu triggern. Dadurch kann jede Applikation, also auch Applikationen von verschiedenen Vorrichtungen, durch denselben Bootloader zum Durchlaufen der Update-Routine angeregt werden. Das Ändern des Codes, also das eigentliche Überschreiben zum Zwecke der Aktualisierung, erfolgt dann durch die Applikation selbst.
-
In einer Ausgestaltung der Erfindung umfasst das Verfahren das Schreiben, durch die Applikation, einer zweiten Indikation in den gemeinsamen Speicherbereich, wobei die zweite Indikation einen Grund für das Ändern des Applikationscodes repräsentiert, insbesondere wobei das Schreiben nach dem Durchlaufen der Updateroutine, durch die Applikation erfolgt. Mit Vorteil kann die Applikation/ der Bootloader den Grund des letzten Reset bestimmen, indem die zweite Indikation aus dem gemeinsamen Speicherbereich ausgelesen werden kann. Daraufhin kann ein Durchlaufen einer Bootloader-Sequenz angepasst werden. Mit anderen Worten können in Abhängigkeit des Reset-Grundes Bootloader-Sequenzen angepasst, insbesondere weggelassen werden. Dadurch kann z.B. ein Neustart der Applikation schneller erfolgen.
-
In einer Ausgestaltung der Erfindung ist der gemeinsame Speicherbereich ein Speicherbereich in einer nichtflüchtigen Speichervorrichtung. Dadurch wird ermöglicht, dass in dem Speicherbereich abgelegte Daten nach einem Neustart noch zur Verfügung stehen.
-
In einer Ausgestaltung der Erfindung umfasst das Festlegen der mindestens einen Codierung zu jeder LIN-Adresse, das Umwandeln einer ASCII-Codierung der LIN-Adresse in ein Hexadezimalformat, insbesondere ist die Codierung im Hexadezimalformat angegeben. Das ASCII-Format der LIN-Adresse kann Missverständnisse hervorrufen. Daher kann diese auch in einem Hexadezimalformat angegeben werden. Das Hexadezimalformat hat den Vorteil, dass es weniger fehleranfällig ist, alle regulären BootloaderFunktionalitäten aber weiterhin unterstützt werden.
-
In einer Ausgestaltung der Erfindung ist der gemeinsame Speicherbereich auf einem EEPROM, einem Mikrokontroller-Register, oder auch in der Applikation festlegbar. Dadurch können verschiedene verfügbare Speicherressourcen flexibel genutzt werden. Insbesondere ist kein zusätzlicher Speicher erforderlich. Der gemeinsame Speicherbereich kann auf jeder verfügbaren Speichervorrichtung festgelegt werden.
-
Insbesondere umfasst der gemeinsame Speicherbereich einen ersten und einen zweiten Bereich, wobei die Codierung und die erste Indikation in den ersten Bereich und die zweite Indikation in den zweiten Bereich geschrieben werden.
-
Die Unterteilung in zwei Speicherbereiche ermöglicht die eineindeutige Zuordnung von erster Indikation und Codierung zu der zweiten Indikation.
-
In einer Ausgestaltung der Erfindung ist die erste Indikation aus einer begrenzten Anzahl an Indikatoren gewählt. Das Vorliegen einer Indikation, die nicht aus der begrenzten Anzahl der Indikationen ausgewählt ist, kann somit als Hinweis verstanden werden, dass die Indikation fehlerhaft sein kann. Falls ein Wert der Indikation also außerhalb eines bestimmten Wertebereiches liegt, kann entweder durch Rückgriff auf einen Standardwert der Indikation ein Standardverfahren eingeleitet werden, oder eine Interaktion zwischen Bootloader und Applikation kann abgebrochen werden. Dadurch kann die Interaktion zwischen Bootloader und Applikation abgesichert werden.
-
In einer Ausgestaltung der Erfindung umfasst die Codierung einen ersten und einen zweiten Codeabschnitt, wobei in dem ersten Codeabschnitt codiert ist: die Bus-Adresse, eine Bootloader-ID, eine Applikationsversionsnummer; und wobei in dem zweiten Codeabschnitt codiert ist: der gemeinsame Speicherbereich. Mit dieser Unterteilung kann ein geschützter Speicherbereich, z.B. eines EEPROM, geschaffen werden, auf den sowohl der Bootloader als auch die Applikation Zugriff haben und in dem unveränderliche Betriebsdaten abgelegt werden können. Diese Betriebsdaten gehen dann beim Flashen/ dem Update nicht verloren. Dieser Bereich ist durch die Codierung variabel. Vorzugsweise weisen der erste und/oder der zweite Codeabschnitt eine Größe von einem Byte auf. Die Bus-Adresse kann insbesondere die LIN-Adresse eines LIN-Busses sein.
-
In einer Ausgestaltung der Erfindung ist der gemeinsame Speicherbereich ein geschützter Speicherbereich, der durch das zweite Byte der Codierung indiziert ist, wobei das zweite Byte einen Endbereich des nichtflüchtigen Speichers definiert, dessen Code nicht geändert werden soll. In dem geschützten Speicherbereich sind dann auch Werkseinstellungen, Betriebsdaten usw. speicherbar. Auch sind hier Flashcycles speicherbar. Die minimale Größe des geschützten Speicherbereiches liegt bei 12 Byte, die maximale Größe des geschützten Speicherbereiches liegt bei 192 Byte.
-
Vorzugsweise umfasst die softwaregesteuerte Vorrichtung einen Elektromotor. Das Verfahren kann also insbesondere zum Aktualisieren der Firmware eines Elektromotors und/oder zum Vermitteln von Daten zwischen dem Bootloader und der Firmware einer Steuerungssoftware eines Elektromotors verwendet werden. Der Elektromotor kann dadurch selektiv für eine Aktualisierung der Software über einen Daten-Bus, unter einer Mehrzahl an Bus-Teilnehmern angesprochen werden. Der Daten-Bus kann insbesondere ein LIN-Bus sein. Zusätzlich oder alternativ kann dadurch ein Verfahren bereitgestellt werden, durch welches der Firmware Daten des Bootloaders bereitgestellt werden, so dass die Firmware in Abhängigkeit der bereitgestellten Daten geregelt oder gesteuert werden kann. Insbesondere kann die Firmware nach einem Neustart unterschiedliche Programmabläufe ausführen, je nachdem durch welchen Grund der Neustart bedingt ist.
-
Gemäß einem zweiten Aspekt der Erfindung ist ein Verfahren geschaffen zum selektiven Durchlaufen einer Codesequenz eines Bootloaders infolge eines Unterbrechungsereignisses, insbesondere eines Resets einer Applikation einer softwaregesteuerten Vorrichtung in einem Fahrzeug, das Verfahren umfassend: Bestimmen, durch den Bootloader, eines Resetgrundes, der das Unterbrechungsereignis repräsentiert, wobei das Bestimmen das Abrufen einer ersten Information, die den Resetgrund repräsentiert, aus einem gemeinsamen Speicherbereich, umfasst; und in Reaktion auf das Bestimmen: Zumindest teilweises Durchlaufen der Codesequenz des Bootloaders, um die Applikation zu starten. Mit Vorteil kann die Applikation/ der Bootloader den Grund des letzten Reset bestimmen, indem die erste Information aus dem gemeinsamen Speicherbereich ausgelesen werden kann. Daraufhin kann ein Durchlaufen einer Bootloader-Sequenz angepasst werden. Mit anderen Worten können in Abhängigkeit des Reset-Grundes Bootloader-Sequenzen angepasst, insbesondere weggelassen werden. Dadurch kann z.B. ein Neustart der Applikation schneller erfolgen.
-
In einer Ausgestaltung des zweiten Aspektes der Erfindung ist das Unterbrechungsereignis ein Power-On-Reset (POR) oder ein Watchdog-Reset oder ein Wake-Up-Ereignis oder ein Verzögerungsereignis. Verschiedene Unterbrechungsereignisse können verschiedene Charakteristiken aufweisen, die dazu führen, dass die zu durchlaufende Bootloader-Sequenz entsprechend dem Unterbrechungsereignis angepasst werden kann.
-
In einer Ausgestaltung des zweiten Aspektes der Erfindung ist der gemeinsame Speicherbereich ein Bereich eines Registers eines Mikrokontrollers der softwaregesteuerten Vorrichtung, insbesondere wobei der gemeinsame Speicherbereich ein geschützter Bereich ist. Die erste Information kann in einem geschützten Bereich abgelegt sein, der bei z.B. bei einem Update nicht überschrieben wird. Dadurch wird erreicht, dass die Information über das Unterbrechungsereignis dauerhaft gesichert ist und jederzeit abgerufen werden kann.
-
In einer Ausgestaltung des zweiten Aspektes der Erfindung umfasst das zumindest teilweise Durchlaufen der CodeSequenz ferner: wenn ein POR-Ereignis bestimmt wurde: vollständiges Durchlaufen der Bootloader-Sequenz, wobei das vollständige Durchlaufen ein Warten einer festgelegten ersten Zeitspanne, insbesondere ca. 50 ms, umfasst; wenn ein Watchdog-Reset oder ein Verzögerungsereignis oder ein Wake-up Ereignis bestimmt wurden: teilweises Durchlaufen der Bootloader-Sequenz, wobei das teilweise Durchlaufen ein Warten einer zweiten Zeitspanne, insbesondere ca. 15 ms, umfasst. Die zweite Zeitspanne kann insbesondere kleiner als die erste Zeitspanne sein. Im Falle eines POR-Ereignisses, kann die vollständige Bootloader-Sequenz durchlaufen werden. Diese umfasst die Wartezeit von 50 ms vor dem Starten der Applikation, wobei die 50 ms eine maximale Wartezeit darstellen, wenn eine Applikation mit LIN-BUS Kommunikation vorliegt (die maximal zulässige Zeitdauer bis die Kommunikation zwischen Applikation und LIN-BUS vollständig hergestellt ist beträgt 100ms). Wenn das Unterbrechungsereignis ein Watchdog-Reset oder ein Verzögerungsereignis oder ein Wake-Up Ereignis ist, kann der Bootloader nur eine kurze Wartezeit oder gar keine Wartezeit vorsehen. Die Applikation kann direkt, oder nach kurzer Verzögerung, z.B. 15ms, von dem Bootloader gestartet werden. Dies kann dazu führen, dass die Wartezeit bis zum Start der Applikation und somit bis zur vollen Einsatzfähigkeit des Systems, in Abhängigkeit des Neustartgrundes gering gehalten wird.
-
Insbesondere umfasst das Bestimmen ferner ein Aufrufen des Registers des Mikrokontrollers und ein Abrufen des Registereintrages durch die Bootloader-Sequenz.
-
Insbesondere umfasst das Bestimmen ferner ein Feststellen, ob eine Updateanfrage für die Applikation vorliegt; und/oder ein Feststellen, ob das Update bereits ausgeführt wurde.
-
In einer weiteren Ausgestaltung des zweiten Aspektes der Erfindung umfasst das Verfahren ferner ein Ablegen, durch die Applikation, der ersten Information in dem gemeinsamen Speicherbereich in Reaktion auf das Unterbrechungsereignis.
-
Kurze Beschreibung der Zeichnungen
-
Nachfolgend sind anhand der beigefügten Zeichnungen beispielhafte Ausführungsformen der Erfindung näher beschrieben. Es zeigen:
- die 1a bis 1f eine schematische Darstellung eines beispielhaften Verfahrens gemäß der Erfindung in einer beispielhaften softwaregesteuerten Vorrichtung;
- die 2 eine erste Ausführungsform eines beispielhaften Verfahrens gemäß eines Aspektes der Erfindung;
- die 3 eine zweite Ausführungsform des beispielhaften Verfahrens gemäß des Aspektes der Erfindung aus 2;
- die 4 eine beispielhafte Aufteilung eines Speicherbereiches eines Speichers einer softwaregesteuerten Vorrichtung.
-
Figurenbeschreibung
-
Die 1a bis 1f zeigen ein beispielhaftes Verfahren gemäß der Erfindung. In Block 1 wird zunächst ein Initialisierungsvorgang durchgeführt. In Block 2 wird eine initiale Anmeldung 1 einer Applikation im Bus-System durchgeführt. Beispielhaft ist der Daten-Bus als LIN-Bus ausgebildet. Dabei wird in einem Schritt 2A auf das Empfangen einer Initialnachricht des Daten-Busses durch die Vorrichtung gewartet. In einem nächsten Schritt 2B wir das Ablaufen einer Wartezeit abgefragt (Timeout). Die Wartezeit kann beispielsweise vorherbestimmt sein.
-
Wird innerhalb der Wartezeit keine Nachricht empfangen, wird in einem Schritt 2C die Betriebsspannung überprüft. Beispielsweise wird abgefragt, ob die Betriebsspannung größer einer minimalen Betriebsspannung ist. Im Beispiel ist die minimale Betriebsspannung 7V. Falls die minimale Betriebsspannung nicht erreicht ist (falsch), wird wieder in den Schritt 2A des Wartens auf das Empfangen einer Initial-Nachricht zurückgesprungen. Ist die minimale Betriebsspannung erreicht (wahr), wird hingegen in einem Schritt 2D abgefragt, ob eine Anfrage zur Aktualisierung des Bootloaders vorliegt. Falls dies nicht der Fall ist, wird in einem Schritt 2E die Applikation gestartet. Liegt hingegen solch eine Anfrage vor, wird in eine Routine 7 zur Aktualisierung des Bootloaders gesprungen.
-
Wird im Schritt 2B die Wartezeit nicht überschritten (falsch), so wird in einem Schritt 2F das Empfangen einer definierten Botschaft abgefragt. Im Beispiel wird dabei das Empfangen eines Befehls „ProgX“ abgefragt, wobei der Teil „Prog“ einen Befehl zum Ausführen einer Aktion bezeichnet, und „X“ eine Variable zum Codieren des Befehls bezeichnet. Beispielsweise kann „X“ für einen Wert stehen, der das Ausführen eines Updates anstößt, oder einen anderen Wert, der ein Auslesen der Versionsnummer der Firmware, oder das Auslesen der Versionsnummer des Bootloaders anstößt. Wurde eine definierte Botschaft nicht empfangen (falsch), so wird wieder in den Schritt 2A zurückgesprungen. Die definierte Botschaft kann insbesondere eine Abfrage der Versionsnummer des Bootloaders oder der Applikationssoftware, oder ein Befehl zum Aktualisieren der Applikationssoftware (Flashen) sein. Ferner kann die Botschaft eine Adressierung eines Busteilnehmers, beispielsweise eines Stellantriebes, umfassen. Im Falle, dass eine definierte Botschaft empfangen wurde (true), wird in einem Schritt 2G eine Bestätigung gesendet. Folgend wird eine Routine zur Aktualisierung aufgerufen.
-
In Block 3 (siehe insbesondere die 1b und 1c) ist ein beispielhaftes Verfahren einer Überschreiboperation gezeigt. In einem Schritt 3A wird ein Befehl zum Ausführen der Überschreiboperation empfangen. Das Empfangen umfasst das Überprüfen, ob der Befehl dem als Broadcast übertragenen Befehl „Prog!“ zum Ausführen eines Updates entspricht. Falls im Schritt 2F der Befehl „Prog!“ empfangen wurde, wird folglich eine Aktualisierung der Firmware ausgeführt. Ebenso wird eine Aktualisierung der Firmware ausgeführt, falls die Botschaft an den empfangenden Busteilnehmer gerichtet ist, und innerhalb eines vorgegebenen Wertebereichs liegt. Im Beispiel liegt umfasst der Wertebereich den Adressraum OxCO bis 0XDF, und die empfangene Nachricht muss der im Speicher des Busteilnehmers gespeicherten Adresse entsprechen. Im Falle, dass entweder eine Broadcast-Nachricht für ein Update oder ein an den Busteilnehmer gerichteter Befehl zur Aktualisierung der Firmware empfangen wurde (wahr) wird in einem weiteren Schritt 3B ein Schreibschutz eines Flash-Speichers ausgeschaltet. In einem weiteren Schritt 3C wir der Flash-Speicher gelöscht. Insbesondere kann das Löschen den vollständigen Flash-Speicher, abgesehen von dem für den Bootloader vorhergesehenen oder von dem Bootloader allokierten Bereich, umfassen. In einem weiteren Schritt 3D kann dann überprüft werden, ob der Löschvorgang erfolgreich war. Falls dies der Fall ist (wahr), wird in einem Schritt 3E eine Bestätigung des Löschvorgangs gesendet. In einem Schritt 3F wird schließlich eine Synchronisation der Taktfrequenz der Steuerschaltungen der zu aktualisierenden Busteilnehmer vorgenommen. Insbesondere kann die Synchronisation auf eine Taktfrequenz eines Bus-Masters, insbesondere eines LIN-Masters, erfolgen. Hierfür kann von dem Bus-Master eine entsprechende Nachricht über den Bus an die Busteilnehmer gesendet werden. Beispielsweise erfolgt eine Änderung der Taktfrequenz von 9600 Hz auf bis zu 512 kHz, vorzugsweise auf bis zu 48 kHz. Anschließen wird in einem Schritt 3G überprüft, ob die vollständige Datenmenge für den Überschreibvorgang empfangen wurde. Falls alle Daten empfangen wurden (wahr), wird in einem Schritt 3H der Bootloader zurückgesetzt (reset). Falls nicht alle Daten empfangen wurden (falsch), wird in einem Schritt 3I überprüft, ob eine Prüfsumme der gesendeten Daten um mehr als einen vorgegebenen Fehlerwert CHK_ERR_Max von einem erwarteten Wert der Prüfsumme abweicht. Ist dies der Fall, wird in einem Schritt 3J ein Fehlerzustand eingenommen. Ist dies nicht der Fall (falsch), wird in einem Schritt 3K überprüft, ob ein vorgesehenes Präfix empfangen wurde und im Schritt 3L, ob die auf das Präfix folgenden Daten empfangen wurden. Wurden das Präfix und die Daten empfangen, wird im Schritt 3M nochmals die Prüfsumme berechnet und mit der empfangenen Prüfsumme verglichen. Stimmen beide Werte nicht überein, wird zurück in den Schritt 3G gesprungen, anderenfalls wird in einem Schritt 3M überprüft, ob ein normaler Datensatz übermittelt wurde. Falls ja, werden in einem Schritt 3Q die empfangenen Daten verarbeitet. Ist dies nicht der Fall (falsch), wird in einem Schritt 3R überprüft, ob ein finaler Dateneintrag vorliegt. Liegt kein finaler Dateneintrag vor, wird in einem Schritt 3S wiederum in den Fehlerzustand gewechselt, anderenfalls (wahr) wird in einem Schritt 3T überprüft, ob die verbleibenden Daten erfolgreich geschrieben wurden. Falls die Daten erfolgreich geschrieben wurden (wahr), wird in einem Schritt 3U eine Bestätigungsnachricht gesendet und in einem Schritt 3V ein Zähler FlashCount erhöht, woraufhin im Beispiel wieder in den Schritt 3G gesprungen wird. Wurde im Schritt 3T festgestellt, dass die weiteren Daten nicht erfolgreich geschrieben wurden (falsch), wird in einem Schritt 3W eine Fehlermeldung ausgegeben.
-
In den in der 1d gezeigten Blöcken 4 bis 6 sind weitere Bootloaderfunktionalitäten gezeigt. Liegt im Schritt 3A der Fall vor, dass kein Befehl zur Aktualisierung des Bootloaders vorliegt (falsch), so wird in einen Schritt 4A des Blocks 4 gesprungen und geprüft, ob eine Abfrage der Versionsnummer (Befehl „Prog?“) der Applikation vorliegt. Der Befehl kann wiederum als Broadcast „Prog?“, oder als an den Busteilnehmer gerichtete Nachricht innerhalb eines vordefinierten Adressraums (hier im Wertebereich 0x80 bis 0x9F) vorliegen. Wird ein Befehl in diesem Wertebereich empfangen, wird ferner überprüft, ob der empfangene Wert einem vom Busteilnehmer gespeicherten Wert entspricht (empfangener Wert - 0X20 = gespeicherter Wert) und der Befehl folglich an diesen Busteilnehmer gerichtet ist. Wurde eine der beiden Voraussetzungen erfüllt (wahr), so werden die Schritte 4B bis 4D ausgeführt, wobei in dem Schritt 4B die Versionsnummer der Applikation gesendet wird, im Schritt 4C eine entsprechende Prüfsummer versendet wird und im Schritt 4C ein Neustart (Reset) des Bootloaders ausgeführt wird.
-
Im anderen Fall, dass im Schritt 4A keine Abfrage der Versionsnummer der Applikation vorliegt (falsch), wird in einen Schritt 5A des Blocks 5 gesprungen, in dem geprüft wird, ob ein Befehl „Prog%“ zur Abfrage der Versionsnummer des Bootloaders vorliegt. Auch hier kann der Befehl als Broadcast „Prog%“, oder als an den Busteilnehmer gerichtete Nachricht innerhalb eines vordefinierten Adressraums (hier im Wertebereich 0xA0 bis 0xBF) vorliegen. Wird ein Befehl in diesem Wertebereich empfangen, wird ferner überprüft, ob der empfangene Wert einem vom Busteilnehmer gespeicherten Wert entspricht und der Befehl folglich an diesen Busteilnehmer gerichtet ist. Im Beispiel wird dazu überprüft, ob der empfangene Wert, abzüglich dem Wert 0X40, dem gespeicherten Wert entspricht. Liegt einer der beiden Fälle vor (wahr), so werden die Schritte 5B bis 5D ausgeführt, wobei in dem Schritt 5B die Versionsnummer des Bootloaders gesendet wird, im Schritt 5C eine entsprechende Prüfsummer versendet wird und im Schritt 5C ein Neustart (Reset) des Bootloaders ausgeführt wird.
-
Liegt jedoch im Schritt 5A keine Anfrage bezüglich der Versionsnummer des Bootloaders vor (falsch), so wird in einen Schritt 6A des Blocks 6 gesprungen, der prüft, ob ein Befehl „Prog#“ zum Löschen des Speichers vorliegt. Liegt solch ein Befehl vor (wahr), wird in einem Schritt 6B der EEPROM gelöscht und in einem Schritt 6C der Flashspeicher gelöscht. Daraufhin wird in einem Schritt 6D eine Bestätigung des Löschvorgangs und in einem Schritt 6E eine Bestätigung von dem Busteilnehmer an den Bus-Master gesendet. Schließlich wird der Bootloader in einem schritt 6F neugestartet (Reset). Liegt im Schritt 6A kein Befehl zum Löschen des Speichers vor, so wird der Bootloader in einem weiteren Verfahrensschritt neugestartet.
-
In Block 7 (siehe 1e und 1f) ist ein beispielhaftes Verfahren zum Updaten des Bootloaders selbst gezeigt. Wurde im Schritt 2D festgestellt, dass eine Anfrage zur Aktualisierung des Bootloaders vorliegt, wird beispielsweise eine Update-Routine gemäß dem Block 7 ausgeführt. In einem Schritt 7A erfolgt dabei zuerst eine Initialisierung, wobei in einem folgenden Schritt 7B das Ablaufen einer maximalen Initialisierungszeit abgefragt wird. Falls die Initialisierungszeit abgelaufen ist, wird in einem Schritt 7C das Ablaufen eines weiteren Zeitlimits überprüft. Ist auch dieses abgelaufen (wahr), wird in einem Schritt 7D der Bootloader neugestartet. Ist hingegen im Schritt 7B die maximale Initialisierungszeit nicht erreicht worden (falsch), wird in einem Schritt 7E überprüft, ob ein Befehl „BootX“ zum Starten des Bootloaders empfangen wurde. Falls dies nicht der Fall ist (falsch), wird in den Schritt 7A zurückgesprungen. Wurde der Befehl „BootX“ hingegen empfangen, wird in einem Schritt 7F eine Bestätigung gesendet und in einem Schritt 7G wird geprüft, ob eine Aktualisierung des Bootloaders erfolgt. Ist dies nicht der Fall, wird in einen Schritt 7H wieder ein Neustart des Bootloaders eingeleitet. Anderenfalls wird in einem Schritt 7I eine Aktualisierung des Bootloaders durch die Applikationssoftware (Firmware) gestartet. Dabei kann die Taktfrequenz wieder auf die Taktfrequenz des Bus-Masters synchronisiert werden. Insbesondere kann die Taktfrequenz des Busteilnehmers/der Bus-Teilnehmer erhöht werden, so dass der Aktualisierungsvorgang beschleunigt wird.
-
In einem weiteren Schritt 7J wird dann überprüft, ob alle Daten empfangen wurden. Beispielsweise kann überprüft werden, ob alle Daten-Frames zum Ausführen des Updates des Bootloaders empfangen wurden. Wurden alle Daten empfangen (wahr), kann in einem Schritt 7K ein Neustart des Bootloaders eingeleitet werden. Wurden hingegen nicht alle Daten empfangen (falsch), wird in einem Schritt 7L eine Prüfsumme der Daten gebildet und überprüft, ob die berechnete Prüfsumme mit einer empfangenen Prüfsumme übereinstimmt. Insbesondere kann überprüft werden, ob der Fehlerwert, der sich aus dem Vergleich der beiden Werte der Prüfsumme ergibt, einen maximalen Fehlerwert überschreitet. Falls dies nicht der Fall ist, wird in einem Schritt 7M ein Fehlerzustand eingenommen. Anderenfalls wird in einem Schritt 7N überprüft, ob ein Präfix der Daten empfangen wurde. Falls ja, wird in einem Schritt 7O überprüft, ob die übrigen Daten empfangen wurden. Wurden die übrigen Daten ebenfalls empfangen, wird in einem Schritt 7P überprüft, ob die Prüfsumme korrekt ist. Falls der Wert der Prüfsumme falsch ist, wird in einem Schritt 7T eine Fehlermeldung gesendet und in einem Schritt 7R ein Zähler des Prüfsummenfehlers erhöht. Schließlich wird zurück in den Schritt 7J gesprungen. Wird im Schritt 7P festgestellt, dass der Wert der Prüfsumme korrekt ist, dann wird in einem weiteren Schritt 7S geprüft, ob ein normaler Dateneintrag vorliegt. Ist dies nicht der Fall, wird in einem Schritt 7T der Bootloader in den dafür vorgesehenen Speicherbereich beschrieben. Daraufhin wird in den Schritt 7J zurückgesprungen. Wird nun in einem nächsten Schritt 7S festgestellt, dass es sich nicht um einen normalen Dateneintrag handelt, dann wird in einem Schritt 7O geprüft, ob ein finaler Dateneintrag vorliegt. Falls dies auch nicht der Fall ist, wird in einem Schritt 7V in einen Fehlerzustand gewechselt. Liegt hingegen ein finaler Dateneintrag vor, wird in einem Schritt 7W geprüft, ob die Daten erfolgreich in den Datenspeicher, insbesondere in den Flash-Speicher, geschrieben wurden. Falls im Schritt 7W festgestellt wurde, dass die restlichen Daten erfolgreich in den Speicher geschrieben wurden (wahr), wird in einem Schritt 7X eine Endbestätigung gesendet und daraufhin in den Schritt 7J zurückgesprungen. Wurde hingegen im Schritt 7W nicht festgestellt, dass die Daten erfolgreich in den Speicher geschrieben wurden (falsch), so wird in einem Schritt 7Y eine Fehlerbestätigung gesendet.
-
2 zeigt ein beispielhaftes Verfahren zum selektiven Durchlaufen einer Bootsequenz in Abhängigkeit eines Reset-Grundes. Das Verfahren beginnt mit in einem Schritt 22A einem Power On Reset (POR), d.h. mit Anschalten einer Energiequelle. Im Folgenden wird bestimmt, welche Art Unterbrechungsereignis vorliegt, also was der Grund der Unterbrechung der Energiezufuhr war. Hierfür wird beispielsweise in einem Schritt 22B überprüft, ob der Reset durch einen Watchdog ausgelöst wurde und wenn ja, wird eine entsprechende Indikation in einen Speicherbereich geschrieben (Schritt 22C). Falls nicht, wird in einem weiteren Schritt 22C überprüft, ob das Unterbrechungsereignis durch ein Aufwachen aus einem Ruhezustand erfolgte und gegebenenfalls eine entsprechende Indikation in einen Speicherbereich geschrieben (Schritt 22E). Ist dies auch nicht der Fall, wird in einem weiteren Schritt 22F überprüft, ob das Unterbrechungsereignis durch ein über den LIN-Bus empfangenes Aufwecksignal ausgelöst wurde. Wiederum wird gegebenenfalls eine entsprechende Indikation in einen Speicher geschrieben (Schritt 22G). Sodann wird in einem Schritt 22H bestimmt, ob ein „Flash Process“ - also ein Update - durchgeführt werden soll. Wenn dies der Fall ist, wird dies getan und in einem Schritt 22J die Beendigung des Update-Prozesses überprüft, sowie auch hierüber in einem Schritt 22K eine weitere Indikation in den Speicherbereich geschrieben. Nach dem Ausführen des Updates, oder falls im Schritt 22H festgestellt wurde, dass kein Update durchgeführt werden soll, wird die Applikation in einem Schritt 221 gebootet. Der Bootprozess kann auf jeden Fall unter Berücksichtigung der in dem Speicherbereich abgelegten Indikationen erfolgen.
-
3 zeigt ein beispielhaftes Verfahren zum selektiven Durchlaufen einer Bootsequenz in Abhängigkeit eines Reset-Grundes unter Berücksichtigung einer Wartezeit. Nach dem Einschalten im Schritt 33A wird in den Schritten 33B, 33E und 33F überprüft, was für ein Unterbrechungsereignis vorliegt. Wenn lediglich ein „normales“ POR-Ereignis vorliegt (also kein Watchdog-Reset (vgl. Schritt 33B), kein Retention-Mode (Speichermodus, vgl. Schritt 33E) und kein LIN wake-up (vgl. Schritt 33F) wird eine Wartezeit von 50 ms veranschlagt (Schritt 33G), bevor die Applikation in einem Schritt 33D gebootet wird. Liegt ein anderer ResetGrund vor, wird eine kürzere Wartezeit von 15 ms beigemessen (Schritt 33C), bevor die Applikation im Schritt 33D gebootet wird.
-
4 zeigt ein Schema eines Adressbereiches eines NVRAM in einer Hexadezimaldarstellung. Der Adressbereich ist ein geschützter Adressbereich. Die minimale Größe des geschützten Adressbereichs beträgt 15 Byte (von 0x500001B4 - 0x500001BF). Eine maximale Größe des geschützten Adressbereichs beträgt 192 Byte (von 0x500000FF - 0x500001BF). Die Größe des geschützten Adressbereiches hängt von dem Byte mit der Adresse Ox1B6 ab. Der geschützte Adressbereich umfasst weiterhin ein Byte für einen Flashcount (O1B8) und ein Byte für eine Adresse einer Vorrichtung der der Speicherbereich zugeordnet ist (Ox1BA). Jedes dieser Bytes ist mit einer Prüfsumme (Checksum) abgesichert. Des Weiteren ist der Adressbereich 0x500001BC bis 0x500001BF für interne Festlegungen, z.B. unveränderliche Betriebsparameter, Versionsnummer, etc. vorgesehen.
