Bug in der ARM Lib ?

[Darthyson]

Hallo zusammen

@Mirko, danke für den Verweis auf die richtige Stelle der Spec.

Soweit wie ich mich da durchgelesen habe, gibt es eigentlich keine riesen Unterschiede zwischen Maskversion 0x0701 & 0x0705. Hier und da mal Sachen, die bei der einen optional sind und bei der anderen mandatory.
Allerdings gibt die sblib es z.Zt mit den ganzen #define's in der bcu_type.h nicht wirklich her, dynamisch die Maskversion zu setzen. Es wird wohl daher vorerst auf 3 weitere Build-Config's für die 0x0705 hinauslaufen.

@luckychild, das

Code: Alles auswählen

#define PROP_LOAD_OFFSET  0 bzw. 1

war ein Versuch in der sblib zwischen:
DMP_LoadStateMachineWrite_RCo_Mem (APCI_MEMORY_WRITE_PDU) KNX Spec. 3/5/2 3.28.2 p.109 (deprecated) und
DMP_LoadStateMachineWrite_RCo_IO (ApciPropertyValueWrite) KNX Spec. 3/5/2 3.28.3.4 p.115 zu unterscheiden.
Genau das 3.Byte fehlt eben, bei DMP_LoadStateMachineWrite_RCo_IO, wodurch PROP_LOAD_OFFSET ins "Spiel" kam.
Das hat wahrscheinlich auch u.a. zu diesem Problem geführt.

Code: Alles auswählen

<LdCtrlTaskSegment LsmIdx="5" Address="xxx" />

verwenden und damit die Adresse der ComObjectTable gesetzt wird.

Leider muss ich das wohl doch revidieren, da die ETS es doch nicht so durchreicht, wie ich gehofft hatte.

Daher seh ich z.Zt leider auch keine andere Möglichkeit, als die ComObjectTable bzw. userEeprom.commsTabAddr bei "problematischen" Prduktdatenbanken per "Hand" zu setzen, allerdings entweder über Florians Variante:

Code: Alles auswählen

if (userEeprom.commsTabAddr != 0xZZZZ)
{
    userEeprom.commsTabAddr = 0xZZZZ;
}

oder eine separate Methode der bcu, da ein

Code: Alles auswählen

userEeprom.commsTabAddr == 0 

eigentlich lt. Spec. eine entladende ComObjectTable/Interface Object/Property bedeuten sollte.

Um es kurz zu machen, ich sitze immer noch an dem Problem.
Da allerdings LoadStateMachines, Interface Objects und Properties in der sblib nur sehr rudimänter implementiert sind, wird das noch ein Weilchen dauern. Dieses WE wird da leider nicht mehr viel passieren, allerdings hoffe ich in der nächsten Woche dazu mal einen neuen Branch der sblib bei Github hochzuladen.

Hier schonmal ein serielles dump beim Laden deiner Helios Produktdatenbank:

Code: Alles auswählen

Properties dump enabled BCU_TYPE: 0x705 MASK_VERSION: 0x705 LOAD_CONTROL_ADDR: 0x0104 LOAD_STATE_ADDR: 0xB6E9
findProperty: objectIdx=0x01 OT_ADDR_TABLE propertyid=0x38 PID_MAX_APDULENGTH not implemented
handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x00 LS_UNLOADED
handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x00 LS_UNLOADED
handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x00 LS_UNLOADED
handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x02 LS_LOADING
handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x01 OT_ADDR_TABLE Data: 40 00 01 FF F2 03 80 00 len: 8
  --> start: 0x4000 length: 0x01FF end: 0x41FE access: 0xF2 memtype: 0x03 attrib: 0x80

propertyValueWriteTelegram: objectIdx=0x00 OT_DEVICE propertyid=0x0E PID_DEVICE_CONTROL
handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x01 OT_ADDR_TABLE Data: 40 00 00 01 12 00 01 10 len: 8
  --> startaddress: 0x4000 PEI: 0x00 Manufacturer: 0x0112 AppID: 0x0001 Vers.: 0x10
  ----> userEeprom.addrTabAddr=0x4000

handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x01 LS_LOADED
handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x02 LS_LOADING
handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x02 OT_ASSOC_TABLE Data: 41 FF 01 FF F2 03 80 00 len: 8
  --> start: 0x41FF length: 0x01FF end: 0x43FD access: 0xF2 memtype: 0x03 attrib: 0x80

handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x02 OT_ASSOC_TABLE Data: 41 FF 00 01 12 00 01 10 len: 8
  --> startaddress: 0x41FF PEI: 0x00 Manufacturer: 0x0112 AppID: 0x0001 Vers.: 0x10
  ----> userEeprom.assocTabAddr=0x41FF

handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x01 LS_LOADED
handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x02 LS_LOADING
handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 07 00 00 F8 F2 02 00 00 len: 8
  --> start: 0x0700 length: 0x00F8 end: 0x07F7 access: 0xF2 memtype: 0x02 attrib: 0x00

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 43 FE 01 3C F2 03 80 00 len: 8
  --> start: 0x43FE length: 0x013C end: 0x4539 access: 0xF2 memtype: 0x03 attrib: 0x80

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 46 00 00 15 22 03 80 00 len: 8
  --> start: 0x4600 length: 0x0015 end: 0x4614 access: 0x22 memtype: 0x03 attrib: 0x80

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x03 OT_APPLICATION Data: 45 30 00 01 12 00 01 10 len: 8
  --> startaddress: 0x4530 PEI: 0x00 Manufacturer: 0x0112 AppID: 0x0001 Vers.: 0x10
  ----> userEeprom.commsTabAddr == 0x4530
  ----> userEeprom.appPeiType == 0x00
  ----> userEeprom.manufacturerH & L == 0x0112
  ----> userEeprom.deviceTypeH & L == 0x0001
  ----> userEeprom.version == 0x10

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleTaskCtrl1 ONLY PARTLY IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 45 01 01 00 00 00 00 00 len: 8
  --> userEeprom.eibObjAddr: 0x4501 userEeprom.eibObjCount: 0x01

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x01 LS_LOADED

