KNX Bootloader für ARM

[Olli]

Hallo,

ich hatte bisher immer noch Probleme mit dem Bus Updater.
Das war vornehmlich dann zu beobachten, wenn weitere Buskommunikation in Form von groupwrite Nachrichten vorherrschte.
Nach etlichen Versuchen und Busaufzeichnungen habe ich dann das Problem erkannt:
Es wird nach einem groupwrite ein weiteres ACK gesendet, allerdings mit der Eigenschaft "Repeat on Error: Yes"
Dieses erneute Senden eines Acknowledges brint die calimero lib aus dem Tritt und die Verbindung wird abgebrochen.

Das Ganze habe ich dann auch mal bei der calimero lib gemeldet:
https://github.com/calimero-project/cal ... /issues/96

Dort wure mir dann die Codestelle aufgezeigt, die bei erneutem ACK Empfang das disconnect einleitet.

Daraufhin habe ich die calimero lib als Projektdateien mit eingefügt und die Stelle auskommentiert.

Nun gibt es zwar diese Sicherheit nicht mehr, dass im Falle eines offnen Endpoints dieser geschlossen wird, sobald ein ACK empfangen wird, aber dafür funktioniert der Bus Updater nun problemlos (auch am produktiven KNX Bus).

Eventuell wächst daraus ja auch noch eine Änderung der calimero lib, aber das weiß ich natürlich nicht.

Ich habe mir mal die Freiheit genommen, den Bus Updater mit seinen Eigenschaften im neuen Wiki zu beschreiben:
https://selfbus.org/wiki/software/tools ... dater-tool

Die neue Version ist hier im Git zu finden.

Das bestehende Problem mit der Anfangsadresse 0x2000 für die Release Version besteht zwar immer noch, aber so kann man den Updater bereits verwenden.

Grüße,
Olli

[Olli]

Nachtrag:
Mit den aktuellen Sourcen funktioniert nun auch der Bootloader in der Release Variante.
Also kann man nun ab 0x2000 das Programm beginnen lassen

Damit ist aus meiner Sicht der Bus Updater vollständig einsetzbar.

Grüße,
Olli

[Mirko]

Super!

[StefanSverige]

Super Olli das du dich da hinter geklemmt hast, dann haben sich meine Java Experimente mit dem Updater ja gelohnt

Jetzt fehlt nur noch ein kleines GUI das einem das ganze Tippen abnimmt

[Olli]

Hallo,

ich möchte hier bekannt machen, dass es eine Umstellung im Updater gab.
Die Version 0.53 verwendet im full download Modus nun die ersten 2 Bytes der Daten für die Adresse der Daten.

Zum Hintergrund:
Bei mir im produktiven System gab es mit dem Bus Updater noch immer Abbrüche, weil die Nachrichten nicht durch kamen. Allerdings sehr sporadisch und nicht reproduzierbar.
Somit habe ich mich entschlossen, die Daten einfach erneut zu senden, wenn die Nachricht nicht durchkam (also keine Bestätigung vom KNX Gerät kam).
Dieses war nicht so einfach möglich, da ursprünglich einfach die Adresse der Daten im Controller hochgezählt wurde. Da das PC-Tool im Falle der Störung nicht wusste, ob die Daten nun im Controller angekommen waren oder nicht, konnte die erneute Versendung der Daten nicht stattfinden.

Ich habe die Nachricht nun so umgebaut, dass von den 12 Datenbytes die ersten 2 Bytes für die Adresse der Daten genutzt wird.
Damit kann das PC-Tool nun an eine beliebige Stelle des Speichers im Controller schreiben.
Leider geht der Vorteil der Stabilität zu Lasten der Geschwindigkeit.
Wo vorher 12 Bytes Daten pro Nachricht versendet werden konnten, werden nun nur 10 Bytes Daten übertragen.
Für mich ist das allerdings immer noch schneller, als mehrfach ein Update starten zu müssen.

Daher muss die Version 0.53 des Bootloaders unbedingt mit der Version 0.53 des PC-Tools genutzt werden.

Grüße,
Olli

[Darthyson]

Hallo Olli,

ich habe mal versucht mit dem out8 deinen Updater zu nutzen.
Das Updaten über -uid funktioniert eigentlich problemlos, siehe log (hab ich etwas gekürzt):

Code: Alles auswählen

