Forum: Fahrzeugelektronik Untersuchung defektes VW Türsteuergerät

Sebastian W. schrieb:
>
> 2. Um welchen Microcontroller handelt es sich bei dem TQFP32 IC auf dem
> dritten Foto mit dem Logo von Freescale und den Aufschriften "SP100",
> "897VFA", "2L31N" und "CTCTANO703"?

Mask Set "2L31N" sollte ein MC68HC908EY16 oder MC68HC908EY8 sein.

Sebastian W. schrieb:
> 3. Wofür sind wohl diese aufgestellten Blechstreifen zwischen dem Relais
> (ein ACT512) und dem Elko gut?

Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit 
der Einklemmschutz realisiert

Sieht (zumindest für mich) so aus, als hätte dieser Kamerad " 'n Loch im 
Kopp"...

Dieter S. schrieb:
> Mask Set "2L31N" sollte ein MC68HC908EY16 oder MC68HC908EY8 sein.
Ok, werde ich mal anhand der Beschaltung überprüfen.

Heinz R. schrieb:
> Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit
> der Einklemmschutz realisiert
Kann wohl sein, liegt dann aber im Milliohmbereich.

Michael W. schrieb:
> Sieht (zumindest für mich) so aus, als hätte dieser Kamerad " 'n Loch im
> Kopp"...
Danke für den Hinweis. Aber auch bei genauerer Betrachtung kann ich kein 
Loch erkennen. Höchstens ganz feine kurze Risse in der Mitte des 
Gehäusedeckels.

LG, Sebastian

Jepp - das war dann eine optische Täuschung. 'In groß' sieht das Bauteil 
unbeschädigt aus. Danke für die Aufklärung.

Sebastian W. schrieb:
>
> Ok, werde ich mal anhand der Beschaltung überprüfen.

Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man 
auf dem Bild sieht.

Wenn die Spannungsversorgung in Ordnung ist: schauen ob der 
Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus). 
Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor 
sollte sich mit einem Magnet testen lassen.

Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles 
passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689 
übernehmen und schauen ob man den Relais schalten kann).

Sebastian W. schrieb:
> Heinz R. schrieb:
>> Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit
>> der Einklemmschutz realisiert
> Kann wohl sein, liegt dann aber im Milliohmbereich.

Ohmbereich bei 20 A wäre auch eine blöde Idee. Diese gestanzten Mäander 
sind ebenfalls sehr beliebt in Lichtsteuergeräten für die 
Ausfallerkennung. Jedenfalls in der Vor-LED-Zeit als noch mehrere Ampere 
pro Birne glühten.

Interessant finde ich bei dem vierten Bild (4643) die "Schmauchspur". 
Kenne ich von Klingeldraht als (altes analoges) Telefonkabel, der hat 
über die Jahre durch die dauernd anliegende hohe Spannung Staub 
angezogen. Nur eine der beiden Adern. Aber daß der Effekt auch schon bei 
12V funktioniert erstaunt mich. Theoretisch wäre noch denkbar, daß durch 
das Magnetfeld bei Schaltvorgängen ferromagnetischer Staub besonders 
angezogen wird, aber das scheint mir eher zu weit hergeholt.

so ein Hallsensor hat normalerweise einen Pullup Widerstand und der 
Transistor zieht das dann runter, könnte sein das der Widerstand und 
dadurch auch der Ausgangstransistor des Hallgebers hops gegangen sind 
und deswegen die Leiterbahn etwas viel Strom abbekommen hat.

Hallo,

alles richtig wie bisher erklärt. Ich habe das gleiche Module im 
Roomster.
Problem: Bei Kälte gingen beide Fenster nicht mehr auf. An warmen Tage 
war es wieder möglich. Nun ging gar nichts mehr.
Platine bei 120°C für 30 Minuten in den Ofen gelegt. Dann lief es zwei 
Wochen. Dann ging es wieder nicht mehr. Ich vermute eine kalte 
Lötstelle. Habe keine gefunden. Habe die Rückseite nachgelötet und die 
großen Widerstände. Keine Verbesserung
Hatte nach Anleitung aus Internet YouTube den LIN Baustein ausgetauscht. 
Hat das Problem nicht behoben.
Gestern wieder in Ofen gelegt. Bei 130°C eine Stunde. Geht wieder. Mal 
sehen.

Bei YouTube ist der Film von Mr. Selfmaker zu Roomster sehenswert:
https://youtu.be/1EP5U9uHmy0
sehenswert.

Das Relais ist es bei mir nicht. Der Hallsensor auch nicht, weil beide 
Fenster nicht gehen.

Wer bei sich es das gleiche (Kälte-) Problem hat und die Lösung oder das 
Defekte Teil gefunden hat, bitte melden. Ich vermute es muss die 
LIN-Leitung sein, weil bei meinen Defekt beide Fenster nicht mehr gehen.

Viele Grüße

Mit 120-130° wird das Lot nicht weich und du Quälst  nur sinnlos die 
Hardware.

Ja, das stimmt, wobei 105°C für Autoelektronik meist zum Operating Range 
gehört. Und es ist keine Lösung. Allerdings ein Beitrag zur 
Lösungsfindung.

Hier noch ein Film, der mit Kältespray und Föhn den uC als empfindliche 
Stelle identifiziert.

https://youtu.be/ZlExAJYp2x4

Wenn nur dir Fensterheber nicht mehr gehen, könnten auch die 
Fensterheberschalter hin sein/kalte Lötstellen haben.
Mal testen, ob die Fenster noch per FFB öffnen/schließen.

