Corvette CCM Reverse Engineering Anyone?

[BlackW1dow]

The C68 programmer never responds to anything and has no ability to talk on the bus. For diagnostic purposes, you can connect a jumper between pin 4 on the HVAC control head and pin 14 on the ALDL connector to allow a Tech 2 to talk to the HVAC Programmer via the E&C Bus. Check section 8A-52-0 of your FSM. The two connections between C9/C10 on the HVAC Programmer and the ALDL are only there to receive the $10 CCM broadcast message and nothing else.


Torqhead is correct. As we discussed via PM, your '92 has a different diagnostic message from the 94-96 Corvette. It is three bytes shorter. The CCM's poll request message, however, is identical. To be clear, this means that the message the CCM sends to the ECM is the same as the 94-96, but the reply from the ECM is different. Since the reply is what Torqhead has to account for, that's why their setup won't work for the earlier cars.

Additionally, Torqhead's modified '411 PCM only has connectors for the PCM found in the 94-96 Corvette, not the ECM found in the 92-93 Corvette. So they are absolutely correct that their system would not work for you.

However, should we be able to figure out how to fake that message ourselves with open-source hardware and software, that means we would be able to provide anyone with a 90-96 Corvette the ability to have a working dash with any aftermarket computer, whether that be Torqhead, Holley, Haltech, etc etc etc. So hopefully we can figure that out. Torqhead clearly knows some of the things we'd like to know already, but as they're in the business of making money, I don't think they'd be willing to share that information freely.

Thanks for the response, and it makes some more sense now! Please let me know if I can contribute to the cause anymore. I should have a EPROM dump for another user tomorrow.

[NomakeWan]

If you've already got a dump on the way, then I think you're good. The rest is stuff the analyzing group needs to do. I'm still working on Arduino stuff, while others are working on analyzing the actual code. Hopefully one of them can figure out the $41 CCM poll response through reverse-engineering the dumps. That would be fantastic since there's still several unknowns (bytes 8, 9, 16, 17, 19 and 20 for the 94-96, bytes 8, 9, 16 and 17 for the 92-93).

[steveo]

i could probably help with your tool too nomakewan, i will have an ECM and CCM on the same test bench some time soon and can do some testing/analysis. i feel like the ECM's response to that poll might be better figured out by analysis of the ECM code since we have already done a ton of groundwork there, and i'm sure most of the unknown bytes you're looking for are well defined addresses in memory of EE

[NomakeWan]

i could probably help with your tool too nomakewan, i will have an ECM and CCM on the same test bench some time soon and can do some testing/analysis. i feel like the ECM's response to that poll might be better figured out by analysis of the ECM code since we have already done a ton of groundwork there, and i'm sure most of the unknown bytes you're looking for are well defined addresses in memory of EE

Oh, duh, good point; this is the reply from the ECM, so of course the ECM would have it defined. One would just have to find the routine that fires off data when it receives the $40 poll message. Good point!

I was out all day today but hopefully tomorrow I can run those experiements I was planning on. I'll keep you all posted.

[spfautsch]

One thing I would like to see more of are eeprom dumps from cars with PASSKey codes other than 9 and 15. The code isn't scrambled or anything like that, but there are two bytes that follow it that would be nice to have more examples of.

NomakeWan on the C68 option I changed that on the remanned CCM yesterday before I put some miles on it. It seems like it does change the broadcast messages. Attached is an idle log from before changing the bit with engine off, and more (look for the notes I wrote between sessions). My gut tells me this option was for functionality that never made it into production on the C4s. I'll change this in my original CCM later on so more can be tested.

Also, one of the option bits I missed was 'rough road detection'. This is something I've never heard of, but appears to be enabled in all these dumps - if the datastream definition is as accurate as I think it is.

I also figured out that the unit only seems to write the odometer to eeprom after a start. It also wrote 32 miles at some point while the engine was running because I drove 44 in one trip. I spent the better part of yesterday afternoon sitting around waiting for it to update, and then figured I'd need to drive it a few more miles to get that to happen. Lo and behold after idling for a short time it wrote out the remaining 12.75 miles to $b657.

I'm planning on putting the car back together starting tonight. After that I intend to figure out how to make the PASSKey authentication work on the test bench and I'll get the remanned unit headed towards steveo.

[steveo]

i'm excited to play with a CCM. i have my old 8051 test bench ecm rigged up now. it'll be good to do some hands-on comms experiments with a really active ALDL bus too. sounds like getting programming working will be pretty easy. i think i'll take your idea and do a full read, compare, erase/write as required, then read to verify. should be pretty quick.

[spfautsch]

Cool, I was somewhat worried about sending it to you for fear you might smash it with a hammer after all the difficulty they've caused you. :-)

I've learned a little about the vats / passkey validation. Evidently the status is stored in eeprom. Either that or there's tank circuit that keeps ram powered up, but there aren't any big caps on this thing so I'm leaning towards eeprom.

Whenever a vats validation fails the code enforces a 2:30 "penalty period". Any vats attempts during this period will fail even with the correct resistor, as well as resetting the penalty period. If power is removed from the unswitched battery input before the timer expires there will be a 2:30 penalty period after power is restored. There's no apparent special sequence of events - as long as the correct resistor is present when the two ign circuits go high vats is de-activated presumably for the current run cycle.

I have noticed however that the unit doesn't go to sleep after the normal 20 seconds unless it sees the key-in circuit go open in addition to a door ajar circuit.

I'm done messing with it for now so I'll get it headed your way in the next day or so. It's programmed for a #11 key, and I'll send a 4.7k resistor soldered onto some pins so you can test with / without vats active. I also hooked up my 8051 PCM on the test bench to verify that comms work. It also still has junk scribbled in the unused FF bytes of the eeprom, and the c68 bit is on. Feel free to erase the unused stuff and modify whatever's in the .xdf.

I've wired a jumper from the chime 1 output on pin c14 to the reman pin. Even though I asked for 'radio silence' on this, I was somewhat hoping someone would figure it out. Edit: Sorry NomakeWan, I missed your response. Thanks - I hope the chime box inputs are 5v ttl, but even if not, all the outputs are protected so I don't think any circuitry can get "hurt". Anyway, this makes these easily un-lockable by simply turning this pin on from the aldl. It would be a shame if a picture of this board leaked out... :-O