KNX Schaltaktor 'reverse engineering'

[Miro S. (miros)]

Hallo zusammen,

nachdem ich gerade einen Dimmaktor wieder zum Leben erweckt habe 
(Beitrag "KNX Zweikanaldimmaktor reparieren"), liegt jetzt der nächste 
Problembär auf meinem Tisch: Ein 8fach Schaltaktor mit Stromerkennung 
von ABB (SA/S 8.16.5S).

Fehlerbild: Er lässt sich über die ETS nicht mehr mit der passenden 
Applikation programmieren. Der Vorgang bricht mit einer Fehlermeldung 
ab, dass die auf dem Aktor befindliche Applikation nicht kompatibel ist.
Aktuell ist Version 2.0 und angeblich ist die 15.15 auf dem Aktor.

Das Innenleben des Aktors sieht wunderbar aus, alle Spannungen sind 
vorhanden und der Resonator schwingt wie gefordert.

Meine Theorie ist, dass es sich um einen Bit-Flip oder Folge eines 
Verbindungsabbruchs handeln könnte. Der Controller (Atmega32) hat 
einfach eine kaputte Konfiguration.
Da die Applikationen nur bestimmte Updatepfade erlauben, kann ich nicht 
auf ordentlichem Wege "drüber bügeln".

Jetzt zur Idee:
Die 10 goldenen Pads sind mglw. ein ISP-Interface.
Ich verbinde mich mit einem entsprechenden Debugger, finde die 
Speicherstelle oder Funktion und manipuliere den Wert auf z.B. "1.2".
Dann sollte der Aktor wieder nutzbar sein.

Meine Fragen dazu:
1) Könnte der Plan funktionieren?
2) Ich habe einen "Waveshare Atmel AT AVRISP" bestellt. Welche Software 
würdet ihr für das Debugging empfehlen?

Viele Grüße
Miro

[Route_66 H. (route_66)]

Miro S. schrieb:
> Meine Fragen dazu:
> 1) Könnte der Plan funktionieren?

Der Hersteller müsste schon einen Intelligenzquotient nahe Null haben, 
wenn er den Ausleseschutz nicht aktiviert hat.

Also: keine Chance!

[Sly_marbo (Gast)]

Bei 10 Pins und Atmega32 ist mir nach JTAG nicht ISP. Aber mehr Ahnung 
hab ich da leider garnicht.

[Markus (Gast)]

Sly_marbo schrieb:
> Bei 10 Pins und Atmega32 ist mir nach JTAG nicht ISP. Aber mehr Ahnung
> hab ich da leider garnicht.

Das merkt man!

Es gibt auch 10pol ISP von Atmel und nicht nur 6 Pol

[Miro S. (miros)]

Hmm, im Datenblatt steht noch was über von außen zugänglichem Flash:
"The Onchip ISP Flash allows the program memory to be reprogrammed 
in-system through an SPI serial interface, by a conventional nonvolatile 
memory programmer, or by an On-chip Boot program running on the AVR 
core."

Auf der Rückseite sind nochmal 6 zuätzliche Pins.
Der eigentliche Programmcode ist mir ja egal, weil die KNX Applikationen 
eher sowas wie Konfiguration sind und ausgetauscht werden können.

[Markus (Gast)]

Kannst du mal bitte versuchen die Kommunikations-Sektion abzuzeichnen? 
Wäre interessant zu wissen wie KNX die Daten über die Leitung schickt. 
Zudem ist der Atmel da drauf ja bastlerfreundlich. Also kann man das ja 
nachbauen.

[Johannes S. (Gast)]

Miro S. schrieb:
> Der Vorgang bricht mit einer Fehlermeldung
> ab, dass die auf dem Aktor befindliche Applikation nicht kompatibel ist.

das deutet doch eher darauf hin das man das falsche Gerät in der ETS 
Konfiguration hat. Lässt sich die Info auslesen und die vorhandene 
Parametrierung löschen/auf Auslieferzustand zurücksetzen?

Markus schrieb:
> Also kann man das ja
> nachbauen.

Das sind Busankoppler die es nur von Herstellern gibt. Sowas bekommt man 
als Modul oder nimmt z.B. ein Siemens Buskoppler für ca. 20€. Mit dem 
spricht man per UART, dafür gibt es reichlich Beispiele im Netz, auch 
Arduino Programme.
Mit einem ESP kommt man auch per Funk an seinen Bus wenn man einen IP 
Koppler am Bus hat.
Und das KNX Protokoll ist auch kein Geheimnis, findet man auch legal im 
Netz.

[Miro S. (miros)]

