BIM112 Geräte verlieren die ETS-Programmierstatus Flags

[Darthyson]

Hallo,

ich habe zwei TS_ARM als in16-bim112 und auch als rol-jal-bim112 getestet.
Dabei ist mir aufgefallen, dass beim programmieren der physikalischen Adresse des einen TS_ARM,
der andere in der ETS seine Programmierstatusflags verliert und immer wieder neu programmiert werden muss.

Das Problem ist meiner Meinung nach, dass alle sblib-Geräte die selbe Seriennummer bekommen,
welche aus der Teilenummer des ARM erzeugt wird.

Zum Testen habe ich in der bcu_base.cpp die Erzeugung der Seriennummer so geändert,
dass aus der 128bit-Seriennummer des ARM eine 48bit "Hash"-Seriennummer generiert wird.
Dadurch konnte ich dann die physikalischen Adressen ohne Probleme programmieren.

Falls das jemand nachvollziehen kann, würde ich dazu einen Pull-Request machen.

Viele Grüße
Denis

[Mirko]

Hi Denis,
klingt für mich nach einer sinnvollen Anpassung. Eindeutige Seriennummern sind sicher nie verkehrt

Grüße
Mirko

[Mirko]

Beim darüber Nachdenken fiel mir noch folgendes ein:

Wenn Du die 128Bit auf 48 reduzierst, gibt es ja auf jeden Fall einen Informationsverlust. Das bedeutet dann aber doch, dass es bei etlichen ARM Seriennummern die gleichen reduzierten 48 Bit ergeben wird. Wie geht man dann mit diesen Kollisionen um, wenn das bei der Programmierung Probleme macht. Wenn man die Seriennummer nicht zentral vergeben möchte, bleibt doch nur, den Bus auf solche Kollisionen zu prüfen. Könnte man das mit in der sblib implementieren und z.B. bei der ersten Inbetriebnahme des Gerätes eine valide Seriennummer erzeugen und im EEPROM bzw. Flash des LPC speichern? Ich fürchte, das geht nicht.

Eine zweite Hürde wäre das Firmwareupdate. Sobald Dein SW-Change im Code drin ist, müssen aktualisierte Geräte neu angelernt werden, da sich ja dann die Seriennummer geändert hat. Darauf muss dann hingewiesen werden.

Und dann wäre noch die Frage, warum das Problem bisher nicht auffiel?

[Darthyson]

Hallo,

unter https://community.nxp.com/t5/LPC-Microc ... m-p/596131 steht, dass man die kompletten 128bit verwenden sollte.

NXP_USA:

Unfortunately the details of what go into the 128-bit GUID cannot be disclosed. It can be said, however, that the 128-bit GUIDs are not random, nor are they sequential. Thus to ensure there are no collisions with other devices, the full 128 bits should be used.

Allerdings wenn ich das richtig sehe ist die Seriennummer bei KNX nur 48bit, daher ein Hashen um mögliche Kollisionen bei den Seriennummern zu reduzieren, ausschliessen kann man es aber leider nicht.

Warum das Problem bisher nicht auffiel kann ich nicht sagen, da ich mich erst seit kurzem mit dem ARM beschäftige,
bisher hatte ich immer den alten LPC922 im Einsatz. Betrifft möglicherweise auch nur Geräte mit BCU2 bzw. BIM112,
wenn ich den Code richtig lese.

Getestet habe ich mit der aktuellen ETS Version 5.7.4 und den MDT-Produktdatenbanken:
MDT_KP_BE_01_Binary_Input_V20a.knxprod
MDT_KP_Jalousieaktor_V28.knxprod

Das zugehörige ETS-Log beim Programmieren der phys. Adresse 1.1.22:

Code: Alles auswählen

