SRS-lampen på en Leaf AZE0 begynte å blinke. Feilkode B0094, front crash zone sensor. Nettet er ganske samstemt her: airbag-koder på Nissan krever Consult eller Autel, fordi modulen sitter bak security access. Det stemmer bare ikke. Under viser jeg hvordan du leser og sletter airbag-DTC over CAN med en OVMS-modul til noen hundrelapper.

Advarsel: SRS er sikkerhetskritisk. Gjør du dette feil kan du utløse en airbag eller sette hele systemet ut av spill. Alt under er gjort på egen bil og eget ansvar. En aktiv crash-sensor-feil skal fikses fysisk, ikke bare slettes bort.

Utstyr

En OVMS-modul (ESP32 pluss LTE) i OBD-porten. To ting er nyttige her: Leaf-pluginet xnl for UDS/OBD mot vilkårlige ECU-er, og rå can tx for å sende hvilken som helst ramme på hvilken som helst buss. Har du en annen CAN-adapter som sender rå rammer (for eksempel SocketCAN med cansend), gjør den akkurat samme jobben.

CAN-topologi, Leaf AZE0 (2013-2016, 24 kWh)

can1 (EV-CAN): traksjonsbatteri, lader, motor. LBC ligger på 0x79B med rx 0x7BB.
can2 (Car-CAN): karosseriet. Det er her airbag-modulen henger.

Airbag-ECU-en har request 0x752 og response 0x772. Sånn er det på hele AZE0-plattformen.

Lese DTC

Bilen må være våken (tenning på, eller v.e.on=yes), ellers er airbag-modulen rett og slett strømløs.

xnl obd can2 device 752 772 2101   # DTC-status / datablokk
xnl obd can2 device 752 772 2103   # hendelseslogg

Nissan koder DTC-ene i to byte. Slik oversetter hex seg til verkstedkode:

0x8094  ->  B0094   front crash zone sensor
0xD266  ->  U1266   komm-feil, annen modul
0xD232  ->  U1232   komm-feil, annen modul
0xA820  ->  B2820   komm-feil, annen modul

Bare B0094 lå faktisk i airbag-modulen. U-kodene og B2820 var komm-koder som dukket opp i andre moduler under en full-bil-skann, rett og slett fordi de mistet kontakten med airbag-ECU-en midt i en transaksjon. Ikke selvstendige feil, bare støy.

Slette: alt feiler først

Slette-tjenesten er UDS 0x14 (ClearDiagnosticInformation). Hver eneste variant ble avvist:

can can2 tx standard 752 03 14 FF FF     -> 7F 14 12   subFunctionNotSupported
can can2 tx standard 752 03 14 FF 00     -> 7F 14 12
can can2 tx standard 752 03 14 00 00     -> 7F 14 12
can can2 tx standard 752 04 14 FF FF FF  -> (ingen svar)

Den UDS-formede ga ikke et pip tilbake. Ikke engang en avvisning. Og det er det som er interessant: en ECU som misliker en ramme svarer 7F. Total stillhet betyr derimot at rammen ble droppet allerede på buss-nivå.

Funnet: rammene var for korte

OVMS sin can tx padder ikke opp til 8 databyte. 752 04 14 FF FF FF går ut med DLC 6. Og Nissan-ECU-er forkaster stille alle classic-CAN-rammer med DLC forskjellig fra 8. Samtlige clear-forsøk var 6 til 7 byte og ble dermed kastet før modulen i det hele tatt rakk å lese innholdet. Det var altså aldri security access som var veggen. Det var rammelengden.

Isolasjonstest

Verifisert med TesterPresent (0x3E), padet til 8 byte:

can can2 tx standard 752 02 3E 00 FF FF FF FF FF  -> 772: 03 7F 3E 12

Der kom svaret. Rammen når fram så snart den er 8 byte, og ECU-en snakker.

Clear-sekvens som fungerer

Bilen våken, alt padet til 8 byte. Én kommando per linje, for OVMS-shellen tåler ikke ;:

# 1) Åpne diagnostikk-sesjon 0xC0
can can2 tx standard 752 02 10 C0 FF FF FF FF FF  -> 772: 50 C0   (sesjon åpnet)

# 2) ClearDiagnosticInformation, UDS-form, 3-byte gruppe 0xFFFFFF
can can2 tx standard 752 04 14 FF FF FF FF FF FF  -> 772: 01 54   (slettet)

54 er positivt svar på 0x14 (0x14 pluss 0x40).

Bare UDS-formen godtas: 04 14 FF FF FF (3-byte gruppe 0xFFFFFF). KWP-variantene med 2-byte gruppe gir 7F 14 12.
Ingen security access. Ingen 0x27 seed/key. Det slettes rett fra sesjon 0xC0.
Alt padet til 8 byte med FF. Dette er hele poenget, og verdt å gjenta.

Fang svarene med snifferen rundt kommandoene:

re start
# ... send kommandoene ...
re list     # trafikk på can2/772
re stop

Aktiv feil re-latcher

B0094 kom tilbake på under ett sekund etter 54. Sletting fjerner den lagrede oppføringen, men er feilen fortsatt fysisk til stede, setter ECU-en koden umiddelbart igjen. Clear-sekvensen er altså et verifiseringsverktøy, ikke en reparasjon: fiks maskinvaren, slett, og se om koden kommer tilbake. Gjør den det, er feilen fremdeles der.

B0094 fysisk

Plassering: inne i ladeluken i frontnesen, bak et deksel. Ikke bak nedre grill, som man kanskje skulle tro. Gul SRS-kontakt.
Delenr: Nissan 98581-3JA0A (Bosch). Retningsbestemt, med orienteringspil, og monteres samme vei som originalen. Støtfølsom, så vær forsiktig.

B0094 skiller mellom sensor og kabling i sub-tilstanden:

SENSOR FAIL / UNMATCH        -> intern sensorfeil, bytt sensor
DISCONNECT / COMM / GND-SHORT -> kabling/kontakt/jord, ikke bytt sensor

Den definitive testen: monter ny sensor, kjør clear-sekvensen, og se om B0094 holder seg borte. Kommer den tilbake, får du jakte på kabelstrekket fram til kontakten eller ACU-kontakten under midtkonsollen.

Oppsummert

«Airbag-koder krever Consult/Autel» er rett og slett feil på Leaf AZE0. Du leser og sletter airbag-DTC med rå CAN-tilgang på Car-CAN, helt uten security access. Det som stopper folk, er padding: Nissan forkaster stille rammer som ikke er 8 byte. Pad med FF, bruk 04 14 FF FF FF, og modulen svarer 54. Husk bare at slettingen er diagnose, ikke reparasjon.

Jobber du med kjøretøysdiagnostikk, CAN-reverse-engineering eller bil-mot-system-integrasjon? Ta kontakt.

Slik nullstilte jeg en airbag-feilkode på Nissan Leaf over CAN-bussen: uten Consult eller Autel