VG

Dieter S. schrieb:
> Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man
> auf dem Bild sieht.
>
> Wenn die Spannungsversorgung in Ordnung ist: schauen ob der
> Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus).
> Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor
> sollte sich mit einem Magnet testen lassen.
>
> Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles
> passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689
> übernehmen und schauen ob man den Relais schalten kann).

Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation 
mit diesen Steuergeräten funktioniert. Das mir vorliegende Steuergerät 
der Fahrertür benutzt ja den LIN-Bus zur Kommunikation mit dem 
Steuergerät der Beifahrertür. Aber wer von beiden ist der Master? Und 
sind die beiden Steuergeräte digital autonom, oder kommunizieren sie 
auch noch mit dem Bordsteuergerät oder dem Komfortsteuergerät? Ich habe 
mich jetzt im tx-board.de angemeldet (und einen Beitrag dort eröffnet, 
siehe 
https://tx-board.de/threads/t5-1-buseinbindung-tuersteuergeraete.156611/), 
und auch über erwin.volkswagen.de die Stromlaufpläne heruntergeladen, 
bin aber immer noch mehr oder weniger so schlau wie zuvor ...

LG, Sebastian

Ist doch gut zu erkennen:

Gilt für Transporter, Multivan evtl anders!:

Beide Fensterhebermotoren reden über LIN miteinander, vmtl zur Steuerung 
des rechten Motors von der Fahrertür aus.
Zusätzlich hängt noch jede Tür am Komfortsteuergerät, das steuert dann 
"Fenster auf/zu per FFB" und die ZV-Funktionen.

VG

Sebastian W. schrieb:
>
> Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation
> mit diesen Steuergeräten funktioniert.

Weißt Du schon ob der Mikrocontroller noch funktioniert? Wenn Du mit dem 
LIN Bus experimentieren willst muß zusätzlich auch noch der LIN 
Transceiver im MC33689 funktionieren.

Je nach dem wie einfach man an den LIN Bus im Fahrzeug herankommt kannst 
Du dort mitschneiden was passiert wenn man die Fensterheber betätigt und 
dann schauen wie das Steuergerät darauf reagiert.

Diagnose per LIN Bus zu den Türsteuergeräten gibt es wahrscheinlich 
auch, das könnte man ebenfalls mitschneiden.

Soul E. schrieb:
>
> Ein alter Freesscale HC08 mit internem EEPROM? Einmal über BDM auslesen
> und neu schreiben, also die Zellen refreshen.

Der MC68HC908EY16/8 hat noch kein BDM, das Monitor Module (MON) wäre 
aber vorhanden (falls nicht gesperrt).

Sebastian W. schrieb:
> Dieter S. schrieb:
 kann).

> Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation
> mit diesen Steuergeräten funktioniert. Das mir vorliegende Steuergerät
> der Fahrertür benutzt ja den LIN-Bus zur Kommunikation mit dem
> Steuergerät der Beifahrertür. Aber wer von beiden ist der Master?
...
>
> LG, Sebastian

Hallo Sebastian,

das Steuergerät der linken Seite müsste der Master sein. Es hat den für 
den Master vorgeschriebene Pullup Widerstand von 1kOhm,als 
Parallelschaltung von zwei parallelen 2kOhm Widerständen.
Daher findet wohl auch keine Kommunikation mit der ECU statt, weil diese 
der Master wäre und nicht das Steuergerät in der linken Tür. Es scheint 
also ein autonomer LIN Bus zu sein zwischen den Türen zu sein. Über den 
Diagnose-Stecker des Roomster lässt sich bei mir keine Information über 
die Fensterheber-Steuergeräte auslesen.

Viele Grüße Rüdiger

Rüdiger schrieb:
> Das Relais ist es bei mir nicht. Der Hallsensor auch nicht, weil beide
> Fenster nicht gehen.
So war es bei uns auch. Nach dem Tausch des fahrerseitigen 
Türsteuergeräts ging auch die Beifahrerseite wieder.

H. H. schrieb:
> Und da ist er ja auch: TLE4945-2G.
Danke, das passt!

Wollvieh W. schrieb:
> Interessant finde ich bei dem vierten Bild (4643) die "Schmauchspur".
Thomas O. schrieb:
> und deswegen die Leiterbahn etwas viel Strom abbekommen hat.
Ja, seltsam. Die Leitung ist die Spannungsversorgung des Hallsensors. 
Strom sollte da nur minimal fließen.

Rüdiger schrieb:
> Hier noch ein Film, der mit Kältespray und Föhn den uC als empfindliche
> Stelle identifiziert.
Ok ...

Matthias B. schrieb:
> Zusätzlich hängt noch jede Tür am Komfortsteuergerät, das steuert dann
> "Fenster auf/zu per FFB" und die ZV-Funktionen.
Rüdiger schrieb:
> das Steuergerät der linken Seite müsste der Master sein. Es hat den für
> den Master vorgeschriebene Pullup Widerstand von 1kOhm,als
> Parallelschaltung von zwei parallelen 2kOhm Widerständen.
> Daher findet wohl auch keine Kommunikation mit der ECU statt, weil diese
> der Master wäre und nicht das Steuergerät in der linken Tür. Es scheint
> also ein autonomer LIN Bus nur zwischen den Türen zu sein.
Ich denke Rüdiger hat hier recht. Der uC kann kein CAN, und der 
(einzige) LIN-Bus geht nur zur anderen Tür, nicht zum 
Komfortsteuergerät. Man kann mit der FFB auch glaube ich die Fenster 
nicht schließen -- das werde ich aber noch überprüfen.

