pcmhacking.net

Looking excellent, thanks for the update!!!!

Trying to work out the best method of identifying the ECM and also compatible OS's to match.

I think reading the service number will be the best bet for doing both of the above. Should be able to read the service number in the bin also and compare against other compatible service numbers/OS matches and begin generating a list.

Now technically.. any E38 CAN be used in any car. Its all the same hardware after all, but its the boot block/parameter block which is technically never reprogrammed. So it would require a FULL clone of the ecu including the slave operating system which I am yet to look into at all. Im pretty sure that the ECU will still work with the wrong slave OS, as in you can clone the main cpu.. then do the slave OS after. I dont think it works doing it the other way around though.

Wonder if SPS will fix it up after cloning boot+OS+cal.. maybe itll do the slave after detecting its incorrect?

I found some patterns so far that can be used for safely identifying stuff.

Now the boot block or 0000-bfff area. This seems constant in all the e38 files I have so far. The p/n of bootblock can be get at 3f5 in hex converted to decimal. All e38 I found have p/n 12605900. So this area definitely stays constant across the board and there is no need to reflash it.
The bootblock p/n of e67 is 12605811. By reading that p/n a guess can be made for the pcm type e38 vs e67.

c000-ffff are is the eeprom area. It can be reflashed on its own since it is on separate sector

SA10 0C000h–0FFFFh

Here things get complicated. the eeprom data can fluctuate between c000-dfff and e000-ffff, just like the ls1 data.
Some data here is constant offset while other fluctuates with pcm and os being used.
The constant data so far is
a version number in ascii at #7 bytes from start.[3 bytes number]
at #28 offset is the pcm number in 4 bytes in hex
at #2c offset is the trace number 16 bytes in ascii.
[There is one exception I have and is from 08 l96 bin, I am not sure if it is bad bin data or some exception, need more files to verify]

Vin, seed/key and other data fluctuates.

The main identifier of the type of eeprom data used is a5a0. It indicates the end of sector. It is also used by the pcm to check if the data is valid. The location can be linked with the OS used. So far I have found 3 different locations for it.
#326 offset
#1be offset
#1da offset
What will happen if the OS looks for a5a0 at the address it is set for and can`t find. The typical scenario is to consider the sector invalid and defaults the content to ffs, making it impossible to get a valid seed/key or if it is blanked you will get ffffs for seed/key.

It is still unclear how to link the OS with the valid eeprom data. Some situations might need updating c000-ffff for certain OS upgrades.


Slave can also make a kind of brick condition, A list for slave used vs OS number. I am sure there isn`t much slaves out there. What is the main purpose for slave, is it linked with TAC being used, or have other functions also. If the slave share a ram with main OS and exchange data there, a wrong configuration will make the pcm inoperable but not necessarily bricked. Still needs confirmation.

Reading slave or at least flashing it is the safest path for OS upgrade, together with the eeprom data update.

kur4o wrote:I found some patterns so far that can be used for safely identifying stuff.

Now the boot block or 0000-bfff area. This seems constant in all the e38 files I have so far. The p/n of bootblock can be get at 3f5 in hex converted to decimal. All e38 I found have p/n 12605900. So this area definitely stays constant across the board and there is no need to reflash it.
The bootblock p/n of e67 is 12605811. By reading that p/n a guess can be made for the pcm type e38 vs e67.

c000-ffff are is the eeprom area. It can be reflashed on its own since it is on separate sector

SA10 0C000h–0FFFFh

Awesome stuff here!
Ok so I can see my E38's also hav the 12605900.
The service number on the unit I have is 12612384. Im surprised it does not appear in the bin at all.. I have checked every possible variant of it.

Next, for the eeprom/parameter section, this will actually be SA6 (3000-37FF) and SA7 (3800-3FFF) if looking at the memory map. If you shift those memory address left by two, you end up with C000-DFFF and E000 to FFFF.
So, those are the two sections you have been referring to, which I think makes sense to what is happening. I believe when actions such as VIN programming occurs, the ECU erases the opposite section and copies the data across including the changes it needs and then erases the old section. If another change occurs, it does the same thing and uses the opposite sector again.

I can confirm this by doing a proper VIN change though DID commands and see what actually happens.

I think its bascially a matter of just checking the offsets and seeing which one has data and which was is FF's, then begin processing from there to get vin,serial,seed/key, partnumber ect from the bin.

Usually they are not shifted.

At boot a mirror of the eeprom area is crated in memory.
During runtime all actions taken place in memory.

When shutting down via network management or simply switching key to off position (power cycle), ram content is written once to eeprom emulation area.

This is done since it is no true eeprom and still needs to have write cycle absolut count considered.



Above is usual, GM PowerPC Plattform can do different. We have to find out
I can confirm that area is not at the opposite location when changing VIN in my E38 on desk.

I remember when I looked at binary files comparing before & after read/write there was a certain section that moves back & forwards around 200 or 2000 bytes each write & was told there was a reason for it but can't remember what it was.

daniel2345 wrote:Usually they are not shifted.

At boot a mirror of the eeprom area is crated in memory.
During runtime all actions taken place in memory.

When shutting down via network management or simply switching key to off position (power cycle), ram content is written once to eeprom emulation area.

This is done since it is no true eeprom and still needs to have write cycle absolut count considered.



Above is usual, GM PowerPC Plattform can do different. We have to find out
I can confirm that area is not at the opposite location when changing VIN in my E38 on desk.

Hmmmm ok thats interesting.

Since when tuning software writes the seed/key for tuning locking, that is the area it is affecting. Since if that section is in RAM, and then is rewritten/saved on key down, it would undo the changes that the tuning software did (If that makes sense??).

Or maybe it only rewrites it if it thinks the ram memory has been modified using a DID request over canbus. Ie... if the VIN is changed.

VX L67 Getrag wrote:I remember when I looked at binary files comparing before & after read/write there was a certain section that moves back & forwards around 200 or 2000 bytes each write & was told there was a reason for it but can't remember what it was.

Yeah see that makes sense to me if it was switching due to my previous explanation.

Ill verify here shortly after cracking open this E98 that just arrived

Why would key switch undo the changes?

New seed&key is in ram. Key turned, ram written to eeprom. Remember in car, the ecu is not instantly tuned off since it has always battery terminal 30 connected. It switches itself to "sleep" when everything is done.

If you hardcut power on desk, that might not work.


Also the writing of ram to eeprom can be triggered on various events, such as diagnostic writes.
Maybe this is done here.
99% of runtime in lifecycle no such event apart from key cycle occurs.

But remember, im only talking about what might be common.
My eep section has not moved while writing VIN and it has been said it is always on the same position in E38 files?


Edit: wait. I just re read and saw that the "fluctuation" is from 0xC000..0xFFFF. Two sections with 0x2000.

That might be possible, i saw this whole block as eeprom and did not check what is where...

Just cracked open an E98 ecu just now, picture below.
It appears all the parts appear on the back side, so I dont think I need to desolder the front connectors and look at the front side.

Has one of these SGM chipsets... so its time to do an SPS update and see whats actually happening!