PS D:\Updater> java\bin\java -jar SB_updater_0.54.jar 192.168.0.91 -fileName out8-bcu1_0x3000.hex -uid 4D:00:04:05:E7:A4:6B:AF:0D:77:72:5E -v -full


     _____ ________    __________  __  _______    __  ______  ____  ___  ________________
    / ___// ____/ /   / ____/ __ )/ / / / ___/   / / / / __ \/ __ \/   |/_  __/ ____/ __ \
    \__ \/ __/ / /   / /_  / __  / / / /\__ \   / / / / /_/ / / / / /| | / / / __/ / /_/ /
   ___/ / /___/ /___/ __/ / /_/ / /_/ /___/ /  / /_/ / ____/ /_/ / ___ |/ / / /___/ _, _/
  /____/_____/_____/_/   /_____/\____//____/   \____/_/   /_____/_/  |_/_/ /_____/_/ |_|
  by Stefan Haller, Oliver Stefan et al.                                      Version 0.54


Unlocking device with UID 4D:00:04:05:E7:A4:6B:AF:0D:77:72:5E ... done (0)
Device Bootloader Identity   : 0x1054, Features: 0x8100, Bootloader Size: 0x3000

Requesting App Version String ...
  Current App Version String is: O08.10  5.00

Loading new firmware file ...
  Hex file parsed: starting at 0x3000, length 10900 bytes
  Could not find the App Version string, setting to 0. Please specify manually with -appVersionPtr!
  Firmware starts directly beyond bootloader.

Requesting Boot Descriptor ...
  Current firmware: starts at 0x3000 ends at 0x9340 CRC is 0x655a48cc

Starting to send new firmware now:
Erase sector 3 ...done (0)
 OKErase sector 4 ...done (0)
 OKErase sector 5 ...done (0)
 OKSending application data (10900 bytes)
........................
Program device at flash address 0x3000 with 256 bytes and CRC32 0x445c7dc ... done (0)
........................
Program device at flash address 0x3100 with 256 bytes and CRC32 0x9c697227 ... done (0)
........................
Program device at flash address 0x3200 with 256 bytes and CRC32 0x64ffabaa ... done (0)
.........................
...
...
...
Program device at flash address 0x5800 with 256 bytes and CRC32 0x5d94d38a ... done (0)
........................
Program device at flash address 0x5900 with 256 bytes and CRC32 0x446fffb7 ... done (0)
..............
Program device at flash address 0x5a00 with 148 bytes and CRC32 0x77738b2d ... done (0)
Wrote 10900 bytes from file to device.

Preparing boot descriptor with start address 0x3000, end address 0x5a94, CRC32 0xeb13cb87, APP_VERSION pointer 0x3000
..Update boot descriptor with CRC32 0xbc1df29e, length 10 done (0)
Firmware Update done, Restarting device now ...


PS D:\Updater>

Probleme habe ich über -device zu updaten, siehe log (ungekürzt):

Code: Alles auswählen

PS D:\Updater> java\bin\java -jar SB_updater_0.54.jar 192.168.0.91 -fileName out8-bcu1_0x3000.hex -device 1.1.1 -v -full


     _____ ________    __________  __  _______    __  ______  ____  ___  ________________
    / ___// ____/ /   / ____/ __ )/ / / / ___/   / / / / __ \/ __ \/   |/_  __/ ____/ __ \
    \__ \/ __/ / /   / /_  / __  / / / /\__ \   / / / / /_/ / / / / /| | / / / __/ / /_/ /
   ___/ / /___/ /___/ __/ / /_/ / /_/ /___/ /  / /_/ / ____/ /_/ / ___ |/ / / /___/ _, _/
  /____/_____/_____/_/   /_____/\____//____/   \____/_/   /_____/_/  |_/_/ /_____/_/ |_|
  by Stefan Haller, Oliver Stefan et al.                                      Version 0.54


