Corvette CCM Reverse Engineering Anyone?

[spfautsch]

I wasn't implying you should have to do all the work of coding steveo, but you'll probably save yourself a lot of grief by keeping my paws out of your source. I'll be happy to contribute whatever I can. Most of my notes are already in this thread and I'll continue to post as I continue to map out the eeprom. The only ask I have is perhaps a bench mode option that will listen and reply with some fake PCM responses to make the unit be happy, and quiet.

I've yet to do simple stuff like talking to the unit with "normal" comms to see if it has any dtcs, etc. Been too focused on cracking the eeprom nut.

Edit: The lower 4 bits of the odometer appear to be stored at $6b57 in units of 1/4 mile. Odd that it's in the same location on all the dumps we have. If I were worried about wear leveling I'd have allocated a number of cells, but the odds of all four dumps using the same byte out of any number larger than 2 seems pretty low.

[spfautsch]

Here's current progress on eeprom mapping. Some items are fairly easily confirmed, some a developed theory, and some just a wild-assed-guess. The number of question marks added after the info is relative to my confidence.

$b600: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00 = odometer minus low 4 bits = 0x2B8D0 178384 mi
$b612: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b624: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b636: 00 (33 bytes)
$b657: 05 = vss counter * 1k = 1.25 mi ?
$b658: 00 (21 bytes)
$b66d: 01 31 ff d6 ff ff ff ff ff ff ff ff ff ff ff ff ff ff = erase counter ??
$b67f: 4a 9f
$b681: 44 dc = olm remaining engine revolutions ??
$b683: 02 d6 37 48 2d 5b 34 c7 04 67 36 1e 17 91 49 46 31 01 1d a1 48 2e 40 5e 39 18 35 af 12 (dtc history ???????)
$b6a0: 13 04 = olm remaining miles ??
$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)
$b6a5: 01 (32 bytes)
$b6c5: ff 3a 
$b6c7: 02 manual trans ??
$b6c8: 00 00
$b6ca: fe = mode5 lockout
$66cb: 40 00 10 00 00 00 80 00 20 00 08 01 80 40 20 10 08 04 02 80 00 08 04 02 01 00 00 00 00 20 00 80 00 (33 bytes ff in 94 eeprom - poss. custom PCM polling msg ?????)
$b6ec: ff (259 bytes) unused
$b7ef: <vin> (17 bytes)

If anyone spots missing bytes or overlapping addresses please point it out and I'll clean it up. The hex editor I use doesn't support copying the hex conversion so a lot of this was typed while tabbing between my notes and ghex.

The erase counter is just an educated guess - I've noticed it increment several times after starting the engine and letting it idle, and most recently after resetting the oil life monitor (olm).

The oil life monitor stuff seems pretty straightforward, but I'm somewhat confused as to why the two counters are stored so far apart, and what the jumble of info between them might be. As such I'm giving this one two question marks. Whatever the case, I've noticed the remaining revolutions decrement from dump to dump when the engine has been running. After I cleared the olm from the dic controls the revolution counter was reset to 20000 (0x4320 hex) and the miles to 5885 (0x16fd).

On the vats code, I've no idea what the following two bytes are - my guess is tolerance. But the key code is stored at $b6a2 in the clear based on having dumps from two with 15s and one with a 9. Also, per NomakeWan's previously posted info, when the eeprom is read without the correct vats resistor the 02 request returns 00 00 00 for these bytes. And there appears to be an authentication routine for this, it's not as simple as hooking up a trim pot and finding the resistance. It appears a specific sequence must be recognized - i.e. key-in pin goes low, vats read, ign1 and ign3 go high and key-in also goes high. Just a guess but I tried all 14 values about 3 different ways last night and was unable to read these bytes from the salvage ccm.

Since we have no dumps from ZR-1s and all we have appear to be equipped with the C68 climate control, that's about as far as I can go on vehicle options. I do have a message out to someone I know with a 90's ZR-1, but he may or may not be willing / able to help.

One other bit I've noticed but haven't found in my notes yet is that the alarm status (aka utd status) seems to be stored in eeprom as well. My assumption is if I arm the utd and then disconnect the battery that the doors will lock when I hook it back up.

Plans are to try tickling the vss input with a tone generator today to see if the vss counter at $7057 / $6b57 increments. After that I might do something completely idiotic and try to zero the odometer triplet and erase the mode5 lockout bit / byte (on the salvage ccm).

steveo I notice an oddity when trying to read only the eeprom range with flashack. If I specify module f1 with offset b600 and 200 bytes (all hex) it complains.

ERROR! Some parameters are nonsensical.  Please check your settings in the advanced tab.

