KNX Schaltaktor 'reverse engineering'

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!

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 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?

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 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 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.

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.

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

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.

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...

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

Ergebnis: 0x3c

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

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.

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

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

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 ;-)

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.

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...

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.