ich habe mir vor 2 Jahren einen ELM 327 OBD Bluetooth Diagnose Stecker und Adapterkabel für CAN H, für meinen Fiat Ducato 2017 gekauft und die Software AlfaObd Demo auf meinem Handy installiert.
Alles funktionierte prima, hatte Zugriff auf alle Steuergeräte auf dem CAN H und L Bus und konnte auf alle Service / Statusinformationen zugreifen.
Bis auf den Body Computer, dort habe ich einmal den Status ausgelesen und habe seitem keinen Zugriff mehr.
Mittlerweile habe ich auch PC Diagnose Software verschiedener Anbieter und Versionen erprobt, immer mit dem gleichen Ergebnis, die Kommunikation wird abgebrochen.
Ich habe mich mit dem Kommunikationsproblem auseinandergesetzt und den Datenaustausch zwischen dem Handy und dem ELM 327 OBD Adapter mitgeschnitten, mit folgendem Ergebnis:
Cr, >, Steuerzeichen aus dem EML 327 standard.
Nach Initialisierung der ELM 327 Parameter mit den AT Befehlen, wird die "Diagnostic Session Control" SID 0x10 Subfunction 0x03 "Extendet Diagnostic Session":
1003Cr an das Steuergerät gesendet.
In den meisten Fällen ist die Antwort des Diagnose Adapters: NO DATACrCr> => keine Antwort des Steuergerätes innerhalb der Wartezeit durch ATST19 = 100ms.
In wenigen Fällen Antwortet der Bodycomputer mit: 7F2278CrCr> das ich wie folgt Interpretiere: Response ID: 0x7F: Negative Response, Sub Function: 0x22 ??? Sollte doch 0x10 sein ??,
Laut meinen Unterlagen gibt es einen Negative Response code 0x22: "Conditions Not Correct", jedoch keinen Code: 0x78.
Gemäß ISO 14229: 0x22: "conditionsNotCorrect" 0x78: "requestCorrectlyReceived-ResponsePending"
Kann mir jemand helfen, die Antwort richtig zu Interpretieren, als auch Möglichkeiten aufzuzeigen, das Steuergerät in einen diagnosefähigen Zustand zu versetzen.
In wenigen Fällen Antwortet der Bodycomputer mit: 7F2278CrCr> das ich
wie folgt Interpretiere: Response ID: 0x7F: Negative Response, Sub
Function: 0x22 ??? Sollte doch 0x10 sein ??,
0x22 ist "Read Data By Identifier", also wurde dieser Service aufgerufen. Dass als Antwort 0x78 ("Request correctly received, but response is pending") kommen kann ist durchaus üblich, dann kommt die Antwort später.
Hallo zusammen,
ich habe mir vor 2 Jahren einen ELM 327 OBD Bluetooth Diagnose Stecker
und Adapterkabel für CAN H, für meinen Fiat Ducato 2017 gekauft und die
Software AlfaObd Demo auf meinem Handy installiert.
Alles funktionierte prima, hatte Zugriff auf alle Steuergeräte auf dem
CAN H und L Bus und konnte auf alle Service / Statusinformationen
zugreifen.
Bis auf den Body Computer, dort habe ich einmal den Status ausgelesen
und habe seitem keinen Zugriff mehr.
Mittlerweile habe ich auch PC Diagnose Software verschiedener Anbieter
und Versionen erprobt, immer mit dem gleichen Ergebnis, die
Kommunikation wird abgebrochen.
Ich habe mich mit dem Kommunikationsproblem auseinandergesetzt und den
Datenaustausch zwischen dem Handy und dem ELM 327 OBD Adapter
mitgeschnitten, mit folgendem Ergebnis:
Cr, >, Steuerzeichen aus dem EML 327 standard.
Nach Initialisierung der ELM 327 Parameter mit den AT Befehlen, wird die
"Diagnostic Session Control" SID 0x10 Subfunction 0x03 "Extendet
Diagnostic Session":
1003Cr an das Steuergerät gesendet.
In den meisten Fällen ist die Antwort des Diagnose Adapters: NO
DATACrCr> => keine Antwort des Steuergerätes innerhalb der Wartezeit
durch ATST19 = 100ms.
In wenigen Fällen Antwortet der Bodycomputer mit: 7F2278CrCr> das ich
wie folgt Interpretiere: Response ID: 0x7F: Negative Response, Sub
Function: 0x22 ??? Sollte doch 0x10 sein ??,
Laut meinen Unterlagen gibt es einen Negative Response code 0x22:
"Conditions Not Correct", jedoch keinen Code: 0x78.
Gemäß ISO 14229: 0x22: "conditionsNotCorrect" 0x78:
"requestCorrectlyReceived-ResponsePending"
Kann mir jemand helfen, die Antwort richtig zu Interpretieren, als auch
Möglichkeiten aufzuzeigen, das Steuergerät in einen diagnosefähigen
Zustand zu versetzen.
Mit besten Dank im voraus
Gruß Klaus
funktioniert die Software mit welcher zuerst getestet wurde auch nicht mehr?
Was hast du seitdem geändert? Evtl. ein anderes Kabel verwendet?
Hast du einen Abschlusswiderstand verwendet?
funktioniert die Software mit welcher zuerst getestet wurde auch nicht
mehr?
Antwort: Wurde durch ein Software update auf dem Handy vom Playstore überschrieben,
Alte Version nicht mehr feststellbar.
Die Kommunikation wird von der Android, als auch Windows software, auch anderer Hersteller,abgebrochen. (in Summe 3 verschiedene :-( )
was hast du seitdem geändert? Evtl. ein anderes Kabel verwendet?
Hast du einen Abschlusswiderstand verwendet?
Antwort:
Offensichtlich korrekt, kein Widerstand vorhanden, gleiche Kabel.....
Info: alle anderen Steuergeräte auf dem H und L CAN Bus lassen sich einwandfrei Diagnostizieren.
Hallo Dieter,
0x22 ist "Read Data By Identifier", also wurde dieser Service
aufgerufen. Dass als Antwort 0x78 ("Request correctly received, but
response is pending") kommen kann ist durchaus üblich, dann kommt die
Antwort später.
Die Antwort des Steuergerätes passt nicht in das UDS Schma einer Negativen Antwort:
Da die Funktion 0x10 aufgerufen wurde passt die Antwort 0x22 nicht gem.
UDS Standard, auch 0x78 ist kein NRC Code.
Bei so ziemlich jeder "Demo"- Diagnosesoftware bestehen Funktionseinschränkungen, besonders gern bei Sonderfunktionen.
Beschreibung im Playstore lesen, was bei der Demoversion alles gesperrt ist.
die Diagnose Funktionen haben in der Demo Version keine einschränkung.
Die verwendeten Windows Voll Versionen brechen die Kommunikation an der gleichen stelle ebenfalls ab. siehe EML 327 Protokolldatei
Die Antwort des Steuergerätes passt nicht in das UDS Schma einer
Negativen Antwort:
Da die Funktion 0x10 aufgerufen wurde passt die Antwort 0x22 nicht gem.
UDS Standard, auch 0x78 ist kein NRC Code.
Dann solltest Dir vielleicht mal die ISO 14229-1 ansehen, natürlich ist 0x78 ein möglicher Response Code. Wenn Du ein vernünftiges Log der CAN Kommunikation hättest könntest Du schauen was genau passiert. Der ELM_327_Protokolle.txt bringt nichts.
Wenn ich dich richtig verstehe, dann ist die Antwort des Diagnose Adapters: 7F2278 wie folgt zu Interpretieren:
0x7F: Negative Response
0x22 Service SID: Read Data By Identifier
0x78 NRC requestCorrectlyReceived-ResponsePending
Auch wenn zuvor eine "Diagnostic Session Control" 0x10 angefragt wird, kann die negative Antwort sich auf eine vorhergehende Anfrage "Read Data By Identifier" 0x22 beziehen.
Dann würde der Body Computer seit Dezember 2021 in diesem Problem stecken. Das das Fahrzeug inzischen 100te mal gestartet, verschlossen, Steuergeräte schlafen gelegt, von der Spannungsversorgung getrennt.....
Ich ging bisher davon aus, wenn nicht regelmäßig 0x3E "Tester Present" an das Steuergerät gesendet wird, die Diagnostic Session abgebrochen und die normale Default Session aktiviert wird.
Wie bekomme ich die Kommunikation wieder ans laufen ?
Ich verstehe das so, dass die Bedingungen für den Zugriff auf den BC nicht erfüllt sind. Evtl. hast du damals zufällig die richtigen Bedingungen hergestellt (z. B. ZV)?
Ist es nicht eher wahrscheinlich das das BCM zur Herstellung einer Diagnosesitzung einen Sicherheitscode erwartet und vorher alle Anfragen dieser Art ablehnt?
Wie schaut es denn mit einfachen Abfragen aus, wie z.B. Modulnamen/Typennummern?
Mit einem ELM Chipsatz bist Du schon relativ weit oben im OSI-Modell, evtl. wäre es erkenntnisreicher mit einem Lowlevel CAN Interface anzufangen, z.b. was SLCAN kompatibles (gibts auch für STM32 und Arduino), da hast Du mehr Kontrolle über die Frames und Antworten.
Ich verstehe das so, dass die Bedingungen für den Zugriff auf den BC
nicht erfüllt sind. Evtl. hast du damals zufällig die richtigen
Bedingungen hergestellt (z. B. ZV)?
Bei diesem Fahrzeug ist nur Vorraussetzung, das das der Zündschlüssel auf Betriebsstellung ist. Sonst sind keine Voraussetzungen zu erfüllen.
Ist es nicht eher wahrscheinlich das das BCM zur Herstellung einer
Diagnosesitzung einen Sicherheitscode erwartet und vorher alle Anfragen
dieser Art ablehnt?
Das CAN Bus System des Fahrzeug verfügt noch nicht über ein SGW Security-Gateway. Ein Sicherheitscode ist nur für das Schlüssel anlernen erforderlich.
Da ich bereits einmal Zugriff hatte, als auch über Protokollierte Diagnosesitzungen von Kollegen mit dem gleichen Body Computer verfüge,
weiss ich, wie der Soll Ablauf unter Idealbedingungen abläuft.
Mit einem ELM Chipsatz bist Du schon relativ weit oben im OSI-Modell,
evtl. wäre es erkenntnisreicher mit einem Lowlevel CAN Interface
anzufangen,
Eigentlich bin ich ja froh darüber, das ich auf diese Schicht Zugriff habe,
da ich dort mit vorhandener Soft und Harware und mit überschaubaren Programmieraufwand arbeiten kann.
Ich zweifle ja den Telegramminhalt nicht an, es gibt deshalb für mich noch keinen Grund tiefer in die Protokollschicht abzutauchen. Frage: was wird dann besser ?
Ich weis nur nicht, wie ich den Bodycomputer wieder in einen Diagnostizierbaren Zustand versetzen kann, ohne die gespeicherten Inhalte zu verlieren, weil ich davon noch keine Datensicherung habe.
Mit einem normalen ELM327 kommt man meines Wissens nicht überall dran.
Kann es sein das du ein "Adapter"-Kabel benötigst um Zugriff auf das entsprechende Modul zugreifen zu können? https://electronic-fuchs.de/c/produkte/multiecuscan/adapter
Ich hatte mal (Privat) was deaktivieren lassen und die dabei Verwendete Software (Multiecuscan) verlangte ein Adapter-Kabel dazwischen geschaltet um an das dazu entsprechende Steuergerät zu kommen.
https://multiecuscan.de/
Mit einem normalen ELM327 kommt man meines Wissens nicht überall dran.
Kann es sein das du ein "Adapter"-Kabel benötigst
"normalen ELM327 kommt man meines Wissens nicht überall dran"
:-) doch, wenn man weiss welche Services man Adressieren muß, als auch die Antwort richtig interpretieren.
"Kann es sein das du ein "Adapter"-Kabel benötigst" ja, ist im Einsatz und funktioniert
Nachtrag: Erfahrungswert aus Fiat-Autohaus. Ich weiß, klingt erst mal
nicht plausibel.
das ist schon plausibel, denn bei dem AU Vorgang wird wohl eine besondere "Diagnostic Session Control" aufgerufen, aber welche ist das ?
Darüber habe ich keine Unterlagen.
Der Hinweis mit der AU ist vollkommen berechtigt:
Wilde Vermutung: möglicherweise wurde der AU Diagnose Zustand durch abziehen des OB Steckers einfach unterbrochen und im Sinne des Steuergerätes nicht korrekt beendet. Denn das Fahrzeug war im Mai 2022 bei einer HU / AU,
erst danach habe ich gemerkt, das ich keinen Zugriff auf den Bodycomputer habe.
Das würde aber ja bedeuten das sich das BcM den Sessionzustand im
Flash/EEPROM ablegt anstelle im RAM. Ist das plausibel?
Ich habe bisher nur einmal sie Fahrzeugbatterie abgeklemmt, habe aber vorher eine Stützbatterie im Motorraum angeklemmt. Aus den mir vorliegenden Erfahrungsberichten nach abklemmen der Fahrzeugbatterie geht von Verlust von Datum / Uhrzeit bis zum verlust aller Settings, angelernten Werten und Statistik Daten. Das möchte ich ersteinmal vermeiden.
Ich habe bisher nur einmal sie Fahrzeugbatterie abgeklemmt, habe aber
vorher eine Stützbatterie im Motorraum angeklemmt.
Ja, dann kann das durchaus sein, auch wenn ich eigentlich erwarten würde das die Firmware den UDS Status "Tester Present" laufend abfragt und bei ausbleiben sämtliche Sessions beendet.
Ja, dann kann das durchaus sein, auch wenn ich eigentlich erwarten würde
das die Firmware den UDS Status "Tester Present" laufend abfragt und bei
ausbleiben sämtliche Sessions beendet.
So habe ich auch schon gedacht,aber dem ist wohl nicht so.
Wie kann ich die offensichtlich noch laufende Session abbrechen?
In den meisten Fällen ist die Antwort des Diagnose Adapters: NO DATACrCr> => keine Antwort des Steuergerätes innerhalb der Wartezeit durch ATSTFC = 1000ms.
In wenigen Fällen 0x7F2278
0x7F: Negative Response
0x22 Service SID: Read Data By Identifier
0x78 NRC requestCorrectlyReceived-ResponsePending
Ich bin noch auf der Suche nach informationen, was bei der AU Untersuchung über die Diagnose Steckdose so abgeht...
Wilde Vermutung: oder eine abgebrochene Diagnosesitzung über die K-line ?
Gibt es hierzu Erfahrungen oder Hinweise ?
Der Tip mit der AU ist absolut ziellos.
Bei der Abgasuntersuchung wird allein auf das Motorsteuergerät, bzw über das Gateway auf die Standard OBD Dienste zu gegriffen. Alle anderen Steuergeräte wie eben dein Bodycomputer werden ignoriert.
Wenn du beim Batteriewechsel mit Stützbatterie gearbeitet hast, wäre es noch ein Versuch das Steuergerät einzeln zu trennen. Dann wären halt nur die darin gespeicherten Daten weg. Wobei viele Werte eigentlich im EEPROM gespeichert sein müssten.
