Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.

This is actually really good information. I recall a few threads over on the Corvette Forums of people experiencing this phenomenon (including the relay randomly cycling) but couldn't figure out what was going on. Now you've documented the likely culprit, which is excellent. I'll have to keep that in mind on my own vehicles; though at least so far I still enter and exit from the driver's door, so I haven't experienced that issue yet personally.

I wonder if that's something that could be patched out in firmware? Make it so it'll sleep regardless of the driver's door cycling after, say, the same amount of time as the Delayed Accessory Bus timeout?

[spfautsch]

Unsoldering and socketing the uveprom isn't on my bucket list at the moment. Only when the reman unit comes back to me will something like that even be on my radar. I'm certainly not removing the original unit from the car again until perhaps when the carpets and seat covers are replaced.

In the mean time my workaround will be to attempt a current sense circuit that will give me a green led indicating the CCM is in sleep mode. Hopefully I'll be able to do that with a fuse tap so no wiring will need to be modified. If that works I can always tap a momentary pushbutton into the left door ajar wire that can be triggered from the passenger seat.

This wasn't as much of a problem until my 'good' battery maintainer died. It would run a charge cycle when the battery got down around 12.1v. The cheapo HF maintainer that replaced it will let the car eat the battery.

By the way, when steveo is done you're still welcome to take a turn with the reman if you'd like to use it for your arduino PCM simulator project.

[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.