2017. március 30., csütörtök

ECU #7

Majdnem úgy kezdtem ezt a bevezetőt, hogy a mai posztban alig lesz jó hír, de az utolsó pillanatban mégis csak mellém szegődött a szerencse, így jut egy az elejére és a végére is. Sajnos az utóbbi időben ismét kevesebb volt a szabadidőm ezért jóval kevesebbet tudtam foglalkozni az autóval, de továbbra is igyekszem.

Az első jó hír az, hogy a 1315a térkép kiírása mégis jelentős változást hozott. A korábbi posztban szereplő bizonytalanság annak volt köszönhető, hogy 50-100km-t kellett menni az autóval mire ténylegesen beállt minden. Azóta már több 100km-en vagyok túl, a hatás pedig tartós és egyértelműen érződik. Az azóta történt néhány logolás alkalmával pedig egyszer sem volt EGR aktivitás. Főleg az alacsony-közepes fordulatszám tartományokban hozott javulást. 2000-es fordulat környékéről sokkal jobban megindul, mint korábban. Ez egyezik azzal a tartománnyal, ahol a kiírás után a long term fuel trim értéke 0-ra változott. Időközben csináltam egy reset-et (áramtalanítás) is, de ez után is ugyanúgy kellett várni valamennyit a végleges hatáshoz, további javulás pedig nem jelentkezett.
Az OP-COM-ban van lehetőség resetelni a O2 loop értékeket. A reset előtt kiírja az aktuális állapotot, ez a korábbi -5%-ról -2%-ra esett vissza.

Nem tudom ez pontosan mit jelent, mert szerintem nem egy állandó értékkel kellene korrigálnia az egész tartományban, de ha a korrekció 0-hoz közelít az valószínűleg jó. Mivel szeretem tudni mennyi az annyi, mértem egy gyorsulást is. A 0-100-nak itt nem lett volna sok értelme, ezért csak a 2-esben kigyorsítást néztem. Javult a Referencia #3 -hoz képest, de hogy mennyit, azt egyelőre nem árulom el. Majd a Referencia #4 -ből kiderül.
A végleges cél azonban nem csak a működés kiiktatása, hanem a szelep teljes eltávolítása lenne. Lehúztam az EGR szelep csatiját, de a második indításkor már villant is a check engine. EGR szelep alacsony feszültség hibát dobott. A szelep helyén tartásával még talán együtt tudnék élni, de van egy aggodalmam, miszerint ha nem teljeskörűen van kikapcsolva, akkor benne maradhat például egy gyújtás vagy egyéb nem kívánatos korrekció. Szóval jelentős az előrelépés, de ez csak részeredmény.

100
Kíváncsiságból tankoltam 100-as oktánszámú benzint. Elsősorban érezhető menetdinamika változásra és a kopogási hajlam változására voltam kíváncsi. Menetdinamika terén gyakorlatilag semmi pozitívumot nem éreztem. A kopogási hajlam kiderítéséhez futottam egy tesztkört. Ez kicsit más volt, mint a korábbiak, mivel viszonylag hosszan mentem egyenletes tempóval, kevesebb alacsony fordulatos kigyorsítás volt, így az eredmény közvetlen nem összevethető a korábbiakkal. Ennek ellenére egyértelműen kedvezőbb, még ha nem is tünteti el teljesen a jelenséget. Hosszabb távon egyelőre nem tervezek 100-as benzint használni.