#,Zeit,Dienst,Flags ,Prio,Quelladresse,Quellname,Zieladresse,Zielname,Rout,Typ,DPT,Info
4,"02.09.2020 17:43:08,758",zum Bus,,System,1.1.253,-,0/0/0,Broadcast,6,PhysAddrRead,,
5,"02.09.2020 17:43:08,779",vom Bus,,System,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",0/0/0,Broadcast,6,PhysAddrResponse,,
6,"02.09.2020 17:43:11,768",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,T_Connect,,
7,"02.09.2020 17:43:11,791",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,DeviceDescriptorRead (S=0),,DescriptorType=0
8,"02.09.2020 17:43:11,808",vom Bus,,System,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",1.1.253,-,6,T_ACK (S=0),,
9,"02.09.2020 17:43:11,836",vom Bus,,System,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",1.1.253,-,6,DeviceDescriptorResponse (S=0),,"DescriptorType=0, DescriptorData=07 01"
10,"02.09.2020 17:43:11,855",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,T_ACK (S=0),,
11,"02.09.2020 17:43:11,893",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,PropertyValueRead (S=1),,"ObjectIndex=0, PropertyId=11, Count=1, StartIndex=1"
12,"02.09.2020 17:43:11,912",vom Bus,,System,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",1.1.253,-,6,T_ACK (S=1),,
13,"02.09.2020 17:43:11,943",vom Bus,,System,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",1.1.253,-,6,PropertyValueResponse (S=1),,"ObjectIndex=0, PropertyId=11, Count=1, StartIndex=1, Data=80 00 05 00 00 01"
14,"02.09.2020 17:43:11,963",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,T_ACK (S=1),,
15,"02.09.2020 17:43:12,004",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,Restart (S=2),,
16,"02.09.2020 17:43:12,023",zum Bus,,System,1.1.253,-,1.1.22,"Binäreingang 16-fach, 8TE, Eingänge potentialfrei",6,T_Disconnect,,
17,"02.09.2020 17:43:12,044",zum Bus,,System,1.1.253,-,0/0/0,Broadcast,6,PhysAddrRead,,

Die entscheidende Zeile ist:

PropertyValueResponse (S=1),,"ObjectIndex=0, PropertyId=11, Count=1, StartIndex=1, Data=80 00 05 00 00 01"

bei der das Gerät der ETS die Seriennummer schickt. Danach fehlen die Programmierflags bei Geräten mit der gleichen Seriennummer.

Sobald Dein SW-Change im Code drin ist, müssen aktualisierte Geräte neu angelernt werden, da sich ja dann die Seriennummer geändert hat. Darauf muss dann hingewiesen werden.

Daher hab ichs auch erstmal hier ins Forum geschrieben, da es doch eine etwas größere Änderung wäre.
Ich hoffe dass es noch jemand nachvollziehen kann.

Viele Grüße
Denis

[Doumanix]

Dabei ist mir aufgefallen, dass beim programmieren der physikalischen Adresse des einen TS_ARM,
der andere in der ETS seine Programmierstatusflags verliert und immer wieder neu programmiert werden muss.

Das Problem ist meiner Meinung nach, dass alle sblib-Geräte die selbe Seriennummer bekommen,
welche aus der Teilenummer des ARM erzeugt wird.

Hi Denis,

kannst du das bitte noch weiter konkretisieren? Ich habe immerhin mehrere ARM Geräte parallel am Laufen und mir sind solche Probleme noch nicht aufgefallen. Ich habe immerhin 5 ARM Eingangsmodule und mehrere SChalt- bzw. Rolloaktoren am Bus. Sollen zwar noch deutlich mehr werden, aber um das von dir beschriebene Problem nachzustellen, sollte das ja ausreichen.

Wie hast du das genau festgestellt? Zeigt die ETS plötzlich nicht mehr die grünen Haken an?

Ich vermute, du hast selbst compilliert? Wo / wie übersetzt du? Linux / Windows? MCUXpresso / LPCXpresso?
etc etc.

Grüße
Christian

[Darthyson]

Hallo,

Ja genau, die 5 grünen Haken in der ETS sind dann bei den anderen Geräten weg.

