Corvette CCM Reverse Engineering Anyone?

[steveo]

good theory, didn't seem to make a difference. i tried a few more sane combinations of stuff.

you would figure connecting the battery with 'key in ignition' and 'vats resistance correct' would be okay, and then IGN.

if things like 'connect battery with key already inserted' caused a no start condition there would probably be a recall.

another thing that bothers me is that this is a diagnostic bus, the theory that it would be in an unusable state because the state of every sensor and pin not being perfect doesn't make sense from a design standpoint. how would a diagnostic technician be able to figure out, for example, that the 'key in ignition' switch had failed without the ALDL being useable? there's no way GM would say 'until the vehicle is perfect you get no diagnostic information'. that's like saying 'it's illegal to visit a doctor until you are in perfect health'.

[NomakeWan]

I mean, sure; but there's still security. They clearly cared about adding some sort of security to the bus in 1992, since there's those handshake bits in the 40/41 messages that weren't there in 90-91. And even in 1990, there were parts of the CCM that would be locked out if the correct key was not inserted.

But it is interesting that for whatever reason, you're not getting the "key on" operation from the CCM, only the "key off" operation. You've got +12V going to F1+F2 constant, and then switch on +12V to E4 and E5? Just sanity checking here.

[steveo]

are you sure that's what's happening? it's not a case of an inappropriate ECM response, it isn't in a key-on state? can you tell that from the current communications somehow ?

i have not connected E5 (edited)to anything, should i?

i have, right now:

- security light between C6 and +12v (confirmed working earlier)
- ground to C11 (key in thing)
- +12v to F1 and F2
- +12v to E4
- ground to E15
- E12 to F5 resistor (no security light, so probably correct)
- ALDL to F12

there are alligator clips and twisty wires involved but i am confident everything is connected.

i plan to build a better idle traffic scanner in flashhack too, might be helpful.

[steveo]

i built a better idle traffic scanner. here's the CCM/ECM datastream right from boot if i just power the whole bus.

flashhack Version 1.1
Scanning ALDL 40 messages with timeout of 10000ms
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 AF 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 AF
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 3F 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 3F
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 E8 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 E8
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 7C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 7C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 0C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 0C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 B6 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 B6
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 48 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 48
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 F1 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 F1
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 82 00 FF FF
IDLE: [DEV:10] 08 87 02 00

edit - here is the CCM with no ECM on the bus:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00

[kur4o]

Steveo can you run some pcm patch.

1b8e5
[26 0e] --> 01 01

I still suspect some theft loop. The ccm is not unlocked at just echo the key instead of calculating a key from pcm seed.

The patch will force pcm to get unlocked and hopefully provide good data to ccm[FFFFs].

[steveo]

so here's a code sample:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04

to quote kur4o:

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.

what i'm observing:

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it

[steveo]

Steveo can you run some pcm patch.

1b8e5
[26 0e] --> 01 01

I still suspect some theft loop. The ccm is not unlocked at just echo the key instead of calculating a key from pcm seed.

The patch will force pcm to get unlocked and hopefully provide good data to ccm[FFFFs].

i'll try, 1B8E5 is in dead space, though. i assume you mean 0B8E5

[steveo]

that worked! you know that comms code so well.

why though? what was wrong with my ECM that wasn't unlocking, but it was working for spfautch ? maybe because mine is an 8051 rather than a 1333? are they not interchangable?

[kur4o]

I think ccm is just echoing the seed and not converting it to key for the pcm.