Markus schrieb:
> Kannst du mal bitte versuchen die Kommunikations-Sektion abzuzeichnen?
> Wäre interessant zu wissen wie KNX die Daten über die Leitung schickt.
> Zudem ist der Atmel da drauf ja bastlerfreundlich. Also kann man das ja
> nachbauen.

Schau mal in den Thread hier 
(Beitrag "KNX Zweikanaldimmaktor reparieren"), da ist der 
Transceiver FZE1066 zu sehen und im Datenblatt findest du auf Seite 6 
einen Schaltplan.
Der Schaltaktor hier verwendet einen Custom-Chip als Transceiver auf dem 
"ABB Blue 1.0" steht. Der macht de-facto das gleiche, hat aber nur 18 
Pins.

@Johannes:
Falsche Applikation kann ich ausschließen, weil er bei mir zwei Jahre 
lang lief. Dann habe ich einmal beim Parametrieren "Partiell" angeklickt 
und peng, kaputt. Die Bordmittel habe ich alle probiert: Entladen, 
Physische Adresse neu, neue Applikation. Wie geht ein echter Werksreset?

[Miro S. (miros)]

Hier ist mal ein Bild von der Unterseite der Platine. Rechts sind die 10 
Pads des vermeintlichen JTAG-Anschlusses zu sehen. Leider sind dort z.B. 
TDI und TDO nicht mit dem Controller verbunden. Dort stehen nur GND und 
VCC zur Verfügung. Dieser Weg endet also hier.

Darüber sind allerdings noch 6 Pads zu sehen, diese sind mit folgenden 
Pins des Atmega32 verbunden:
1:MISO    2:VCC
3:SCK     4:MOSI
5:-RESET  5:GND
Das sollte also für ISP passen.

Gibt es Fallstricke, wenn ich den Programmieradapter anschließe? Ich 
würde das Board parallel mit simulierter Busspannung versorgen und dann 
den Ausleseversuch starten. Kann dabei der Inhalt durch 
Schutzmechanismen gelöscht werden?

[Oger (Gast)]

15.15 = 0xFF = Line war konstant High als ausgelesen wurde, Ziel-Antwort 
wäre wohl 0x20
Sprich der Chip hat überhaupt keine Antwort gegeben.

[Miro S. (miros)]

Oger schrieb:
> 15.15 = 0xFF = Line war konstant High als ausgelesen wurde, Ziel-Antwort
> wäre wohl 0x20
> Sprich der Chip hat überhaupt keine Antwort gegeben.

Außer der Applikationsversion werden bei der gleichen Abfrage noch 
andere Informationen wie z.B. die Hardwarerevision abgefragt. Der Wert 
war z.B. korrekt. Deswegen vermute ich eher, dass es beim Schreiben des 
Wertes einen Fehler gegeben hat.

[hinz (Gast)]

Miro S. schrieb:
> Gibt es Fallstricke, wenn ich den Programmieradapter anschließe? Ich
> würde das Board parallel mit simulierter Busspannung versorgen und dann
> den Ausleseversuch starten.

Das sollte funktionieren. Und nach dem Auslesen der Fuses weißt du auch 
wie es um das Auslesen des Programmspeichers steht.


> Kann dabei der Inhalt durch
> Schutzmechanismen gelöscht werden?

Wenn man nicht murkst...

[Miro S. (miros)]

hinz schrieb:
> Wenn man nicht murkst...

...bedeutet ja?
Ich wollte einfach avr-dude das Ding auslesen lassen und dann mit dem 
.hex File mal weitersehen.
Warte halt noch auf den AVRISP.

[alopecosa (Gast)]

Miro S. schrieb:
> Ich
> würde das Board parallel mit simulierter Busspannung versorgen und dann

Die natürlich mit Drossel etc. aufgebaut ist.

Die Drossel in der Busspannungsversorgung hat ja keinen optischen 
Hintergrund ;)

[Miro S. (miros)]

Für den Betrieb des Atmega32 mit ISP hat die Drossel ja keine Bedeutung, 
denn der Transceiver-Chip erzeugt VCC(3,3V) aus der Busspannung (~27V), 
egal ob er Bits auf den Bus senden kann.

Aber ja, ich verwende immer eine entsprechende Ersatzschaltung, wenn ich 
nicht direkt an einem Bus hänge.

[hinz (Gast)]

Miro S. schrieb:
> hinz schrieb:
>> Wenn man nicht murkst...
>
> ...bedeutet ja?

Durch Murks kann der Chip für alle Zeiten gelöscht werden, manchmal 
entweicht dabei auch der magische Rauch.


> Ich wollte einfach avr-dude das Ding auslesen lassen und dann mit dem
> .hex File mal weitersehen.
> Warte halt noch auf den AVRISP.

Lies zunächst die Fuses aus, dann siehst du ob weiteres sinnvoll ist.