Dieter S. schrieb:
> Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man
> auf dem Bild sieht.
>
> Wenn die Spannungsversorgung in Ordnung ist: schauen ob der
> Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus).
> Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor
> sollte sich mit einem Magnet testen lassen.
>
> Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles
> passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689
> übernehmen und schauen ob man den Relais schalten kann).

Ich habe das Steuergerät jetzt mal mit +12V Spannung versorgt, und sehe 
jetzt auf dem LIN-Bus Stecker Datenübertragung mit 19280 Baud:

1

0ms: LIN-Bus wird rezessiv (12V)

2

110ms: Master sendet (A) Wake-up (413us, 8 Bitzeiten dominant 0.85V)

3

130ms: Master sendet (B) ID 0x26 Data 0x00 0x00 0x40 0x00 ChecksumClassic 0xBF

4

145ms: Master sendet (C) ID 0x13, keine Antwort

5

230ms, und dann weiter alle 100ms: Master sendet (B)

6

345ms, und dann weiter alle 200ms: Master sendet (C)

Sowohl uC als auch MC33689 scheinen also zu funktionieren.

LG, Sebastian

Sebastian W. schrieb:
>
> Sowohl uC als auch MC33689 scheinen also zu funktionieren.
>

Ob die Ansteuerung des Relais funktioniert ist noch nicht klar, das 
macht ebenfalls der MC33689. Der kann auch noch Eingangssignale (Tasten) 
auswerten.

Wohin geht denn das Signal des Hall-Sensor? Eventuell mit einem Magnet 
prüfen ob sich das Signal ändert.

Dieter S. schrieb:
> Der kann auch noch Eingangssignale (Tasten) auswerten.

Der MC33689 wertet an L1 die Plusspannung auf T6ca/2 aus.

T8h/4 (der Türkontakt Fahrerseite) wird nach einer Schutzbeschaltung vom 
uC an Pin 1 (PTA2) ausgewertet. Wenn ich T8h/4 mit Masse verbinde, 
ändert sich (B) in ID 0x26 Data 0x08 0x00 0x40 0x00 ChecksumClassic 
0xB7.

Die anderen drei Eingänge (T8h/5 für F220 "zu" und F241 "auf" der 
Schließeinheit, T8h/7 für den Fensterheberschalter E81, und T6ca/1 für 
den Fensterheberschalter E40) müssen Pegel auswerten, da die Taster mit 
verschiedenen Widerständen für verschiedene Kippzustände arbeiten. Dass 
wird dann auch eher eine Aufgabe für den uC sein. Ich bin aber noch 
dabei den Schaltplan der Platine vollständig zu rekonstruieren.

Dieter S. schrieb:
> Ob die Ansteuerung des Relais funktioniert ist noch nicht klar, das
> macht ebenfalls der MC33689.
> Wohin geht denn das Signal des Hall-Sensor? Eventuell mit einem Magnet
> prüfen ob sich das Signal ändert.

Werd ich auch noch prüfen.

LG, Sebastian

Hallo Sebastian,

mir fehlt bei Deinem ersten Beitrag die genauer Beschreibung des 
Fehlerbildes.
Gingen beide Fenster nicht mehr auf und zu oder nur das Linke. Trat die 
Fehlfunktion langsam auf, oder plötzlich 100% Ausfall. War es 
Temperaturabhängig?

Die Teilebezeichnung
6Y2959802
beinhaltet sowohl Platine als auch den Motor. Wurden also der Motor 
zusammen mit der Platine ausgetauscht?
Vielleicht ist auch nur der Motor kaputt, z.B. durch verklemmte oder 
verschmutzte Kohlebürsten und die Elektronik funktioniert.

Viele Grüße
Rüdiger

Rüdiger schrieb:
> mir fehlt bei Deinem ersten Beitrag die genauer Beschreibung des
> Fehlerbildes.
> Gingen beide Fenster nicht mehr auf und zu oder nur das Linke. Trat die
> Fehlfunktion langsam auf, oder plötzlich 100% Ausfall. War es
> Temperaturabhängig?

Beide Fenster liessen sich plötzlich nicht mehr bedienen. Keine 
Temperaturabhängigkeit.

> Die Teilebezeichnung
> 6Y2959802
> beinhaltet sowohl Platine als auch den Motor. Wurden also der Motor
> zusammen mit der Platine ausgetauscht?
> Vielleicht ist auch nur der Motor kaputt, z.B. durch verklemmte oder
> verschmutzte Kohlebürsten und die Elektronik funktioniert.

Motor und Platine wurden als ein Ersatzteil getauscht. Der Motor des 
"defekten" Geräts funktioniert am Labornetzteil.

Ich habe jetzt mit einem 4k7-Poti zwischen T6ca/1 und T8h/6 den 
Fensterheberschalter vorne links emuliert. Wenn ich die Platine ohne den 
Motor betreibe, dann schalten die Relais dabei auch beide, und die 
LIN-Bus-Nachrichten (B) ändern sich. Allerdings endet der Schaltvorgang 
immer nach 150ms, wohl weil der Hallsensor keine Bewegung und der Shunt 
keinen Stromfluß meldet. Wenn ich die Platine mit dem Motor betreibe, 
dann bricht mir die Versorgungsspannung meines Labornetzteils (max. 5A) 
durch den Motoranlaufstrom innerhalb 1ms auf 1.5V ein und das 
Steuergerät startet neu. Morgen sollte ich ein stärkeres 12V-Netzteil 
erhalten, dann teste ich weiter ...

