Megane 3 [Recherche] Nachrüstung des ESP-Sportmodus

Diskutiere [Recherche] Nachrüstung des ESP-Sportmodus im Forum Elektronik im Bereich Technik - Hallo zusammen, da das Thema ESP-Sportmodus im nicht-RS-Megane einiges an Recherche und Austausch erfordert, habe ich diesen neuen Thread...
M

miki4

Türaufmacher
Beiträge
10
Hallo zusammen,

da das Thema ESP-Sportmodus im nicht-RS-Megane einiges an Recherche und Austausch erfordert, habe ich diesen neuen Thread eröffnet, um den ddt4all-Thread nicht weiter für das Thema zu missbrauchen. Ich bitte die Moderatoren, die relevanten Beiträge aus dem ddt4all-Thread (zumindest jene ab dem 30. Januar 2024) der Vollständigkeit halber in diesen Thread zu kopieren. Konkret tüfteln Jay1980 und ich derzeit an der Sache. Wenn jemand etwas dazu beitragen kann, der ist herzlich dazu eingeladen, sein Wissen hier zu teilen. Ich hoffe, wir kommen auf diesem Weg bald in den Genuss des besonderen ESP-Modus, welcher bisher den RS-Fahrern vorbehalten blieb.


Mein neuer Beitrag zum Thema, Stand 06.02.2024:

Ich glaube, dass es keine oder zumindest keine signifikanten Hardwareunterschiede zwischen den verschiedenen Teilenummern des ABS/ESP-Blocks gibt. Die BMW-Fraktion hat es auch geschafft, den M-Trackmode bzw. ESC-Sportmodus per Software in die Fahrzeuge zu codieren, die ab Werk keinen haben. Das ist kein Beweis, aber ein Indiz, immerhin sind das ähnliche, wenn nicht der gleiche Typ ABS-Block. Besonders interessant finde ich einen Post in einem ECU-Forum, wo ein User schreibt, dass es trotz verschiedener Teilenummern der ABS-Blöcke beim Megane 3 und Scenic 3, prinzipiell nur den Typ ABS und ABS/ESP gibt. Ich gehe davon aus, dass er von der Hardware spricht *hier war ein Link zur Quelle*. Das deckt sich mit meiner Erfahrung bei den Motorsteuergeräten.

Das ABS/ESP-Steuergerät (eine Variante vom ATE MK60) hat ähnlich dem ECM einmal den Microcontroller-internen Flash-Speicher (möglicherweise auch zwei, da es zwei größere Chips auf der Platine gibt) und einmal den EEPROM. Im EEPROM ist u.a. der Kilometerstand gespeichert. Ich gehe davon aus, dass hier, wie bei den ECMs, im Flash die reine Software und Wertetabellen gespeichert sind, und im EEPROM die fahrzeugspezifischen Daten wie Fahrgestellnummer, Gespeicherte Fehlercodes, die Konfiguration (und nachweisbar der Kilometerstand).

Man müsste herausfinden, ob das Besondere am RS eine gänzlich eigene Softwareversion ist, die in den Flash programmiert werden müsste, oder ob die Software (abgesehen von verschiedenen Versionsständen) gleich zum normalen Megane ist, und lediglich die Konfiguration entscheidet, ob der Sportmodus vorhanden/blockiert ist. @Jay1980: Hast du vielleicht schon bei deinen Experimenten mit REPROG herausgefunden, ob das die gleiche Software ist? Wenn die komplette Software beim RS anders ist, könnte es schwer werden, eine anwenderfreundliche Lösung zu finden. Ich habe kein Tool gefunden, was den Flash des ABS/ESP-Steuergeräts im Megane per OBD lesen oder schreiben kann. Das bedeutet, dass man hinsichtlich CLIP und REPROG weiter forschen müsste, ob damit etwas machbar ist. Alternativ DDT2000, womit man den Schreibvorgang angeblich forcieren kann, wofür man aber ein spezielles Interface (z.B. Derelek) benötigt, sauteuer. Das will ich mir noch anschauen. Wenn das nicht klappt, müsste man ansonsten nämlich direkt an den internen Flash des Mikrocontrollers auf der Platine im ABS-Block, und da wird es schon allein aufgrund der Einbausituation des ABS-Blocks unattraktiv. Mein Gefühl sagt mir aber, dass es nicht die Software im Flash ist, sondern die Konfiguration im EEPROM, die entscheidend ist.

