ETS-Programmierung - Strommessender Schaltaktor 6OUT

[ghifunk]

Diesen Dialog gab es mit deinem hex-File nicht.

[Florian]

Stand der Dinge: Mein Testprojekt kann ich auch mit der ETS5.7.4 problemlos programmieren, sowohl nach entladen, als auch bei komplett leerem Flash.
Die Analyse der von Gerhard ausgelesenen hex-Files hat zwei interessante Dinge gezeigt:
- Im Fehlerfall ist die Programmierung wesentlich weiter fortgeschritten gewesen, als von mir vermutet. Der Fehler trat während des Programmierens der Applikation auf. Zu dem Zeitpunkt ist das Firmwareupdate längst gelaufen, genauso wie die Programmierung der Adress- und der Assoziationstabelle.
- In den hex-Files finde ich außerdem keine Katastrophen. Der Memmapper ist vollkommen intakt, die Daten, die programmiert wurden, sind soweit plausibel.
Auch wenn ich den Fehler nicht nachvollziehen kann, habe ich dennoch einen Verdacht, ein einzelnes Datenbyte auf einer MemMapper-Seite kann ich in die Richtung interpretieren: Das User-Eeprom des Aktors ist länger, als es die sblib eigentlich erlaubt. Daher verlängere ich den Bereich, indem ich eine MemMapper-Seite direkt anschließend positioniere. Das funktioniert - solange die ETS nie versucht, in einem Zugriff über die Grenze zwischen beiden Bereichen hinwegzuschreiben. Ich konnte so etwas nie beobachten, aber das wäre meine Vermutung was abhängig der Applikationsdaten vielleicht doch passiert. Ich werde mal auf Verdacht diesen Fall entschärfen und dann sehen, was passiert.

[ghifunk]

Hallo Florian,
danke für deine Bemühungen! Sehe ich das richtig, daß es als Ergebnis der Untersuchungen eine neue Firmware-Version mit der obigen Änderung gibt? Evtl. ist ein solches Timing-Problem auch der Grund, weshalb ich die Programmierung einmal durch bekommen habe? Das wäre gut zu wissen! Ich stehe für den Test jederzeit zur Verfügung!

[Florian]

Hallo Gerhard,
als Beta-Tester bist Du fest eingeplant
Eigentlich wollte ich Dir heute eine Testversion zukommen lassen, aber leider funktioniert das was ich hier habe schon bei mir nicht richtig. Leider habe ich meine alte Build-Umgebung nicht mehr, daher kann es hier an diversen Stellen klemmen.
Eine erste Erkenntnis ist, das ich endlich eine Fehlererkennung in den MemMapper einbauen muss, damit er selbst kaputte Verwaltungsstrukturen erkennen kann. Das nervt jetzt auch mich...

[Florian]

So, hier hätte ich jetzt eine Debugging-Version mit 2 Änderungen gegenüber der alten Version:
- Schreibvorgänge über die Adresse 0x4B00 sollten jetzt sauber laufen, selbst wenn innerhalb eines Zugriffs die Adresse überschritten wird.
- Wenn der MemMapper beim Systemstart feststellt, dass die Verwaltungsstrukturen offensichtlich kaputt-geschrieben worden sind (mehrere Nullen gefunden), wird die gesamte Tabelle zurückgesetzt. Dies hat einige Nebenwirkungen auf das geladene Programm, die kanalunabhängigen Optionen fehlen dann. Es sollte jedoch verhindern, dass man den Mikrocontroller löschen und neu programmieren muss, um das Programm wieder zum Leben zu erwecken.

Kannst Du das bitte bei Dir testen, Gerhard. Wenn das Deine Probleme nicht löst, brauche ich eine Kopie von Deinem Projekt, denn dann muss ich den Fehler im Debugger suchen gehen.

[ghifunk]