LG, Sebastian

Sebastian W. schrieb:
> Morgen sollte ich ein stärkeres 12V-Netzteil
> erhalten, dann teste ich weiter ...

Ok, ich teste jetzt mit einem 12V/30A Netzteil.

Der Eingang T6ca/1 wird über den Fensterheberschalter vorne links E40 
direkt bzw. über drei verschiedene Widerstände mit T8h/6 (GND) 
verbunden, und die Emulation mit einem 4k7-Poti bringt den Motor auch 
entsprechend zum laufen.

Der Motor scheint so 15A Anlaufstrom zu ziehen, bevor er (mechanisch 
unbelastet) mit 2.7A vor sich hinläuft. Passt zur Sicherung S37 mit 30A.

Auf dem LIN-Bus ändern sich während der Betätigung die Nachrichten an ID 
0x26 von 0x00 0x00 0x40 0x00 auf 0x00 0x01 0x40 0x00, 0x00 0x05 0x40 
0x00, 0x00 0x02 0x40 0x00 bzw. 0x00 0x06 0x40 0x00.

Klemme ich das Poti zwischen T8h/7 und T8h/6, um den 
Fensterheberschalter in der Fahrertür für das Beifahrerfenster zu 
emulieren, ändern sich die Nachrichten an ID 0x26 auf 0x00 0x08 0x40 
0x00, 0x00 0x28 0x40 0x00, 0x00 0x10 0x40 0x00 bzw. 0x00 0x30 0x40 0x00.

Auch die Eingänge T8h/5 (F220/F241) und T8h/4 (F2) scheinen zu 
funktionieren, und ändern weitere Bits in den LIN-Nachrichten an ID 
0x26.

Lege ich +12V an T6ca/2, so ändern sich wiederum weitere Bits in den 
0x26-Nachrichten. Zusätzlich fängt das Steuergerät an, LIN-Nachrichten 
an die ID 0x3C zu senden, und Nachrichten von ID 0x3D zu erfragen.

Wollvieh W. schrieb:
> der hat über die Jahre durch die dauernd anliegende hohe Spannung Staub
> angezogen. Nur eine der beiden Adern. Aber daß der Effekt auch schon bei
> 12V funktioniert erstaunt mich.

Dabei scheint es sich um Abrieb der Motorkohlen zu handeln.

Sebastian W. schrieb:
> Ich habe das defekte Gerät hier vor mir und würde gerne die
> eigentliche Fehlerursache finden.

Tja. Mir scheint das Gerät gar nicht defekt zu sein. Ich könnte die ICs 
noch mit Heißluft nachlöten. Ansonsten bleibt wohl nur die Hoffnung, 
dass der Fehler nicht an den Kabelverbindungen im Auto lag und also mit 
dem Ersatzteil nicht erneut auftritt ...

LG, Sebastian

Die Kabel in der Fahrertür sind ein heißer Tipp für einen Kabelbruch - 
ist auch rel. einfach zu beheben. Ich würde als erstes dort zu suchen 
beginnen.

Rüdiger schrieb:
> Wer bei sich es das gleiche (Kälte-) Problem hat und die Lösung oder das
> Defekte Teil gefunden hat, bitte melden.

Scheint eine VW-Krankheit zu sein, die sich durch alle Typenreihen 
zieht. Bei mir war es vor ~10 Jahren das Komfortsteuergerät:

Beitrag "Tips für Reparatur von VW Komfortsteuergerät?"

Ich konnte den eigentlichen Fehler nicht wirklich identifizieren, aber 
er trat danach nie wieder auf.

Eine Kabelverbindung, die ich bisher gar nicht verstehe, ist die 
zwischen dem Türsteuergerät J386 an T8h/8 und dem Komfortsteuergerät 
J393 an T23/6.

Auf dem Türsteuergerät ist diese Verbindung zum einen über einen 
Spannungsteiler mit B5/AD5 des Mikrocontroller verbunden, und zwar T8h/8 
- 100k - B5/AD5 - 33k - GND.

Zusätzlich ist T8h/8 aber noch über eine etwas aufwändigere Verschaltung 
aus drei SOT23, einen SOT89, zwei MELFs und zwei Widerständen mit C2 und 
A0 des Mikrocontrollers verbunden.

Anbei der Schaltungsausschnitt. G bedeutet GND, T sind nur Testpunkte.

Kann irgendwer die drei SOT23, den SOT89 und die zwei MELF 
identifizieren, um dem Sinn dieser Schaltung auf die Spur zu kommen?

LG, Sebastian

H. H. schrieb:
> "BM"= BCX55-16 von Infineon.
> "WC"= BCR133 von Infineon.
> "A7"= BAV99W von Infineon.
> "1B"= ???2222 von Onsemi.
> Und die Melfs sind 360 Ohm 1% Widerstände.

¡Muchas gracias, señor! Also drei NPN und eine Schutzdiode gegen 
negative Spannung ...

LG, Sebastian

H. H. schrieb:
> Da lag ich daneben, es ist ein BC846B von Onsemi.
Ist aber auch ein NPN.

