e92 emulator and tuning assistant

[enslaved87]

Quick update.

I've had limited time recently to work on these projects with work. That said, I have made some substantial progress.

First - my initial approach was simply too broad of a brush and a bit naive, quite frankly. The majority of my time has been spent on completing and polishing up the e92 emulator, which ultimately serves as the backbone to this program (TorqueModeler). I say naive, because I did not fully grasp the complexity of the FULL ecu behavior and moreover, the differences between all the OS's - some are quite dramatic. I have since regrouped my thoughts and tackled this from a structured attack angle. I've got the foundation of the emulator built with two primary derivitives (early/late, or e92/e92A) followed by every single OS I have on disk (~44 gas so far) full RE'd so they load and behave like they do on real silicon. Emulator scaffolding is built around the Unicorn PPC32 cpu emulator engine.

The bulk of the effort has really been identifying and characterizing all the sub components and callers within the ecm which has been quite the rabbit hole. But - I'm glad I went through the exercise, because it has uncovered a tremendous wealth of knowledge and a stand alone emulator that can be treated EXACTLY like a real live ecu without any tangible risk. Has really turned into a standalone product all by itsself.

Current capabilities:

Boot a real FULLREAD, identify VIN/OS, drive analog dests, watch the scheduler and KOEO GMLAN, and rehearse the two-stage write (process_uds utilities, then SCPB-W1) against metal-proven dests.

What’s working and proven on silicon so far:

• CPU / OS boot — Scheduler reaches phase 3, idle is real WFI, tick climbs.
• INTC — IACKR/EOIR CPR stacking. FIFO5 EOQF (vec 128) and eMIOS FLAG (vec 203) both fire.
• C90FL — flash model with PEG.
• eTPU — CDCR STS hold so the OS CDC poll is real Unicorn time (not an instant self-clear). SPRAM/CDC path runs.
• FlexCAN A+B — 0x7E0/0x7E8 diagnostic door at the 0x9000 lander. SOFTRST/HALT modeled so firmware can actually TX. Dual-bus IDs when CODE=0xC is written.
• GMLAN / UDS — KOEO PPEI packing is firmware codecs, not planted frames. Idle 0x1C3 matches silicon. Stock $1A / $09 / $01 / $23 (16 B SRAM).
• VLE math — Host-invoke samples grids. Honor-OS VVE interpolator 0x299F7C does run on continue_boot.
• GUI — Boot OS, analog sliders, named SRAM, labeled fakes (Being simulated, no engine is spinning, thus must invoke certain variables to trick real firmware).

I will be putting this on git sooner than later. I suspect it might help those of you fighting to understand certain behaviors. When this is complete and stable, I will shift gears back to finishing TM for release.

Thank you again to all those that have helped me out along the way - simply could not have gotten this far without those inputs.

Screenshot 2026-09-04 160337.png

[antus]

Wow. So that is emulating the PCM, and is partially running a real OS from a bin to the point where you can communicate with it at the moment? Well done!

[enslaved87]

Wow. So that is emulating the PCM, and is partially running a real OS from a bin to the point where you can communicate with it at the moment? Well done!

cousin-eddie-bingo.gif

[fl0wl0w]

How are you handling all of the SPI devices? The Delphi ASIC, HC08 emmisions thingy, ON20845 PMIC, ETC driver, Injector drivers.

[enslaved87]

How are you handling all of the SPI devices? The Delphi ASIC, HC08 emmisions thingy, ON20845 PMIC, ETC driver, Injector drivers.

I'm not modeling those chips as chips. That's more or less, the whole point of this HIL. The MPC5674F has four DSPI modules (0xFFF90000 A through 0xFFF9C000 D). Boot and OS sit in TCF/TFFF/RFDF polls on those status registers. If SR never comes back ready, you never get to WFI. So Unicorn's DSPI is zero-time SPI: PUSHR completes immediately, SR comes back TFFF|TCF|RFDF, POPR echoes the last 16 bits you shoved. DSPI_D is the same idea on the write-session hooks. There is no Delphi ASIC state machine, no HC08, no ON20845, no ETC/injector SPI protocol sitting on the other end of that wire. Firmware thinks it talked to a slave. It got a completed transfer. That's it, and it's labeled as such.