KESS, MPPS, OP-COM
A két kütyüt azóta is felváltva használom (már amennyit az utóbbi időben használtam), és kiderült egy újabb nem elhanyagolható jellemzőjük. Míg az MPPS és az OP-COM jelentős terhelést jelent a CPU-nak, addig a KESS gyakorlatilag semmit. Ez mindkettőnél az írásra és az olvasásra is igaz. Utóbbival így jóval hosszabb lehet a laptop akkujának üzemideje. Ha nincs a közelben hálózati csatlakozási lehetőség, akkor fontos lehet, főleg ha utána még logolni is kell. Mindkét szoftvert virtuális gépben használom, ezért próbáltam korlátozni a CPU-t (execution cap), de csak annyit értem el, hogy lassabb lett az írás/olvasás, illetve az élő adat mintavételi gyakorisága. Jelenleg nincs módom rá, hogy kipróbáljam, de elképzelhető, hogy egy erősebb géppel pontosabb adatokat is ki lehetne nyerni az OP-COM-ból.
Ezen felül a KESS-nél állandó jelenség maradt, hogy olvasás után le kell venni az akkusarut, különben nem reagál az ECU semmire. Szerencsére írás után ilyenre nincs szükség. Az MPPS-nél ezzel szemben csak a már korábban említett 4 hibakódot dobja.
KESS-nél nem szeretem, hogy nehézkes az összeállítás, ezért ha lehet inkább az egyetlen kábel MPPS-t használom. Persze a checksum számítási képesség továbbra is nélkülözhetetlenné teszi a KESS-t.

Checksum
Az ellenőrző összeg számításának módja nagyobb szabadságot adna írásnál, és furdalta is az oldalam a kíváncsiság, ezért próbálkoztam egy keveset (sokat) a megfejtésével.

Ahhoz, hogy az ellenőrző összeget előre lehessen számítani és előre be lehessen írni a programba 3 dolgot kell ismerni:
- az érték (eredmény) helyét,
- a számítás módját, azaz az algoritmust,
- és azt a tartományt, amire az algoritmust alkalmazza.

Az eredmény helye, mint ahogy azt korábban írtam meglett. A másik kettő kiderítése azonban számos kísérlet ellene sem sikerült. Találtam egy jó oldalt  CRC visszafejtés témában, amiben szerepel egy viszonylag könnyen érthető leírás a CRC-ről általában. Utóbbiban a 3-dik fejezetig jutottam (azaz éppen csak elkezdtem), de utána úgy döntöttem, hogy az időmet inkább olyan dolgokra fordítom, amiből nagyobb hasznom származik. A kísérletezés már korábban kezdődött, és párhuzamosan folyt az egyéb tevékenységek mellett, de egyre több és több időmet vette igénybe. Leírom pontosan milyen módszerekkel is próbálkoztam:

- Jacksum-al az összes 16 bites értéket adó algoritmust végigszámoltattam néhány programra.
- A binárist különböző jellegzetes helyeken elvágtam (pl: 0x8002 (32780) után) és csak a fennmaradó részre végeztem a számítást.
- Az elvágást majdnem sikerült egyszerűen automatizálni a "for((i=32780;i<=33070;i+=1)); do dd bs=1 skip=$i if=./12210453EB.Bin 2>/dev/null | jacksum -a crc16 -E hex; done" paranccsal, de a pipe valahogy nem adja át jól az értéket a jacksum-nak (1024Kb lesz 512Kb helyett), ezért használhatatlan.
- Ezért írtam python szkriptet, ami PyCRC-t használva megvalósítja a fenti automatizmust.
- A fenti python alapot felhasználva készítettem egy újabb szkriptet, ami a bájtokat egyesével összeadja, a 16 bites felső limitnél pedig körbeforgatja. Ezt természetesen különböző tartományokban. Arra később jöttem rá, hogy ez a számítási módszer nem lehet helyes, mert a tesztfájlban egy viszonylag kis mértékű módosításra is jelentősen változik az ellenőrző összeg értéke.
- Ezután lépett életbe a fenti cikk 3-dik fejezetében is szerelpő osztó keresése. Továbbra is különböző tartományokra. Egy tesztfájlon nézve itt már a nagy számok törvénye értelmében volt pozitív eredmény, de a második tesztfájllal összevetve mindig kiderült, hogy helytelen.
- Aztán elkezdtem forgatni az értéket (az összes permutációjával, pl: 1234 -> 3412), és ha jól rémlik még offset-el is bonyolítottam, de ebben már nem vagyok biztos.

