PCM Hammer E38

[antus]

This is the current develop branch of PCM Hammer. The SWMI fields and so forth are proposed naming and align more closely with GM standards. However I am trying to understand slave identifiers. My test bench E38 will no longer accept an SPS write of the slave module. My current working theory is that mismatching the main OS and the Slave OS causes problems with re-writing the slave. But this is unconfirmed. I have another E38 to keep testing with for slave write implementation but before I go too far down the road, what knowledge is out there about E38 and it's slave?

Is it SWMI 9 is the slave OSID and SWMI 10 is its calibration?
Do they really have 2 segments in the slave?
Is it confirmed that the slave segments are written to a different flash on the PCM? So definitely not included in the 2Mb in the main flash?
Is the SWMI of the slave answered by the main OS? So we can write the main flash, then ask it the SWMI to get the segments we need to write to slave?
I understand there are 4 types of E38 - is the information here correct? https://www.ewaltsautotuning.com/flashi ... patibility

2006-2007 E38 (service numbers 12597121 & 19210738)
2008 E38 (service numbers 19418222 & 12612384)
2009 E38 (service numbers 19418223 & 12625455)
** Early 2009 G8 GT with the 6.0L uses a 2008 (12612384) Late 2009 uses the (12625455)
2010+ E38 (service numbers 19418221 & 12633238)
** 2010 2500HD trucks with the LY6 still used a 2009 (12625455) E38 ECM
***If you're locked out of an E38 following an attempt to reflash a different year's OS—for instance, flashing a 2010 OS onto a 2007 E38—common keys to try are 3F80, 43D4, or simply mirroring the seed. These solutions may save you from resorting to a time-consuming brute force attack or an ECM replacement.***

Are there physical differences, or is it to do with the slave and not changing it?
If you cross flash do you outright brick, or just get bad security data, hence the above comment?
Any other gotchas?

[15:04:13.179] PCM Hammer
[15:04:13.179] Copyright (C) 2018-2026 PcmHacking.net - GPL v3
[15:04:13.179] Build: 2026-07-20 15:02:24
[15:04:13.180] Running at: Monday, July 20 2026, 15:04:13
[15:04:13.268] SLCAN device ready.
[15:04:15.451] Detected PCM on Can500k
[15:04:15.451] PCM Identification:
[15:04:16.221] OSID: 12605899
[15:04:16.221] VIN: 2G1WS553581200000
[15:04:16.221] Traceability (MTC): 86YPMSK180512F8Q
[15:04:16.221] SWMI 01: 12617175
[15:04:16.221] SWMI 02: 12621641
[15:04:16.221] SWMI 03: 12620980
[15:04:16.221] SWMI 04: 12607527
[15:04:16.221] SWMI 05: 12620979
[15:04:16.221] SWMI 06: 12621786
[15:04:16.221] SWMI 09: 12605899
[15:04:16.221] SWMI 10: 12605916
[15:04:16.221] End Model P/N: 12617174

[MPC001]

Yes the slave/motor control processor has an OS & a calibration segment. The 2 SWMI's.

Separate flash to main 2 mb flash.

The main OS has no idea what the slave SWMI's need to be.

Have had 10+ main OS's paired with 06/07 slave OS's with no brick effects. & Vice versa.

Degree of bricking on main OS cross flash varies. 06/07 <> 08 minor corruption only as the Vin is the mainly the only thing that moves by 4 bytes. 09's & 10+ the changes are more extensive & when the NVM parts of RAM are saved to flash the damage can go from scrambled seed/keys, right to boot loops that need the back removed to fix. Worst combo probably 06/07 x flashed to 10+. Or vice versa.

Yes 4 different E38 SW formats (Parameter block layouts). Same HW. Different boot block early 06 compared to late 06+. Boot block is the same late 06 to end of production.

This might be helpful re slave:

viewtopic.php?t=8932

[antus]

Cool. Thanks. About to push up a Linux CLI version, and while developing that I found a range of other driver bugs and also had made a false assumption about OSID, so was failing to auto detect E38. All of that is resolved.

So, are the bricks because the param block is not written, or is written to the wrong place? If the hardware is the same, then a clone write, should avoid a brick. Maybe the factory tools and some aftermarket tools work differently?

So SWMI 9 and 10 are the slave OS and slave OS cal? And when I read them from a normally operating PCM where does it get the IDs? Does it reach out across QSPI and ask the Slave to identify itself? I have a feeling it might, I vaugely recall seeing these SWMI responses failing on a half bricked PCM with a bad slave once.

[Tazzi]

Cool. Thanks. About to push up a Linux CLI version, and while developing that I found a range of other driver bugs and also had made a false assumption about OSID, so was failing to auto detect E38. All of that is resolved.

So, are the bricks because the param block is not written, or is written to the wrong place? If the hardware is the same, then a clone write, should avoid a brick. Maybe the factory tools and some aftermarket tools work differently?

