Wozu ein Bus Updater?

Um den Sinn und Zweck eines Bus Updaters zu erkennen, muss man zuerst verstanden haben, dass das "Programmieren" des "Applikationsprogramms" mittels ETS kein wirkliches programmieren im herkömmlichen Sinne ist.
Mittels ETS werden Konfigurationsdaten zu den KNX Geräten gesendet, die die Software sich entsprechend verhalten lassen.

Das eigentliche Programm bzw. die Software auf dem KNX Gerät lässt sich so nicht beeinflussen.

Einige Hersteller haben ähnlich wie wir hier ein Updater Programm, um über den KNX Bus neue Software auf ihre Geräte zu übertragen.

So soll es auch der Selfbus Bus Updater machen. Wenn eine neue Software mit neuen Funktionen, Bugfixes oder ähnlichem zur Verfügung steht, kann diese mithilfe des Bus Updaters auf das KNX Gerät übertragen werden.
Somit ist kein Ausbau der Controllerplatine z.B. aus dem REG Gehäuse oder kein Einsammeln der Rauchmelder notwendig.

Funktionsweise

Der Updater besteht aus 2 Teilen: dem Bootloader auf dem ARM Prozessor im KNX Gerät und dem PC Tool auf Java Basis.

Der Bootloader bootet immer als erstes auf dem Controller und verwaltet dann die erste Funktionsweise.
Ist noch kein Programm auf dem Controller, verbleibt der Bootloader im programmierbaren Modus.
Sollte jedoch bereits vorher ein Programm per Bus Updater übertragen worden sein, wird dieses direkt gestartet.

Die folgende Grafik zeigt den Speicheraufbau eines LPC1115 mit Bootloader (Release).
Der Bootloader verbiegt den ProgramCounter nach erfolgreicher Prüfung der Applikationssoftware auf die Speicheradresse 0x2000.
Dadurch wird das Applikationsprogramm ausgeführt und der Bootloader wird im weiteren Betrieb nicht wieder verwendet.

 

Das PC Tool auf Java Basis ist aktuell (noch) ein Konsolenprogramm, welches auf dem PC gestartet wird.

Ein KNX IP Interface oder Router mit Tunneling Funktion wird benötigt, um die Daten auf den KNX Bus zu übertragen.
Das Tool prüft vor dem übertragen der Daten, ob die Daten für den Updater passen sind.

Bedienung des Bootloaders auf dem ARM

Der Bootloader hat 3 verschiedene Zustände:
- Prog LED blinkt langsam (1s an, 1s aus): Bootloader ist aktiv, hat aber keine Verbindung zum PC Updater Tool
- Prog LED blinkt schnell (250ms an, 250ms aus): Bootloader hat Verbindung zum PC Updater Tool (Daten werden übertragen)
- Prog LED blinkt langsam und wechselt zwischen hell und dunkel: Der Bootloader ist aktiv und dazu wurde der Programmiermodus üder den PROG Taster gestartet

Den Bootloader kann man auf verschiedene Wege aktivieren:
- ohne Programm ist der Bootloader immer nach dem Einschalten aktiv
- aus dem laufenden Programm kann der Bootloader durch das PC Tool aktiviert werden (siehe "Bedienung des PC Updater Tools")
- durch Abklemmen der Spannungsversorgung; beim Anklemmen muss der PROG Taster gedrückt sein (bis die PROG LED blinkt)

Bedienung des PC Updater Tools