Attempting to restart device 1.1.1 in bootloader mode ...
Requesting UID from15.15.192 ... Feb. 05, 2021 6:46:02 PM org.hkfree.knxduino.updater.Updater onCompletion
SEVERE: completed tuwien.auto.calimero.KNXTimeoutException: timeout waiting for data response
tuwien.auto.calimero.KNXTimeoutException: timeout waiting for data response
        at tuwien.auto.calimero.mgmt.UpdatableManagementClientImpl.waitForResponses(UpdatableManagementClientImpl.java:1190)
        at tuwien.auto.calimero.mgmt.UpdatableManagementClientImpl.waitForResponse(UpdatableManagementClientImpl.java:1141)
        at tuwien.auto.calimero.mgmt.UpdatableManagementClientImpl.sendWait(UpdatableManagementClientImpl.java:1125)
        at tuwien.auto.calimero.mgmt.UpdatableManagementClientImpl.sendUpdateData(UpdatableManagementClientImpl.java:1253)
        at org.hkfree.knxduino.updater.Updater.run(Updater.java:691)
        at org.hkfree.knxduino.updater.Updater.main(Updater.java:110)
PS D:\Updater>

Das hat bei mir einmal funktioniert und seit dem bekomme ich immer die KNXTimeoutException.
Nach "Requesting UID from15.15.192" blinkt die RUN-Led im 250ms Takt.
Am Bus hängt nur IP-Schnittstelle und out8 4TE.

Kann es sein, dass wenn man in eclipse die Flash-Location auf 0x3000 setzt, man die Möglichkeit des Debuggens der App verliert, selbst wenn der Bootloader nicht geflasht ist und man mit dem GUI Flash Tool "Program (mass erase first)" flasht?

Viele Grüße
Denis

[Darthyson]

Hallo,

Olli oder Stefan mögen mich berichtigen, aber meiner Meinung nach fehlt im Wiki-Eintrag zum Bootloader ein wichtiger Hinweis:

Wenn man eine App für den Bootloader compiliert muss man nicht nur den Flashbereich anpassen, sondern auch die Ramloc8 auf 0x10000100 und Size 0x1f00 (256byte werden damit für den Bootloader reserviert). Ist zwar im Wiki auf dem Bild zu sehen, aber leider nicht rot umrandet und auch nicht im Text erwähnt.

Ursprünglich wollte ich den Bootloader nutzen um möglichst viel Buslast zu erzeugen und damit den DEV-Timing+0x07B0+Properties Branch zu testen. Allerdings hat das nicht so recht geklappt. Dadurch bin ich tiefer in den Bootloader eingestiegen und bin gerade dabei einige Änderungen/Erweiterung auf dem obigen Branch mit einzubauen. @Olli und @Stefan falls ihr da auch gerade dran sitzt wäre es schön sich etwas abzusprechen.

Habt ihr schon mal getestet die Telegramme mit erhöhter Priorität zu senden?

P.S. Die bisherigen Ergebnisse vom DEV-Timing...Branch testen sehen sehr viel versprechend aus. Mit -delay 0 (Mindestgrenze von 40ms im Updater entfernt):
Wrote 10900 bytes from file to device in 03:08. Mit 0 Timeouts an meinen Hausbus wo immer was los ist. 68 Geräte an einer Linie
Wrote 10900 bytes from file to device in 01:52. Mit 0 Timeouts am Testbus mit 2 Geräten

Grüße
Denis

[gnampf]

sollten die Bootloader-Telegramme nicht eher eine möglichst niedrige Prio haben? Ich möchte ja nicht plötzlich mehrere Minuten das Licht nicht einschalten können, nur weil ich ein Gerät neu flashe. Dann lieber etwas länger warten bis das flashen durch ist
Aber warum sollte der Bootloader noch RAM verbrauchen nachdem er die Anwendung startet? Liegt das Problem vielleicht eher darin, dass der Speicherbereich dann nicht mehr sauber vorinitialisiert ist? Oder macht der Prozessor einen Teil der Speicherverwaltung?

[Darthyson]

Hi gnampf,

Ich möchte ja nicht plötzlich mehrere Minuten das Licht nicht einschalten können

Das ist sicherlich Ansichtssache. Für mich wäre es wichtig, dass das Update sicher/sauber und schnell durch den Bus geht. Ich hab keine Lust 4min zu warten um dann am letzten Byte zu scheitern und einen Timeout zu bekommen um dann wieder von vorne anzufangen. Es war auch als Frage formuliert . Meine Überlegung geht jetzt zumindest in die Richtung es auszuprobieren und eventuell als -prio o.ä. Parameter anzubieten. Mal schauen...

Aber warum sollte der Bootloader noch RAM verbrauchen nachdem er die Anwendung startet?

Er verbraucht nicht nachdem, sondern davor (siehe bootloader.cpp):