@Jay1980: Du hast ja bereits herausgefunden, dass Schreibbefehle an das ABS/ESP blockiert werden. In der ESP_HSA_X95_8.1.xml steht betreffend der "Configuration vehicule" -> "Calculateur neuf = Fonction REF uniquement Activée". Ich weiß zwar nicht genau, was "REF" in dem Zusammenhang bedeutet, aber der String lässt vermuten, dass die Konfiguration eben nur einmalig durchführbar ist, weswegen deine Schreibbefehle geblockt werden. Wir brauchen also ein neues Steuergerät oder eines, welches virginized wurde, also in quasi-Neuzustand versetzt. Das müsste mit einem Virgin-File, welches auf den EEPROM geschrieben wird, erledigt sein. Ein solches passendes File habe ich allerdings bisher nicht gefunden, auch keine Möglichkeit, eines zu erstellen. Es gibt aber definitiv Tools, die den EEPROM per OBD lesen und schreiben können, die Software *hier stand ein Softwarename* sogar mit einem normalen ELM327-Interface! Nur leider kostenpflichtig. Ich versuche, da ran zu kommen oder eine Alternative zu finden. Das ist jedenfalls eine vielversprechende Möglichkeit, etwas zu erreichen. Man könnte z.B. auch versuchen, wenn man schon kein Virgin-File hat, den EEPROM-Dump des RS-Steuergeräts 1:1 auf einen nicht-RS-Block zu schreiben (vorausgesetzt Softwarestand passt, sonst kann es einen Brick geben). Das würde zwar die falsche Fahrgestellnummer und Kilometerstand mitnehmen, aber die richtige Konfiguration. Es wäre auch hilfreich, wenn man mehrere EEPROM-Dumps von verschiedenen Meganes hätte, dann könnte man die variablen Bereiche erfassen, um so ggf. manuell ein Virgin-File zu erstellen. In dem Zusammenhang ist es auch interessant, ob ein simpler REPROG das Steuergerät bereits ausreichend zurücksetzt, um eine neue Konfiguration schreiben zu dürfen. In dem Fall könnte man nämlich direkt nach dem REPROG (vor der Konfiguration) einen Dump des EEPROMs ziehen, um diesen nach Belieben zurückflashen zu können, wenn man eine andere Konfiguration ausprobieren möchte.

Zum Virginizen des ESP steht übrigens auch was in der ESP.xml: "2 opérations sont nécessaires pour rendre le calculateur en l'état vierge : RAZ des configurations et téléchargement d'un calibrage vierge.". Auf Deutsch also im Prinzip: Alle Konfigurationen des Steuergeräts auf 0 setzen und ein Virgin-File uploaden. Für das Virgin-File solle man den "PDE" kontaktieren, vermutlich irgendeine Tech-Abteilung bei Renault.

Du schriebst vorher: "Was die nicht-Konfiguration vom RS betrifft: das steht auf den ddt Screens.". Könntest du mir sagen, wo du das genau gefunden hast? Auch die Kommentare speziell den RS betreffend. Das müsste ja in den XMLs zu finden sein, finde ich aber leider kaum etwas zu.

Gruß
miki4
 
Zuletzt bearbeitet:
M

Marianpol

Türaufmacher
Beiträge
5
Den für die Dekodierung der Dateien verantwortlichen Code kann ich leider nicht an Sie weitergeben, da ich ihn von einer vertrauenswürdigen Person erhalten habe. Das müssen Sie mir verzeihen. Ich kann alle gewünschten Dateien dekodieren und Ihnen geben.

Ich glaube nicht, dass der Unterschied durch die größere EEPROM-Speicheroberfläche so groß ist, dass er ein Bootloader-Loop-Problem verursachen könnte.

Ja, ich habe einen Parser, der dekodierte Dateien in einen Dump verarbeitet, der direkt auf Treiber hochgeladen werden kann. Es funktioniert, ist aber nicht sehr ausgefeilt.

Es ist seltsam, dass das Lesen und Schreiben mit RenoLink so lange dauert. Meine Implementierung zum Lesen und Schreiben des EEPROM-Speichers ermöglicht das Lesen von 4 KB Speicher in etwa 25 Sekunden, und das Schreiben des gesamten Speichers dauert etwa 2 Minuten (und könnte verkürzt werden, indem nur die geänderten Felder geschrieben werden).

