Corvette CCM Reverse Engineering Anyone?

[spfautsch]

Seems like it's crashing - eehack loses connection immediately after which I assume is the ccm spamming the bus for a response from the pcm. Also, mode 6 commands do not generate a reply, even ones that work.

I've been reading the datasheet and it seems like eeprom has to be programmed one byte at a time, so that explains some of what I was seeing. Will experiment a bit more and see if it's possible to write multiple bytes sequentially.

My fear with the odometer is there's an eeprom block protection register that can only be cleared during the first 64 e-clock cycles. It's probably cleared by the initialization routine, but once set cannot be cleared except in test and upload modes. I haven't looked at any of your disassembly work but my fear is that before mode 5 is entered it sets the write protect register to 03 which locks the first 128 bytes of eeprom.

[kur4o]

PPROG is cleared to zero at reset, and that`s it. Only one subroutine uses it and it is triggered by oci1 at some timer interval.

[spfautsch]

PPROG is cleared to zero at reset, and that`s it. Only one subroutine uses it and it is triggered by oci1 at some timer interval.

I see the reference to it at initialization because it's using direct addressing. The one in the timer routine worries me but I don't see that using direct addressing. ($1035)

By the way, you were right on with the odometer being stored in ram at $607c and my tone generator works on the test bench regardless of vats.

steveo the part #s spec'd for 94 are 16157364, 16212971 and 95 can have either 16230561, 16230686, 16223622. I'm working on the 95, pn 16223622. I would assume any can be used interchangeably, it's possible the only difference is firmware versions. You could also do what I was planning on doing - returning mine to RockAuto with a nastygram about how it wasn't plug-and-play, had the wrong vats code, auto trans, etc. They have a very liberal return policy.

I agree it sucks that we get no reply. Honestly I think we can simply send sequential write instructions. It'll be slow but there's not a lot of data to write. At most the two option bytes and the 17 characters of the vin.

[spfautsch]

Nevermind my rantings earlier about eeprom write protect.

At some point I'd thought it was ok to omit the RTS at the end of the uploaded routines so it was crashing after writing the first byte of the odometer.

Odometer zeroed and lockout bit erased.

TX+F166066000C616F7103BF7B6CAC617F7103B3956
RX+NO REPLY
TX+F15C0660007F103B394A
RX+NO REPLY
TX+F15802B6CA35
RX+NO REPLY
TX+F15802B6CA35
RX+F19602FF400010000000800020000801804020100804028000080002000000000020000800FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED
TX+F15605B4
RX+F15705AA09

Mode 5 above without the reman pin shorted.

The tantalum capacitors to permanently repair my original unit should be here today so I'll put the remanned unit in the car to see if the LCD displays what I hope it will.

[kur4o]

I will make some test headers lately for experimentation. The way I see it custom mode 6 with jump to vector subroutine will read the bin in large chucks. It might be read fully without some data being omitted by mode2 and mode3.

[spfautsch]

Sounds good. If all else fails I offered to loan the board to steveo so you guys can avoid teaching a remedial course in machine code to an idiot (referring to myself).

Blindly erasing / writing the vats bytes worked. I haven't driven it like this yet, but I doubt I'll be able to resist the temptation.

IMG_20210930_141239896.jpg

It occurred to me kur4o (and you might have suggested it and I misunderstood) that the reason for copying the entire eeprom to $7000 is for comparison during the write procedure. The eeprom value cannot be read unless the control register is cleared, so I guess it was to save a few instructions when determining what changed and whether an erase will be required.

[kur4o]

some food for testing
Send in mode 6 download and execute.

ldaa #YY 86 YY
staa byte_fc 97 fc
ldy xxxx 18 ce XX XX
ldx off_ffb0 fe ff b0 update fix

jsr 0,x ad 00 fix
rtn 39

YY=length of reply message
XXXX= start address to dump data.

We can also set it: when you upload a data, the pcm will write and than read the written data and reply back with the data stored. Something like an echo message.

[steveo]

Seems like it's crashing - eehack loses connection immediately after which I assume is the ccm spamming the bus for a response from the pcm. Also, mode 6 commands do not generate a reply, even ones that work.

I've been reading the datasheet and it seems like eeprom has to be programmed one byte at a time, so that explains some of what I was seeing. Will experiment a bit more and see if it's possible to write multiple bytes sequentially.

My fear with the odometer is there's an eeprom block protection register that can only be cleared during the first 64 e-clock cycles. It's probably cleared by the initialization routine, but once set cannot be cleared except in test and upload modes. I haven't looked at any of your disassembly work but my fear is that before mode 5 is entered it sets the write protect register to 03 which locks the first 128 bytes of eeprom.

if it has a broken implementation of mode 6 i can deal with that, but it would be a good idea if we figure the header out so it sends a reply. it's hard to write reliable software without knowing if the commands are successful. i wonder if i can find a CCM here locally from a wrecker or something that i can sell on ebay after. is it the 1994 or 1995 version you are working with right now? it would be good to be on the same page. actually don't really think i can write good software remotely. it took me like 1000000 hours just to make flashhack work on the 'vette aldl bus reliably because it was just a back-and-forth with nomakewan and a lot of trial and error.