Code: Alles auswählen

static inline void jumpToApplication(unsigned int start)
{
     ...
    // copy the first 200 bytes of the "application" (the vector table)
    // into the RAM and than remap the vector table inside the RAM
    for (i = 0; i < BL_DEFAULT_VECTOR_TABLE_SIZE; i++, rom++, ram++)
    {
        *ram = *rom;
    }
    LPC_SYSCON->SYSMEMREMAP = 0x01;
    ...
}

Genau die Funktion jumpToApplication(...) hab ich leider noch nicht vollständig durchdrungen, bin mir aber mittlerweile sehr sicher, dass eine App welche die ersten 0x100 Byte vom RAM nicht für den bootloader freigibt auch nicht funktionieren wird. Meine These unterstützt auch das memory-layout LPC1115-App-With-Bootloader.xml welches vom ursprünglichen Entwickler (Martin Glück) bereits in 2015 ins Repo committed wurde.

Viele Grüße
Denis

[gnampf]

also ich glaub wohl das es so ist, aber der Sinn erschliesst sich mir halt noch nicht, ausser es liegt an einer fehlenden Initialisierung weil der Prozessor ja keinen Reset macht. Ansonsten sollte beim Start der Anwendung alles was er gebraucht hat ja hinfaellig sein und von der Anwendung genutzt werden koennen.

Hm... hat der ARM die Moeglichkeit einen RAM-Bereich uebers Flash zu mappen? In den ersten 0xC0-Bytes im Flash liegt die IRQ-Table. Bei unserer Anwendung aber liegt sie da nicht, sondern bei 0x3000. Bei IRQs wuerde also wohl der vom Bootloader gerufen. Ich vermute deswegen wird ein entsprechender Bereich vom RAM mit der IRQ-Table befuellt und bei 0x00 ueber das Flash gelegt? Der darf dann natuerlich nicht mehr voll von der Anwendung genutzt werden, da sonst die IRQ-Table zerschossen wird.

Zur Prio: wenn auf jeden Fall als Parameter. Ja, klar, es dauert ggf. laenger und braucht womoeglich den ein oder anderen Retry mehr. An den Timeouts sollten wir eh noch arbeiten und dafuer sorgen das die praktisch nicht auftreten, sondern das ganze wiederholt wird. Bei den Datenbloecken scheints ja zu klappen, beim Flash-Befehl am Ende von jedem Block aber fehlts und er bricht ggf. ab.
Nur: wenn der Programmiervorgang alles andere verhindert kann das auch sicherheitskritisch sein. Der PM verlaengert ploetzlich das LIcht auf der Treppe nicht mehr und du stehst im Dunkeln. Oder wie gesagt noch schlimmer: das LIcht im Wohnzimmer geht nicht mehr an und der WAF macht dir die naechsten Wochen schmerzlich klar, dass das olle moderne Haus doch absoluter Mist ist (auch wenn es gestern noch absolut toll war)

Tante Edith hat da gerade das SYSMEMREMAP gefunden:

The system memory remap register selects whether the ARM interrupt vectors are read from the boot ROM, the flash, or the SRAM. By default, the flash memory is mapped to address 0x0000 0000. When the MAP bits in the SYSMEMREMAP register are set to 0x0 or 0x1, the boot ROM or RAM respectively are mapped to the bottom 512 bytes of the memory map (addresses 0x0000 0000 to 0x0000 0200).

und 0x1 bedeutet

0x1 User RAM Mode. Interrupt vectors are re-mapped to Static RAM

Boot-Rom haben wir ja leider keins

Und Tante Edith nochmal: doch,. Boot-Rom hat er, aber halt ROM... nicht beschreibbar, ist der serielle Bootloader drin. Hilft also nix.
hier haben sie alle IRQs auf die Anwendung gemapped. Sowas kostet aber halt dann jedes Mal ein paar Zyklen, ist denke ich nicht optimal. Entweder verzichten wir in der Anwendung also auf 0x00-0xC0, oder wir muessten den Bootloader seine IRQs ins RAM legen lassen und den Flash-Bereich 0x3000-0x30C0 (oder 0x3004-0x30C0?) (auch) im Flash an 0x0000-0x00C0 speichern. Dafuer muesste man dem Compiler beim Bootloader dann beibringen die IRQ-Table auch an anderer Stelle abzulegen.