Corvette CCM Reverse Engineering Anyone?

[spfautsch]

After a couple short drives, it seems like the ccm's code isn't working on the data at $7000. After putting 3.0 miles on mine nothing in this area of ram or eeprom changed, and message 0 was still showing the same eeprom mileage that was off by 1 mile. After disconnecting the battery the 3 miles disappeared.

It turns out there's some kind of timer (kur4o mentioned this from disassembly) so it only writes to eeprom after a certain amount of run or off time (haven't figured it out completely). On the second drive I stopped after 1.1 miles to talk to a friend and that mileage has been written to $b657. But after sitting in my garage for ~45 minutes it still hasn't written the additional 1.3 miles to eeprom.

I suspect there's also a traveled miles trigger because I ran across a user over on cf that had battery drain issues and the ccm was crashing after a certain number of miles (which reset the odometer back n miles until the trigger was again reached). This sounds like a bad capacitor on the 12v rail, which is needed for eeprom programming voltage.

I suspect after a lot of erase cycles the wear leveling logic might move this byte to one of the many adjacent zeroed bytes, but I think eeprom is good for ~1m write / erases so I doubt there are that many of these still in service after that many write cycles.

by the way, is the end goal of this to have an XDF that covers the eeprom and we edit it like that ?

I hadn't thought about that as a possibility. I don't know tunerpro that well but is it possible to write complex conversion routines? The odometer storage methodology is very unique - skipping ff bytes apparently if there's data in byte 1 of the structure. The rest of the option bits and the vats code would be easy to do in an XDF - there really aren't many needed. This way the write tool wouldn't need to know anything about different eeprom options, etc. as I'm sure there are probably different protocols used on older units and possibly different eeprom layouts year to year.

I've also considered omitting the odometer capability altogether. If it can be done only by editing the bin by hand that will make it discouraging enough that every Y-body Bill isn't pulling his ccm out to roll the miles back.

Also, as a note, my '94 has FX3. Both my '94 and '95, as you surmised, have C68.

I doubt the FX3 controller is connected to the aldl, and it's not connected to the ccm so it's probably an option for other / future platforms. I just found it interesting that they included provisions so early for that, ETC, and the power seat bits - one for driver and passenger. This was probably used later for the driver customization stuff triggered by different keyfobs.

On your arduino stuff, here's a schematic of what I used on the Volkswagen k-line / obduino. I think it should work for GM 8192 baud also but no guarantees. The transistors you're using are all small signal PNP, but I think the to-18 might be intended for RF / Microwave frequencies so the gain may be different from the to-92 version which is just a general purpose small signal transistor. Edit: If you wanted, I've no plans to re-use this so I'd be happy to throw the components in an envelope and snail-mail them.