Ich werde mir diese beiden Softwareversionen ansehen, die sich nur in der Nummer unterscheiden. IDA-Erfahrung ist eine Sache, die korrekte Definition eines Prozessors eine andere. Ich bin nicht sicher, ob es sich bei der Prozessorarchitektur um M Core handelt, daher weiß ich nicht, ob die dekompilierten Daten überhaupt korrekt sind. Ich brauche eine zuverlässige Quelle, wo ich einen Algorithmus finden kann, der die Prüfsumme berechnet.

Sie haben Recht, es können 40 km/h sein, nicht 43 km/h. Ich habe vergessen, das Messgerät zu verzerren.

Ich habe die Software 487553806R, die laut REPROG-Daten im Megane 3 RS verwendet wurde. MK60 unterstützt das Lesen von FLASH über UDS/KWP2000 nicht. Es ist nur ein Schreibzugriff möglich. Wie Sie sagen, kann es ohne Kenntnis der Pins schwierig sein, Daten von dieser MCU zu dumpen.

Ich habe versucht, FLASH zu dekompilieren, nachdem ich mithilfe der Prozessordefinition der M-Core-Architektur unnötige Daten in IDA entfernt hatte, aber die Daten sahen beschissen aus. Null Befestigungspunkt.
 
Zuletzt bearbeitet von einem Moderator:
M

miki4

Türaufmacher
Threadstarter
Beiträge
10
Danke für die Infos.

Die 478553806R Firmware ist uns auch aufgefallen. Außerdem die 47855X9514, allerdings gibt es diese nicht auf der Reprog-Disk.

Wir haben einen Nachweis, dass sich die 3806R Firmware auf einem Phase1 TCE180 befindet. Es ist diese Firmware, die ich versucht habe, auf den 2272R Block zu flashen, woraufhin es den Soft-Brick gab. Ich möchte dies nochmals versuchen mit einem 95160 EEPROM anstelle des 95320, da die Platinen sonst gleich zu sein scheinen.
Wenn es wirklich so ist, dass die Firmware original auf einem RS war, dann ist es vermutlich eine Prototypen-Firmware. Laut den CLIP Datenbanken wurde es beim RS nur beim Produktionsdatum 17.12.2008 verwendet. Jedenfalls erhärtet sich hier nochmals der Verdacht, dass sich die Phase1 Modelle (speziell TCE180) leichter modifizieren lassen auf RS-Config bzw. Abschalten des ASR, da diese teilweise die 3806R Firmware benutzen.



Ja, es gibt eine schnellere Möglichkeit, den EEPROM zu schreiben, so wie REPROG es auch tut. Allerdings nutzt Renolink einen anderen Weg. Es scheint künstlich verlangsamt worden zu sein, um das Sammeln von Seed-Key-Paaren zu erschweren, da der Write-Prozess erst sehr spät beginnt.
 
Zuletzt bearbeitet von einem Moderator:
M

Marianpol

Türaufmacher
Beiträge
5
Zum Speichern verwende ich den Befehl 3BFC, wahrscheinlich derselbe wie RenoLink. Vielleicht erzwingt RenoLink mit roher Gewalt die Schreibberechtigung und dauert deshalb so lange. Der Schlüssel ist zwei Bytes lang und der Treiber erzwingt keine Wartezeit, bevor der nächste Schlüssel gesendet wird. Für CLIP wird der Befehl 3482 verwendet.
 
Zuletzt bearbeitet von einem Moderator:
M

miki4

Türaufmacher
Threadstarter
Beiträge
10
Frohe Weihnachten allerseits!

Danke für die Dateien. Interessant, dass der Kalibrierungsbereich des EEPROMs separat in der *C.bin hinterlegt ist, das war mir bisher nicht bekannt, da ich nur die eine *L.bin decryptet hatte, allerdings ungeparsed.