Hallo Florian,
ich habe versucht mein Projekt zu programmieren und habe es nicht hin bekommen. Weder auf der V5.7.4 noch auf 5.6.6.
Dort habe ich ein altes vorhandenes Projekt mit den Daten vom Aktor erweitert und versucht es einzuspielen - ging nicht!
Habe auch nochmal die SA/S 8.16.6.1 von ABB neu eingelesen aber nichts!?
Kannst du mir evtl. mal Dein Testprojekt schicken um zu probieren ob das evtl. geht?
Bin am verzweifeln und hab mir nun schon einen Originalaktor von ABB bestellt damit ich meine Anlage wieder aktiv bekomme. Bin mal gespannt ob der geht! Aber trotzdem würde ich deinen Schaltaktor hier gerne zum laufen bringen.
Gruß
Gerhard

[Florian]

Hallo Gerhard,

als Anhang mein Testprojekt. Die Datei musst Du wieder zu .knxproj umbenennen.

Im Projekt befinden sich gleich drei SA/S 8.16.6.1, in letzter Zeit benutzt habe ich "EV 8.16.6.1" und "UP 8.16.6.1". Ich benutze die ETS 5.7.4.

Ein Punkt der mir noch eingefallen ist: Was für eine Bus-Schnittstelle benutzt Du? Ich habe hier nur USB-Interfaces.

Viel Erfolg!

[ghifunk]

Hallo Florian,
ich habe heute nochmal einige Versuche gemacht und folgendes festgestellt:
Ich benutze eine IP-Schnittstelle Siemens N148 - und habe heute plötzlich Probleme beim Programmieren eines
MDT-Glastasters gehabt. Das hat mich stutzig gemacht und ich habe mal den Verkehr auf meinem Netzwerk beobachtet.
Da laufen einige Kameras drauf und machen teilweise einen ordentlichen Traffic zum Server. Die hab ich nun mal kurzer Hand außer Betrieb genommen und konnte daraufhin meinen Glastaster wieder programmieren - siehe da!
Nun habe ich das mit dem 6-Fach Aktor getestet. Die letzte Version vom 9.3. (siehe oben) funktionierte leider nicht.
da kam nach lagem "hin und her" bei ca. 75% dann doch die Fehlermeldung. Aber mit Deinem TestprojektReadout geht die Programmierung unter V5.7.4 problemlos schon mehrere mal hintereinander. Macht auch relativ lange bei 75% rum, wird aber dann erfolgreich fertig! Der Aktor funktioniert auch ganz normal, nur das die beiden unteren LED's an sind.
Vieleicht hilft Dir das weiter...
Ich werde dein Testprojekt nun auch nochmal probieren.
Gruß
Gerhard

[Darthyson]

Hallo Florian & Gehard,

vielleicht hilft euch das hier ein wenig weiter. Ist ein Log der Telegramme welche die ETS an das Device schickt zur Speicherallocation und anschliessendem DMA/APCI_MEMORY_WRITE_PDU.

Code: Alles auswählen

------------------------------------------------------------------------
| out6-cs-bim112 Build Debug 6Ch komplettes Applikationsprogramm laden |
------------------------------------------------------------------------

Properties dump enabled BCU_TYPE: 0x701 MASK_VERSION: 0x701 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 FF 03 00 00 len: 8
  --> start: 0x4000 length: 0x01FF end: 0x41FE access: 0xFF memtype: 0x03 attrib: 0x00

handleLoadStateMachine: objectIdx=0x01 OT_ADDR_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x01 OT_ADDR_TABLE Data: 40 00 80 00 02 A0 5D 32 len: 8
  --> startaddress: 0x4000 PEI: 0x80 Manufacturer: 0x0002 AppID: 0xA05D Vers.: 0x32
  ----> 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: 42 00 01 FF FF 03 00 00 len: 8
  --> start: 0x4200 length: 0x01FF end: 0x43FE access: 0xFF memtype: 0x03 attrib: 0x00