Sowohl in16-bim112 (8x und 16x Variante) als auch rol-jal-bim112 habe ich selbst kompiliert mit aktuellem Repo-Stand. Alles für den TS_ARM mit Compilerflag TS_ARM. Den 4TE Controller habe ich noch nicht getestet.

Als Buszugang für die Programmierung habe ich sowohl "Gira IP-Router 103000" als auch "Gira IP Schnittstelle 216800/V02" verwendet.

Zum Compilieren habe ich folgendes System:
Windows 10 Version 2004 (Build 19041.508) mit
MCUXpresso IDE v11.2.0 [Build 4120] [2020-07-09].
ETS 5.7.4 (Build 1093)

Wobei ich die Compilierung bzw. das resultierende *.axf File nicht als Problem vermute, da ja die korrekte Seriennummer bestehend aus Part-ID des ARM und der sbLib-Version an die ETS übermittelt wird.
siehe bcu_base.cpp ab Zeile 106:

Code: Alles auswählen

#if BCU_TYPE != BCU1_TYPE
    unsigned int serial;
    iapReadPartID(& serial);
    memcpy (userEeprom.serial, &serial, 4);
    userEeprom.serial[4] = SBLIB_VERSION >> 8;
    userEeprom.serial[5] = SBLIB_VERSION;

Ich vermute vielmehr die Ursache liegt bei der ETS-Version oder den MDT-Produktdatenbanken.

Viele Grüße
Denis

[Darthyson]

Hallo Doumanix,

kleiner Nachtrag:

Ich habe immerhin 5 ARM Eingangsmodule

Welche Version (BCU, x-fach, Produktdatenbank) verwendest du denn?

Weil beim Testen der 8x in16-bim112 fiel mir auf, dass für den 4x und 8x der falsche Devicetype im Code steht.
Gibt dazu auch einen Pull-Request im Repo von mir.

Viele Grüße
Denis

[Darthyson]

Hallo,

nach einem Tipp von Doumanix habe ich mal mit der ETS Version 5.6.6 getestet, und siehe da KEINE Probleme.

Kurz Google bemüht und folgendes gefunden:
Changelog ETS 5.7.0

da steht dann unter Bug-Fixes:

Bug-Fixes
Benutzeroberfläche & Funktionsweise

Einzigartigkeit der Seriennummern des Geräts geprüft

Anschliessend mit der ETS Version 5.7.0 Build 619 getestet, und das Problem ist WIEDER DA.

Hier mein Vorschlag zur Änderung der /software-arm-lib/trunk/sblib/src/eib/bcu_base.cpp als Diff für die Erzeugung einer gehashten Seriennummer:
siehe neueren Post
Änderungen sind jetzt im software-arm-lib Repository drin.

Das durch die Reduktion von 128bit auf 48bit Kollisionen entstehen ist leider nicht auszuschliessen.

Grüße
Denis

edit: ursprüngliches Diff gelöscht und auf aktuellen Post verlinkt.
edit2: Verweis auf sblib Repository

[Darthyson]

Hallo zusammen,

wollte das nochmal pushen, da ich das nicht ganz für unwichtig halte:

Dabei ist mir aufgefallen, dass beim programmieren der physikalischen Adresse des einen TS_ARM,
der andere in der ETS seine Programmierstatusflags verliert und immer wieder neu programmiert werden muss.

Kann eventuell jemand mit zwei BIM112 Geräten und einer ETS-Version >= 5.7.0 das mal testen?
Mit Programmierstatusflags mein ich die hier in der ETS:

Programmierflags

Changelog ETS v5.7.0: ... Bug-Fixes: .... Einzigartigkeit der Seriennummern des Geräts geprüft ...

Viel Grüße Denis

[StefanSverige]

Die Seriennummer wird vermutlich für KNX Secure immer wichtiger und daher wird das Thema jetzt gepusht.
Der Hersteller kann das Zentral vergeben, was bei uns schwer bis unmöglich ist.

Der Vorschlag mit dem Hash ist nach der Antwort von NXP vermutlich die beste Lösung und wenn es wirklich mal bei einem Probleme gibt, müsste man schauen.