Talán mondanom sem kell, de ezeknek a műveletekek elég nagy a számítási igényük, így nem volt elég csak kitalálni mit is szeretnék, majd megírni a szkriptet, de hosszú-hosszú órákat is várni kellett az eredményekre. Bár próbáltam mindenre odafigyelni, annyi különböző módszert vizsgáltam, hogy 1-2 hiba így is becsúszhatott, és az is lehet, hogy túlléptem a helyes megoldáson. Nem tartom valószínűnek, de elképzelhető. Ezek után egyelőre felhagyok a további próbálkozással.

FTVV
A tankszellőztetés térkép megtalálása könnyű prédának látszott, de egyelőre ez is kifogott rajtam. Az élő adatok közt ugyanolyan százalékos értéket produkál, mint az EGR. Könnyű hasonló táblázatba rendezni. Az egyik mért adathalmazból egy gyönyörű térképet is sikerült kreálni. Azonban két baj van vele. Az egyik, hogy a táblázatomban nincs hasonló térkép, még akkor sem, ha teszem azt felcserélem a tengelyeket.

09391263 BA
[[   0   20   28   36   44   52   60   68   76   84   92  100]
 [ 800    8    5    0    0    0    0    0 1111 1111 1111 1111]
 [1200    1    2    0    0    0    9   52 1111 1111 1111 1111]
 [1600    3    3   14   10   10   62   73   90   98  100 1111]
 [2000    9   19   32   54   72   88   98  100  100  100 1111]
 [2400   28   44   56   70   85   94  100   99  100  100 1111]
 [2800   31   51   68   88   97  100   99  100  100  100 1111]
 [3200   38   64   86   98  100  100  100  100  100  100 1111]
 [3600   36  100   97  100  100 1111 1111  100  100  100 1111]
 [4000   21   84  100  100  100  100  100  100  100  100 1111]
 [4400   79 1111 1111 1111 1111 1111 1111  100  100  100 1111]
 [4800 1111 1111 1111 1111 1111 1111 1111 1111 1111  100 1111]
 [5200 1111 1111 1111 1111 1111 1111 1111 1111 1111  100 1111]
 [5600 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111]
 [6000 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111]
 [6400 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111]] Fuel Tank Ventilation Valve


A másik, hogy ha másik logot nézek, akkor pontosan ugyanerre a lekérdezésre ez az eredmény: 
09391263 BA
[[   0   20   28   36   44   52   60   68   76   84   92  100]
 [ 800    2    1    0    0 1111    0 1111 1111 1111 1111 1111]
 [1200    1    3    0    0    0    0   33 1111 1111 1111 1111]
 [1600    1    1    3    3    9   13   22   39   39    0 1111]
 [2000    2    4    8   22   23    7   14   38   37   32 1111]
 [2400   19   31   31   29   27   34   61   48   17    2 1111]
 [2800   23   38   37   52   66   44   28   25   47   27 1111]
 [3200    8   27   61  100   72    0   47   34   14   28 1111]
 [3600    0 1111 1111    0 1111    0 1111 1111   20   40 1111]
 [4000    0 1111 1111 1111 1111 1111 1111    0    0   42 1111]
 [4400 1111   50  100 1111 1111 1111  100 1111    0   25 1111]
 [4800 1111 1111 1111 1111 1111 1111 1111 1111   50    0 1111]
 [5200 1111 1111 1111 1111 1111 1111 1111 1111  100  100 1111]
 [5600 1111 1111 1111 1111 1111 1111 1111 1111  100 1111 1111]
 [6000 1111 1111 1111 1111 1111 1111 1111  100  100 1111 1111]
 [6400 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111]] Fuel Tank Ventilation Valve