Also: B5 ist ein uC-Eingang für die Spannung an T8h/8. A0 ist ein 
uC-Ausgang und zieht T8h/8 über 180R auf GND.

Aber was macht C2 und die Schaltung aus BC846B, BCX55-16, 3k3, 10k und 
10R? C2 scheint ja auch ein uC-Ausgang zu sein. Aktiviert C2 einen 
Konstantstrom zu GND?

LG, Sebastian

H. H. schrieb:
> Schaltplan zeichnen!

C2, B5 und A0 sind alles Ports des M68HC908EY Mikrocontrollers.

Aber was genau bewirkt C2 bei dieser Schaltung ... ?

LG, Sebastian

Sebastian W. schrieb:
> Eine Kabelverbindung, die ich bisher gar nicht verstehe, ist die
> zwischen dem Türsteuergerät J386 an T8h/8 und dem Komfortsteuergerät
> J393 an T23/6.
>

Wenn ich es richtig sehe (Siehe Bild) gibt es Varianten des T5 bei denen 
an T23/6 von J393 die "Auf" und "Zu" Schalter liegen (Unterscheidung per 
Widerstand). Eventuell wird ja genau das über die Schaltung 
nachgebildet.

Dieter S. schrieb:
> Wenn ich es richtig sehe (Siehe Bild) gibt es Varianten des T5 bei denen
> an T23/6 von J393 die "Auf" und "Zu" Schalter liegen (Unterscheidung per
> Widerstand). Eventuell wird ja genau das über die Schaltung
> nachgebildet.

Das könnte sein. Gute Idee! Das Auf- und Zuschließen der Fahrertür muss 
ja irgendwie an ein CAN-fähiges Steuergerät übermittelt werden.

B5 würde dann zur Erkennung der Steuerspannung von J393 dienen, A0 würde 
die Betätigung von F220 "Auf" über den 180R-Widerstand signalisieren, 
und C2 müsste dann die Betätigung von F241 "Zu" als Schaltverbindung zu 
GND emulieren. Tut C2 das in dieser Schaltung?

Mein Steuergerät übernimmt ja die Türschlossüberwachung insofern, als 
bei meiner T5-Variante F220 als direkter Schalter, und F241 als Schalter 
mit Widerstand, zwischen T8h/5 und GND (T8h/1) verbunden ist.

Ich werde also erstens mal die Schaltschwelle an T8h/5 auf einen 
möglichen Widerstandswert von 180R untersuchen. Und zweitens werde ich 
mal 12V über einen Pullup-Widerstand an T8h/8 anlegen und schauen, ob 
das Steuergerät bei Simulation von "Auf" oder "Zu" an T8h/5 diese 
Zustände an T8h/8 "weiterreicht".

LG, Sebastian

Sebastian W. schrieb:
> Tut C2 das in dieser Schaltung?

Die Schaltung scheint tatsächlich bei C2 High T8h/8 relativ niederohmig 
auf GND zu ziehen, dabei aber den maximalen Strom auf 70mA zu begrenzen.

LG, Sebastian

Sebastian W. schrieb:
> Und zweitens werde ich
> mal 12V über einen Pullup-Widerstand an T8h/8 anlegen und schauen, ob
> das Steuergerät bei Simulation von "Auf" oder "Zu" an T8h/5 diese
> Zustände an T8h/8 "weiterreicht".

Tatsächlich scheint, bei Vorhandensein eines 12V-Pegels an T8h/8 über 
einen 2k2 Pullup, mein Steuergerät das Türschloss-Signal von T8h/5 an 
T8h/8 weiterzuleiten.

LG, Sebastian

Jetzt fehlt noch ein Dump der Firmware, wenn der Chip nicht gelockt ist 
sollte das per MON (Monitor Module) machbar sein. Dann kann man sich 
genau ansehen was alles gemacht wird.

Sebastian W. schrieb:
> Tatsächlich scheint, bei Vorhandensein eines 12V-Pegels an T8h/8 über
> einen 2k2 Pullup, mein Steuergerät das Türschloss-Signal von T8h/5 an
> T8h/8 weiterzuleiten.

Anbei die Messungen.

Noch nicht ganz klar ist mir der Pegel von 2.2V an T8h/5 bei Verbindung 
über 180 Ohm zu GND. Wenn dort also 12mA fließen, dann ergibt sich für 
den Spannungsabfall zwischen den internen 12V (eigentlich 11.3V der 
Verpolschutzdiode wegen) und diesen 2.2V ein Widerstand von 760 Ohm. Die 
Schaltung benutzt aber einen Pullup-Widerstand von 2k ... ?

LG, Sebastian

Dieter S. schrieb:
> Jetzt fehlt noch ein Dump der Firmware, wenn der Chip nicht gelockt ist
> sollte das per MON (Monitor Module) machbar sein. Dann kann man sich
> genau ansehen was alles gemacht wird.

Da muss ich mich erst einmal einarbeiten. Aber ein Dump und 
anschließender Re-Flash soll ja verjüngend wirken.

Also, wenn ich es richtig verstehe, dann wird !IRQ vom MC33689 über 3k3 
auf 5V gezogen. Also sollte ich A1 über 10k auf GND legen, und dann kann 
ich nach einem Reset über A0 und einen USB-TTL-Wandler irgendwie mit dem 
Prozessor im "Forced Monitor Mode" kommunizieren?

LG, Sebastian

