Corvette CCM Reverse Engineering Anyone?

[steveo]

I better get some learning done on what these commands do and what you're trying to accomplish because I may be missing your whole point or just doing it all wrong. Maybe have NomakeWan try the same since he has a much better understanding of the protocol.

no, you're doing good, i just wanted proof that those commands are responsive or not to see if they exist. i'd say they don't.

I'm having an obscene amount of fun mapping digital inputs to (perceived) memory locations and physical pins. Also discovered how to crack open old db9 solder type connectors to harvest the pins so I have the capability to do much, much more. Thus far I have the bit and address(es) for the key in, left door switch, hatch switch, low oil, and high beam inputs. I'm as happy as a possum eating a sweet potato.

that's really valuable for sure, the more of those addresses you post and we can label, the faster disassembly of the program will go.

as soon as you manage to get the bit to flip that kur4o mentioned earlier, lets make sure it unlocks mode 5/6

[spfautsch]

I somewhat believe these things are more primitive than you would care to believe. Maybe I'm reading the stuff NomakeWan posted too literally, but if it says "upload to RAM will be denied" I tend to believe the eeprom write / erase stuff may not be required. The program shouldn't be trying to write to eeprom every time the odometer increments.

My hillbilly dissertation of how I think it might work is as such:

Mode 5 commands upload values directly to ram. I.E. VIN, engine code, transmission type (autos had a fluid temp sensor), odometer, etc. Then let the machine go to sleep and the eeprom compare / write function takes care of things. I'll experiment more with the english / metric bit tomorrow to see if it's retained after a power loss. If it is that will surely tell us something valuable.

I'm plugging along. Have the address / bit location for another 5 digital inputs. Not many more left before I have to start looking for ADC registers.

[NomakeWan]

The program won't be writing to EEPROM every time the odometer increments, no. The EEPROM should only be used for that initialization/remanufacture purpose via the Mode 5/6 request. That's why once that bit flips, it becomes useless.

[spfautsch]

Though this is not what I consider the holy grail at this point, the eeprom seems to definitely be used for storage of the odometer along with all the other configurables, both long and short-term. There appear to be no other non-volatile capable storage components on the board. The eeprom must be writable after the sacrosanct 100 miles, or where else would this data be stored? There are simply rules which we have yet to fully understand.

I have all the digital input pins mapped out to memory except the F10 seat belt switch. I'm learning as I go so things could change, but thus far the 8D section of the FSM has proven invaluable.

[kur4o]

Figuring the mode 5/6 access is only half the job. Than we have to write some code that is uploaded and updates the eeprom area with custom data.

As for the odometer being updated. I suspect it is updated in ram and before the module goes to sleep check if the values differ from the stored ones and stores the new data at the eeprom. What is interesting is that the data is stored at 3 different locations on the eeprom and is somehow scrambled. bit swapped or byte swapped or something.

There is still some commands that can program specific areas of the eeprom but it is still too messy in the code to figure how it works.

[NomakeWan]

Though this is not what I consider the holy grail at this point, the eeprom seems to definitely be used for storage of the odometer along with all the other configurables, both long and short-term. There appear to be no other non-volatile capable storage components on the board. The eeprom must be writable after the sacrosanct 100 miles, or where else would this data be stored? There are simply rules which we have yet to fully understand.

I have all the digital input pins mapped out to memory except the F10 seat belt switch. I'm learning as I go so things could change, but thus far the 8D section of the FSM has proven invaluable.

There should be something else, or some other way it's keeping track of the odometer. Folks over on the Corvette Forums have pointed out that when you program a "new" CCM via Mode 5, you can only get within 6-mile increments. Yet in-situ, the car is able to keep track of the odometer in 1-mile increments. So perhaps there's something to that there as well.

Sadly my '95 is quite irritated with me at the moment so I can't actually get reliable idle polls off of it. It'll be filled with irrelevant or missing data due to the PCM being pissed off. I'll still be doing an experiment to see if I can pretend to be the PCM and make the CCM and the dash happy, though, since I don't actually need the PCM for that. I can however point out a few patterns I found while messing around with it.

With the car having sat idle for a while, scanning the idle shows 10590000000097 for the C68 HVAC, and 4057000069 for the CCM poll. This just gets repeated constantly with no expected responses.

When the key is first turned on and the PCM actually responds to the first 4057000069 call, the next poll appeared as 40572089C0. Every subsequent poll appeared as 4057FFFF6B. After turning the key off again, the CCM poll changed to 4057A06366. I imagine that after I leave the car alone for over 30 minutes and the CCM is given a chance to go back to sleep, the idle poll will be back to 4057000069 until the next time I cycle the key.

EDIT: Confirmed. I left the car overnight, then plugged in and checked the idle comms, and sure enough it was back to 4057000069.

[spfautsch]

There should be something else, or some other way it's keeping track of the odometer. Folks over on the Corvette Forums have pointed out that when you program a "new" CCM via Mode 5, you can only get within 6-mile increments. Yet in-situ, the car is able to keep track of the odometer in 1-mile increments. So perhaps there's something to that there as well.

My guess is there's some vss counter stored along with the odometer. Interesting tidbit there, might help us determine how it's being stored.

I'm making progress slowly. Have many of the digital inputs mapped out to the I/O ic. By the way, does anyone recognize what this might be? I'm not finding much of use when I search for any of the numbers on it. Most of the digital inputs and outputs seem to be handled by this piece.

whats-this-ic.jpg

While mapping out the arm utd pin, I discovered that the upper byte of $644b seems to contain the state of the alarm. I also found that this seemed to survive a power loss, and discovered that it indeed somehow relates to $7105 (RAM) and $b705 (EEPROM).

[Tom H]

While I don't have much to offer to this thread, perhaps this one detail might be of interest. In working with the '97 PCM and I believe all those from '94 up, low power mode is entered by resetting the Power Monitor IC (PMIC). The circuit uses too much current to just stop the CPU. When the PCM wants low power mode it goes into a tight loop: bra *
After the watchdog/cop time out the PMIC doesn't power until it sees ignition voltage.

Any mod to the car that asserts leakage voltage on to the ignition: even a very short pulse will turn on my pcm.

Hope this is of some use.
-Tom