Corvette CCM Reverse Engineering Anyone?

[steveo]

im thinking updating it while running will work im theory but some trickery might be necessary

if that doesn't work we can certainly have a good method for very quickly updating some relocated tables with zero risk without engine running. and those changes will be persistent

[steveo]

well, a bit of discovering my own bugs and i got this working really well on EE, and so it should only need a slight tweak to work with the CCM.

still need to fully implement it so it reads/compares the bin, but it's really cool to be able to program stuff to the onboard eeprom of the ECM

i think once we find a use case for it, WAY more cool than fixing a CCM, so this research has had a really positive side effect

proof of concept:

DEBUG::Sending raw command: DEVICE=F4 COMMAND=2 DATA=0E90
Got reply to command: DEVICE=F4 COMMAND=2 DATA=BEEFBEEFBEEFBEEFBEEFBEEFBEEFBEEF

[kur4o]

Great work so far.

Adding tables to eeprom will be a matter of just changing table lookup address. so it will be a permanent setting. One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

[steveo]

One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

that shouldn't be hard
flashhack should only write what you change

[spfautsch]

Really cool ideas.

im thinking updating it while running will work im theory but some trickery might be necessary

I like your thinking and don't intend to rain on your parade, but...

Just "riffing", here are a few pitfalls I think you might run into in practice:

1) When the PPROG register is not cleared i.e. during erase / programming, the datasheet seems to indicate the eeprom cannot be read just like ROM. What will happen? Test it and find out?

2) Bad things could happen if during an erase + write procedure the PCM needs to read something from a cell of a relocated table for instance like spark advance, and does so immediately after an erase, but before the subsequent program (eeprom contains #$FF). Switching off the table relocation temporarily would remedy this and pitfall #1.

3) I know almost nothing about how the two $EE programs work, but to draw a parallel to my diy-ltcc firmware I'm almost certain bad things would happen if you blocked the main loop for 10 ms (a write or erase cycle) while the engine was running. You'd need access to a timer / counter here to prevent holding up time-sensitive processing (aka starvation).

All in all though, still not a bad idea in theory. I don't know what tables could functionally be relocated to eeprom, but tuning tables like VE and spark this way would certainly reduce the need for slower and slightly more hazardous flash erase + programming cycles. I use the qualifier "slightly" because it seems flashhack is nearly bullet and idiot proof.

Edit: After some more tuning oriented thought, there are probably a half to nearly a dozen different constants that would be incredibly useful to have control over and would likely be extremely benign if fed transiently anomalous data. Injector flow constant, cylinder volume, prime pulsewidth multiplier, probably four or five I haven't thought about in two years. If easily relocated, those would be very useful for injector swaps and extreme VE / displacement changes.

[steveo]

i don't think we have to worry about anything reading from the eeprom while we are writing it , the big concern is interrupting things by 10 or 20 ms for sure. that delay probably needs to be reconciled and it might not be worth the effort. it could be done though. i do wonder what actually happens if you try to read while elat is set. i will experiment.
i think just being able to tune things on the eeprom would be cool enough. we could be doing spark table updates in a few seconds.