Reverse Engineering Bosch ME9/MED9: Anti-Lag System (ALS) programozása Assembly szinten

TIMESTAMP: 2026.02.24 | TARGET: BOSCH ME9 / MED9 | AUTHOR: APS TUNING

Az előző bejegyzésben bemutattam, hogyan lehet a gyári NVRAM tükör és a CAN-busz manipulálásával egy gyári ECU-t többprogramos (Map Switcher) képességekkel felruházni. Ha már megvan a stabil alap és a szabadon kapcsolható programhely (pl. a 3-as Map), itt az ideje, hogy igazi motorsport funkcióval töltsük meg: építsünk egy valódi, Lift-off Anti-Lag rendszert (ALS)!

Sokan azt hiszik, hogy a gyári ECU-n az ALS kimerül a "durrogós" (Burbles / Crackles) kipufogóban. Egy valódi Anti-Lag azonban nem csak hangot csinál: gázelvételkor nyitva tartja a fojtószelepet, masszív utógyújtást ad, és dúsítja a keveréket, hogy a turbinát forgásban tartsa. Nézzük meg, hogyan építhető be ez a komplex logika a Bosch ME9 architektúrájába.

Az Előkészületek: Memória-térkép (Memory Mapping)

Mielőtt egyetlen sor kódot is írnánk, elő kell készítenünk a terepet. Egy új, komplex funkció integrálásához három dologra van szükségünk a memóriában:

Szabad RAM terület az állapotoknak: Szükségünk van egy Condition:ALS flagre (pl. a 0x7FDXXX tartományban), ami megmondja a különböző rutinoknak, hogy az ALS éppen aktív-e.
Szabad Flash terület a kódnak: A patch-ek (Assembly rutinok) elhelyezéséhez keresnünk kell egy üres, 0xFF-ekkel teli blokkot a programtérben (Code Space).
Szabad Flash terület a kalibrációnak: Az ALS konstansokat (szögek, nyitási idők) inkább ne hardcode-oljuk az Assembly utasítások közé. Ehelyett logikusabb a Flash kalibrációs területén keresnünk üres bájtokat, és ezeket a memóriacímeket hivatkozzuk meg a kódunkban.

Miért kritikus ez az elrendezés? Mert magát az Assembly kódot (a patch-eket) csak BDM vagy Bench módban, a processzor direkt írásával tudjuk biztonságosan felvinni az ECU-ra. Viszont ha a paramétereket a kalibrációs területre (Data Flash) tesszük, akkor a fékpadi finomhangoláshoz vagy az utcai teszteléshez már elég egy egyszerű OBD flasher. Nem kell minden apró módosításnál kiszerelni az ECU-t; az ALS paraméterek pontosan úgy állíthatók WinOLS-ből, mint egy gyári előgyújtás térkép!

Az alap szükséges kalibrációs konstansaink

Az OBD-n keresztül hangolható ALS-ünkhöz a következő egyedi paramétereket hozzuk létre a kalibrációs térben:

ALS_wdks_w: A fojtószelep nyitási szöge gázelvételkor (Levegő).
ALS_zwout: Az ALS utógyújtás szög.
ALS_cut_treshold: A gyújtásvágás (Hard Cut) agresszivitásának százalékos értéke.
ALS_tef_w (vagy te_w): A befecskendezési idő gázelvételkor (Üzemanyag).

⚠ VIGYÁZZ! – Hőmérsékleti védelem: Az alábbi implementáció a koncepció-bemutatás kedvéért az aktivációs feltételeket a minimálisra szűkíti (fékpedál, RPM, gázpedál, map selector). Éles alkalmazásban kötelező egy hűtőfolyadék hőmérséklet ellenőrzés (tmot > 70°C minimum) az aktivációs láncba! Hideg motoron futó ALS = repedt leömlő, repedt turbó öntvényház és deformált kipufogó szelepek. A tmot RAM változót erősen ajánlott hozzáadni feltételként, ha a felhasználó nincs tisztában azzal, hogy hideg motornál nem kapcsolunk ALS-t.