Maybe something in the ccm says theft is not good echo the seed, and pcm can`t figure it and keeps polling ccm for key.

Maybe someone can post ign on log with ccm and pcm on the bus, so we can compare how it goes there.

[steveo]

well whatever it is, i think i have enough info to emulate the ecm and win control of the bus, but the other thing i noticed is if the ccm wakes up it crashes the flash kernel. i wonder if there's a way to fully lock the ccm up. lots of cool experiments to run....

but id still like to know why my ecm didn't work. i think it's valuable info

[NomakeWan]

are you sure that's what's happening? it's not a case of an inappropriate ECM response, it isn't in a key-on state? can you tell that from the current communications somehow ?

i have not connected E5 (edited)to anything, should i?

i have, right now:

- security light between C6 and +12v (confirmed working earlier)
- ground to C11 (key in thing)
- +12v to F1 and F2
- +12v to E4
- ground to E15
- E12 to F5 resistor (no security light, so probably correct)
- ALDL to F12

there are alligator clips and twisty wires involved but i am confident everything is connected.

i plan to build a better idle traffic scanner in flashhack too, might be helpful.

E5 is the other Key-On +12V. +12V should go to it.

Yes, I could tell that from your logs; in all logs from my 94 and 95, the only time the CCM does not send the F0 poll is when the key is off. As soon as the key is inserted and turned to run, the F0 polls begin. So since your broadcast messages look totally normal save for the lack of F0 polls, that looks like a normal key-off state.

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it

The $10 broadcast message is for the C68 HVAC system, and contains data the CCM has gleaned from the $41 broadcast from the ECM. This is normal. Additionally there is no return message to a $10 broadcast; it is sent into the void and it's up to the HVAC Programmer to do something about it on its own. There is no handshake or anything like that involved.

[steveo]

E5 is the other Key-On +12V. +12V should go to it.

i thought it only got power in the 'start' position

Yes, I could tell that from your logs; in all logs from my 94 and 95, the only time the CCM does not send the F0 poll is when the key is off. As soon as the key is inserted and turned to run, the F0 polls begin. So since your broadcast messages look totally normal save for the lack of F0 polls, that looks like a normal key-off state.

it seems that a handshake is required. we proved that by making the ECM provide the correct response at which point the CCM became bus master and started the F0 polls. i -think- what you're likely seeing in the key-off state is the ECM isn't alive so it's not responding to the CCM.

The $10 broadcast message is for the C68 HVAC system, and contains data the CCM has gleaned from the $41 broadcast from the ECM. This is normal. Additionally there is no return message to a $10 broadcast; it is sent into the void and it's up to the HVAC Programmer to do something about it on its own. There is no handshake or anything like that involved.

thanks, definitely good to know i can ignore that msg

edit: another thing i'm seeing is the CCM wakes back up after 3 seconds even if we send a keepalive F056F0CA. i wonder what keepalive message would be acceptable to keep the CCM shut up.

[NomakeWan]

i thought it only got power in the 'start' position

Turns out it's both START and RUN. E4 is RUN only.

it seems that a handshake is required. we proved that by making the ECM provide the correct response at which point the CCM became bus master and started the F0 polls. i -think- what you're likely seeing in the key-off state is the ECM isn't alive so it's not responding to the CCM.

Interesting. You're probably right; I would have to check my logs on my '95 while running experiments to see if that is indeed the case. I mean, I assume it is since you already got it working thanks to kur4o's hack, but yeah. I could confirm I suppose.

Definitely seems like a security-related thing; again this handshake was not present in the 90-91 and was only added in 92 and later. And since I only have the original 1990 documentation, well, there's that.

[spfautsch]

Turns out it's both START and RUN. E4 is RUN only.

The FSM specifies that E5 / IGN1 is hot in start and run, and that E4 / IGN3 is hot in run only. This implies E4 is not hot in start / cranking but I haven't tested in-car to verify.

Edit: On my test bench setup I was able to connect with eehack and / or read with flashhack with either E4 or E5 connected with a 1333 and 8051 PCM. Though I wasn't paying any attention to the CCM broadcast / polling traffic and responses.

Dammit, for some reason I'm not getting email notifications on new posts.

Steveo I'm too lazy to lookup calids - what year / type bin do you have on the PCM?

[spfautsch]

i have, right now:

- +12v to F1 and F2

Nothing critical here, but the multiple connections to F1+F2 (unswitched battery), C1+D1+E15+E16 (ground) and E13+F12 (aldl) are solely for redundancy in-car in case a wire is damaged. If you look at the pics of the bottom of the board (or open it up, you have my blessing + encouragement) the traces are joined together right on the connector solder pads. Only one wire is needed to any of these on the test bench.