Sebastian W. schrieb:
>
> Also, wenn ich es richtig verstehe, dann wird !IRQ vom MC33689 über 3k3
> auf 5V gezogen. Also sollte ich A1 über 10k auf GND legen, und dann kann
> ich nach einem Reset über A0 und einen USB-TTL-Wandler irgendwie mit dem
> Prozessor im "Forced Monitor Mode" kommunizieren?

"Forced Monitor Mode" passiert ja nur wenn der Chip noch nicht 
programmiert ist (Reset-Vector 0xFFFF). Wenn er schon programmiert ist 
muss IRQ auf 9 Volt (V TST) um in den Monitor Mode zu kommen. Falls IRQ 
mit dem MC33689 verbunden ist wird man die Verbindung vorher auftrennen 
müssen.

Dieter S. schrieb:
> Falls IRQ mit dem MC33689 verbunden ist wird man die Verbindung vorher
> auftrennen müssen.

Ok. Das 1mA durch die Schutzdiode wird den 33689 wohl nicht kratzen, 
aber warum nicht den 3k3 sicherheitshalber vorher auslöten.

Aber brauche ich, bevor ich den Flash auslesen kann, dann nicht auch 
noch diese 8 Sicherheitsbytes? Oder ist das bei dem Mikrocontroller 
optional? Im Datenblatt zumindest hab ich keinen Weg drumherum gefunden 
...

LG, Sebastian

Sebastian W. schrieb:
>
> Aber brauche ich, bevor ich den Flash auslesen kann, dann nicht auch
> noch diese 8 Sicherheitsbytes? Oder ist das bei dem Mikrocontroller
> optional? Im Datenblatt zumindest hab ich keinen Weg drumherum gefunden
> ...

Wenn die Security Bytes programmiert sind ist das Auslesen gesperrt 
falls man deren Wert nicht kennt. Die Frage ist ob man sich an die 
Empfehlung im Datenblatt gehalten hat und die Security Bytes gesetzt 
hat, sonst sind diese Bytes leer (0xFF).

Es kommt darauf an ob Du noch weiter mit dem Steuergerät experimentieren 
möchtest, dann könnte man schauen ob der Monitor Mode Zugriff auf den 
Flash erlaubt. Ansonsten ist das eher Spielerei, die Firmware scheint ja 
zu funktionieren. Da der MC68HC908EY16/MC68HC908EY8 keinen internen 
EEPROM hat sehe ich auch keine Notwendigkeit den Chip neu zu 
programmieren, es wird im Betrieb ja nichts in den Flash geschrieben 
wodurch eventuell die Haltbarkeit der Daten beeinträchtigt wird.

Nachtrag: ich sehe gerade dass sich der Flash des 
MC68HC908EY16/MC68HC908EY8 im Betrieb programmieren läßt. Daß das 
gemacht wird halte ich aber für eher unwahrscheinlich. Da das 
Steuergerät nicht per Diagnose zu erreichen ist gibt es eigentlich 
keinen Grund im Betrieb regelmäßig irgendetwas abzuspeichern.

Was anderes: Welche Teilenummern stehen denn auf dem Steuergerät (das 
können mehrere sein, z.B. Hardware und Software)?

Ich frage weil man bei VW die Software teilweise findet, wobei ich aber 
bei einem Steuergerät, daß nicht per Diagnose erreichbar ist, eher nicht 
davon ausgehe.

Dieter S. schrieb:
> im Betrieb regelmäßig irgendetwas abzuspeichern.

Das Gerät "lernt" die Öffnungs- und Schließwege. Die müssen aber nach 
Ausfall der Batterie neu angelernt werden, werden also eher nicht im 
Flash gespeichert.

Dennoch kann ich es ja mal bezeiten mit 8*0xFF versuchen ...

LG, Sebastian

Dieter S. schrieb:
> Was anderes: Welche Teilenummern stehen denn auf dem Steuergerät (das
> können mehrere sein, z.B. Hardware und Software)?

Bild anbei.

LG, Sebastian

Software dazu konnte ich keine finden. Das war eigentlich zu erwarten, 
wenn das Steuergerät nicht per Diagnose zu erreichen ist kann man auch 
nicht auf diesem Weg neue Software aufspielen und die Software wird 
nicht veröffentlicht.

Nochmal zu den Security Bytes: Ich nehme an daß selbst dann, wenn nicht 
explizit wegen der Flash-Security dort Werte gesetzt wurden, nicht alle 
acht Bytes 0xFF sein werden. Die Bytes 0xFFF6–0xFFFD enthalten ja auch 
Interrupt Vektoren. Alle davon sind vermutlich nicht belegt aber selbst 
wenn es nur einer im Bereich der Security Bytes ist kommt man nicht mehr 
ohne weiteres an den Inhalt des Flash.

Was aber dennoch geht wenn man damit herumspielen will: Man kann Code in 
den RAM laden und ausführen. Damit könnte man z.B. per SPI den Relais 
schalten (über den  MC33689). Inwieweit das Sinn macht ist eine andere 
Frage, das funktioniert ja bei Deinem Gerät.

Wenn man mit dem Monitor Mode experimentieren will sollte man den 
Watchdog des MC33689 deaktivieren damit man nicht ständig einen Reset 
bekommt.

Vielleicht ist ein Defekt auch "programmiert"?
Erfahrungsgemäß, und ich mache schon seit 35  Jahren Fahrzeugtechnik, 
ist da eher alles was mechanisch bewegt wird, kaputt.
Ganz vorne Schalter, dann Kabel, Motoren (gerade bei mit der Zeit immer 
schwerer gehenden Fensterhebern). Wenn was an den Steuerungen kaputt 
ist, dann oft Leistungsteile und das sieht und riecht man dann.

