E54 PCM, force load of paramater block from flash to sram?

[antus]

Here is a question for the GM gurus.

I have a tester on E54 with a PCM that has a seed and key of 0000. I am trying to advise how to restore it to a factory seed and key so it can be used with SPS.

In order to reproduce this I am trying to write seed and key = 0000 to my bench E54 (address 6000-6003 = 00 00 00 00). The write has been successful. But the kernel is not loading in to the SRAM over the top of the mirror of the paramater block, and as such the SRAM copy passes the internal consistency checks at boot and the PCM is not loading the new data from flash.

I could write a tool to scan the memory and find the SRAM mirror, and then add something to the E54 write process to overwrite the SRAM mirror to force a reload when flashing a parameter block in the E54. But that aside, do any of the GM gurus here have a recommended approach? Is there a command I can send to the PCM to force an SRAM reload from flash or another way to approach this? Or is the simple approach the best and I just locate the SRAM copy and write to it with standard write commands as an additional E54 step under the right circumstances?

[Tazzi]

I deal with this a bit for all PCM types (VPW and CAN) and its more related to allowing the PCM the proper time to reload.

Typically after a full reflash, you will need to then turn ignition off, then wait a good 1minute before then powering back on.

You can watch the amperage drop further after ~40second mark, where the ECU typically powers completely down. On next ignition power up, it reloads all SRAM correctly to reflect correct VIN/Serial ect.

If you power up too quickly, then it will continue using the old ram data since it has not reloaded it all.

[kur4o]

e54 eeprom is prone to corruption, factory code bug.

Rewriting eeprom is also tricky. The boot out sequence is very important to trigger full reset on pcm, I need to look what needs to be done.

[antus]

Thanks both, Tazzi had the answer. I have noticed in the past that SRAM to Flash for a vin change to persist happen immediately at ignition off, and you only need B+ to remain for a few seconds. But it seems, it takes closer to 40 seconds, I gave it a couple of minutes and came back, at shutdown to either load flash to SRAM, or or set a flag that its loaded on next boot. The additional wait before cutting B+ and then a power cycle did the job.

I think PCM Hammer is going to be a very good tool for recovering E54s, when the functionality goes mainstream. I am hearing of a lot of quirks on the platform, and hearing from people with null seed/key or trashed paramater block but its looking like a recovery flash from boot pin (so to speed, address pin ground to be technically correct) and a clone write with pcm hammer from a known good pin, followed by ignition off and wait a minute then power cycle is going to be able to fix them.

We are not doing anything special in the kernel for E54, but it is the original pcm hammer flash kernel and so far its not broken any test PCMs, only recovered them. Maybe the known problems are a bug or problem with the factory code? Here is hopeing. Only a couple of people with test reports comeing in so far on E54 but so far, so good including on my own 2 PCMs.

[antus]

Here is another question I am just posting here since its E54...

Seed = 0000 and seed = FFFF.. are they used in the wild?

I am considering overriding the security algo and if seed is 0000 send 0000 as key (instead of assuming unlocked), or key FFFF for seed FFFF for instances where the param block is erased and not re-written.

If I do this, will I break either recovery mode or legit use cases where factory seed is FFFF with a real key?

Or am I better off just picking the seed is either of those values and advising to try setting a user defined key of 0000 or FFFF if the process fails at kernel upload.

It a bit too much of a hack to try and jump back to the security stage after kernel upload, though if the whole app was running as a state machine it'd be fine to set a few values and set the state back and return to the main state machine code. not a small change just for this though.

[antus]

Thoughts? Good enough?

Code: Select all

// If the seed is a common occurance of corrupted security data, and the user is not attempting to use a custom key, provide a useful suggestion
if (((seedValue == 0x0000) || (seedValue == 0xFFFF)) && (UserDefinedKey == -1))
{
	this.logger.AddUserMessage($"***NOTICE**** Seed is 0x{seedValue.ToString("X4")}, if this process fails, try setting a user defined key of 0x{seedValue.ToString("X4")}");
}

[kur4o]

You need to add settings, send force unlock command even if seed is 0000, using key 0000 or FFFF.

[antus]

It does that already, just the user needs to know to try it.

[kostia111]

I didn't understand your problem very well
but if the unit gives zero SEED
the first thing I would do
is read the MEC value (1A A0)
if it is not zero after programming
the unit will give zero SEED
each time the ignition is turned on, the MEC will decrease by one until it reaches zero

[kostia111]

f you have a standard programming utility file from SPS or at least its number
I would like to see
maybe there are other commands there
to reset after programming