Delphi ASIC — SPI slave as far as the OS is concerned. I'm completing the DSPI transaction so init doesn't spin. I am not reverse-engineering or replaying that ASIC's register map. If something later unique-stores from a POPR word into SRAM and I can pin it, that becomes a named object. Until then it's just an echo.

HC08 emissions box — not in the emulator. No coprocessor core, no SPI framing. If the main OS blocks forever waiting on a specific RX word from it, that's a door I haven't opened. Currently not inventing the reply, but am going to tinker with this next.

ON20845 PMIC — bench power is real with my GPP-3323 on an early donor. In Unicorn that's SIU straps / pull-ups the firmware already expects high, not a PMIC SPI model. I'm not simulating rails, sequencing, or watchdog-via-PMIC (yet).

ETC driver / injector drivers — those live on eTPU + DSPI in the physical ECU. Unicorn's eTPU path is host MMIO only (MCR, CDCR STS, HSR self-clear so the PPC poll loops exit). It does not decode eTPU microcode, does not generate injector or ignition edges, does not PWM a throttle. Analog dest SRAM is eQADC raw (KOEO rails / named VREF/ECT on EARLY).

TLDR: the PowerPC boots, FlexCAN talks, eQADC dests get copied, scheduler tick can climb. The SPI slaves are status-bit stand-ins so the OS doesn't sit in a DSPI spin. That's a fake, it's in the Fakes tab, and I'm not going to pretend I have a cycle-accurate Delphi/HC08/PMIC/ETC/injector farm hanging off DSPI. If someone has a capture of the actual MOSI/MISO to those parts (w/ a logic analyzer on pcb), that's a big win. My next (hopefully final!!!) phase is a lofty one. I'm building a large Beckhoff I/O array and wiring into the plugs to simulate real "engine spinning, injectors firing" behaviors. Thats really the final pièce de résistance to finish this HIL properly. Until thats done and all fleshed out, this is the current state. Even so, I suspect the current state will still be helpful to many who share the same level of nerd.

You touched on exactly why I said my intial approach was naive - these things are far deeper than "just dump the rom and pin shit". Boy, this would have been much easier when I was at my 'previous employer'. coulda woulda shoulda lol.

[enslaved87]

Below is one of many product forks to come from the overarching e92 project. Getting read/write sorted has been critical path to rapidly "diff'ing" these bins in a virtual environment. Thus, sCANtool was created to do just that. This program by itsself has taken an unbeleivable amount of work to get stable. This is well tested on 2 byte EARLY e92 ecu's on the test bench for both read and write. Currently everything EXCEPT for write works on the LATE e92a variants. This is purely because i havent completed enough bench testing on late donors to feel comfortable releasing it to the wild. I should have that all completed and pushed to git in a week or two.

Fully open source, and an exe release with packaged dependencies for ease of use. I am hopeful that the source/kernels and other bits help you guys out on your projects.

https://github.com/enslaved87/sCANtool-public.git
https://github.com/enslaved87/sCANtool- ... tag/v1.0.1

From the README:

sCANtool Public
Vehicle scan, identity, datalog, E92 full-read, and EARLY E92 flash write.

What it does:

Scan — stored / pending / permanent DTCs, MIL + readiness (PID 01), Mode 02 freeze frame, multi-ECU (0x7E0–0x7E7), one-page report export
Identity — VIN, split calibration IDs (never a scraped fake OS), ECU name, module voltage, RPM
Datalog — pick PIDs, set rate, record CSV, live chart, mark events
E92 read — early and late E92 full 4 MiB flash read using this product's own SRAM read kernel (SCPB-R2); the OBD session reconnects after the dump. The last 2 KiB of each 64 KiB window (…F800) is filled 0xFF — a $23 there machine-checks this SRAM reader. Shadow password reads 16 KiB of shadow flash and shows NVPWD (censorship password). Read-only; it does not
program NVPWD.
Write (EARLY only) — Standard mode is Write calibration (LAS 0x40000 / 0x60000 + MAS) or Write entire (cal + OS + HAS). Advanced mode writes one dest. Dests in one job share the write helper and reset to stock when the last dest finishes. Boot, VIN, and 0x1F000 are not written. LATE modules are refused. This reader's …F800 holes (0xFF fill) are replaced from live flash on write so a self-read can go back.