So SWMI 9 and 10 are the slave OS and slave OS cal? And when I read them from a normally operating PCM where does it get the IDs? Does it reach out across QSPI and ask the Slave to identify itself? I have a feeling it might, I vaugely recall seeing these SWMI responses failing on a half bricked PCM with a bad slave once.

The master OS requests the data from the slave chip over QSPI. This is why youll also see a 7E8 03 7F 1A 78 message be sent for the slave OS/Cal since the OS has to pause a split moment to schedule that request.

As for cross flashing, couple things to note:
1) If you do a full clone (boot through to cals), then you can overwrite the slave afterwards. Slave MUST be written to match correctly to the OS otherwise throttle body will behave irattically.
(The OS/Cals are designed for specific throttle bodies, so its important to have it correct. For instance, there is silver or brass based throttle bodies on our VE commodores that must have the correct slave OS/cals to suit).

2) If you skip the boot and only write the OS+cals, then you will result in a semi brick since the parameter area (seed/key/other settings) are misaligned.

3) Kernel must handle the ram sections correctly otherwise powerdown will result in the param block being overwritten with data left over in ram (corruption or replaces new data with the old original).

[antus]

1) cool
2) ok, so with boot is OK as long as you also write the slave? So you can cross flash the 4 versions, if you do all the parts?
3) not sure I understand this. If the kernel is running the PCM, and it shuts down the PCM OS wont be there and wont be executed by the OS. I can see that if the nvram is not erased someting could go wrong on the next boot and it's shutdown. I've def seen things go bad. I'll keep this in mind as I do further development.

New question - do you know if the different slaves need to be flashed differently? I've noticed the OEM process fail at slave write when cross flashing. This is the hard bit, my PCM is in a state where I cannot write the slave anymore. I know I can do BDM on the slave, but any community knowledge that might help up front appreciated.

BTW @Tazzi I got the Linux CLI version up last night, and in building it found a few bugs in the common code that improved all platform versions. The OBD XPro is reading and writing main flash very fast on E38 now. https://github.com/PcmHammer/PcmHammer/ ... 9754475113 But until I understand this slave risk, I wouldn't want most people to use it.

[Tazzi]

3) On all modern ECUs (and old.. technically), they update their parameter section when the ignition is off (battery still on) after a few minutes if sitting idle.
If the ECU has marked the RAM copy of the parameter section as dirty, it will write the ram data to flash.

Basically, have to ensure to either wipe the correct memory area so the ECU doesn't try save old data, or jump back to boot and let the boot section re-intiialize the ram section with the new data.
This is why its important since it can result in a cross flashed ECU even after performing a clone, as the old RAM parameter section data gets saved into flash. This is the real "gotcha" that catches most people.

As for slave writing, they are all the same as far as I am aware.
But, I have come across a similar issue to what you are describing where I tried switching a VZ (2005) E38 boot/OS to a VF (2017) E38 boot/OS, and I was not able to change the slave afterwards. I wonder if there are possibily slight differences in how comms over QSPI are processed between old OS's and newer.

[antus]

Ok that majes sence. Must be why other tools send a whole lot of FF. Thought that was redundantly prepping a buffer, but it must be clearing ram area. Ive had PCMs ive been messing with be mis identified and main OS writes and process fails at slave, then I swap to a different year OS and it works, so diff protocol makes sense. Maybe I need to BDM mine with a known matching OS and Slave and go from there. Some of this work was on P10 and P12, but most of this tech is generational. Not sure there is much demand for slave write on those, but it'd be nice to be complete. E38 would probably be more interesting to more people.

FWIW i've been trying to read slave too. Got it working on the VPW PCMs but the slave boots from the first 2k, then re-maps the flash so its not been possible to read the first 2k. And without that, if you have to bring your own first 2k you might as well bring your own whole segment. So i've shelved slave read unless something changes there.

[MPC001]

So SWMI 9 and 10 are the slave OS and slave OS cal? And when I read them from a normally operating PCM where does it get the IDs? Does it reach out across QSPI and ask the Slave to identify itself? I have a feeling it might, I vaugely recall seeing these SWMI responses failing on a half bricked PCM with a bad slave once.

You're welcome. Correct ! Your example above SWMI 9 - 12605899 is the slave OS, 12605916 SWMI 10 is the slave cal.

And yes the main OS gets the slave info, seg id's/SWMI & other items like CRC 16 CVN's via the SPI link.

[MPC001]

FWIW i've been trying to read slave too. Got it working on the VPW PCMs but the slave boots from the first 2k, then re-maps the flash so its not been possible to read the first 2k. And without that, if you have to bring your own first 2k you might as well bring your own whole segment. So i've shelved slave read unless something changes there.

FWIW - E40 seems to be the only slave that can be read out via CAN. Via Service $35 - which appears not to be available post E40. In 20 years no one has got E38+ slave reads running. Don't doubt it's possible, but not really worth the dev effort.

[MPC001]

E38 would probably be more interesting to more people.

Certainly seems to be the most prolific ECM ever produced. Something over 20 years in production.