Corvette CCM Reverse Engineering Anyone?

[spfautsch]

See my edit to the previous post. When I'm done celebrating I'll show my work in detail.

Edit: So I basically just copied the example from page 60 of the datasheet. I found it on some some electronics reseller's site here: 68hc11e datasheet but I'm sure there are other / better / different copies floating around.

Bear in mind that I was changing a #$39 byte to #$30. If any 0 bits needed to change to 1s I would have had to first erase the byte before writing.

0660008630c602f7103bb7b7ffc603f7103b

mode 6 payload breakdown:
8630 ldaa #$30        load $30 into register a
c602 ldab #$02        load $02 into register b
f7103b stab $103b     store register b contents to address $103b - set EELAT bit - enables write mode to eeprom
b7b7ff staa $b7ff     store register a contents to address $b7ff (last byte of eeprom)
c603 ldab #$03        load $03 into register b
f7103b stab $103b     store register b contents to address $103b - set EPGM bit - enables programming voltage

# note - example jumps to a delay 10 ms routine, I simply sent the next command as quickly as possible after the previous 06 payload

0660007f103b

mode 6 payload breakdown:
7f103b clr $103b      clear EELAT and EPGM bits and return to read mode

Obviously working on multiple bytes more logic will need to be involved - i.e. waiting 10ms after enabling programming voltage, etc.

[kur4o]

FOund some other stuff. Byte_70CA bit $01 if it is set you can enter m5 without pin set.

Stock is FE, I guess if changed to FF, you will enter m5.

Too bad at one point there is a check a 607c value[ is mileage] and is compared against 8220[stock $64=100miles].
If it is over 70CA is rearmed to FE value

I suppose mileage is at least 2 words, one is lower and one is upper range.

Some eeprom examples to follow.

[spfautsch]

Yes, odometer storage is some weird $h!t. Near as I can tell the first byte is how many erased bytes there are from byte 2 to where two contiguous $FF or $00 bytes are encountered. My guess is they were worried about eeprom wear leveling. And I'm 100% confident the low 4 bits of the odometer are stored in some other unit such as VSS counts or something closely related. But it's certainly stored in eeprom. Haven't taken the task of identifying that one beyond theory.

I feel like I want to work on some other things, but none of those things are that important. I have to go into the office tomorrow and punch the timeclock so-to-speak. Maybe Tuesday I'll work on making the odometer increment by feeding the module some fake 4kppm data.

I'm just stoked to have essentially 0wned this module without the benefit of a service tool snoop log.

[steveo]

this is unreal progress. cant believe you had it nailed so quickly.

i would love to build this work into a user friendly tool like flashhack when you are ready

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

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