Not a show stopper but would save me a bunch of time dumping memory.

[kur4o]

Don`t take the addresses too much, since they might be valid only for 95 ccms. The 94 code is a litlle bit different and some of the data might be located at other places. There is also different p/ns per years mainly. If it is a 94 cmm it should work with all engines.

I still have no clue on the eeprom registers. In the disassembly they are used but can`t say what they do and how it is done. Interesting is that on ee code the vin is written straight without setting any registers. I guess it is unlocked for writing.

[NomakeWan]

Two things on the analysis.

First, engine revolutions and miles are not the only factors used for the oil life monitor. Oil temperature also affects the calculation. How this is actually used however is a mystery; is it a multiplier that increases recorded revolutions/miles? Or are particular temperature deltas stored in EEPROM? Not a clue, but the FSM says oil temp is used in the oil life calculation so it's something to consider.

For the VATS thing, what's likely happening on your salvage CCM is you're actually running into the security lockout. Every time an "incorrect key" is attempted to be used, a timer of 3 minutes starts. Every failed attempt resets this timer. So if you're using the trim pot method, you must wait 5 minutes between attempts. It's easy to forget about this limitation on the bench since you don't have the car's dashboard and relays giving you the feedback you expect.

EDIT: Also, I forgot, but thanks to user BlackW1dow we have some CCM poll data from the 1992 Corvette. From his idle scan logs, the CCM poll request is the same as the 94-96 (40 57 FF FF 6B), but the ECM response is longer than the 1990-1991 yet shorter than the 1994-1996. An example response from his car is here:

41 64 01 F3 00 5A 60 01 00 6F 0F D6 83 00 51 FF FF 86

From this, I assume that the layout is:
Device MessageLength RPM MAP TPS CTS IAT StatusBit1 StatusBit2 Revs InjectorOn1 InjectorOn2 InjectorScaler VSS OTS ?? ?? Checksum

[spfautsch]

First, engine revolutions and miles are not the only factors used for the oil life monitor. Oil temperature also affects the calculation.

Thanks, that might account for some of that info. I'd forgotten about oil temp being factored in. On the salvage ccm it's almost all zeros, but I also noticed the remaining miles was set to 7500 on it (I haven't messed with resetting it). I suppose this might be a ccm from a legitimate low-miles garage queen. It also has a really small # in the presumed erase counter.

what's likely happening on your salvage CCM is you're actually running into the security lockout.

I've considered that but I've been removing power between attempts and I'm not seeing any changes in the eeprom between attempts so I'm not sure how it would know there was a "penalty period" remaining. I don't have enough switches and buttons to simulate a key-on event on the test bench, but I might attempt it because I'd really like to confirm what vats resistor it wants. It's certainly not 15.

Edit: Anyone know how to query this thing for vehicle speed via mode1? I can't tell if it thinks it's moving or not.

[NomakeWan]

Edit: Anyone know how to query this thing for vehicle speed via mode1? I can't tell if it thinks it's moving or not.

http://gearhead-efi.com/gearhead-efi/def/aldl/A297.DS

[spfautsch]

Thank you! I've been searching for that for days.

Interesting, the option bits in message 1 look like it might align perfectly with $b6c6 - $b6c7 if bit 2 set = manual, bit 1 clear = LT1.

I wasn't seeing byte 13 of message 0 change, so I'm going to assume the ccm doesn't think it should record the miles since vats is still active and the engine doesn't appear to be running. Curious how your arduino experiment works out, but I'll just put the seat back in the car and test that way.

Edit: Interesting stuff, somewhat miffed that I failed to locate it on my own. Will save me dozens of hours of pounding the pavement. Option bits align perfectly with $b6c6-$b6c9. Interesting that there's an option for electronic throttle control, which wasn't available until 1997 model year if my assumption is correct. This info is a gold mine. FX3 and LTPMS option bits which were very rare back in the day, hints on how to enable diagnostic mode. Poof, mind blown. I feel like I've just turned the corner on the home stretch.

Edit2: The mileage calculation even confirms my odometer conversion thoughts. The odometer data presented in message 0 won't give the least significant 4 bits either.

[steveo]

steveo I notice an oddity when trying to read only the eeprom range with flashack. If I specify module f1 with offset b600 and 200 bytes (all hex) it complains.

yeah the way it's written right now is 'memory size' is the total size of the chip and 'memory offset' is just the start of useful data, so what you're actually telling it is the rom is 0x0200 bytes long, but to ignore the first 0xB600 bytes.
i realize the labelling isn't great. i can definitely add a few more parameters to make stuff better for this project.