Als ich mit Mikrocontrollern und richtiger Elektronik angefangen habe, 
hatte ich im  Anfang auch schon mal hier und da, einen einfachen Fehler 
verkompliziert.

Sebastian W. schrieb:
>
> Der Motor scheint so 15A Anlaufstrom zu ziehen, bevor er (mechanisch
> unbelastet) mit 2.7A vor sich hinläuft. Passt zur Sicherung S37 mit 30A.
>
Ich habe ein sehr ähnliches Steuergerät aus einem Polo von 2006 in die 
Hände bekommen (siehe Bilder, Einbauort hinten rechts).

Bei dem ist der Anlaufstrom des Motor unter 5 Ampere (die 
Strombegrenzung eines 5 Ampere Netzteil spricht nicht an) und der Motor 
zieht im Leerlauf 1.6 Ampere.

Ich weiß nicht ob die Motoren so unterschiedlich sind oder ob das 
eventuell etwas mit dem ursprünglichen Problem zu tun haben könnte.

Dieter S. schrieb:
> Ich weiß nicht ob die Motoren so unterschiedlich sind oder ob das
> eventuell etwas mit dem ursprünglichen Problem zu tun haben könnte.

Mmh. Ich messe bei meinem Motor 0,45Ω von einer Seite des Kommutators 
zur anderen, und 0,5Ω von Kontaktblech zu Kontaktblech. Er läuft bei 1V 
an, und zieht im Stillstand bei 0.9V 1.6A. Beim Anlauf mit 12V regelt 
mein LNT bei 5.1V kurz ab, im laufenden Betrieb mit Getriebe aber ohne 
Last am Zahnrad sind es 2.5A. Den Anlaufstrom von 15A habe ich als 
Spannungsabfall über einem 100mΩ-Widerstand gemessen (Stromversorgung 
war hierbei ein 12V/30A Noname-Netzteil). Kommutator und Bürsten sind 
mit Druckluft und Iso von Kohlenstaub und Fett gereinigt.

Vielleicht hat dein Motor trotz gleicher Abmessungen eine andere 
Wicklung mit weniger Stromaufnahme?

Und, obwohl das PCB gleich zu sein scheint, unterscheidet sich die 
Bestückung deiner Platine in einigen Punkten. Die drei 2201-Widerstände 
fehlen, von den drei 1601-Widerständen fehlt der mittlere, und auch die 
Schaltung zur Türschloßemulation auf T8h/8 scheint zu fehlen.

Ist denn die Typbezeichnung dieselbe?

LG, Sebastian

Sebastian W. schrieb:
>
> Und, obwohl das PCB gleich zu sein scheint, unterscheidet sich die
> Bestückung deiner Platine in einigen Punkten. Die drei 2201-Widerstände
> fehlen, von den drei 1601-Widerständen fehlt der mittlere, und auch die
> Schaltung zur Türschloßemulation auf T8h/8 scheint zu fehlen.

Das Teil ist ein LIN Slave und empfängt vermutlich nur die Fenster 
hoch/runter Kommandos (die kennen ich allerdings noch nicht). Es fehlt 
außerdem der Quarz, für den LIN Slave reicht vermutlich der interne 
Oszillator (ICG) des MC68HC908EY. Nur die Tasten (kodiert per 
Widerstand) und der Türkontakt sowie LIN ist am Stecker belegt.

> Ist denn die Typbezeichnung dieselbe?

Die Teilenummer ist 6Y0959812.

Ich denke daß auch bei Dir die Platinen der anderen Fensterheber 
Unterschiede zum ersten Bild (20230515_215134_small.jpg) haben werden.

Dieter S. schrieb:
> Das Teil ist ein LIN Slave und empfängt vermutlich nur die Fenster
> hoch/runter Kommandos (die kennen ich allerdings noch nicht). Es fehlt
> außerdem der Quarz, für den LIN Slave reicht vermutlich der interne
> Oszillator (ICG) des MC68HC908EY. Nur die Tasten (kodiert per
> Widerstand) und der Türkontakt sowie LIN ist am Stecker belegt.

Ah ja, klar. Hinten sind ja auch keine Türschlösser ...

Spannend wäre für mich noch ein Vergleich der Motoren. Es kann natürlich 
sein, dass bei mir ein Wicklungsschluß die Stromaufnahme leistungslos 
erhöht. Allerdings sind die Türfenster des T5 schon schwerer als die 
hinteren Türfenster des Polo ...

LG, Sebastian

Sebastian W. schrieb:
>
> Spannend wäre für mich noch ein Vergleich der Motoren.

6Y0959812 bekommt man gebraucht recht günstig (unter EUR 20).

Zu den LIN Messages: Der LIN Slave reagiert auf Bits im ersten Byte der 
ID 0x26 und schaltet den Motor. Auf den Request mit ID 0x15 liefert er 
zwei Bytes die normalerweise beide 0x00 sind, im ersten Byte sind bei 
Schalterbetätigung Bits gesetzt.

Nachtrag: Der LIN Slave reagiert auch auf ID 0x3C/0x3D, also Diagnose 
über LIN. Ich werde mal sehen welche SIDs unterstützt werden.

