PCM Hammer E38

[Tazzi]

I guess it comes down to how many people are actually editing the slave and using that?
All current commercial solutions only edit the main CPU as far as I am aware, same with basically every other controller.

Doesn't mean it wouldn't be useful, but for the 99% case, I don't believe there is a huge amount of people that would use it (tuning wise).

[antus]

I have spent most my time on P10 and P12 slave so far, but I would expect the same. They have serious tamper protection in there, including XOR of slave RAM to trigger a reboot if anything looks off. And since its used for ETC, I think that is really just throttle position or TB blade angle? so probably does not need tuneing in the slave itself, but rather what those angles mean in the main os. So the app really only needs to know when writing an OS, what slave code is needed and send it in if its changed, or maybe a user override to force write incase it is corrupted or something. What I have learnt so far is to enter the slave bootloader we hold a pin high or low from the main CPU and send a reset over SPI and the slave reboots but jumps to the slave kernel instead of entering the main OS. So you cant prepare the ram and then execute seperately like on the main CPU, you have to do it in one shot. This is the older types, I expect the same in the E38, so far. It looks like it was done for a highly stable and safe design, there is no possibility of editing ram contents at run time which means you can't break the throttle control.

[Tre-Cool]

i look at from a tuning perspective. the ecu holds 3 throttle response maps. ideally these are meant to be activated by either a hardwire input or from a can signal (ebcm or bcm)
then there are 3 other parameters that can define which map is used per gear.

you can do some interesting power management with blower cars this way, but you can only reduce the desired pedal to throttle, not go up otherwise you hit a limp mode. so i for 1 would like to be able to flash the slave cal or in the least know what my maximum limit is for the entire

Now in saying all that Efilive, HPT dont show those extra tables that allows you to make those maps define to a gear. I use it in my car to dull/reduce the throttle opening & limit power for the lower gears.

EFILive_Tune_sLGsutWGAf.png

[veee8]

I imagine there is a bit of a safety liability aspect for messing too much with the ETC areas with the potential of bypassing the watchdog in the slave for the throttle error shutdown. Likely also a contributor for the other flashers to shy away from.

[antus]

Well this has gotten quite interesting. While we have working read and write on the main flash with an old-school kernel -> load to ram, set execute flag, do the thing entirely from an uploaded kernel, it turns out factory works quite differently. They load the kernel, no execute, and... its not a kernel. Its a library. It has an erase and a program function and thats it. No main loop, no control workflow. So factory spec re-flash is to put your.. not kernel.. library in a fixed location in ram, and let the RTOS see it, and set a flag and reboot to bootloader, then the bootloader controls the program flow and calls in to your erase and program libraries. And the erase and program functions put the flash chip in the appropriate internal flash state machine mode, do the erase or program, then put it back in to read array (normal) mode. The slave is the same. The boot loader is in control, the pcm is unlocked (no reboot on completion of the main flash chip re-program) and then you put your flash not kernel.. library in the ram at the right location, then the bootloader sees it, sees a type flag of 1 (not 0) and knows its for the slave, and streams it over QSPI to the slave, and the slave OS.. bootloader I guess runs the slave reprogram calling in to the erase and program functions that were just uploaded. The slave is HCS12. This means, as we suspected, read is not possible, and we dont have a control loop available for read. And now I really want to implement slave read, just because it was said that nobody has done it, even though it is of low value, so lets see if we can find a way. I suppose we might need to put it in place of one of the functions called from the main slave loop and then take over QSPI and run our own handler and start sending data back. Lets see how this goes... and for the big picture, might need to discard the old school kernel and write some functions that work more closely with the bootloader. Although, if we do it old school style then we can erase boot loader and replace it, and it seems factory method cannot, so that might solve the limitations with swapping E38 between generations, so there might be some win there doing it that way too.

[MPC001]

Very insightful, thank you!

[AngelMarc]

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.

Is that the "virtual EEPROM" I've read about?

[AngelMarc]

I vaguely (and maybe falsely) recall there being a specific E38 OS (maybe it was E40 or something) that can do proper speed density. I'm sure there'd be interest in that, and if slave needs to change for it...

Also not sure how much it would matter for what my weird ass wants out of the E67 (still have one of those sitting on a shelf). I never did find out if there was one OS that does all the different cylinder configurations, or if E67 can do a proper speed density at all without custom code. Not having a tool to flash whatever I want, I stopped looking into it much.

[antus]

Yes its the virual eeprom. Its a common way of doing it across many gm pcms. It mirrors flash to sram, and only when it changes, on shutdown, the power down code on ignition off (b+ on) it'll erase and write the block to the flash param block. If the sram is dirty on boot then it'll read the block and copy it to sram. this is for not commonly changed stuff but it allows the pcm to write it any time, those occasional changes get persisted to flash with engine off and pcm nit servicing the car, and without any external eeprom chip.

not too sure about OSs yet. I'll probably leave that to others and universal patcher, I am more interested in just the read and write flash part. Main flash is pretty well understood the original way, which still is possible here but the new way, and slave are quite different so I want to get it all figured out properly for both this gen and its evolution in to newer gens later.

I still havnt found the gpio pin the main cpu uses to reset the slave. If anyone has insight about that, it's the last missing piece.

[AngelMarc]

I'll definitely be looking into it after you get that part sorted. I have an E38 that may or may not work. Pulled it out of a puddle of mud; should be sealed up well enough for that to not matter. Hope the white powder under the plugs was just dried up dielectric grease or similar. Never even made a bench rig to connect a scanner to it.