Corvette CCM Reverse Engineering Anyone?

[brian617]

That's a fairly common function (opening, closing drivers door) across many manufactures in order for modules to enter sleep mode. Learned this years ago when testing for parasitic drains. You sure went the long way around to discover that lol. However that is a very unusual parking sequence.

[spfautsch]

Well I did instruct you to laugh if you must. Evidently I don't do anything the easy way. :-)

I don't feel like it was wasted effort though - some of the larger tantalum caps on both boards look as if they may have been leaking. I'd rather been safe than have to yank the module out again.

Whatever the case, the outcome is that now anyone with the desire to remove the module can unlock it for programming, and do so without rare and expensive GM tools.

[steveo]

just snip the wire and power the CCM from ignition switched power.
or solve multiple problems and increase safety - put a battery kill switch in there and bypass PCM BAT around the switch so you retain BLM memory

[steveo]

... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....

[spfautsch]

just snip the wire and power the CCM from ignition switched power.

Not that I couldn't live without it, but this would cause the trip odometer and fuel economy stats to be lost, not to mention miles off the odometer, oil life monitor history, etc. The firmware doesn't seem to write to the eeprom after a drive cycle unless the alarm is armed and even then it's only storing the alarm status bit. The rest of this stuff seems only to be written at the beginning of a drive cycle (after engine is started).

... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....

If you feel so inclined, be my guest. As I mentioned, it's not big on my list, and I'd certainly need some help from you guys to patch anything. I've got bigger fish to fry than this pesky little turd.

[steveo]

i'm working on a routine for optimized writes to the onboard 68hc11 eeprom over aldl, without any persistent programs in ram.

the logic kind of goes like this:

- read contents eeprom

- compare each byte at a bit level and determine required operation per-byte (ignore/program and erase/erase only/program only)

examples:
bin has 0xFF, eeprom has 0xEF: erase only.
bin has 0xEF, eeprom has 0xFF, program only
bin has 0xEF and eeprom has 0xEF, ignore.

- generate 'instruction list' and pack instructions in optimized fashion into maximum aldl packet size.

- send instructions

- read back altered areas and verify (or maybe i will just do a checksum run)

does this seem like a waste of time for the CCM? sure is......

but this entire thing should be able to be used to work with the internal eeprom on an ecm like EE so we can store tables both in e-side and t-side unused eeprom, which could be written very quickly with zero risk, so if someone wanted to relocate some critical table for rapid re-tuning, we'd be good with that.

if it works out, i will rework the EE flash tool so it simply compares/writes/whatever the onboard eeprom(s) right from the bin along with the main program, this should work seamlessly with the bin compare tool (you know, the one that figures out if we even need to write the t-side and e-side..), so if someone wanted to modify the onboard eeprom area in their bin, it would just reprogram that.

[In-Tech]

i'm working on a routine for optimized writes to the onboard 68hc11 eeprom over aldl, without any persistent programs in ram.

the logic kind of goes like this:

- read contents eeprom

- compare each byte at a bit level and determine required operation per-byte (ignore/program and erase/erase only/program only)

examples:
bin has 0xFF, eeprom has 0xEF: erase only.
bin has 0xEF, eeprom has 0xFF, program only
bin has 0xEF and eeprom has 0xEF, ignore.

- generate 'instruction list' and pack instructions in optimized fashion into maximum aldl packet size.

- send instructions

- read back altered areas and verify (or maybe i will just do a checksum run)

does this seem like a waste of time for the CCM? sure is......

but this entire thing should be able to be used to work with the internal eeprom on an ecm like EE so we can store tables both in e-side and t-side unused eeprom, which could be written very quickly with zero risk, so if someone wanted to relocate some critical table for rapid re-tuning, we'd be good with that.

if it works out, i will rework the EE flash tool so it simply compares/writes/whatever the onboard eeprom(s) right from the bin along with the main program, this should work seamlessly with the bin compare tool (you know, the one that figures out if we even need to write the t-side and e-side..), so if someone wanted to modify the onboard eeprom area in their bin, it would just reprogram that.

I like your thoughts steveo, I might have missed it, how do plan to implement the bit toggle without using the internal ROM/RAM allowance of voltage? Seems like you are looking at EEprom attributes to set and not programming. I'm learning here too.

[In-Tech]

Maybe it doesn't apply to this. Years ago in the 90's I think, and not this controller but who cares, still Motorola based, I made a dumper that would show the EEprom attributes for the unknown readable,writeable,ram,rom areas. Then I wrote a program using its' internal rom routines so I could change whatever to whatever. Basically I could change the attributes of the flash to whatever I wanted. Of course all 8 bit crap back in the day but it seems this is what we are dealing with too. All of these controls are built into rom as they have to be for whatever the MANufacture wanted them to be, mostly secured in my experience except for car crap, car crap is stupid dumb and many years behind. I was doing iso7816 crapola.