Corvette CCM Reverse Engineering Anyone?

[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.

[spfautsch]

Check my work, but no luck. I didn't post all comms but I tried requesting as much as 0x40 and as few as 0x01 bytes returned.

TX+F15605B4
RX+F15705AA09
TX+F166066000864097FC18CEB683FEFFB0AD003938
RX+NO REPLY
TX+F15605B4
RX+F1570500B3


TX+F15605B4
RX+F15705AA09
TX+F166066000864097FC18CE7083FEFFB0AD00397E
RX+NO REPLY
TX+F15605B4
RX+F1570500B3

What if we try to get it a reply with some fixed response first, would that help?

My original unit has all new tantalum caps. I'm probably going to put a "cheater wire" in before I put it back in the car so I can test mode 5 / 6.