Vagy egy még másikra ez:
09391263 BA
[[   0   20   28   36   44   52   60   68   76   84   92  100]
 [ 800    3    3 1111    0 1111 1111 1111 1111 1111 1111 1111]
 [1200    0    4    0    0    4    9   69   80   93 1111 1111]
 [1600    7   18   27   17   44   70   78   88  100  100 1111]
 [2000   17   18   23   46   72   88   91   95   96   92 1111]
 [2400   14   28   36   47   62   55   67   79   79   83 1111]
 [2800   20   30   37   57 1111   41   74   75   72   81 1111]
 [3200    0 1111 1111 1111 1111 1111 1111   45  100   88 1111]
 [3600    0   67 1111 1111  100 1111 1111 1111   74   91 1111]
 [4000   82 1111 1111 1111 1111   82 1111 1111 1111   81 1111]
 [4400 1111   37 1111 1111 1111 1111 1111 1111 1111   78 1111]
 [4800 1111 1111 1111 1111 1111 1111 1111 1111 1111   78 1111]
 [5200 1111 1111 1111   83 1111 1111 1111 1111   74   81 1111]
 [5600 1111 1111 1111 1111 1111 1111 1111 1111 1111   79 1111]
 [6000 1111 1111 1111 1111 1111 1111 1111 1111 1111   83 1111]
 [6400 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111]] Fuel Tank Ventilation Valve


Köszönő viszonyban sincsenek egymással. Megpróbáltam hát más tengelyértékekkel nézni. Kiegészítettem egy korábbi grafikont, és valóban mintha a pedál pozíció jobban illeszkedne, mint a MAP értéke.
De nem. Ugyanabba a két hibába futok bele. A pedál után próbáltam sebesség, levegő hőmérséklet, vízhőmérséklet alapján is, különböző határértékekkel, de vagy nem hasonlítanak a mérések eredményei vagy nincs ilyen a táblázatban. Annyira ezt sem tartottam fontosnak, így egy időre ezt is félretettem. Innen három olyan irányba mozdultam tovább, ami segíthet majd ezt és a hasonló problémákat is megoldani:
    - meg kell tudni milyen tengelyértékek tartoznak az egyes térképekhez, azzal jóval könnyebb lenne azok azonosítása,
    - ki kell egészíteni a táblázatot, hátha kimaradt belőle valami,
    - tovább kell kutatni pulikus információk után (pl: pontosan hogyan is működik a szellőztető szelep).

Tengelyértékek
Az elmélet szerint valahol lennie kell egy összerendelésnek, ami a térképekben szereplő értékeknek értelmet ad. A nyilvánvaló lehetőség, miszerint minden térkép kezdeti címe, azaz a térkép első bájtjának programban elfoglalt pozíciója alapján könnyű szerrel fellelhető lesz, hamar, néhány manuális keresés után kudarcba fulladt. Elég sok térképre vonatkozóan van 1-2, néhány esetben több olyan érték a programban, ami lehetne a kezdőértékük, de közel sem mindre, ráadásul ezen értékek körül sincs olyan jellegzetes ismétlődő minta, ami arra engedne következtetni, hogy tengely definícióval állunk szemben. Könnyen jött a következő ötlet. Lehetséges, hogy a pozíció nem a program elejétől, hanem egy másik résztől számítódik (pl: 0x8000-től). Így például a 1317a térképre nem "828F"-ként, hanem csak "028F"-ként hivatkozna, azaz lenne egy offset. Ismét nekiálltam automatizálni. Kiválasztottam néhány térképet és azokra futtattam a számítást. Attól függően, hogy melyik térképeket választottam, nagyjából 10-15 térkép egyidejű keresése után már nem nem talált közös offset-et. Itt is próbálkoztam a permutációkkal, de az sem hozott eredményt. Talán mégsincs ilyen összerendelés, vagy csak nem az összes térképre, vagy nem általános a módszer, vagy ismét csak elnéztem valamit. Míg a checksum-nál úgy éreztem a végetlenségig próbálkozhatnék a különböző eljárásokkal, itt egyszerűen kifogytam az öteletekből.

Táblázat
Unalmas perceimben (nem) újra és újra előszedtem a WinOLS-t és nézegettem a számokat. Sikerült még néhány új térképet kifacsarni a az adathalomból. Most olyan 120 körül járhatok. Pontosan nem tudom, mert nem álltam neki megszámolni, a WinOLS-ben viszont néhány nem térképet is nyilvántartok, ami torzítja az ottani adatokat. Ezen felül pedig elkezdtem feldolgozni a maradék rendelkezésre álló programjaimat. A 12590370 YS volt az első, és miután rájöttem, hogy a 12594688 AH alig különbözik az előbbitől, már ezzel is készen voltam. A kettő közti különbség egyetlen nyilvántartott térképet sem érint.
Egyébként kezd bennem élni a gyanú, hogy az ECU jelölése nem sokat jelent a rajta lévő program szempontjából. Legfeljebb annyit, hogy melyik az a kezdeti programverzió, amit a gyártáskor rátöltöttek. És csak a tényleges programban szereplő verziószám számít.
Előállt a táblázat második verziója.

