Corvette CCM Reverse Engineering Anyone?

[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

[steveo]

that logic is roughly how the f-body VATS works too, it's probably a standard implementation

i was thinking i'd steal your idea for writing the eeprom with that textbook method for the 8051 as well. it might be nice to have a flash routine that writes the entire e-side and t-side eeprom from whatever is in the bin file, for someone that wanted to store a table or two in there that would be easily changed without a complete bin erase/rewrite.

[steveo]

oh and i'd never leak a picture of YOUR board, don't worry. but if i manage to find another 'vette CCM somewhere with some custom wiring i'll definitely post a pic, because it may or may not be someone else that found that top secret remanufacturing pin.

[NomakeWan]

I have an update! Was finally able to get access to the '94 again, and so I grabbed a new dump of the CCM, and got an idle scan while it was running.

For reference, odometer was 119,905 when this dump was taken just now.

Arduino project got sidelined due to other projects getting in the way. I hope to be able to get back to it again by this coming weekend.

[spfautsch]

Thanks, that's incredibly helpful on the odometer storage.

(0x1d460 = 119904) + (0x06 * 0.25 = 1.5) = 119905.5

I'm probably not going to post any more elaborate explanations of the odometer storage going forward. Primarily because I want there to remain some mystery in it's storage mechanism, but also because I'd rather disclose the location of the reman pin and leave the odometer to those who choose to do their homework or ask for help at the price of providing documentation of the validity of their request. If you have genuine interest in knowing it's function PM me and I'll share information commensurate with how much I trust you and your motives.

Meanwhile, I've discovered what I described to steveo as a "rotten easter egg" in the firmware. Once completely re-assembled and having some miles racked up on it, I've come to understand the following:

There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.

Note how I park the car normally.

IMG_20211013_191155036.jpgIMG_20211013_191207026.jpg

Made necessary by the amount of crap stored in my garage, my parking methodology was meant to prevent my wife from dooring the f**k out of my side mirrors and / or doors when exiting her daily driver. Normal parking procedure involves backing into the garage at an angle, cutting the wheels to the right, exiting the vehicle and then rolling it several feet back into final position by hand before setting the parking brake through the open side window. During the colder months I would regularly perform this procedure and then leave the engine running while I maneuvered around to the passenger side of the car and rolled the driver's window up with my leverage aid device before shutting it off and removing the key.

What is a "leverage aid device" you ask?

IMG_20211013_192417861.jpg

It's the same device I used to depress the clutch pedal in order to start the car about a million times during the development of the diy-ltcc controller. Not once was the driver's door opened through the numerous multi-hour long development + test sessions where I would shake out bugs in the firmware startup routines. In the year and a half since I've come to learn my neighbors found much loathing in hearing the sound of my car's exhaust note late at night.

I'm fairly certain this "rotten easter egg" explains 95% of my battery drain issue. Laugh if you must.

So here's the reman pin connected to output pin c14. Inboard on the unpopulated 40 pin IDC header, fourth from the end.

IMG_20211007_134727479.jpg

[NomakeWan]

There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.

This is actually really good information. I recall a few threads over on the Corvette Forums of people experiencing this phenomenon (including the relay randomly cycling) but couldn't figure out what was going on. Now you've documented the likely culprit, which is excellent. I'll have to keep that in mind on my own vehicles; though at least so far I still enter and exit from the driver's door, so I haven't experienced that issue yet personally.

I wonder if that's something that could be patched out in firmware? Make it so it'll sleep regardless of the driver's door cycling after, say, the same amount of time as the Delayed Accessory Bus timeout?

[spfautsch]

Unsoldering and socketing the uveprom isn't on my bucket list at the moment. Only when the reman unit comes back to me will something like that even be on my radar. I'm certainly not removing the original unit from the car again until perhaps when the carpets and seat covers are replaced.

In the mean time my workaround will be to attempt a current sense circuit that will give me a green led indicating the CCM is in sleep mode. Hopefully I'll be able to do that with a fuse tap so no wiring will need to be modified. If that works I can always tap a momentary pushbutton into the left door ajar wire that can be triggered from the passenger seat.

This wasn't as much of a problem until my 'good' battery maintainer died. It would run a charge cycle when the battery got down around 12.1v. The cheapo HF maintainer that replaced it will let the car eat the battery.

By the way, when steveo is done you're still welcome to take a turn with the reman if you'd like to use it for your arduino PCM simulator project.

[brian617]

That's a fairly common function (opening, closing drivers door) across many manufactures in order for modules to enter sleep mode. Learned this years ago when testing for parasitic drains. You sure went the long way around to discover that lol. However that is a very unusual parking sequence.

[spfautsch]

Well I did instruct you to laugh if you must. Evidently I don't do anything the easy way. :-)

I don't feel like it was wasted effort though - some of the larger tantalum caps on both boards look as if they may have been leaking. I'd rather been safe than have to yank the module out again.

Whatever the case, the outcome is that now anyone with the desire to remove the module can unlock it for programming, and do so without rare and expensive GM tools.