Dieter S. schrieb:
> Zu den LIN Messages: Der LIN Slave reagiert auf Bits im ersten Byte der
> ID 0x26 und schaltet den Motor. Auf den Request mit ID 0x15 liefert er
> zwei Bytes die normalerweise beide 0x00 sind, im ersten Byte sind bei
> Schalterbetätigung Bits gesetzt.
>
> Nachtrag: Der LIN Slave reagiert auch auf ID 0x3C/0x3D, also Diagnose
> über LIN. Ich werde mal sehen welche SIDs unterstützt werden.

Interessant. Mein LIN Mastergerät aus der Fahrertür verschickt ID 0x26 
mit 4 Bytes. Dabei wird der Fensterheberschalter E40 (in Fahrertür für 
Fenster vorne links) mit 0x01, 0x05, 0x02 bzw. 0x06 im zweiten Byte 
kodiert, der Fensterheberschalter E81 (in Fahrertür für Fenster vorne 
rechts) mit 0x08, 0x28, 0x10 bzw. 0x30 im zweiten Byte, die 
Türschloßkontakte mit 0x10, 0x14, 0x20 bzw. 0x22 im ersten Byte, der 
Türkontakt mit 0x08 im ersten Byte, und die Spannungsversorgung R82 an 
T6ca/2 über 0x40 bzw. 0x41 im ersten Byte.

Auf welche Bits im ersten Byte reagiert denn dein LIN Slave hinten 
rechts?

Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten 
mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000 
01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse 
zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR H" 
bzw. "GSRMH " sagt mir erstmal aber nichts ...

LG, Sebastian

Sebastian W. schrieb:
>
> Auf welche Bits im ersten Byte reagiert denn dein LIN Slave hinten
> rechts?

Das habe ich noch nicht im Detail geprüft weil der Motor momentan nicht 
angeschlossen ist und daher der Relais nur kurz anzieht bis bemerkt wird 
daß keine Reaktion über den HAL Sensor kommt. Es sind aber relativ 
sicher nur die drei unteren Bits im ersten Byte von Bedeutung.

> Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten
> mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000
> 01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse
> zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR "
> bzw. "GSRMH " sagt mir erstmal aber nichts ...

Der LIN Slave hat die Adresse (NAD) 0x04. Ich bekomme z.B. die typische 
"Negative Response" wenn die SID nicht unterstützt wird (Beispiel 
Response: "04 03 7F 01 11 00 00 FF" bei der SID 01). Ich muß das aber 
noch genauer untersuchen.

Sebastian W. schrieb:
>
> Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten
> mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000
> 01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse
> zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR H"
> bzw. "GSRMH " sagt mir erstmal aber nichts ...

Ich bekomme etwas ähnliches als segmentierte Antwort auf SID 0x1A:

1

04 10 30 5A 9B 36 59 30    ..0Z.6Y0      First Frame (FF)

2

04 21 39 35 39 38 31 32    .!959812      Consecutive Frame (CF)

3

04 22 20 20 20 B0 33 32    ."   .32      CF

4

04 23 31 00 00 00 00 00    .#1.....      CF

5

04 24 00 00 00 00 00 54    .$.....T      CF

6

04 25 53 47 20 48 52 20    .%SG HR       CF

7

04 26 4D 52 36 20 20 20    .&MR6         CF

8

04 27 20 48 57 30 30 32    .' HW002      CF

9

04 28 20 FF FF FF FF FF    .( .....      last CF (Fill Byte 0xFF)

Das sind neun Response Frames mit ID 0x3D, die gesamte Länge der Daten 
ist 0x30. Bei Dir ist die NAD wohl 0x01 anstelle 0x04.

Die Daten sind u.a. die Teilenummer und weitere Angaben auf dem Label.

Sebastian W. schrieb:
> Vielleicht hat dein Motor trotz gleicher Abmessungen eine andere
> Wicklung mit weniger Stromaufnahme?

Glaube ich nicht. Jedenfalls werden die nicht so große Unterschiede 
haben.
Das bestätigt meine Annahme.
Da es die Fahrertür betrifft, die ungleich mehr bedient wird, ist das 
noch etwas, was für meine Annahme spricht, dass der Fehler eher in den 
mechanischen Teilen liegt. Vielleicht ist der Motor (mit Getriebeteil) 
hin, was ich aber auch noch nicht glaube. Die Hebemechanik ist sicher 
schwergängig oder ausgeschlagen. Das führt dann zum klemmen und zu dem 
hohen Strom.

Frank O. schrieb:
> Das führt dann zum klemmen und zu dem hohen Strom.

Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik, 
nur mit dem Getriebezahnrad ...

LG, Sebastian

Sebastian W. schrieb:
> Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik,
> nur mit dem Getriebezahnrad ...

vielleicht hat sich ja ein Tropfen Öl verklemmt? :-)

Miss doch den Motor mal einfach direkt am Labornetzteil?

Heinz R. schrieb:
> Miss doch den Motor mal einfach direkt am Labornetzteil?

Sebastian W. schrieb:
> Er läuft bei 1V an, und zieht im Stillstand bei 0.9V 1.6A. Beim Anlauf
> mit 12V regelt mein LNT bei 5.1V kurz ab, im laufenden Betrieb mit
> Getriebe aber ohne Last am Zahnrad sind es 2.5A.
All diese Messungen waren am LNT.

LG, Sebastian

Sebastian W. schrieb:
> Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik,
> nur mit dem Getriebezahnrad ...

Dann wirst du wohl den "Fehler" auf deinem Schreibtisch liegen haben.