handleLoadStateMachine: objectIdx=0x02 OT_ASSOC_TABLE loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x02 OT_ASSOC_TABLE Data: 42 00 80 00 02 A0 5D 32 len: 8
  --> startaddress: 0x4200 PEI: 0x80 Manufacturer: 0x0002 AppID: 0xA05D Vers.: 0x32
  ----> userEeprom.assocTabAddr=0x4200

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: 4B 20 2A CE FF 03 80 00 len: 8
  --> start: 0x4B20 length: 0x2ACE end: 0x75ED access: 0xFF memtype: 0x03 attrib: 0x80
  ------> invalid end: 0x75ED

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 44 00 02 AB FF 03 80 00 len: 8
  --> start: 0x4400 length: 0x02AB end: 0x46AA access: 0xFF memtype: 0x03 attrib: 0x80

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsDataSegment NOT IMPLEMENTED! objectIdx=0x03 OT_APPLICATION Data: 48 00 03 17 FF 03 00 00 len: 8
  --> start: 0x4800 length: 0x0317 end: 0x4B16 access: 0xFF memtype: 0x03 attrib: 0x00

handleLoadStateMachine: objectIdx=0x03 OT_APPLICATION loadstate=0x05 LS_LOADCOMPLETING
handleAllocAbsTaskSegment: objectIdx=0x03 OT_APPLICATION Data: 4C BE 80 00 02 A0 5D 32 len: 8
  --> startaddress: 0x4CBE PEI: 0x80 Manufacturer: 0x0002 AppID: 0xA05D Vers.: 0x32
  ----> userEeprom.commsTabAddr == 0x4CBE
  ----> userEeprom.appPeiType == 0x80
  ----> userEeprom.manufacturerH & L == 0x0002
  ----> userEeprom.deviceTypeH & L == 0xA05D
  ----> userEeprom.version == 0x32

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

Das funktioniert - solange die ETS nie versucht, in einem Zugriff über die Grenze zwischen beiden Bereichen hinwegzuschreiben.

Dort gibt es eigentlich kein AbsDataSegment welches 0x4B00 (Ende User-EEPROM) und 0x4B20 (Beginn vom MemMapperMod) beinhaltet, daher dürfte die ETS da auch nix schreiben. Mein Log passt soweit auch zu den <LoadProcedures> der .knxprod

@Gerhard, kannst du eventuell ein Log der ETS-Telegramme vom erfolglosen Programmieren hier hochladen? Gerade die fehlschlagende Adresse würde auch mich interessieren.

Viele Grüße
Denis

Edit: Satz vervollständigt
Edit2: falsche Info gestrichen

[Florian]

Dort gibt es eigentlich kein AbsDataSegment welches 0x4B00 (Ende User-EEPROM) und 0x4B20 (Beginn vom MemMapperMod) beinhaltet, daher dürfte die ETS da auch nix schreiben. Mein Log passt soweit auch zu den <LoadProcedures> der .knxprod

Hallo Denis,
das angesprochene mögliche Problem ist ein anderes: Das User-EEPROM endet nicht bei 0x4B00, sondern bei 0x4B16, wie in Deinem Log auch geschrieben. Und dieser Übergang über 0x4B00 ist der Punkt. Davor befinden sich die kanalspezifischen Optionen, danach kanalunabhängige. Für diese paar Bytes nach 0x4B00 wird im MemMapper eine eigene Seite angelegt (siehe app_main.cpp -> setup()). Theroetisch kann die ETS die 0x4B00-Grenze innerhalb eines Lese- oder Schreibzugriffs überqueren. In der Praxis habe ich das noch nicht beobachtet, da liest beispielsweise die ETS bei 0x4AFF ein einzelnes Byte und ab 0x4B00 wieder längere Stücke.
Das Segment ab 0x4B20 ist ein anderes: Das scheint im Original der Programmspeicher selbst zu sein. Für dessen Behandlung habe ich im MemMapperMod getrickst.