Genau, Renolink verwendet ebenso den Befehl 3BFC. 3482, wie CLIP ihn verwendet, erlaubt sicherlich einen schnelleren Schreibvorgang, da man einen größeren Block von Bytes auf einmal senden kann, allerdings sind 2 Minuten mit 3BFC, so wie du es realisiert hast, bereits sehr schnell und mehr als ausreichend. Ich muss mich an dieser Stelle korrigieren. Ich sagte früher, dass bei Renolink vor jedem Write ein vollständiger Read forciert wird. Dies passiert nur bei ausschließlichem Write des Kilometerstands (meiner Meinung nach, wie gesagt, um das Sammeln von Seed-Key-Paaren durch Sniffing zu erschweren, da der Lesevorgang zuerst mehrere Minuten in Anspruch nimmt). Beim vollständigen Write des EEPROMs passiert dies nicht, allerdings dauert es dennoch 45 Minuten für 4 KB. Es wird mit jedem 3BFC Befehl nur ein Byte geschrieben und zwischen jedem Befehl vergeht Zeit. Ähnlich sieht es beim Read aus, wobei hier 4 Bytes auf einmal gelesen werden. Für den Read wird der Befehl 2109 verwendet, analog zum Auslesen der ASTM-Parameter nach DDT XML (a propos: weiß jemand, wofür ASTM in diesem Zusammenhang steht?). Zwischen jedem Befehl vergeht Zeit, die man auch kaum beschleunigen kann, da der Befehl erst abgearbeitet und der ELM wieder bereit sein muss. Wir mussten den Read selbst implementieren, da Renolink aus irgendeinem Grund nur 2 KB lesen kann, zumindest in Version 2.10. Das schnellste, was wir auf diese Weise geschafft haben, sind ungefähr 2 Minuten für 4 KB, allerdings unbequem, da man dafür jedes Mal die Baudrate des Interfaces anpassen muss, da Renolink, welches wir für den Write benötigen, unbedingt 1000000 Baud erfordert, während der selbst implementierte Read mit einer anderen Baudrate schneller ist. In jedem Fall wäre es sehr hilfreich, wenn du uns deine Implementation für den Read/Write zur Verfügung stellen würdest, um die kommenden Tests im Fahrzeug zu beschleunigen.

In den kommenden Tagen möchten wir an einem Phase 1 TCE180 eines Forenmitglieds mit 3806R-Firmware ausprobieren, ob sich der Kalibrierungsbereich im EEPROM anpassen lässt, ohne dass dies einen Checksummenfehler verursacht, wie es bei den 4 KB Firmwares der Fall ist. Bei den 2010er und 2015er RS-Blöcken, die wir haben, wird nämlich kein Fehler verursacht. Wenn dies bei der 3806R-Firmware ebenso möglich ist, werden wir versuchen, die ASR-Schwelle zu verändern und das entsprechende Byte einzugrenzen, sofern es sich im EEPROM befindet. Wenn das klappt, ließe sich das sehr wahrscheinlich auch bei allen anderen Firmwares umsetzen, sofern man die Checksumme knackt. Die Firmwares mit dem identischen Kalibrierungsbereich, die ich im Bezug auf das Knacken des Algorithmus erwähnt hatte, sind übrigens 3319R und 9934R. Beide habe ich im letzten Post zur Verfügung gestellt. Sie unterscheiden sich nur in der Versionsnummer am Ende und der Checksumme.
Darüberhinaus möchten wir ausprobieren, ob sich bei dieser Firmware per DDT etwas RS-spezifisches konfigurieren lässt, und falls ja, welche Auswirkungen dies hat. Bei allen anderen nicht-RS Firmwares, die uns zum Testen zu Verfügung standen, ging dies nämlich nicht. Wie vor mehreren Jahren ein Forenmitglied mal schrieb, sei das alles gar kein Problem gewesen (das war damals ein Phase 1). Die Vermutung liegt daher nahe, dass das geht (Stichwort RS-Prototypenfirmware).
Außerdem möchten wir, wenn es keinen Checksummencheck gibt, den Kalibrierungsbereich der RS-Blöcke (der übrigens beim 2010er und 2015er RS-Block identisch ist) anpassen, sodass er mit dem Layout des Kalibrierungsbereichs der 3806R-Firmware übereinstimmt, flashen, und schauen, welche Auswirkungen dies hat. Wir wissen noch nicht, wo die Kennlinien für den Sportmodus verankert sind, Möglicherweise auch direkt in der Firmware im Flash, aber durch solche Tests kommt man der Sache näher. Die Tatsache, dass Marianpol eine Möglichkeit hat, die REPROG-Files zu decrypten, ist auch ein Schritt in die richtige Richtung.