Temporary limitations:
Write is refused on LATE E92, on serial OBD-only adapters, and on the demo adapter. Read and write kernels are never resident together.

[fl0wl0w]

I don't see Interrupts being disabled in your Kernel. That means the bootloader is still servicing the eMIOS11 interrupt to keep the watchdogs alive. Since the handler resides in flash, you won't be able to overwrite the bootloader. You also won't be able to use the Kernel from bootmode.

Take a look at the Kernel I released for E92. I spent a lot of time making the Interrupts work, but that is unnecessary for the Kernel. You just have to service the core watchdog and the external watchdog periodically. eMIOS11 handler fires every 12.5ms. If you integrate this into your Kernel, then you can write freely to anywhere in flash. https://github.com/FL0WL0W/KernelMPC567 ... c/main.cpp

[enslaved87]

I don't see Interrupts being disabled in your Kernel. That means the bootloader is still servicing the eMIOS11 interrupt to keep the watchdogs alive. Since the handler resides in flash, you won't be able to overwrite the bootloader. You also won't be able to use the Kernel from bootmode.

Take a look at the Kernel I released for E92. I spent a lot of time making the Interrupts work, but that is unnecessary for the Kernel. You just have to service the core watchdog and the external watchdog periodically. eMIOS11 handler fires every 12.5ms. If you integrate this into your Kernel, then you can write freely to anywhere in flash. https://github.com/FL0WL0W/KernelMPC567 ... c/main.cpp

Excellent - that's super helpful! That one was eating at me.

I went back and looked at why my bootloader was leaving EE on and why the eMIOS11 ISR was firing from flash instead of the handler. Turns out the bootloader’s IVT is still sitting in flash, so even though I set INTC.PSR[62] and wrteei 1, the vector table (VTBA/IVOR4) never got remapped to SRAM. That’s why I was hitting the flash ISR instead of the EMIOS_ 11_Handler. I still need to add the IVOR remap for the interrupt path.

Noticed your path is entirely different from mine. I suppose the nice part about folks working in somewhat of a vacuum. Not sure if that's your final version in git, or still actively working on it -- but noticed a couple things I've fought with. Maybe helpful for you, maybe not.

- TransferCompanionWord can hang forever. while ((SR & RFDF) == 0) {} with no timeout. If the companion isn’t there, you’re stuck with EE on and no TSR pet except from that same ISR.
- The comment says run STM at 1 MHz and poll from main. kSTMConfiguration1MHz / kCompanionServicePeriodTicks are unused. main() does wrteei 1 and only pets from EMIOS_11_Handler. That’s fine if eMIOS ch11 is still armed and your SRAM vector table is live. It is not the “just kick both WDs in a loop, interrupts unnecessary” version. main() never pets in the FlexCAN poll loop, so if ch11 isn’t running (BAM/bootmode, or someone stopped the timer) the ISR never fires and both watchdogs die — the same hole you called out.
- You inherit the bootloader’s timer. Same assumption we had, just with your own ISR body. Upload-over-bootloader: OK. True bootmode: genuinely not sure yet.

Couple other nitpicks, but clearly you've been doing this more than I have. Appreciate the feedback/help.

[fl0wl0w]

The E92 Kernel was just a proof of concept and scratchpad for investigating interrupt setup. My E78 Kernel is complete and fixes some of the pitfalls you mentioned.

- I'm not too worried about the external watchdog hanging. If we don't get a response it means something is wrong.
- AI Left a bunch of comments in there. eMIOS11 is armed from bootloader and SRAM vector table is setup already.
- You are correct that BAM won't currently work because it does not explicitly set up eMIOS11. E78 Kernel doesn't use interrupts cause they really are not needed for a Kernel.

Check out my E78 Kernel. It is quite a bit more organized and readable. I will eventually get around to giving the same love to the E92 Kernel since everything has been made reusable. https://github.com/FL0WL0W/KernelMPC5566

[kidturbo]

Nice work on the emulator. I'll dig up all the diesel and other weird GM OS versions I have laying around and drop you a link. Along with the kernel work, huge progress been made in the open source programing realm over last six month. Keep it going..