Nézzük meg, hogyan vesszük át az irányítást ezen a három ponton a gyári szoftver felett!

1. LEVEGŐ: A Fojtószelep kitámasztása (wdks_w)

Gázelvételkor a gyári nyomatékmodell azonnal becsukná a pillangószelepet. Ezt a folyamatot a végső hardveres kimenet előtt patcheljük meg. Ha a Map Switcherünk a 3-as programon áll, a fordulatszám megfelelő (pl. > 1500 RPM), és a gázpedált felengedik, a kódunk aktiválja a Condition:ALS RAM flaget. Ezzel egyidőben felülírjuk a gyári fojtószelep-pozíciót a saját kalibrációs értékünkkel (pl. 15-20%-os nyitás).
Biztonsági funkció: Ha a sofőr hozzáér a fékpedálhoz, az ALS azonnal kikapcsol, visszaadva a fékrásegítő vákuumot és a motorféket.

WDKS_W PATCH (LEVEGŐ VEZÉRLÉS)

; BELÉPÉS: r11 = gyári wdks_w
; KILÉPÉS: r11 = gyári vagy ALS wdks_w

als_wdks:

li      r0, 0x0
stb     r0, RAM_Condition_ALS(r13)

lbz     r12, RAM_condition_brake_switch(r13)
cmpwi   r12, 1
beq     als_exit

lbz     r12, RAM_map_selector(r13)
cmpwi   r12, 3
bne     als_exit

lhz     r12, RAM_nmot(r13)
cmpwi   r12, 0x1770
ble     als_exit

lhz     r12, RAM_wped_w(r13)
cmplwi  r12, 0x147A
bge     als_exit

li      r0, 1
stb     r0, RAM_Condition_ALS(r13)

lis     r11, kalibracio_ALS_wdks_w@h
ori     r11, r11, kalibracio_ALS_wdks_w@l
lhz     r11, 0(r11)

als_exit:

sth     r11, RAM_wdks_w(r13)

b       vissza_a_gyari_kodhoz

2. SZIKRA (Part 1): Gyújtáskésleltetés és a Biztonsági Rendszer (zwout)

Ha a Condition:ALS flag aktív (tehát a fojtószelep már nyitva van), egy rutinunk átveszi a gyújtásvezérlést. A gyári előgyújtás helyett betöltjük az ALS_zwout kalibrációs értékét (ami tipikusan jelentős ATDC – felső holtpont utáni – gyújtáskésleltetés), amely a kipufogócsatornában történő égést és a turbina folyamatos gyorsítását segíti elő.

Itt azonban egy kritikus architekturális korlátba ütközünk: a Bosch Funktionsüberwachung (funkcionális biztonsági felügyelet) rendszerébe. A Bosch ME9/MED9 vezérlők a gyújtásszöget redundáns módon tárolják: a tényleges kimeneti érték (zwout) mellett annak bitenkénti egyes komplemensét (zwoutcpl) is eltárolják. Ez a Doppelablageprüfung mechanizmus, amely a memóriasérülések és illegális módosítások detektálására szolgál.

A biztonsági monitor minden ciklusban ellenőrzi, hogy a két érték konzisztens-e (zwoutcpl == NOT zwout). Ha inkonzisztenciát észlel, a gyújtásszög érvénytelennek minősül a nyomatékmodell számára, és a Funktionsüberwachung torque intervention-t indíthat (pl. gyújtáskésleltetés, fojtószelep zárás vagy szélsőséges esetben üzemanyag-lekapcsolás).

A megoldás kulcsa az, hogy nem kerüljük meg a gyári logikát, hanem integrálódunk bele. A patch-ünk csak a gyújtásszög regiszter tartalmát módosítja, majd közvetlenül a gyári mentési és komplemensképző (NOR) művelet előtt tér vissza a fő végrehajtási ágba. Ennek eredményeként a redundáns értékpár (zwout és zwoutcpl) továbbra is konzisztens marad, így a biztonsági rendszer teljesen legitim, gyári eredetű módosításként érzékeli az ALS által beállított gyújtásszöget.

