Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

i definitely seem to be getting some garbage but no heartbeat.

if i disconnect the CCM, the ecm responds, so i know it's alive.

i've tried both calibrations 16200891 and 16209281 from my site.

here's what the CCM is spitting out, the ECM does not seem to respond from what I can see, but the ECM is certainly there, as if i disconnect the CCM, the ECM responds.

any idea why they aren't handshaking or whatever they're s'posed to do ?

13430ms to 13540ms (110ms) :: 10590887020006 40574E9F7C 416702000087004800000000880004E84900A0A08A
::: GAP78ms
13618ms to 13743ms (125ms) :: 10590887020006 4057E84938 41670200008700480000000088000481DA00A0A060
::: GAP78ms
13821ms to 13946ms (125ms) :: 10590887020006 405781DA0E 4167020000870048000000008800041B8400A0A01C
::: GAP78ms
14024ms to 14149ms (125ms) :: 10590887020006 40571B84CA 416702000087004800000000880004B51500A0A0F1
::: GAP78ms
14227ms to 14352ms (125ms) :: 10590887020006 4057B5159F 4167020000870048000000008800044EC000A0A0AD
::: GAP78ms
14430ms to 14524ms (94ms) :: 10590887020006 40574EC05B 416702000087004800000000880004E85B00A0A078

That looks totally normal, and in fact the ECM response is right there. I'm not sure why EEHack's idle scan has such weird spacing, but it always has. I've altered your above logs to have the correct spacing to make it more clear.

To elaborate, the 10 message is the HVAC broadcast (no response expected), the 40 message is the CCM polling the ECM, and the 41 message is the ECM responding to the CCM.

What's interesting to note here are the timer bytes in the 41 response. This makes me really really really want to know what "word_1983" is in $EE, because whatever that timer is, it's apparently being used by the CCM. The values of those two bytes in the ECM's response then reappear in the mystery bytes of the CCM's next poll. This explains why the CCM's initial poll before the ECM comes online is 4057000069, and why eventually it just becomes 4057FFFF6B. But knowing what these intermediate values mean (and perhaps finding out why GM thought it important for the CCM to echo these values in the 40 poll, something they only started doing in 1992) would mean figuring out word_1983.

kur4o, any insight into that particular area of the $EE program?

[kur4o]

1983 seems related with vats communication between pcm and ccm.
0000 means theft not completed, and some initial timer expired.
FFFF means theft completed pcm unlocked
random data means there is info exchanged between pcm and ccm

It is also related with the data ccm polls to pcm the 2 bytes of the 40 message.


In Steveo log there is something wrong with that, it doesn`t follow the earlier discovered patterns. Maybe the pcm-ccm communication is stuck at that theft loop and untill finished there will be no broadcasting.

Edit: also found another 40/40 request response in the code. the massage is 10 bytes long and is again y-body related, some of the data is similar to 40/41 message.

Could it be for older ccms or newer ones.

[steveo]

That looks totally normal, and in fact the ECM response is right there.

In Steveo log there is something wrong with that, it doesn`t follow the earlier discovered patterns. Maybe the pcm-ccm communication is stuck at that theft loop and untill finished there will be no broadcasting.

you're right, i see the ecm responding, but if the CCM saw the ECM's reply as okay, wouldn't it begin sending the usual F0 56 xx [checksum] where xx is the current id of the bus master

if certain CCM configurations wont work with certain ECM configurations, i'd definitely like to understand what's going on there, otherwise people using this software to help with CCM replacement might not have much luck

Maybe the pcm-ccm communication is stuck at that theft loop

theft loop ?

[kur4o]

I suspect theft communication is critical and before it got initialized ccm wont go over normal communication mode and will loop the pcm till hadshake is good, Also at reset or ign on if modules are powered at different time it might be an issue.

spfautsch points at the start of the thread that the ccm polls change from 0000 to xxxx to ffff and than works as normal.

Actually that poll is some seed to pcm and pcm will return key at 41 response word_1983

[spfautsch]

Try asking for mode 1 message 0 - byte 1 is vats status:

 1     0-2  UNIVERSAL THEFT DETERRENT STATE
                0 = PASSIVE
                1 = ACTIVE
                2 = DOORS ARMED
                3 = DOORS AND HATCH ARMED
                4 = ALARM
                5 = ALARM TIMED OUT

Or on my bench I connected a led to the security pin on C6. If it's lit solid with switched 12v on you've triggered vats. If so you'll need to remove the switched power (IGN) and leave it powered up on unswitched battery until the penalty period times out. That could be as long as 12-15 minutes. Double-check the vats resistor connections also.

You may have to trick it into passing vats by simulating a key-in, then applying power to E4. < Edit!

Another possibility is that it wants to see the left door switch triggered before key-on. I wonder if there's some mechanism involving word_1983 that changes the vats requirements. I know it worked on the test bench without any of the key-in or door open trickery, but that was after it had already passed vats while connected to my test bench PCM with said trickery.