PCMHacking.net
A tankszellőzés működésének részleteivel kapcsolatban ugyan nem találtam sokmindent, de ráakadtam a címben szereplő oldalra, ahol rengeteg DELCO ECU-val kapcsolatos információ van. Számomra közvetlenül felhasználható segítséget most sem találtam, de olyat mint ez a teljesen visszafejtett kommentekkel ellátott program igen. Ilyenből van jónéhány és rendkívül hasznosnak bizonyulnak, mert sokkal jobban érthetővé teszi az ECU-k belső logikáját. Nem mellesleg megjelenik benne egy rakás térkép, aminek létezéséről eddig foglalmam sem volt. Amiről meg igen, annak a jellegzetességeiről tudtam meg többet.

Disassemble
Kacérkodtam a disassemble gondolatával, mégha ez csak valószínűleg részleges eredményeket hozna is, de a fenti fájl inkább csak elvette a kedvem, minthogy bátorított volna. Monumentális erőfeszítés lenne egy hasonló létrehozása. Az a PCMHacking alapján nagyjából körvonalazódott, hogy a GMPT-15 Motorola chip-et használ, amit a legnépszerűbb IDA Pro Free változata nem tud lekezelni. Találtam viszont egy másik progit (68kd), amivel sikerült valamilyen assembly kódot varázsolnom, de sokat nem foglalkoztam vele, az értelmezéséhez sokat kellene még tanulnom.

12594688 AH / 12594690

A számos sikertelenség után pedig itt a jó hír a végére. Miután a lehúzott EGR szelep csati hibát dobott, arra gondoltam, hogy magát a működést valószínűleg egyetlen kapcsoló határozza meg. Ez valószínűleg csak egyetlen bájt, amit teljes visszafejtés nélkül gyakorlatilag lehetetlen megtalálni. Azt már korábban ellenőriztem, hogy a 1315a térkép az összes rendelkezésmre álló programban tartamaz adatot, így túl sokat nem is foglalkoztam velük. De aztán az előző posztban egy komment hatására (ezúttal is köszönet) egymáshoz illesztettem a kirakó részleteit. Simán átbillenthették bármelyik programban a kapcsolót anélkül is, hogy a működést leíró térképekhez hozzányúltak volna. Azt pedig tudjuk, hogy a későbbi évjáratokban már a szakszervízekben is inkább kiírták az EGR-t hiba esetén, sőt volt olyan változat, ami a gyárból is EGR nélkül érkezett. Tehát, ha van ilyen programom, akkor az utolsók közül kell legyen valamelyik. A legutolsó pedig nálam a 12594688 AH a 12594690 szoftver verzióval.
Feltöltöttem és mértem egyet, úgy hogy a térképeket érintetlenül hagytam. A tesztkörön OP-COM-al figyeltem az eseményeket, és csodák csodája az EGR aktivitás nem mozdult a 0-ról. Érdekes, hogy ennek elenére már gyújtáson és persze menet közben is jelzi az EGR szelepre jutó feszültségét (1,14V). A tesztkör után ismét lehúztam a csatit és mentem egy kört. Leállítottam és megint mentem. Majd indítottam mégegyet. És nincs hibakód. Azóta összesen ~20-30 km-t mehettem, és annyi biztos, hogy a korábbi kiírás után jelentkező dinamikajavulás itt is megmaradt. Az alapjárat ebben is az eredeti alá megy, és talán egy kicsit a korábban próbált alá is.

Ismét sok a teendő. Ki kell elemezni az új adatokat és valamit kezdeni kell végre ezzel az alapjárattal.

Nincsenek megjegyzések:

Megjegyzés küldése