Ez a módszer biztosítja, hogy az ALS működése teljes mértékben kompatibilis maradjon a Bosch torque monitoring és biztonsági architektúrájával, elkerülve bármilyen watchdog fault vagy torque intervention aktiválását.

ZWOUT PATCH – Doppelablageprüfung-kompatibilis gyújtáskésleltetés

; BELÉPÉS: r31 = gyári zwout

ALS_zwout:

lbz     r10, RAM_map_selector(r13)
cmpwi   r10, 3
bne     normal_zwout

lbz     r10, RAM_Condition_ALS(r13)
cmpwi   r10, 0
beq     normal_zwout

lis     r31, kalibracio_als_ign_angle@h
ori     r31, r31, kalibracio_als_ign_angle@l
lbz     r31, 0(r31)

extsb   r31, r31                 ; Sign extension: ALS szög negatív (ATDC)

normal_zwout:

stb     r31, RAM_zwout(r13)       ; Gyári VAGY ALS gyújtásszög mentése

nor     r11, r31, r31            ; Komplemens képzés (NOR önmagával = NOT)

stb     r11, RAM_zwoutcpl(r13)   ; zwoutcpl = ~zwout → Doppelablage OK!

b       vissza_a_gyari_kodhoz

2. SZIKRA (Part 2): Az LFSR Gyújtásvágás (Hard Cut)

Egy profi ALS nem csak késlelteti a szikrát, hanem véletlenszerűen "elvágja" (kihagyatja) a hengerek gyújtását, hogy kímélje a szelepeket és WRC-s hangzása legyen. Mivel az ECU-ban nincs "dobókocka" (hardveres véletlenszám-generátor), ezt szoftveresen, egy LFSR (Linear Feedback Shift Register) algoritmussal kell implementálnunk a trafók töltési idejét vezérlő (dwell_time) rutinban.

A választott visszacsatolási polinom: x⁸ + x⁶ + x⁵ + x⁴ + 1. Ez egy primitív polinom GF(2) felett, ami azt jelenti, hogy a generált szekvencia maximális hosszúságú: a 8 bites LFSR mind a 255 lehetséges nem-nulla állapotot bejárja, mielőtt ismétlődne. Ez kritikus az egyenletes hengerenkénti vágáseloszlás miatt – egy rövidebb periódusú polinom bizonyos hengereket szisztematikusan előnyben részesítene, ami egyenetlen hőterheléshez vezetne.

Nézzük az idevágó Assembly kódot:

LFSR VÉLETLENSZÁM GENERÁTOR ÉS THRESHOLD

; Load seed
lbz     r9, RAM_als_core(r13)

; 8-bit maximal LFSR feedback polynomial: x⁸+x⁶+x⁵+x⁴+1
; Tap pozíciók: bit 7, 5, 4, 3 (PPC 32-bit: bit 24, 26, 27, 28)
; A rlwinm MB=ME=7 rövidítés → a feedback bit mindig bit 7-be (MSB) kerül,
; az rlwimi végén pedig bit 24-be (PPC 32-bit MSB a byte-on belül) írjuk.

rlwinm  r10, r9, 31, 7, 7       ; r10 = bit 7 (tap: x⁸)
rlwinm  r11, r9, 29, 7, 7       ; r11 = bit 5 (tap: x⁶)
xor     r10, r10, r11

rlwinm  r11, r9, 28, 7, 7       ; r11 = bit 4 (tap: x⁵)
xor     r10, r10, r11

rlwinm  r11, r9, 27, 7, 7       ; r11 = bit 3 (tap: x⁴)
xor     r10, r10, r11

andi.   r10, r10, 1             ; Feedback bit izolálása

rlwinm  r9, r9, 31, 1, 31      ; Regiszter jobbra shift (>> 1)

rlwimi  r9, r10, 7, 24, 24    ; Feedback bit beillesztése MSB-be (bit 24 = byte MSB)

stb     r9, RAM_als_core(r13)   ; Új seed mentése

