E92 PCM Reverse Engineering

[gmtech825]

HP's kernel also reads out the boot, except for those addresses mentioned above

[enslaved87]

All,

If you havent seen this yet, hope it helps. Both generation E92's read/write fully fleshed out and open sourced.

https://github.com/enslaved87/sCANtool-public

[gmtech825]

Does anyone know if the parameter blocks/EEPROM ranges use checksums. From what I can tell they do not. I wrote a modified block without correcting on the bench and everything seems happy

[gmtech825]

edit for updated file:

OsExtra_ranges_by_OS (2).txt

For anyone that needs it, this is a list I made of the extra checksums that exist for torque security/ect. use at your own risk.

They’re a big-endian 16-bit word sum over the range, with the stored value a 32-bit two’s complement negate of that sum ( ~sum + 1)

[gixxer92]

Does anyone know if the parameter blocks/EEPROM ranges use checksums. From what I can tell they do not. I wrote a modified block without correcting on the bench and everything seems happy

I did some testing on my late E92A with the OS 12691210.
I changed the tester ID by one digit through the normal diagnostic commands. The ECM accepted it and showed the new value right away. I found that it needed the AE 28 80 command to actually save it. After that command, the change survived having all power completely removed from the ECM. I restored the original value afterward and confirmed that it also stayed restored after another full power cycle.

Then compared full reads from before and after the test. The changes were all below 0x40000, where the parameter information is stored. Nothing at or above 0x40000 changed. It also changed about 44,000 bytes instead of only changing the one value. From what was explained to me, it looks like the ECM moved the records between two storage banks and cleaned up the old bank.

So I don't think this test proves there is no checksum. Since the ECM’s own write command was used, the ECM could have corrected a checksum or other record information for us. Your raw block modification working is probably better evidence for there not being one on that block.
What the test did prove is that the parameter area is banked or journaled, and AE 28 80 seems to be the command that makes the change permanent. A raw write test with and without changing the record header or ending bytes would probably be needed to answer the checksum question for sure.

[gixxer92]

OsExtra_ranges_by_OS.txt


For anyone that needs it, this is a list I made of the extra checksums that exist for torque security/ect. use at your own risk.

They’re a big-endian 16-bit word sum over the range, with the stored value a 32-bit two’s complement negate of that sum ( ~sum + 1)

Here’s what I checked on my end, with some help building the checker.
I checked the list against two E92A operating systems:
- 12691210 — late 2017 E92A
- 12711165 — 2018 E92A

I used stock files, modified files and data physically read from the ECMs. Each OS had five listed checksum ranges.
Four different BIN files were tested, with five ranges checked in each file. All 20 checks matched the ranges and calculation in your list.
The checker:
- Reads each pair of bytes as a big-endian 16-bit number.
- Adds the numbers using a wrapping 32-bit total.
- Calculates 0 minus that total, modulo 2^32.
- Reads the stored four-byte checksum as a big-endian 32-bit value.
- Compares the calculated and stored values.

This gives the same result as the two’s-complement calculation you described: ~sum + 1.
The calculation worked on modified and physically read data, not only an untouched stock file. When calibration data was different, some of the stored checksum values were also different. Recalculating them still produced the exact stored values.

For the OS 12691210 and 12711165 files I tested, the listed ranges and checksum calculation matched. These checksums also appear to be separate from the parameter/EEPROM question because all five listed ranges are in the calibration area above 0x40000.

I used a short, read-only PowerShell script made specifically for this test. I had OpenAI Codex help write it. I manually entered the five ranges from the posted list, then ran the checker against the four BIN files.
The bytes covered by these checksum ranges in the physical-read files were read from the ECM over CAN using a Macchina M2. The checksum script itself runs offline and is read-only. It did not modify the BIN files or write anything to the ECM.

[gixxer92]

To add some background about me and where my knowledge in this conversation is coming from:
About a year and a half ago, I installed an L8T 6.6L in my 2017 Silverado. I paid two different tuners to work on smoothing out the idle, but at the time I had very little experience with Virtual Torque after I had put the BTR L8T Torque Cam and Long Tube headers on the truck. Let me stipulate up front: I am the doer of my own demise here.

I still wasn’t happy with the idle. The truck has Atomic Fabrication polyurethane engine mounts, so you can physically feel the idle-control triangle fighting against the natural roughness of the engine and camshaft (it drives me nuts).

I initially started using Claude to help apply the common correction factors people use with HP Tuners. From there, I started learning the nuances of SOI/EOI, Burst Knock, Virtual Torque, VVE, open-loop, closed-loop STFT, and closed-loop fueling.

