Corvette CCM Reverse Engineering Anyone?

[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

[spfautsch]

Not sure if that's what's employed here, but my interest in identifying the 81848 52 pin IC is because I've traced all the inputs that wake the processor to this chip. It's also handling all the other digital inputs and at least a dozen digital outputs.

Honestly, I'm not 100% confident I haven't already resolved my battery drain issue. I've had the salvage CCM in the car with all fuses in for several days and there's been no noticeable drain. I intend to reinstall the original that has some temporary repair caps installed to see how things pan out.

At this point my priority is to try and locate the reman pin and hope we can learn how to reprogram these units because it seems like the number of dealers / individuals that have the equipment and expertise to reprogram them is dwindling. Repairing them also seems a tall order - most of the solid state stuff on the board is Delco branded, making cross references a major pita.

[kur4o]

81848 can be referred as a ccm TPU unit. There is some shared memory within the 3-4000$ range where I traced one of the input to main code.

I suspect most of the input- outputs are handled by this chip and send to main cpu via shared memory region.

[spfautsch]

Let's call it IC "C" for brevity.

I was sort of hoping for a cross reference with possibly a datasheet. But I've traced everything out except 6 pins that have vias underneath the chip. I'm leaning towards this being SPI because it has four lines direct to the cpu pins 22 (miso), 23 (mosi), 24 (sck) and 31 (pa3 - assuming device select).

It appears to have 40 general purpose i/o pins, 12 are used as outputs and I've traced the other 27 back to sources, verified, etc. The inputs labeled feedback I assume are for open circuit detection. I'll continue to work on pin 10, but here's where I think most of these registers map to in (what I assume is) ram.

inputs:           register bit:
 8 ign3 (e4)                  8
 9 ign1 (e5)                  7
10 unknown (via under chip)   6
11 park lights on (d14)       5
12 disarm utd (d15)           4
13 r door sw (d16)            3
14 l door sw (c12)            2
15 key in sw (c11)            1 $6449
16 hatch sw (c10)             8
17 unlock ckt (c5)            7
18 lock ckt (c4)              6
19 arm utd (c3)               5
20 defrost req (d5)           4
21 diag mode (d6)             3
22 unused (d7)                2
23 oil float sw (f8)          1 $6448
24 turn flasher (f9)          8
25 seat belt sw (f10)         7
26 hi beam (f15)              6
27 unused (e14)               5
28 m clock feedback           4
29 data strobe feedback       3
30 data clock feedback        2
31 lcd data feedback          1 $6447
32 lcd blanking feedback      8
33 courtesy lamp feedback     7
34 defog control feedback     6
35 horn feedback              5

outputs:
36 low oil lamp (d13)         4
37 courtesy lamps (d12)       3
38 lcd blanking (d11)         2
39 rear defog (d10)           1 $6446
40 horn (c16)                 8
41 chime 2 (c15)              7
42 chime 1 (c14)              6
43 seat belt lamp (c13)       5
44 check gauges lamp (c9)     4
45 change oil lamp (c8)       3
46 door ajar lamp (c7)        2
47 security lamp (c6)         1 $????

It took a while to confirm $6446-$6449 because when messing with inputs, outputs become affected i.e. closing either door switch causes the courtesy lights to turn on. Likewise, when commanding outputs, some of the feedback pins change state as well.

To jump straight to the chase, I don't think the reman pin is coming in this ic. The only input not accounted for is VSS, which I believe is handled by the cpu.

I know quite a bit more but will only give generalizations now. All 8 adc inputs to the cpu seem to be accounted for. There's an unused one that would connect to E8 if the components were present. I think this is to accomodate another light sensor for a DRL option that I believe was only sold in Canada. The LCD outputs are all driven directly by the cpu pins PA4-PA7.

The other PLCC52 chip labeled 'delco 16126532' which I'll refer to as ic "B" appears to handle all the PWM outputs, but that's about all I've had a chance to trace down. My guess is that it does use shared ram due to the number of lines it shares with the uveprom and what I believe is a dram chip labeled 'delco 16089396'.