Corvette CCM Reverse Engineering Anyone?

[spfautsch]

and just to confirm this is the processor's onboard eeprom we're talking about, right?

I believe it is. Looking at the 68hc11e datasheet, the smaller eeprom versions had 512 bytes starting at $b600 which aligns with where the odometer triplet starts.

[kur4o]

Found 3 subroutine that write data to eeprom, first one is in the main code[I guess it updates eeprom on some regular basis, OCI1 triggered].

The other 2 are very intersting. They should be triggered when mode 2 and mode 3 is sent to ccm.

However when mode 2 and mode3 is requested it is handled by totally different procedure and the code will never run with these 2 eeprom write subroutines. They are really F_d up, and hard to guess what they do. I wonder if you enable mode 5 and make a jump to this piece of code what will happen. Maybe some reseting of the eeprom area[blank out].

I will keep digging.


Edit: the pin needs to be shorted only when you enter mode5. After that there is no need to be kept. In the loop aa response comes from different place.
It just indicates OK[ccm unlocked]

[spfautsch]

In the mean time I've been reading the 6811 datasheet and I'm contemplating writing directly to the eeprom. They give examples in assembler, I just need to translate to the right instructions / params.

Edit: You can abandon your disassembly efforts as it relates to the eeprom routines, we can write to eeprom.

Note - I stupidly used 02 reads instead of 03. I edited the responses for brevity so the checksums are wrong.

TX+F15802B7FFFF
RX+F19602393D
TX+F15605B4
RX+F15705AA09
TX+F15605B4
RX+F15705AA09
TX+F1670660008630C602F7103BB7B7FFC603F7103B0A
RX+NO REPLY
TX+F15B0660007F103B84
RX+NO REPLY
TX+F15802B7FFFF
RX+F196023046

Nevertheless, the last digit of the vin is now $30 (0) instead of $39 (9) even after removing power for several minutes. On to bigger and better things.

[kur4o]

It is not that straightforward as writing to ram than it looks. There are some registers that`s need to be set, and the timing is critical.

We can borrow some code form ee, where it updates the vin.

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