Over the past year, that effort grew into a fairly substantial tuning application. More recently, I began using OpenAI Codex with a Macchina M2 to reverse-engineer the 2014–2018 E92/E92A family. With the use of Codex a large portion of the airflow, fueling, torque-model, state-selection, coefficient, checksum, and calibration paths is mapped out.
One of the biggest things the BIN reverse engineering exposed was that some of the algorithms I originally built from the HP Tuners calculations were incomplete. The visible table math was not necessarily wrong, but it did not show every runtime selector, blend, limiter, adder, coefficient path, or mode transition being applied inside the ECM. That explained several areas where the measured error and correction output did not line up as expected. I've added those discoveries to fill in the missing calculation paths and validate corrections against the ECM’s actual logic instead of assuming the editor view tells the complete story.
The E38/67 is next as i have few friends local that need some help.

I have been around these forums for a while, but historically I was mainly reading and absorbing what everyone was discussing. I didn’t start digging into it this deeply until I became unhappy with the paid tuning work and decided I needed to understand what the ECM was actually doing for myself.
My goal became more than simply adjusting tables. I wanted to disassemble the code and understand the complete path each ECM module follows: which operating states select which calculations, what inputs influence them, how errors should be measured, and how the calibration tables and coefficients interact.

From there, I started implementing the more complete algorithms in software so the calibration can be corrected systematically instead of requiring endless manual trial and error.

For some perspective, the project is currently:
- Production source code only: 45.97 MiB
- Two tuning-software executables: 102.91 MiB
- Source code plus both executables: 148.88 MiB

On my truck and current test process, the software can generally bring each tuning category into range within three or four correction iterations. The HP Tuners datalogger currently has enough bandwidth to log two areas at one time VVE and Virtual Torque together at useful sampling rates.

The software also identifies which areas need more evidence, prioritizes the operating points for the next data log, and generates an HTML map showing what the scanner needs to capture during the next drive.

After reading this thread and several related discussions, I also pulled an old Macchina M2 off the shelf. I can now read the current E92A controller with it. The write path has been proven on bench hardware, and I’m working through the necessary OS-specific validation before treating it as a safe flash method for the truck. That should be done in the next day or two.

That is basically how I arrived here: I started out trying to fix an idle problem and ended up building software to understand and calibrate the ECM from the actual code path outward.

I'm QA in professional background, electronics by trade out of the military.
But the QA background may support the mental issues, a.k.a. OCD's that I don't let go of things that nag at me...

[gmtech825]

Awesome stuff gixxer92! I'd be interested to know more about your findings. might warrant a dedicated thread though.

[MPC001]

This is a serious deep dive gixxer92. Cool stuff!

[kur4o]

OsExtra_ranges_by_OS.txt


For anyone that needs it, this is a list I made of the extra checksums that exist for torque security/ect. use at your own risk.

They’re a big-endian 16-bit word sum over the range, with the stored value a 32-bit two’s complement negate of that sum ( ~sum + 1)

I looled at the list but some values looks weird, especially the 3 range type that have a range in bootblock. I still didn`t find an OS to confirm it
12636334 [3 ranges]
0x9C62-0xA895 / CS@0xA896

Usually the e92 have 3 ranges and e92a have 5 ranges. I already have that mapped for autocorrection, but recently found some OS that use slightly different logic. So it doesn`t cover all cases yet, until I find more complete list of OS archive.

Segments:
Boot Block PN: 4294967295, Ver: ??, Nr: 255[FFFFFFFF - FFFFFFFF], Size: 1
OS PN: 12683365, Ver: AB, Nr: 1 [C0000 - FFFFF, 100000 - 3FFFFF], Size: 340000
System PN: 12675371, Ver: AF, Nr: 2 [40000 - 42FFF], Size: 3000
Fuel PN: 12675312, Ver: AD, Nr: 3 [43000 - 47FFF], Size: 5000
Speedo PN: 12675461, Ver: AC, Nr: 4 [48000 - 49FFF], Size: 2000
EngineDiag PN: 12686587, Ver: AB, Nr: 5 [4A000 - 5FEFF], Size: 15F00
Engine PN: 12686263, Ver: AB, Nr: 6 [5FF00 - BFFFF], Size: 60100
Checksums:
Boot Block Checksum 1: FFFF, Calculated: [Fail] Checksum 2:FFFF, Calculated: [Fail]
OS Checksum 1: 0AEF [OK] Checksum 2: DF58 [OK] [n/a]
SYSSPD ext Checksum 1: FFFAECA7 [OK] Checksum 2: FFF8209D [OK]
System Checksum 1: 8F98 [OK] Checksum 2: EA3C [OK] [n/a]
Fuel Checksum 1: 6C9B [OK] Checksum 2: DAFC [OK] [n/a]
Speedo Checksum 1: 74D7 [OK] Checksum 2: 8833 [OK] [n/a]
EngineDiag Checksum 1: A303 [OK] Checksum 2: D125 [OK] [n/a]
ENG extra 1 Checksum 1: F576275F [OK] Checksum 2: F59F83B1 [OK]
ENG extra 2 Checksum 1: EC2CF15E [OK]
Engine Checksum 1: F8F3 [OK] Checksum 2: DE34 [OK] [n/a]