Türmodule

Das klingt einleuchtend. Beim alten EF-Modul zähle ich auf den Bildern sogar nur 18 Stifte auf der linken, Ausgangsseite, vielleicht sieht man einen auch nicht richtig..

Beim neuen hingegen habe ich max. ein EC gefunden (gibt es überhaupt eine EF Version?) und die hat 22 Pins, bei denen gut erkennbar zwei Zanhlücken sind.

Somit ist mein Fehler klar. Ich hatte nicht richtig nachgezählt.

Ich sehe gerade das bei Spiegeln mit BLIS, die BLIS-LED garnicht über den normalen Spiegelstecker, sondern einem kleinen separaten Stecker verbunden wird.
Wird dieser möglicherweise garnicht ins Türmodul gesteckt und läuft direkt zu einem anderen Modul im Fahrzeug?
Das würde bei den Pins einiges erklären.

Heute sind meine ersten Türmodule eingetroffen (danke Cosworth!) und natürlich gleich zerlegt worden + chainsaw
Die ersten Bilder gibts im Wiki: https://mk4-wiki.denkdose.de/grundlagen/tue…14b533-cd/start

Hier mal ein Bild zur Frage, ob und welche Pins man an einem Modul nachrüsten könnte. Zur Orientierung habe ich mit grün zwei Pins markiert.

Rein optisch ist jetzt schonmal klar, das an dem vFL DDM die oberen vier Pins (1,2 sowie 13,14) nicht nachrüstbar sind. Hier ist schlicht kein Platz auf der Platine vorgesehen. Diese 4 Pins sind aber auch bis zur höchsten Modulversion "-EF" nicht bestückt. Ganz anders beim FL-Modul. Hier gibt es wohl Pin 1 und 13. Die Funktion ist mir jedoch noch unbekannt.

Die gelb markierten wären theoretisch nachrüstbar. Dafür fehlen aber offensichtlich auch Bauteile auf dem Board.
Pin 4 = (unbekannt)
Pin 6 = MIRROR SENSOR SUPPLY
Pin 7 = (unbekannt)
Pin 17 = MIRROR FOLD IN (Spiegeleinklappmotor)
Pin 18 = MIRROR SENSOR INPUT Y (Spiegelpositionssensor für Memoryfunktion Y-Achse)
Pin 19 = MIRROR SENSOR INPUT X (Spiegelpositionssensor für Memoryfunktion X-Achse)

