Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

The CCM does contain an EEPROM where things like VIN, available options (C60 vs C68 climate control, engine type, etc) and odometer are stored. These values are volatile until 100 miles have accumulated on the odometer, after which a bit is cleared that causes the CCM to no longer accept download requests to RAM (EEPROM). Inside the CCM somewhere is a pin that, if grounded, will override this bit. I haven't taken a CCM apart so I have no clue where it would be, but I highly doubt it'll just be plainly marked so that anyone and their dog could find it since it's so critical to the integrity of the data on the CCM. Additionally, as far as I know no one has actually reverse-engineered the communication required to retrieve and/or set the values in this EEPROM. I do have a Tech 2 handy, but as neither of my Corvettes have less than 100 miles on them and I don't feel like tearing apart perfectly-working CCMs, I haven't bothered to see if my Tech 2 comes with those abilities.

The CCM does not have any ability to query other modules to set values in EEPROM. These are only set by an external tester (Tech 1A, Tech 2, etc).

The CCM is also what drives the digital dash on our Corvettes, and is the bus master, and the central security system for the vehicle, among many other tasks. It even handles control of the rear defroster array, independent of the climate control. Replacing the CCM with something else would be a massive undertaking.

Replacing the PCM with something that makes the CCM happy, however, is not. It was already done by Torqhead using a '411 PCM. As for the protocol, the data you're looking for is $40 and $41, where $40 is the CCM making a regular poll of the PCM, and $41 is the response from the PCM containing all available data. The structure of this is in the image below.

ecmccm.jpg

I agree that having open-source tools for all of these functions should be a priority. GM certainly isn't going to support us any longer, and having Torqhead be the only ones who can sell you a solution is not optimal for those of us who would want to cobble something together ourselves. I'm still planning on reverse engineering the ABS communication so that people can recalibrate their TPS or perform the auto bleed function on 95-96 Corvettes without ponying up the cash for a Tech 2 or praying their local Chevy dealer can help for exactly that reason.

[steveo]

i'd be willing to help build a tool set into eehack or flashhack if you tell me what aldl commands are necessary, i think it would be a good idea to merge stuff like this rather than fork if you'd be into it.

i would hope there would be some serious protection on updating the CCM's eeprom as it does contain the mileage

These values are volatile until 100 miles have accumulated on the odometer, after which a bit is cleared that causes the CCM to no longer accept download requests to RAM (EEPROM). Inside the CCM somewhere is a pin that, if grounded, will override this bit.

do you have any documentation of that at all ?

[spfautsch]

Inside the CCM somewhere is a pin that, if grounded, will override this bit.

Mind my asking where you uncovered this tidbit? My assumption was that the eeprom would have to be erased directly with a jtag type device. This also gives me something to look for on the remanned unit.

I'll get some high-res pics up shortly.

The CCM does not have any ability to query other modules to set values in EEPROM. These are only set by an external tester (Tech 1A, Tech 2, etc).

Is this info from the FSM? Mine haven't arrived yet. I'm not disputing this statement but it seems like if it can ask the PCM for message 41 it could also ask it for the VIN, and derive the engine code from that. Though I doubt that's the case.

Also wouldn't the VATS voltage / resistor code have to be set here?

Am I correct to assume the odometer is stored solely in the CCM?

Replacing the CCM with something else would be a massive undertaking.

Exactly. Without it you have no speedometer and the engine can't be turned over unless the starter disable relay is bypassed.

I guess I've gotta go to eBay and get a Tech2 on the way from Hong Kong. I'm very interested to know if this remanned unit has had the eeprom cleared.

[steveo]

Is this info from the FSM? Mine haven't arrived yet. I'm not disputing this statement but it seems like if it can ask the PCM for message 41 it could also ask it for the VIN, and derive the engine code from that. Though I doubt that's the case.

i don't know much about the ccm, but based on how GM did things in those days, i don't think that's what's going on.

Mind my asking where you uncovered this tidbit? My assumption was that the eeprom would have to be erased directly with a jtag type device. This also gives me something to look for on the remanned unit.

I'll get some high-res pics up shortly.

it does make some kind of sense that they'd design the unit to prevent tampering with the odometer after x miles had been travelled, it's possible there would be a workaround for that, though.

we do have a memory dump of the CCM but it might be faster just to see what the TECH tool is doing.

[spfautsch]

Here's a couple quick pics of the board (click for full res).





Though I also doubt the unit can self program the VIN and options, I have seen mention of a learn procedure for the VATS resistor value over on cf. I guess I'll have a deep reading assignment on my plate when the FSM arrives.

I'm very reluctant to drop $370 on a chinese clone tech2 for fear the only thing I'll learn is that it can't talk to this antique module.

[kur4o]

T2 won`t help much. Here is what we have as data.

Now it needs to be cleared what is on the eprom.

I suspect eeprom is stored in the processor, which seem as some variant of 68hc11.

The main bin can be stored to the eprom or inside the processor too.

Noticed some options configuration. Here we might have it at the eprom also.

Someone posted dumps of ccm and I even managed to make a disasembly of them, but couldn`t figure anything specific.

You can read the ccm with flashhack and post the dump too.

Step too. Unsolder the eprom and try to det a dump of it, also put a socket, in case a deeper hackjob will be needed.

We also need to figure what went wrong with the ccm and figure if that consuption is the result of the ccm or something else keeps it alive.

Newer modules have something called go to sleep after predefined time elapsed. Also it sends messages to other modules to wake and sleep them. Something similar might be used here and something might be preventing the ccm to go to low power mode.


Tom H have deeper insight about the vats exchange info between pcm and ccm. It is some password related cycling of some data that is still unclear in the dissasembly.

There was some post somewhere in the corvette forums about repairing ccms, and updating the vins, but was paid top secret stuff. Someone might dig up the threads.

Also adding some datalogging to eehack of that module will not be hard at all, since the stream data is available already. Not so sure about handling dtcs.

[kur4o]

Just looked at some diagrams. Freeking complex unit, operating almost anything in the car. Including driving directly the instrument panel.

The 31 32 pins your are reffering are like pins F1 and F2 -battery input. ALso tons of inputs that wake up the module. I guess it goes to sleep when all is quiet, and the car is locked.

Some interesting pin is d6 -diagnostic enable. Goes to DLC terminal 12. Likely when it is grounded or resistored like 4-10kohm it runs some tests.

[spfautsch]

Thanks kur4o - saved me a bunch of money there. I've done a little bit more searching over at cf and found where they used a tech 2 to dump a PCM and then a tech 1 on the CCM so was suspicious the functionality didn't exist in the newer tool. Looking at the 1, it seems like it needs a memory card for CCM / BCM programming. :-\

I'm looking for the aldl pin to try and dump them on the bench. Then will hook up the original one in car and see if it shows any DTCs. I wasn't seeing the SYS message, but maybe not all DTCs trigger that. I highly doubt that the remanned unit has the same fault as mine, but anything's possible. I'm pretty sure in some model years, leaving the key in the ignition would cause the CCM to never go to sleep.

I noticed a VIN (in two places) in the two dumps NomakeWan posted in the other thread so I'm hoping to find out if the eeprom in the remanned unit has been wiped. It would really suck if the eeprom is integrated with the processor though. I don't see anything that looks like a jtag type pad except for the 5 next to the 28 pin SOIC in the lower right corner. They're just vias to bring those traces to the other plane, but the spacing seems suspiciously uniform.

I wonder if diagnostic enable might be the "magic" pin.