Das PC Updater Tool benötigt JAVA 12 (hier herunterzuladen: https://jdk.java.net/15/) -> ToDo: bitte um Rückmeldung, ob das so funktioniert, mein PC ist "verseucht" mit Java Versionen vom Programmieren

- ein Powershell- oder ein Konsolenfenster öffnen (in Linux ein Terminal)
- eine Powershell lässt sich schnell durch die Eingabe von powershell in die Adresszeile des Dateiexplorers eingeben, dann entfällt das navigieren in den richtigen Ordner
- mit dem Befehl java -jar SB_updater_0.52 -help lässt sich die Hilfe anzeigen bzw. alle möglichen und nötigen Parameter werden dargestellt:

INFO: Selfbus Updater 0.52

usage: SB_updater.jar [options] <host|port> -fileName <filename.hex> -device <KNX device address>

options:
 -help -h                   show this help message
 -fileName                  Filename of hex file to program
 -version                   show tool/library version and exit
 -verbose -v                enable verbose status output
 -localhost <id>            local IP/host name
 -localport <number>        local UDP port (default system assigned)
 -port -p <number>          UDP port on <host> (default 3671)
 -nat -n                    enable Network Address Translation
 -serial -s                 use FT1.2 serial communication
 -routing                   use KNXnet/IP routing
 -medium -m <id>            KNX medium [tp0|tp1|p110|p132|rf] (default tp1)
 -progDevice                KNX device address used for programming (default 15.15.192)
 -device <knxid>            KNX device address in normal operating mode (default none)
 -appVersionPtr <hex/dev>   pointer to APP_VERSION string in new firmware file
 -uid <hex>                 send UID to unlock (default: request UID to unlock)
 -full                      force full upload mode (disable diff)

An dieser Ausgabe ist zu sehen, dass immer eine host IP Adresse des IP Gateways benötigt wird.
Sobald der Standard Port 3671 verwendet werden soll, braucht dieser nicht mit angegeben werden.

Die Option -device wird nicht zwingend benötigt. Wenn das KNX Gerät bereits ein Programm aktiv hat, kann durch die Angabe der physikalischen Adresse der Bootloader aktiviert und somit das Gerät neu programmiert werden.

Die UID des Controllers ist ein wichtiger Parameter. Diese UID ist die Identifikationsnummer eines ARM Prozessors. Ohne diese UID lässt sich ein Programm nicht ohne Eingriff am Gerät übertragen.
Zum Auslesen der UID wird der Parameter -uid weggelassen. Dieses bedingt aber einen aktiven Bootloader mit aktiviertem Programmiermodus.
Wie beim Schreiben der physikalischen Adresse per ETS ist es hier auch zwingend notwendig, dass nur ein Gerät am Bus sich in diesem Modus befindet.
Die UID sollte man sich pro Gerät abspeichern für ein eventuelles Update der Software.

Das PC Updater Tool beherrscht ein differentielles Update, sodass nicht alles immer wieder übertragen werden muss, wenn es sich nicht verändert hat.
Das differentielle Update ist die Standardeinstellung. Wenn das volle Programm übertragen werden soll, muss er Parameter -full mit angegeben werden.

Die zu übertragende Datei wird mit dem Parameter -fileName angegeben.
Sollte nur die UID herausgefunden werden, kann auch der Parameter -f0 angegeben werden, dann wird keine Datei übertragen.

Ein kompletter Aufruf für ein bereits mit Software versorgtes (im Normalmodus laufendes) Gerät lautet z.B.:

java -jar SB_updater_0.52.jar 192.168.178.3 -fileName Rauchmelder-bcu1_0x2000.hex -uid 31:30:00:0B:E9:14:BD:AE:9A:98:1B:77 -device 1.0.11 -full


Erstellen von Programmen mit MCUXpresso für den Bus Updater

Wenn man versucht, ein "normal" übersetztes Programm per Bus Updater zu übertragen wird recht schnell scheitern.
Das PC Tool kontrolliert vor dem Übertragen, ob das Programm an der richtigen Speicheradresse beginnt.

Das kommt daher, dass der Bootloader im Speicherbereich 0x0000 - 0x2000 (bzw. 0x0000 - 0x3000 für die Debug Version) installiert ist.

Man muss das Programm also so kompilieren und linken, dass es ab der Speicherstelle 0x2000 beginnt.

Dazu muss der Linker die entsprechende Einstellung haben:

Zuerst muss in die Einstellungen des entsprechenden Projektes gewechselt werden.
Dazu das Projekt im Projektexplorer anwählen und über Projekt -> Properties die Eigenschaften aufrufen



Anschließend die post-build steps suchen

Über den Button "Edit" kann man die Optionen verändern.
Sie müssen folgendermaßen lauten (oder zumindest beinhalten):
arm-none-eabi-size "${BuildArtifactFileName}"
arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"
arm-none-eabi-objcopy -O ihex ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.hex

Anschließend muss noch die Startadresse auf 0x2000 bzw. 0x3000 (für Debug-Version) gesetzt werden


Normalerweise steht bei Location 0x0000, da das Programm den ganzen Speicherplatz nutzen können soll.
Für den Bootloader müssen wir am Anfang 0x2000 Bytes Platz lassen.

Bei der Size steht für den LPC1115 dort normalerweise 0x10000 (LPC1114: 0x8000).
Um dem Linker klar zu machen, dass das Projekt in den verbleibenden Platz passen muss, sollte auch dieses angepasst werden.
Vom Gesamtplatz im LCP1115 von 0x10000 Bytes wird der Bootloaderplatz mit 0x2000 Bytes abgezogen (0x10000 - 0x2000 = 0xE000)
(Size beim LPC1114: 0x8000 - 0x2000 = 0x6000)

Somit sollte auch klar sein, dass es durchaus Projekte geben kann, die nicht Bootloader kompatibel sind, weil sie einfach zu groß sind.
Beim LPC1115 haben wir eben 0x10000 Bytes, also 64kiB Platz. Zieht man davon die 0x2000 Bytes, also 8kiB ab, verbleiben noch 56kiB für das eigentliche Programm.

Für solche Projekte wie z.B. das Rauchmelder- oder 8-out Projekt ist dieser mehr als ausreichend.

Vorgehensweise

Die Vorgehensweise bei Verwendung des Bus Updaters für den Aufbau eines neuen Gerätes unterscheidet sich ein wenig von der herkömmlichen Vorgehensweise.
Daher möchte ich hier einmal die einzelnen Schritte aufführen

  1. Den Bootloader aus dem Selfbus Git herunterladen. Dabei ist die benötigte Dateiendung davon abhängig, wie der Bootloader auf den ARM Prozessor übertragen werden soll:
    - Für die Übetrgagung mittels UART (siehe ARM Entwicklung - Getting Started) wird die .hex Version benötigt.

    - Falls ein JTAG programmer (LPC-Link o.ä.) zur Verfügung steht und MCUXpresso installiert ist, kann die .axf Datei mit dem GUI FLash Tool aus MCUXpresso heraus verwendet werden.
  2. Das Selfbus Bus Updater PC Tool aus dem Git herunterladen.
  3. Java herunterladen und installieren.
  4. Die entsprechende Software für den ARM Prozessor herunter laden oder mittels MCUXpresso compilieren (Achtung: Startadresse verschieben!)
  5. Den Selfbus Bus Updater in einer Konsole oder Powershell mit entsprechenden Parametern aufrufen
  6. Warten...
  7. Freuen ;-)
       

Problemlösungen

Ich hatte das Problem, dass ich auf meiner Windows 10 Powershell keine farbigen Texte angezeigt bekam, sondern kryptische Zeichen.
Dieses Problem lässt sich folgendermaßen lösen:

- Aufrufen des Registry Editors: Windows Taste auf Tastatur drücken -> regedit eingeben
- in der linken Spalte "HKEY_CURRENT_USER" aufklappen
- "Console" auswählen
- im rechten Fenster den Eintrag "VirtualTerminalLevel" suchen und auf 1 setzen
- sollte der Eintrag "VirtualTerminalLevel" nicht vorhanden sein -> Rechtsklick -> Neu -> DWORD-Wert (32 Bit) -> Name: VirtualTerminalLevel -> Daten: 1

direkt im Anschluss an diese Einstellung sollten die Einträge in der Powershell farbig erscheinen