Interessant sind auch die "Innereien" des Moduls (Details und Datenblätter habe ich im Wiki bereitgestellt: https://mk4-wiki.denkdose.de/grundlagen/tue…14b533-cd/start).

Da gibt es zum einen den Steuer-Chip (A), einen NEC 70F3233M2(A). Über den weiss ich noch wenig. Ist schwer zu bekommen, selbst das Datenblatt.

(B) ist hochinteressant. Das ist ein ST L9950XP, ein "Door actuator driver". Das ist Logik/Leistungsteil für Blinker, Bodenleuchte, Einsteigsleuchte, Spiegelmotoren (inkl Anklappmotor), Spiegelheizung, usw. Der Chip selbst kann "alles", ist aber eher dumm, da er über eine SPI-Schnittstelle seine Befehle vom uC (A) erhält.

Den Anschluß an den MS-CAN Bus erledigt (C), ein Freescale MC33989DW "System Basis Chip with High Speed CAN Transceiver".

Als Treiber für den LIN-Bus, an dem u.a. die Türschalter (Fensterheber) und das hintere Türmodul dran hängt ist (D) zuständig, ein NXP TJA1020 "LIN transceiver".

Auf (E) finden wir ein serielles 1 kb EEPROM im ST M95080-W "8-Kbit serial SPI bus EEPROM". Was auch immer das Modul darin speichern mag. Für eine Firmware ist es zu klein und zu langsam, die stecker eher im uC (A) integriert. Es sind also irgendwelche Parameter. Vielleicht ist das auch schon für eine Memory-Funktion gedacht, auch wenn diese bei dem gezeigten Modul nicht enthalten ist. Aber auch die Anklappfunktion wäre laut Modulcode nicht enthalten, die Elektronik dafür ist aber drauf.

(F) und (G) sind Leistungstreiber (BCP51 und D17NF03L Mosfets). Ich vermute einmal für den Fensterheber und einmal die Heizung, da diese ja ganz ordentlich Strom ziehen. Wozu das Relais oben rechts dient hab ich noch nicht rausgefunden.

Zumindest dürfte schonmal klar sein, das der Funktionsumfang nicht nur an unbestückten Pins und Software liegt, sondern das hier wirklich Bauteile gespart wurden. Wenn mir mal ein vFL "EF" Modul in die Hände fällt (EF hat ja den höchstmöglichen Funktionsumfang) würde ich die Unterschiede feststellen.

Auch reizt es mich noch an die Firmware ranzukommen. Die Chips haben meist irgendwelche Debug- und Programmier-Pins über die man die Firmware "mitlesen" oder auslesen kann. Natürlich gibt es hiergegen Schutzmechanismen der Chiphersteller, die mit sicherheit auch genutzt wurden. Aber es ist ein Angriffsvektor und die zahlreichen Cracker im Netz beweisen das es Methoden gibt den Schutz zu umgehen ("Power glitching", usw.). Das ist aber schon hohe Kunst. Vielleicht kauf ich mir mal so einen UCDS-Verschnitt für nen Hunni und schau auf dem CAN nach was das Ding treibt. Kann ja keine Raketentechnik sein. Ich denke mit nem CAN-Tracer bin ich da ganz schnell hinter wie man Firmware da drauf kriegt. Ein gewiefter Programmierer könnte dem Modul darüber auch eigene Firmware unterschieben. Die Frage ist nur "Was soll so ein Türmodul schon groß anders machen?"

Zitat von Spike1985

Anders machen könnte ein Türmodul zum Beispiel eine Spiegelabsenkung light. Also die Ausrichtung des Spiegels rein über X-Sekunden nach unten. Voraussetzung: Das Modul erkennt die Endstellung (etwa über höhere Stromaufnahme des Motors).

Das Modul kann durchaus das R-Signal empfangen und könnte darauf reagieren. Einen Spiegelmotor mit Sensoren und den durchgeführten Leitungen vorausgesetzt, könnte es die Positionswerte im EEPROM speichern und beim Rückwärtsgang anfahren. Es würde mich fast nicht wundern, wenn dieses Eeprom der Speicher für Spiegel und Sitzposition bei Fahrzeugen mit Memory ist.

Zitat von Erfurter

Vorschlag: Das ist ein Relais mit 2 Weschel-Kontakten, s. S 4 des Datasheet Da drängt sich mir gedanklich die Umschaltung des FH-Motors auf.

Jab, das klingt logisch. Konnte ich bislang nicht prüfen, da das Modul noch nicht mag. Kein Wunder, hab keinen Spiegel dran Werde ich die Tage aber mal nachholen und hoffentlich will das Teil dann auch.

Die CCC wird ins BCM (und IPC) eingespielt, nicht ins Modul selbst. Unklar ist noch, wie das Modul die für es relevanten Parameter daraus ermittelt. Da bin ich derzeit auf der Suche. Es gibt DTCs die darauf hindeuten, das sich das Modul diese Info vom BCM "anfordern". Wie und wann ist aber noch völlig unklar. "Sehen" konnte ich in meinen CAN Traces davon bislang jedenfalls nichts. Ist ja fast wie beim Yeti...

Inzwischen habe ich ja herausgefunden das das BCM die CCC periodisch in den CAN-Bus sendet und sich die Module den für sie relevanten Teil einfach auslesen.

Nachdem ich das Türgedönse nun recht komplett hab, Module, Spiegel, FH-Konsole würde ich mal die Signale untersuchen wollen.
Mich interessiert besonders was auf dem CAN läuft um die Fenster runter- bzw. raufzufahren. Das kann man ja mit der FFB machen.
Weiterhin will ich mich mal ins Thema LIN-Bus einarbeiten. Damit habe ich bislang nämlich noch keine Erfahrung gemacht. Es gibt aber einige interessante Komponenten im Mondeo die über LIN arbeiten. Beim Türmodul ist über LIN die FH-Konsole und das jeweils auf derselben Seite befindliche, hintere Türmodul.

Nope. Das ist der "Door ajar alarm" und der ist völlig separat verkabelt und am BCM angeschlossen. Siehe Steckerbelegung BCM: http://mk4-wiki.denkdose.de/grundlagen/bcm/pinbelegung_c2?s[]=door&s[]=ajar

Also, ich habe das mit dem "Tür auf" mal geklärt. Hier war mir mein "BCM im Glas" wieder eine große Hilfe.
Grundsätzlich ist es so, das von allen Türen (Fahrer, Beifahrer, Passierge und Heckklappe) jeweils ein eigener Schaltkontakt im Schloß ans BCM geht:
Stecker C2 (Grün)
Pin 10 => hinten links
Pin 11 => vorn links
Pin 28 => hinten rechts
Pin 29 => vorn rechts
Pin 30 => Heckklappe

Die habe ich dann alle mal mit Schaltern simuliert und konnte ermitteln, das ID_06B auf dem MS-CAN die Information trägt. Pro Tür ein Bit.
Es handelt sich elektrisch gesehen um Schließerkontakte. Die Pegel am BCM sind active-low. D.H. wenn die jeweilige Tür zu ist, dann liegt am BCM GND-Pegel an (der Kontakt im Schloß ist geschlossen). Geht die Tür auf, dann wird der Kontakt geöffnet und am BCM liegt 12V-Pegel an. Die Bits sind entsprechend, eine "1" für 12V-Pegel (Tür auf) und eine "0" für GND (Tür zu).

Die Zustände der vorderen Türen sind zusätzlich noch in der ID 433 mit kodiert. Sind alle Türen zu, hat D0 den Wert 0x00. Ist die Fahrer oder Beifahrertür auf, gibt es dort 0x40 oder 0x80. Die hinteren Türen, samt Kofferraum haben keinen Einfluß auf diesen Wert.

Somit ist diese Frage auch ein für allemal geklärt