; === Threshold összehasonlítás ===
lis     r5, kalibracio_ALS_cut_treshold@h
ori     r5, r5, kalibracio_ALS_cut_treshold@l
lbz     r5, 0(r5)

cmplw   r9, r5                 ; LFSR output vs. threshold
bge     exit                    ; Ha LFSR >= threshold → normál gyújtás

li      r3, 0
sth     r3, RAM_dwell_time(r13) ; Dwell = 0 → NINCS SZIKRA ezen a hengeren!

exit:

b       vissza_a_gyari_kodhoz

Hogyan működik? Az LFSR rutin generál egy uniform pszeudo-random számot 0 és 255 között. Ezt a random számot hasonlítja össze a rutin a kalibrációs területen lévő ALS_cut_treshold értékével. Ez az igazi zsenialitása a kódnak: a Threshold paraméterrel WinOLS-ből százalékosan tudjuk hangolni az ALS agresszivitását!

Ha a threshold 0x80 (128), akkor ~50%-os az esélye a gyújtásvágásnak.
Ha felemeljük 0xCC-re (204), akkor ~80%-os a vágás – a motor iszonyatosan agresszívan fog visszadurrogni.

ℹ Megjegyzés 5 hengeres motorokhoz (Volvo I5T): A Volvo öthengeres gyújtási sorrendje (1-2-4-5-3) miatt a dwell_time patch hengerenként aszimmetrikusan hat: az LFSR szekvencia nem követi a gyújtási sorrendet, így egyes hengerek statisztikailag több vágást kaphatnak egy adott periódusban, mint mások. 255 ciklus alatt (az LFSR teljes periódusa) ez kiegyenlítődik, de rövid ALS burst-öknél (1-2 másodperc gázelengedés) az eloszlás nem garantáltan egyenletes. Éles alkalmazásban érdemes monitorozni a kipufogó hőmérsékleteket hengerenként (EGT szondákkal), hogy az aszimmetria ne okozzon lokális túlmelegedést.

3. ÜZEMANYAG: A Tolóüzemi Elzárás (Schubabschaltung) kijátszása (tef_w)

Hiába van levegőnk és szikránk, ha nincs üzemanyag, ami berobbanjon a kipufogóban. Gázelvételkor a gyári rendszer azonnal elzárja az injektorokat. Ezt a tef_w (MED9 esetében te_w – effektív befecskendezési idő) felülírásával kerüljük meg.

A rutin ismét ellenőrzi a Condition:ALS flaget. Ha nem aktív, egyszerűen ráejti a futást a gyári érték mentésére. Ha aktív, a gyári 0 ms helyett a mi ALS_tef_w kalibrációs konstansunkat tölti be a befecskendezők végső hardveres regiszterébe. Mivel ez is a kalibrációs területen van, az OBD flasher segítségével tökéletesen belőhetjük azt a milliszekundum értéket, ami a kívánt turbónyomást (Boost) generálja álló gázpedálnál.

TEF_W PATCH (ÜZEMANYAG VEZÉRLÉS)

; BELÉPÉS: r12 = gyári tef_w

ALS_fuel_enrich:

lbz     r10, RAM_map_selector(r13)
cmpwi   r10, 3
bne     fuel_exit

lbz     r10, RAM_Condition_ALS(r13)
cmpwi   r10, 0
beq     fuel_exit

lis     r12, kalibracio_ALS_tef_w@h
ori     r12, r12, kalibracio_ALS_tef_w@l
lhz     r12, 0(r12)

fuel_exit:

sth     r12, RAM_tef_w(r13)

b       vissza_a_gyari_kodhoz

Ezzel a három Assembly patch-csel a gyári Bosch ME9/MED9 vezérlőt egy majdnem professzionális motorsport ECU-vá alakítottuk. A rendszer determinisztikus, biztonságos (Watchdog és fékpedál védelemmel ellátott), és ami a legfontosabb: a kalibrációs memóriatérkép okos használatával utólagosan, OBD-n keresztül finomhangolható.

← VISSZA A LOGOKHOZ