Corvette CCM Reverse Engineering Anyone?

[spfautsch]

e13 and f12 are the aldl pins.

Thanks, that helped me make sense of the pin numbering terminology. They're numbered 1-16 right to left, so what I was calling gray 31 & 32 are F1 and 2 and grounds are on E15 and 16. I assume the gray connector is c and d. Maybe the unpopulated 40 pin IDC header is a and b?

I'm not getting anything with only one serial pin connected, so am having to find connectors to add a second.

Oddly, I'm finding when I power up the board without applying power to the CCM1 and CCM3 circuits, the board sometimes comes up in sleep mode, and sometimes doesn't, but seems to go to sleep eventually. Both of the two additional power circuits are unswitched to battery afaik.

[NomakeWan]

Thanks, that helped me make sense of the pin numbering terminology. They're numbered 1-16 right to left, so what I was calling gray 31 & 32 are F1 and 2 and grounds are on E15 and 16. I assume the gray connector is c and d. Maybe the unpopulated 40 pin IDC header is a and b?

I'm not getting anything with only one serial pin connected, so am having to find connectors to add a second.

Oddly, I'm finding when I power up the board without applying power to the CCM1 and CCM3 circuits, the board sometimes comes up in sleep mode, and sometimes doesn't, but seems to go to sleep eventually. Both of the two additional power circuits are unswitched to battery afaik.

Please see below the relevant pages for pinouts related to power supply and ALDL comms.

ccmwiring1.jpgccmwiring2.jpg

[kur4o]

I found the disassembly I made while ago.

The ram is located at $6000-65ff the eeprom is located at $7000-$71ff main code is at 8000-ffff, first part containing some calibration details, than main code.

We have $200 bytes of eeprom.

NomakeWan can you make an updated dump of the ccm you have. Hope thay gathered some mileage, so we can identify some stuff pretty quick, if the eeprom increase at some places.

I think figuring some commands and sequences will not be hard at all when we label the eeprom.

As far as the secret pin. It is most likely connected to the a/d channels of processor and will have some 12v voltage, when grounded it will override something in the code.

Figuring other grounding inputs inputs and tracing the pcb patterns will likely find the secret pin.

[kur4o]

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.

Also I think I spot the bit that prevents the mode5 entering. It will be esily patched if we have access to writing a custom bin.

Now the main question. What should I expect from mode 5.


Edit;

I think some polling of the ccm will be great. Sending different modes and submodes commands over the aldl bus and recording the reponse.

The CCM ID is f1 or f0. There is also tons of other ids in the code, but it will take some time to figure the usage.

[NomakeWan]

NomakeWan can you make an updated dump of the ccm you have. Hope thay gathered some mileage, so we can identify some stuff pretty quick, if the eeprom increase at some places.

Sure, I can do that later today. I've put plenty of miles on the car since I took those dumps.

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.

Also I think I spot the bit that prevents the mode5 entering. It will be esily patched if we have access to writing a custom bin.

Now the main question. What should I expect from mode 5.

ccmmode5.jpg

[spfautsch]

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.

What if it doesn't need to execute any code? The documentation for mode 5 reads as upload to ram. In these dumps a copy of the eeprom data is present at 0xB600. What if the code works solely on the copy in ram, and the eeprom compare / write procedure is triggered before sleep mode is entered, or by some other mechanism (key off, etc.) so as not to wear out the eeprom?

I have considered the fraud tangent and that does trouble me somewhat. State laws are different on the subject, but in Missouri the lines become somewhat blurry once the vehicle is more than 10 years old. At that point the prosecutor has to prove intent to defraud. So you get back to the same moral dilemna that exists where we ask do guns kill people or do people kill people.

Hoping to have a thorough look at things this weekend. I'm incredibly perturbed that the remanned CCM wasn't remanned. I'm almost certain nothing at all has been done with it because the security light never went out, telling me it's probably programmed for a different VATS pellet.

[kur4o]

Found that eeprom is located at b600 $200 bytes long. At reset the values from eeprom are copied to ram at $7000. Than at some point some of the values are again copied to regular ram area.6000-7000.

There is also some other small area 0-ff used as ram. It is also utilized when mode 5 is entered[used as stack].

Found 2 subroutines in the communication stuff that writes values to eeprom. Too complex yet to figure. Maybe some submode of somthing since are labeled as mode2 and mode3, maybe it is a submode of something else.

spfautsch,
When you have time, you can play with custom send messages through eehack raw commands.
You can poll the ccm with all modes and submodes, looking for response, negative answers and so on.

Do you have the p/n of ccms. I found that each year uses different p/n. On the 95 files you dumped with NomakeWan, there is only 2 byte difference at 8000. maybe this contains options or something like that. Will be really interested to see what is stored on the eprom.

[spfautsch]

I'm working on trying to get the board to function on the test bench so I can do this without going back and forth to the garage. Once I have that figured out I'll start trying some aldl messages.

I don't have all the equipment with me to test that so I'm working on mapping the ADC pins on the processor. It appears there's an unused analog input on E8 / AN6. The components aren't populated so it isn't actually connected to E8 but the pads and traces are there for it to be.

I can't tell for sure but it appears there's a voltage sense circuit on both AN0 and AN7. One heads towards the power supply section and the other receives power from rail side of the fuel level sense resistor. I'll have to dig into this with the board powered up to figure out which is which. One might be for battery voltage and the other for the 5v rail / brown out detection.

The rest are accounted for as such:

E7 - IP Dimmer - AN3
E9 - Fuel level - AN2
E10 - Ambient light sensor - AN5
E11 - DIC buttons - AN1
E12 - PASS resistor - AN4

Part # on the ones I have is 16223622. The other pn RockAuto has a cross reference for is 16230561.

[NomakeWan]

Found that eeprom is located at b600 $200 bytes long. At reset the values from eeprom are copied to ram at $7000. Than at some point some of the values are again copied to regular ram area.6000-7000.

There is also some other small area 0-ff used as ram. It is also utilized when mode 5 is entered[used as stack].

Found 2 subroutines in the communication stuff that writes values to eeprom. Too complex yet to figure. Maybe some submode of somthing since are labeled as mode2 and mode3, maybe it is a submode of something else.

spfautsch,
When you have time, you can play with custom send messages through eehack raw commands.
You can poll the ccm with all modes and submodes, looking for response, negative answers and so on.

Do you have the p/n of ccms. I found that each year uses different p/n. On the 95 files you dumped with NomakeWan, there is only 2 byte difference at 8000. maybe this contains options or something like that. Will be really interested to see what is stored on the eprom.

My '94 is an automatic with auto climate control. My '95 (the one that I did the new dump for) is a manual with auto climate control. I hooked my Tech 2 up to the '95 and it did display the transmission type as one of the CCM options, so that should be at least part of it.

I can't get a dump of the 94 right this second because it's in storage. As soon as I get a chance I'll get you a second dump, since yes, it's accumulated mileage since the first dump as well.

[steveo]

good stuff guys, keep it coming.

we could definitely get some core info on the available data in the eeprom region by comparing different dumps from different cars.

i would assume they are programmed using gm code that is uploaded to ram just like the 8051 is programmed so we would definitely have to find that pin to renable it. once that's found we likely wouldn't need a full comms loop like the 8051 since we aren't reprogramming the main rom, we could likely get it in one shot.

it's possible we could steal some code from $EE to help. we'd need to look at the routines that comms mode 12 calls which sets the VIN and calibration ID in the processor's eeprom. it's likely that we could just change the addressing and figure out how to overwrite whatever we want.

[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