P.S. Netterweise wird im letzten Schritt die Startadresse der User-KNX-ComObjectTable (0x4501) übermittelt. was in diesem Fall sogar das Ende der ComObjectTable+1 ist, aber leider auch nicht wirklich weiterhilft.

Viele Grüße
Denis

[Olli]

Hey Darthyson,

wie hast du den seriellen Dump erzeugt?
Direkt bei der Übertragung aus der ETS?
Kann die sblib das von Hause aus?

Grüße,
Olli

[Darthyson]

Hallo Olli,

ja der Dump ist vom Programmieren der Applikation per ETS.
Nein die sblib kann das z.Zt. nicht. Ich habe das in den letzten Tagen eingebaut. Kann man per #define DUMP_PROPERTIES aktivieren.

Was eigentlich zur nächsten Frage führt, nämlich der Zukunft der sblib. Werde da mal bei Gelegenheit einen neuen Thread aufmachen.

Zur Info:
z.Zt. kennt die sblib folgende #defines fürs debuggen (Liste eventuell nicht vollständig):
DUMP_TELEGRAMS : Ausgabe der KNX-Telegram "Rohdaten"
DUMP_SERIAL : Ausgabe der 128bit Seriennummer des ARM und der daraus erzeugten 48bit Seriennummer für KNX
DUMP_MEM_OPS : Ausgabe der APCI_MEMORY_WRITE_PDU & APCI_MEMORY_READ_PDU Telegramme.

Viele Grüße
Denis

[Florian]

Zur Info:
z.Zt. kennt die sblib folgende #defines fürs debuggen (Liste eventuell nicht vollständig):
DUMP_TELEGRAMS : Ausgabe der KNX-Telegram "Rohdaten"
DUMP_SERIAL : Ausgabe der 128bit Seriennummer des ARM und der daraus erzeugten 48bit Seriennummer für KNX
DUMP_MEM_OPS : Ausgabe der APCI_MEMORY_WRITE_PDU & APCI_MEMORY_READ_PDU Telegramme.

Beim Selfbus-USB-Interface hatte ich ein erweitertes Debugging über eine virtuelle serielle Schnittstelle eingebaut. Die wichtigsten Telegrammtypen werden bereits auscodiert, darauf könnte man aufbauen:
software-arm-incubation/misc/USB-Interface-bcu1/USB-IF_Usb/src/tel_dump.cpp
Ich schreibe da gerade wieder dran rum, u.A. habe ich die Klasse auf eigene Beine gestellt, so dass sie nicht nur in meinem Kontext lauffähig ist.

[luckychild]

Hallo Denis,

danke, dass du dich da so engagierst.

Daher seh ich z.Zt leider auch keine andere Möglichkeit, als die ComObjectTable bzw. userEeprom.commsTabAddr bei "problematischen" Prduktdatenbanken per "Hand" zu setzen,

Ja, das sehe ich genauso. Was spricht deiner Meinung nach gegen eine überladene bcu_base.begin() Methode - ähnlich wie in meinem Beispiel - um die Adressen der Tabellen zu setzen ? Damit würden wir zu alten Apps kompatibel bleiben und schaffen bei Bedarf eine Möglichkeit die Adressen per Hand zu setzen.

Liebe Grüße

[Darthyson]

Hallo zusammen,

ich habe gerade bei Github einen neuen Branch der sblib (DEV-#26-APciPropertyValueWrite) zu diesem Thema aufgemacht. Darin sind meine Änderungen/Erweiterungen der letzten Tage mit eingeflossen und in leicht abgewandelter Form auch Luckychilds Quickfix.
Folgendens ist neu:

• #define/preprocessor Symbole:
  BIM112_75 für die Maskenversion 0x0705
  DUMP_PROPERTIES zum seriellen debuggen/dumpen der LoadStateMachine und PropertyValue- Telegrammen

• Debug_BIM112_75 und Release_BIM112_75 Build-Konfigurationen

• handleAllocAbsDataSegment(...) prüft bereits vor den eigentlichen MemoryWrites, ob der Speicher überhaupt vorhanden ist (Hier muss noch ausgebaut werden)

• andere Sachen die mir gerade nicht einfallen (einfach in die Commits schauen)

Viele Grüße
Denis

[Darthyson]

Hallo Luckychild,

sry hatte vergessen auf die Frage zu antworten.

Was spricht deiner Meinung nach gegen eine überladene bcu_base.begin() Methode

Meine Überlegung war halt, wenn ich die Adresse bei .begin() mit übergebe kann diese auch nicht mehr geändert werden. Dem wiederum steht entgegen, dass userEeprom.commsTabAddr global ist und einfach irgendwo, selbst in der App nach belieben geändert werden kann. Das zu ändern würde ich erstmal weit hinten anstellen. Zweite Sache ist, dass es die BCU1 überhaupt nicht betrifft, da steht die Adresse ganz woanders und ist von der Spec. auch vorgegeben. Daher auch die etwas abgewandelte Form (optionaler Parameter) deines Quickfixes.

Viele Grüße
Denis