[steveo]

ok i get it. powering the whole rig up at once might not be good enough. i'll go ahead and put a switch on IGN and play with it until it works.

[spfautsch]

Sorry for all the difficulties - I sent some extra connectors on pigtails but in hindsight I should have also sent you a LED for the security lamp output.

Another possibility - if the alarm has been triggered you'll need to disarm it by grounding D15. It's also stored in eeprom so you can't turn it off by removing power.

[steveo]

no no, im glad im approaching this blindly, ill have to write documentation for how it works so these failures are invaluable.

ill rig up an led.

so the vats resistor, is that done in hardware? if you replace the ccm, you need to change all your keys too? that sucks

[spfautsch]

The vats resistor is stored in eeprom

$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)

I'm not sure what the aa and 55 bytes are but 0f is the the resistor code. These are some of the locations that return 00 with mode 2 or 3 if vats is active. The values are easy to find - I reprogrammed that unit for code 11 (0x0b) which is 4.75k ohm. I also had it programmed for 15 when I had it in the car and put the 44 miles on it.

The led just needs a 1k limiting resistor to +12v - the CCM output switches to ground.

[steveo]

this thing is funny. i will have to try some more tests. i had IGN disconnected and grounded D15, and it woke up and started trying to talk to the ECM again (but same security issue). the 'security light' never lights, i have a continuity tester with a buzzer hooked up. still ends up in the same communication state

[spfautsch]

With only power to F1 and ground on E16, < edit, had letters swapped] try grounding the drivers side door input - C12. Regardless of security system state your buzzer should cycle on and off about 1.5 times per second.

And yes, almost all digital input pins will wake the unit and cause it to start spamming the aldl.

[NomakeWan]

I suspect theft communication is critical and before it got initialized ccm wont go over normal communication mode and will loop the pcm till hadshake is good, Also at reset or ign on if modules are powered at different time it might be an issue.

spfautsch points at the start of the thread that the ccm polls change from 0000 to xxxx to ffff and than works as normal.

Actually that poll is some seed to pcm and pcm will return key at 41 response word_1983

This looks like a winner and exactly what I would need to know if I were to make a middleman to drive the dash. If it's a call-response key exchange, then I'd need to be able to respond accordingly. Great work so far, looking forward to more updates!

I agree that it looks like an anti-theft loop. The lack of F0 polls is typical for when the CCM is in key-off-engine-off mode. It only starts polling for a scan tool with F0 polls once in a key-on state. As spfautsch stated, this is likely more complex a dance than just applying +12V to all the +V pins. It will likely need to be done as if this were a real car in-place, including the VATS resistor (and key switch!) and having Battery12V be on before Ignition12V.

This could also explain why EEHack and other scan tools get a bunch of "junk" data if the VATS resistor isn't reading correctly at key on; the CCM isn't doing F0 polls, so you're shouting into the void and getting whatever data back just happens to be on the line rather than what you're actually asking for.

[kur4o]

Some initial theory how it works.

Pcm responds for 2 seconds with 0000 at reset. Maybe some time for initialization.

Ccm sends seed to pcm.
Pcm process seed and convert to key. Respond with some random timer data.
ccm sends key
pcm matches precalculated key with ccm key. If all good pcms sends FFFF.

I think if the pcm response with ffff, that might fool that all is good. Anyway it is the pcm that needs to start the engine. CCm doesn`t care much.

Steveo you can give it a try with some fake pcm responses.

[steveo]

With only power to F1 and ground on E16, < edit, had letters swapped] try grounding the drivers side door input - C12. Regardless of security system state your buzzer should cycle on and off about 1.5 times per second.

And yes, almost all digital input pins will wake the unit and cause it to start spamming the aldl.

i ran the test and got the expected result, so that means my security light works, right? it's not triggering the security light during normal operation.

i tried cutting IGN (but not BAT) for a few hours and then came back and connected it again, same result.

not sure what else it could be. there is definitely no heartbeat frame and the CCM definitely does not want to shut up

i would buy that there's some preconditions for the CCM to think it's in a vehicle and everything is okay, but that doesn't explain why it was working on the bench for you ?

also just tried a simulated key insertion - connect BAT without resistor or IGN, then add resistor, then IGN.

[NomakeWan]

i ran the test and got the expected result, so that means my security light works, right? it's not triggering the security light during normal operation.

i tried cutting IGN (but not BAT) for a few hours and then came back and connected it again, same result.

not sure what else it could be. there is definitely no heartbeat frame and the CCM definitely does not want to shut up

i would buy that there's some preconditions for the CCM to think it's in a vehicle and everything is okay, but that doesn't explain why it was working on the bench for you ?

also just tried a simulated key insertion - connect BAT without resistor or IGN, then add resistor, then IGN.

What about pin C11 on the CCM? That's on the grey connector. It's the "key in ignition" switch I was referring to before. When the switch in the car is active, it connects that pin to ground.