@Marianpol Vielleicht könntest du uns zumindest einen Hinweis zum Decrypten geben? Dann kann jeder in der Hinsicht selbstständiger agieren. Wir wissen, dass die REPROG-Files im Prinzip ein ZIP-Archiv sind mit einer statischen Verschlüsselung. Wir sind lediglich noch nicht auf die Verschlüsselungsmethode gekommen, da wir praktisch keine Erfahrung haben, Assemblercode zu verstehen. Standardverfahren wie NOT, XOR, ... und Kombinationen haben uns in der Hinsicht nicht weitergebracht.

Bist du eigentlich sicher, dass die decrypteten und geparsten Files in der Form direkt lauffähig sind auf der MCU? Wenn ich das richtig verstanden habe, hast du noch keine Möglichkeit, direkt auf den Flash zu schreiben, oder?

Woher weißt du, dass kein Read via UDS implementiert ist?

Und was genau meinst du mit "[...] und mit dem Speicherinhalt des Controllers vergleichen."?

Viele Grüße
Miki4
 
Zuletzt bearbeitet:
M

Marianpol

Türaufmacher
Beiträge
5
Bei ABS-Pumpen enthalten die L-Dateien FLASH und EEPROM, die C-Dateien enthalten nur EEPROM. Aus der hochgeladenen L-Datei habe ich den Abschnitt mit dem EEPROM-Inhalt ausgeschnitten, um die Daten für zwei verschiedene Speicherchips zu trennen.



Ich bin nicht 100 % sicher, ob das von mir gesendete FLASH sicher direkt auf die MCU hochgeladen werden kann. Für mich kommt es so vor, obwohl neben dem Hauptspeicherinhalt im Bereich 0x610000-0x69385C auch noch 12 Bytes an der Adresse 0xFFFF00 geladen werden, was weit außerhalb des Standardspeicherbereichs liegt. Ich füge dekodierte REPROG-Dateien an, bevor ich Adressen entferne.


Die ABS-Pumpe unterstützt das Lesen von Software nicht, da ich in einer Programmiersitzung eine 7F3511-Antwort vom Controller erhalte, wobei das Schreiben des Controllers über den Dienst 0x34 funktioniert, obwohl der Hersteller der ABS-Pumpensoftware die Option zum Herunterladen von Software vom Controller versteckt haben könnte in einer anderen Sitzung oder hat mich durch die Übermittlung eines falschen negativen Antwortcodes getäuscht.

So kann ich beispielsweise prüfen, ob und welche Änderungen an der Software der Motorsteuerung vorgenommen wurden. Bei der ABS-Pumpe kann ich prüfen, welcher Bereich des EEPROM-Speichers veränderbar ist und welcher Bereich vom Hersteller ist.
 
Zuletzt bearbeitet von einem Moderator:
Dom0286

Dom0286

Türaufmacher
Beiträge
13
Guten morgen. Gibt es da schon weitere vorschritte? Würde auch gerne den sport modus haben im gt220
 
timwxc

timwxc

Megane-Kenner
Beiträge
136
Moin.
Aktuell ist das Projekt auf Eis gelegt.
Es gibt nach aktuellem Stand keine Möglichkeit das ABS selbst zu programmieren oder ggf. den Schwellwert hochzusetzen.
Es bleibt der Austausch des ABS Blocks.
Das ASR kann dauerhaft deaktiviert werden.
 
Dom0286

Dom0286

Türaufmacher
Beiträge
13
Ok. Und wodrüber ist der sport modus dann zu aktivieren? Über startstop oder Über asr
 
Jay1980

Jay1980

Megane-Experte
Beiträge
1.077
Start/Stop hat nichts zu tun mit dem Sportmodus.
Aktiviert wird er im RS über die Taste wo du das ASR betätigst.
Die Taste ist nur anders bzw. mit RS bedruckt.
Verkabelt ist sie in jedem Megane 3 immer gleich.

Es ist so wie Tim schon geschrieben hat.
 
Thema: [Recherche] Nachrüstung des ESP-Sportmodus

Ähnliche Themen

P
Antworten
2
Aufrufe
2.293
Pi123
P
F
Antworten
0
Aufrufe
4.517
Flydiamond
F
N
Antworten
11
Aufrufe
11.125
feisalsbrother
feisalsbrother
Oben