Implementierung eines CANopen Bootloader

Sequenzdiagramm Ablauf CANopen Bootloader und Applikation

CANopen Bootloader

Bei der Implementierung eines CANopen Bootloader sind einige Besonderheiten zu beachten. Zum Einen ist eine geringe Code-Größe ein oft entscheidendes Merkmal und zum Anderen wird in den meisten Fällen der CAN-Controller im Polling betrieben. Darüber hinaus sind oft hersteller-spezifische Sicherheitsmechanismen zu implementieren. Weiterhin ist der Übergang von Bootloader zur Applikation und umgekehrt technisch anspruchsvoll.

CANopen Protokollimplementierung

Bei der CANopen Protokollimplementierung besteht oft die Herausforderung eine geringe Codegröße zu erzielen. Daher sind in diesem Fall allgemeine CANopen Stacks
weniger geeignet, sondern es ist empfehlenswert, einen spezielle Protokollimplementierung zu erstellen, welche genau auf die Zwecke des Bootloaders abgestimmt ist.
Die dafür minimal nötigen Dienste sind:

  • CANopen Bootup Message
  • CANopen Heartbeat
  • NMT Slave State Machine
    • OPERATIONAL muss nicht unterstützt werden
    • Reset Application ist zwingend notwendig
  • SDO Server – expedited transfer (Lese- und Schreibzugriff)
  • SDO Server – segmented transfer (Schreibzugriff)

Für Fehlerausgaben über CANopen könnte noch der Emergency-Dienst implementiert werden, aber dieser ist für den Firmware-Update nicht nötig.
Da Emergency-Nachrichten asynchron und im Pre-Operational-Zustand gesendet werden können, kann dieser Dienst auch unter Verwendung herstellerspezifischer Informationen zu Debug- oder Statusausgaben verwendet werden.
Mit der Optimierung der Protokollimplementierung auf die aufgeführten Dienste, kann man eine Codegröße von unter 8 kB für die Protokollimplementierung erreichen.

CAN Controller und Timer

Um Rückwirkungen auf die Applikation so gering wie möglich zu halten, sollte der Bootloader so wenig wie möglich Mikrocontroller-Komponenten initialisieren wie möglich.
Dies bedeutet, dass ggf. nur der Taktgeber, der CAN-Controller, die GPIOs für CAN sowie ein Timer initialisiert werden. Auf Interrupt sollte zudem auch verzichtet werden.
Den Timer, welche nur für Heartbeat-Nachrichten benötigt wird, kann man im Polling abfragen. Die möglichen Ungenauigkeiten dabei spielen für diesen Anwendungsfall auch keine Rolle.
Ebenfalls ist es möglich den CAN Controller im Polling zu betreiben. Insbesondere da die CPU neben CAN und Flash keine weiteren Aufgaben zu dem Zeitpunkt zu bearbeiten hat. Der segmentierte Transfer von CANopen bietet zudem den Vorteil, dass eine weitere CAN-Nachricht zum Bootloader erst dann gesendet wird, wenn diese vom Bootloader bestätigt wurde, so dass es da auch zu keinen Überläufen kommen kann. Mit der Nutzung der Hardware-Filterung nach CAN-IDs im CAN-Controller wird die Belastung der CPU weiter reduziert.
Jedoch ist auch eine optionale Unterstützung des CANopen SDO Blocktransfer möglich. Dabei werden zwar bis zu 127 CAN-Telegramme hintereinander an den Bootloader gesendet, aber wenn die Nachrichteninhalte im RAM zwischengepuffert werden, ist dies alles ebenfalls im Polling zu realisieren. Nach dem Empfang eines Blocks von bis zu 127 CAN-Telegrammen schreibt der Bootloader die Daten in den Flash und signalisiert erst danach den erfolgreichen Empfang der Daten.

Start des Bootloaders und der Applikation

Start des Bootloaders
Beim Start des Bootloaders wird nach der Initialisierung geprüft, ob der Bootloader im Bootloader-Modus bleiben soll oder die Applikation starten soll. Soll die Applikation gestartet werden, so wird geprüft, ob die CRC über die Applikation korrekt ist und dann die Applikation angesprungen. Das Merkmal, ob ein Bootloader nach einem Reset im Bootloader-Modus verharren soll, kann auf verschiedene Weise realisiert werden. In dem Beispiel wird ein Marker in einem 4-Byte RAM-Bereich verwendet, welcher bei einem Software-Reset nicht überschrieben wird. Alternativ können Informationen aus dem Flash, EEPROM oder eine externe Beschaltung als Merkmal verwendet werden, dass der Bootloader die Applikation nicht starten soll. Unabhängig davon verbleibt das Gerät im Bootloader, wenn keine gültige Applikation (keine gültige CRC) vorhanden ist. Durch diese Prüfung beim Start ist sichergestellt, dass die Applikation im Flash fehlerfrei ist.

Firmware-Update

Da ein CANopen Bootloader nur standardisierte CANopen Dienste nutzt und zudem die für den Firmware-Update verwendeten CANopen Objekte in der Spezifikation CiA 302-2 beschrieben sind, kann jeder CANopen-Master oder jedes CANopen-Master-Tool, welches segmentierten SDO Transfer unterstützt, zum Update der Applikation eingesetzt werden.
Nachfolgende Abbildung zeigt einen Screenshot des CANopen UpdateManager, welcher ein dediziertes Tool für ein Firmware-Update über CANopen darstellt:

Update des Bootloaders

Soll der Bootloader im Feld aktualisiert werden, so ist ein anderes Vorgehen nötig, da der Bootloader üblicherweise nur Schreibzugriff auf den Speicherbereich der Applikation hat. Eine Variante ist das Flashen eine speziellen Update-Applikation, welche dann den Bootloader austauscht. Dabei kann die Update-Applikation entweder den Bootloader über SDO-Transfer empfangen oder ihn gleich quasi huckepack beinhalten. Dabei wird beim ersten Start der Update-Applikation der Bootloader ausgetauscht wird.
Eine andere Möglichkeit des Update des Bootloaders wäre es, ihn über die normale Applikation zu aktualisieren. Dies hat jedoch den Nachteil, dass Routinen und ggf. Bibliotheken zum Flash-Schreibzugriff in die normale Applikation eingebunden werden müssen, obwohl diese möglicherweise zum normalen Betrieb nicht nötig sind.
Bei einem Update ist Bootloaders ist auch zu Berücksichtigen, dass dies oftmals aufgrund von Speicherzugriffsmechanismen nicht einfach möglich ist.

CANopen Software Toolchain

Der Bootloader ist ein wichtiger Bestandteil der nötigen CANopen Software Toolchain und die Grundlage für eine erfolgreiche CANopen Slave-Entwicklung.