Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

FOund the mode5 code in the bin, but there is not much that it can do. It seems the ccm enters some loop where you can upload custom code. It still doesn`t make sense since there is no execute visible in the loop.

There is a Mode 6 that includes an execute, but the Mode 6 doesn't have the same warnings on it that the Mode 5 does, which makes me think it cannot be used to access the same regions that are used by Mode 5. Here it is for reference anyway:

ccmmode6.jpg

[steveo]

generally mode 5 enables mode 6, and mode 6 is where you can write a code segment to ram and execute it.

[kur4o]

I think there is an execute command too, but it might be tied to mode 5. It is a little different than the ee pcm, but still hackable. WHat will be much more harder is to create custom subroutine that is uploaded and writes data to the eeprom. Some stuff is availble for programming but I guess the more sensitive stuff is omitted.

The software address of the override pin is to be located at $644b bit $02. It should be set so you can enter mode6. I think mode 5 unocks the ccm so you can enter mode 6. Still not quite clear.

ALso the ccm seems to respond differently to F0 and F1 functional addresses. F0 is general communication and F1 is for special functions.

It will be great to get some sniff data from T2 logs of some of the more intersting stuff as options and vin querings and device control.

[NomakeWan]

ALso the ccm seems to respond differently to F0 and F1 functional addresses. F0 is general communication and F1 is for special functions.

Correct. F0 is for when the CCM polls the ALDL for an external device (such as a Tech 2). If there is no response to the F0 poll, nothing happens, the CCM continues to operate as normal. But if that poll is answered by an F1 command, then it executes whatever that command is before returning to normal operation. The CCM sends this F0 poll once per second.

[steveo]

The software address of the override pin is to be located at $644b bit $02. It should be set so you can enter mode6. I think mode 5 unocks the ccm so you can enter mode 6. Still not quite clear.

good find, kur4o. we can trace that back and find the pin for sure - just dump that address with eehack and fiddle pins until it flips the bit.

i'm certain that GM wouldn't let you run mode 6 commands without a mode 5 unlock first unless that hardware pin was grounded, so obviously you'd need to unlock the CCM with software during 'initial low mileage' state and that must be done with a mode 5 request. if it was just a hardware pin unlock they wouldn't bother putting that low mileage code in at all

[NomakeWan]

Interesting; why is it 40 57 0000 69? According to my documents this poll should only be 3 bytes, 40 55 6B. Where are the extra two bytes of 00 coming from?

[spfautsch]

It could simply be an impedance mismatch on the serial line causing noisy comms. All I know is it's working in the car only when the PCM has power. Also, aren't the uveprom based ECMs all 160 baud? Is it possibly trying to talk to an LT5 ECM? Just a WAG.

I've been digging through the processor datasheet looking for port register addresses. I think the key in switch pin may be a good point of reference because it triggers a wake interrupt. I'll try tracing it back.

[NomakeWan]

Only the pre-90 ECMs supported 160 baud. In 1990 with the introduction of the CCM, they all moved to 8192 baud (and went from Pin E on the ALDL connector to Pin M for good measure).

Also, figured out the weirdness with your poll. Your poll does make sense since the checksum is different. But both my documentation and an idle scan from a guy on Corvette Forums show the idle poll to be 40 55 6B instead. However, my documentation is from 1989 when the CCM was first introduced, and that user had a 1990 Corvette.

I went back and looked at a log that steveo had me take of idle traffic on one of my cars, and got 40 57 FF FF 6B as my CCM poll. I'm not sure which of my two cars this was since I didn't make a note of it.

I did however take other logs that were marked. My '94 showed the following polls:

94 Key Off: 40570C025B
94 Key On Engine Off: 4057FFFF6B
94 Key On Engine On: 4057FFFF6B

All very interesting. It would appear GM added two bits at some point after 1990. I wonder what the difference in poll is between key off and key on?

[kur4o]

F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B
[F0 56 F1 C9]

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

[F0 56 F1 C9]

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E 40 57 FF

41
67

02 rpm
F2 ad map
00 tps
4F coolant
4E mat
01 options 1
00 options 2
46
1A
C3
88 inj flow rate
00 mph
42 oil temp
FF tcnt
FF tcnt
00 ad trans temp
A0
A0

9B


10
59

08 option byte
4F coolant
02 rpm
00 mph

3E

Some y0body idle traffic.

You can try to fake the pcm sending some of the above replies than shut the bus by sending f1 mode 8 message.

I am looking for a sniff of y-body t2 session which never worked since t2 tries to shut the ccm. I want to trace the command send.

[spfautsch]

There is a Mode 6 that includes an execute, but the Mode 6 doesn't have the same warnings on it that the Mode 5 does, which makes me think it cannot be used to access the same regions that are used by Mode 5.

ccmmode6.jpg

I'm catching up on my reading, and just had time to digest this. I'd love to know where you found this, but will understand if you'd rather not share.

I might be thinking too primitively, but what if (assuming we can get an AA response to a mode 5 request) it's as simple as sending all 200 bytes of config data directly to $7105 and then let the module go to sleep? Edit: Or simply a chunk of instructions that copies bytes to ram?

Edit: NomakeWan - is 128209 in the ballpark for odometer on your '95 when you dumped it last? How about 124880 back in April 2020 when you first dumped it?

[NomakeWan]

Sounds neat. I'd be interested to hear how the speedometer functions. My guess would have been that the ccm uses the vss line from the pcm for that instead of aldl data.

Mind me asking what arduino you're using? Hardware or software serial? Around 2009 or 2010 I messed around with the mpguino project and got it talking to my VW over iso 9141. I recall building an op-amp setup for that, but I can't find the code. I know I have the parts and schematic stashed in an esd bag in my lab somewhere.

The one I'm using for this experiment is an Arduino Mega 2560. I had it laying around from jury-rigging my furnace after several botched repairs by a local HVAC company. Ended up with a completely new HVAC system this summer, which freed the Mega up for more experiments. EDIT: Oh, and I'm using Hardware serial. I'll use Software if I have to, but running the numbers the hardware should have no problem going to 8192 Baud; there's only 0.1% error at that baudrate with a 16MHz clock.

I will say I completely forgot that the CCM has a VSS line. D'oh. That's probably exactly what drives the speedometer considering I don't recall anyone with aftermarket ECMs mentioning the speedometer doesn't work. I'll still see what happens when I change the reported VSS value, but then I'll set it back to 00 and change the coolant temperature value instead.

I'm catching up on my reading, and just had time to digest this. I'd love to know where you found this, but will understand if you'd rather not share.

Edit: NomakeWan - is 128209 in the ballpark for odometer on your '95 when you dumped it last? How about 124880 back in April 2020 when you first dumped it?

Sadly because I acquired this information from another source, I cannot actually share the complete document. I wish I could. But if it's just information about mode requests, those I can at least crop and screenshot that.

You are right on the money with the odometer; it presently reads 128216 and has not changed since I took the latest log. This also confirms the "within 6 miles" inaccuracy of that register as quoted by the guys on the Corvette Forums.

[spfautsch]

I will say I completely forgot that the CCM has a VSS line. D'oh. That's probably exactly what drives the speedometer

I'd always assumed that since I've never had trouble with the speedo while logging with eehack. At most, I'd imagine the VSS it's getting from the aldl is used for fuel economy calcs.

I cannot actually share the complete document.

No worries, thanks for what you have shared.

I'm still figuring out the details on how the odometer is stored, but ironically it's not really even scrambled, byte swapped or stored in some oddball unit of measure. FF bytes seem to be ignored, presumably because there's some logic to prevent exceeding the maximum erase cycles. If you look at yours, the fifth byte is FF. But it wasn't back in April 2020. The low mileage salvage unit I have has a7 at $b602. 0x0a70 = 2672 and the unit read 2675 when I had it in the car. It's definitely something unique, and I think the 6 mile error is probably more of a side-effect of someone at Delco having a case of Friday afternoon when the programmer logic was specified.

By the way, I think the reason the odometer is stored in three places was due to some sort of federal mandate for digital odometers. Everybody seems to understand it to mean it's stored in three different physical places, but I think it's just a failsafe requirement in case an eeprom cell dies.

Edit: Btw kur4o, I think the eeprom starts at $b5fe and is 514 bytes. It's possible the initialize routine is skipping the first two bytes when it copies the structure to $7000. That would be a useful piece of information because there are lots of zeros following the odometer structure so it's difficult to tell how long it actually is.

[NomakeWan]

Yeah, big hand-meet-palm moment. Of course the speedo worked while logging; only the fuel economy stuff didn't work, but that's probably not even related to speed, but more related to the CCM not being able to get the injector constants and all that jazz. I wonder why VSS is even included in the stream in the first place? Sanity check?

Also, it does make me wonder if there's some other location in the CCM that is storing the "precision" byte for the odometer. Clearly the CCM alone knows the odometer, and clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading? Curious.

[kur4o]

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

If you can simulate the signal you can monitor registers while the mileage increase and when is written to eeprom. On soft shut down or at specific interval or is not stored at all if power is lost to ccm.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

[spfautsch]

... clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading?

Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

The ultimate goal would be to reprogram these completely with open source tools.