Corvette CCM Reverse Engineering Anyone?

[steveo]

can you confirm that the CCM does not respond in any way to a mode 12 request? (0C in hex)

i find it really weird that they'd make it a one-liner to change the cal id or vin in the 8051 but not its CCM companion.

while you're at it see if it responds to 0D unlock

[spfautsch]

can you confirm that the CCM does not respond in any way to a mode 12 request? (0C in hex)

while you're at it see if it responds to 0D unlock

I guess I really need to do some reading and understand the protocol a little better.

COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.

COMM::Sent message: F1560DAC
COMM::Reply was not as expected: f1560dac vs F15600B9

[steveo]

try a few bytes of command payload
like 0C0001 or 0D0000 or something

[spfautsch]

DEBUG::Sending raw command: DEVICE=F1 COMMAND=D DATA=0000
COMM::Sent message: F1580D0000AA
COMM::Packet error: Timeout waiting for reply payload.
DEBUG::Trying to reconnect to bus...

DEBUG::Sending raw command: DEVICE=F1 COMMAND=D DATA=0001
COMM::Sent message: F1580D0001A9
COMM::Reply was not as expected: f1580d0001a9 vs 105908870200
DEBUG::Trying to reconnect to bus...

DEBUG::Sending raw command: DEVICE=F1 COMMAND=C DATA=0000
COMM::Sent message: F1580C0000AB
COMM::Packet error: Timeout waiting for reply payload.
DEBUG::Trying to reconnect to bus...

DEBUG::Sending raw command: DEVICE=F1 COMMAND=C DATA=0001
COMM::Sent message: F1580C0001AA
COMM::Packet error: Timeout waiting for reply payload.
DEBUG::Trying to reconnect to bus...

I better get some learning done on what these commands do and what you're trying to accomplish because I may be missing your whole point or just doing it all wrong. Maybe have NomakeWan try the same since he has a much better understanding of the protocol.

I'm having an obscene amount of fun mapping digital inputs to (perceived) memory locations and physical pins. Also discovered how to crack open old db9 solder type connectors to harvest the pins so I have the capability to do much, much more. Thus far I have the bit and address(es) for the key in, left door switch, hatch switch, low oil, and high beam inputs. I'm as happy as a possum eating a sweet potato.

[steveo]

I better get some learning done on what these commands do and what you're trying to accomplish because I may be missing your whole point or just doing it all wrong. Maybe have NomakeWan try the same since he has a much better understanding of the protocol.

no, you're doing good, i just wanted proof that those commands are responsive or not to see if they exist. i'd say they don't.

I'm having an obscene amount of fun mapping digital inputs to (perceived) memory locations and physical pins. Also discovered how to crack open old db9 solder type connectors to harvest the pins so I have the capability to do much, much more. Thus far I have the bit and address(es) for the key in, left door switch, hatch switch, low oil, and high beam inputs. I'm as happy as a possum eating a sweet potato.

that's really valuable for sure, the more of those addresses you post and we can label, the faster disassembly of the program will go.

as soon as you manage to get the bit to flip that kur4o mentioned earlier, lets make sure it unlocks mode 5/6

[spfautsch]

I somewhat believe these things are more primitive than you would care to believe. Maybe I'm reading the stuff NomakeWan posted too literally, but if it says "upload to RAM will be denied" I tend to believe the eeprom write / erase stuff may not be required. The program shouldn't be trying to write to eeprom every time the odometer increments.

My hillbilly dissertation of how I think it might work is as such:

Mode 5 commands upload values directly to ram. I.E. VIN, engine code, transmission type (autos had a fluid temp sensor), odometer, etc. Then let the machine go to sleep and the eeprom compare / write function takes care of things. I'll experiment more with the english / metric bit tomorrow to see if it's retained after a power loss. If it is that will surely tell us something valuable.

I'm plugging along. Have the address / bit location for another 5 digital inputs. Not many more left before I have to start looking for ADC registers.

[NomakeWan]

The program won't be writing to EEPROM every time the odometer increments, no. The EEPROM should only be used for that initialization/remanufacture purpose via the Mode 5/6 request. That's why once that bit flips, it becomes useless.