[Miro S. (miros)]

Also, das Interface funktioniert.
Jetzt muss ich erstmal nachschlagen, was das bedeutet:

avrdude: safemode: lfuse reads as 9F    --> 10011111
avrdude: safemode: hfuse reads as CD    --> 11001101
avrdude: safemode: Fuses OK

[Timo W. (timo)]

Miro S. schrieb:
> Jetzt muss ich erstmal nachschlagen, was das bedeutet:
>
> avrdude: safemode: lfuse reads as 9F    --> 10011111
> avrdude: safemode: hfuse reads as CD    --> 11001101
> avrdude: safemode: Fuses OK

Das sind nur die fuse Bytes. Die sind für dich erst mal uninteressant.

Lies mal mit "-U lock:r:-:h" das lock byte aus.

[Miro S. (miros)]

Dumps erzeugen hat auch funktioniert :-)
Kennt jemand ein besonders geeignetes Werkzeug für die Analyse der 
Dumps?
Ich probiere gerade Ghidra aus, da habe ich als Plattform ausgewählt:
AVR8, 16 bit, vom gcc erzeugt

Mal schauen...

[Miro S. (miros)]

Timo W. schrieb:
> Lies mal mit "-U lock:r:-:h" das lock byte aus.

Ergebnis: 0x3c

[Miro S. (miros)]

Verdammt, die Files enthalten nur Müll: aufsteigende Zahlenreihen
Liegt das an den Lock-Bits?
Was mache ich falsch?

[Timo W. (timo)]

Miro S. schrieb:
> Ergebnis: 0x3c

Das heißt leider "read protected".

-> Deine dumps enthalten nur unsinn

So kommst du nicht weiter. Der MC lässt sich nicht auslesen.

[Miro S. (miros)]

Schade, schade, das wäre auch zu einfach gewesen.
Jetzt brauche ich einen Proxy für die Tx-Bits, die der Controller auf 
den Bus sendet, um dann die richtige 8 davon zu manipulieren.
grübel

[Timo W. (timo)]

Miro S. schrieb:
> Jetzt brauche ich einen Proxy für die Tx-Bits, die der Controller auf
> den Bus sendet, um dann die richtige 8 davon zu manipulieren.

knxd umprogrammieren. Das könnte sogar funktionieren.

https://github.com/knxd/knxd

[Miro S. (miros)]

Der hat mich schonmal auf einem Raspi in den Wahnsinn getrieben, weil 
der mit einer USB-Schnittstelle immer wieder sporadisch abgeraucht ist.
Wo kann ich denn da Werte manipulieren?
Ich zeichne morgen mal ein Log von der KNX-Kommunikation mit dem Aktor 
auf.

Schade, ich dachte ich kann mal wieder etwas Hardware-nahes machen ;-)

[Timo W. (timo)]

Naja viele knx-usb Schnittellen sind etwas ***X*X*X*X*X*. Ich verwende 
(produktiv) nur IP Interfaces, das läuft sehr zuverlässig.

Ich würde die Funktion verändern die die Daten vom Interface ließt oder 
über Netzwerk ausgibt, und da einfach nach dem Paket such und das 
ersetzen. Quick 'n dirty.

[Miro S. (miros)]

Update:
Über einen KNXD habe ich jetzt die beiden Vorgänge "Device Info" und 
"Applikationsprogramm" geloggt (siehe Anhang).
Die relevante Nachricht enthält "00 02 A0 26 FF", wobei die 0xA026 den 
Gerätetyp kodiert und ok ist. Die 0xFF ist die Applikationsversion 
"15.15".

Man kann im Programmiervorgang auch sehen, dass die ETS solch eine 
Nachricht in den Speicher des Aktors schreibt, allerdings scheint das 
nicht zu klappen.
Das Programmierlog bricht einfach ab, als die ETS die Verbindung 
schließt.

Einziger verbliebener Anhaltspunkt momentan ist die erste Abfrage der 
Version bei der Programmierung (in Zeile 20) so zu manipulieren, dass da 
eine sinnvolle Version drin steht. Denn nach der Abfrage kommt ein 
Dialog in der ETS hoch und meint er muss einmal alles komplett neu 
aufspielen - und das scheitert.
Vielleicht mag er auch diese lange Übertragung (~5 Minuten) nicht.
--> Abbruch --> fehlende Validierung des Uploads --> Rollback

Es würde mir in der Seele wehtun, das Gerät auf den Schrott zu 
schmeißen...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Suche doch mal bei den KNX Spezies:
https://knx-user-forum.de/
Die Chancen stehen nicht schlecht, das die Jungs vom z.B. knxd Projekt 
da schon was vorbereitet haben.