Corvette CCM Reverse Engineering Anyone?

**spfautsch** · 09-30-2021

I've been able to change (write zero) to the VSS*/4000 counter at $b657. I've also been able to erase the option byte at $b6c7 and write bit 2 there for the manual trans.

Edit: This entire paragraph is wrong, disregard. It seems like the 05 unlock is cleared after two 06 uploads are executed, or something... Presumably first being the write and second being the clear command to turn off the eeprom control register (turn off programming voltage). Whatever the case, it doesn't seem to be at all straightforward.

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

All this considered, I'm somewhat afraid that erasing the odometer may be impossible without a patch to the (uveprom) firmware. Hope to have more, better news tomorrow.

**kur4o** · 09-30-2021

When eeporm is copied to 7000 area it is also copied after that at 6xxx area.It is there where pcm add stuff and maybe later write to eeprom from there. & 7000 might be some area that survive more with voltage off. Maybe some backup.

**kur4o** · 09-30-2021

Some more food for the obscene scene.

from ee code

ESERVED:602B clr PPROG ; EEPROM Program Control Register
RESERVED:602E ldaa 0,y
RESERVED:6031 cmpa 0,x
RESERVED:6033 beq loc_605C
RESERVED:6035 ldaa #$16
RESERVED:6037 staa PPROG ; EEPROM Program Control Register
RESERVED:603A staa 0,x
RESERVED:603C ldaa #$17
RESERVED:603E staa PPROG ; EEPROM Program Control Register

ESERVED:6046 loc_6046: ; CODE XREF: MAINsub_4F8D+109Aj
RESERVED:6046 clr PPROG ; EEPROM Program Control Register
RESERVED:6049 ldab 0,y
RESERVED:604C cmpb #$FF
RESERVED:604E beq loc_605C
RESERVED:6050 ldaa #2
RESERVED:6052 staa PPROG ; EEPROM Program Control Register
RESERVED:6055 stab 0,x
RESERVED:6057 ldaa #3
RESERVED:6059 staa PPROG ; EEPROM Program Control Register

From ccm

loc_EAF7:
sei
ldaa #2
staa PPROG ; EEPROM Program Control Register
ldaa #0
staa PPROG ; EEPROM Program Control Register
cli
ldx byte_62F2
ldaa 0,x
cmpa byte_62F1
...................................

ED:EAC4 sei
RESERVED:EAC5 ldaa #$16
RESERVED:EAC7 staa PPROG ; EEPROM Program Control Register
RESERVED:EACA ldaa #0
RESERVED:EACC staa PPROG ; EEPROM Program Control Register
RESERVED:EACF cli
RESERVED:EAD0 ldaa byte_821D
RESERVED:EAD3 staa byte_62F0
RESERVED:EAD6 ldy byte_62F2
RESERVED:EADA ldaa byte_62F1
RESERVED:EADD ldab 0,y
RESERVED:EAE0 cmpb #$FF
RESERVED:EAE2 beq loc_EAEC
RESERVED:EAE4 ldab byte_62F4
RESERVED:EAE7 orab #$20 ; ' '
RESERVED:EAE9 stab byte_62F4
RESERVED:EAEC
RESERVED:EAEC loc_EAEC: ; CODE XREF: sub_EAB8+2Aj
RESERVED:EAEC jmp loc_EBC4
RESERVED:EAEF ; ---------------------------------------------------------------------------
RESERVED:EAEF
RESERVED:EAEF loc_EAEF: ; CODE XREF: sub_EAB8+5j
RESERVED:EAEF dec byte_62F0
RESERVED:EAF2 beq loc_EAF7
RESERVED:EAF4
RESERVED:EAF4 loc_EAF4: ; CODE XREF: sub_EAB8+Aj
RESERVED:EAF4 ; sub_EAB8+80j ...
RESERVED:EAF4 jmp locret_EBDC
RESERVED:EAF7 ; ---------------------------------------------------------------------------
RESERVED:EAF7
RESERVED:EAF7 loc_EAF7: ; CODE XREF: sub_EAB8+3Aj
RESERVED:EAF7 sei
RESERVED:EAF8 ldaa #2
RESERVED:EAFA staa PPROG ; EEPROM Program Control Register
RESERVED:EAFD ldaa #0
RESERVED:EAFF staa PPROG ; EEPROM Program Control Register
RESERVED:EB02 cli

.................................................. ...............

SERVED:EBA5 loc_EBA5: ; CODE XREF: sub_EAB8+E8j
RESERVED:EBA5 sty byte_62F2
RESERVED:EBA9 staa byte_62F1
RESERVED:EBAC ldaa byte_821C
RESERVED:EBAF nega
RESERVED:EBB0 staa byte_62F0
RESERVED:EBB3 sei
RESERVED:EBB4 ldaa #$16
RESERVED:EBB6 staa PPROG ; EEPROM Program Control Register
RESERVED:EBB9 staa 0,y
RESERVED:EBBC ldaa #$17
RESERVED:EBBE staa PPROG ; EEPROM Program Control Register
RESERVED:EBC1 cli

and more

ERVED:A7F0 ldab PPROG ; EEPROM Program Control Register
RESERVED:A7F3 bitb #2
RESERVED:A7F5 beq loc_A819
RESERVED:A7F7 cpx #$B600
RESERVED:A7FA bcs loc_A819
RESERVED:A7FC cpx #$B7FF
RESERVED:A7FF bhi loc_A819
RESERVED:A801 pshx
RESERVED:A802 xgdx
RESERVED:A803 subd #$4600
RESERVED:A806 xgdx
RESERVED:A807 ldab 0,x
RESERVED:A809 pulx
RESERVED:A80A bra loc_A81B
RESERVED:A80C ; ---------------------------------------------------------------------------
RESERVED:A80C
RESERVED:A80C loc_A80C: ; CODE XREF: M3_eeprom_sub_A7A8+21j
RESERVED:A80C cpx #$103F
RESERVED:A80F bhi loc_A819
RESERVED:A811 cpx #$1000
RESERVED:A814 bcs loc_A819
RESERVED:A816 clrb
RESERVED:A817 bra loc_A81B
RESERVED:A819 ; ---------------------------------------------------------------------------
RESERVED:A819
RESERVED:A819 loc_A819: ; CODE XREF: M3_eeprom_sub_A7A8+4Dj
RESERVED:A819 ; M3_eeprom_sub_A7A8+52j ...
RESERVED:A819 ldab 0,x
RESERVED:A81B
RESERVED:A81B loc_A81B: ; CODE XREF: M3_eeprom_sub_A7A8+45j
RESERVED:A81B ; M3_eeprom_sub_A7A8+62j ...
RESERVED:A81B stab 0,y
RESERVED:A81E iny
RESERVED:A820 pulx
RESERVED:A821 inx
RESERVED:A822 inx
RESERVED:A823 deca
RESERVED:A824 bne loc_A7C3
RESERVED:A826 rts
RESERVED:A826 ; End of function M3_eeprom_sub_A7A8
RESERVED:A826

Cant help much. You need to decode some of the functions.

**steveo** · 09-30-2021

i know it's not much help right now but i improved the flashhack mode2 download tool. it will now read a specific region (but you still specify the entire memory size, so it will give you a 0 padded file with the data at the proper offset).

... it also has a checkbox to read via mode 3 (single byte at a time) in case for some reason we run into a GM module that has mode 3 code but not mode 2. this is really slow and stupid but i just had to put it in there. it flies along pretty quickly considering the overhead because flashhack is pretty optimized with regards to timing.

edit: download it at the usual place of course

**NomakeWan** · 09-30-2021

So I think I may have figured out the issue with my Arduino. It might not be hardware after all. I was reading the datasheet for CCM comms, and noticed that there is a note about how the bidirectional system works.

The CCM transmits an "idle byte" (10 1 bits; start bit high, 8 data bits high, end bit high) prior to the first byte of every message instead of detecting an idle line...

...After successful receipt of the message, the remote device to which the message was directed will respond back to the master device with a message of its own. Before transmitting the message, the remote device waits for an idle link state.

My code currently recognizes the $40 poll request message and instantlytransmits the $41 poll response. My AVR may actually be transmitting too quickly. I don't see how that's possible since serial data is orders of magnitude slower than AVR processing, but it makes sense. My code does not "wait for an idle link state," since I don't really know how to recognize that in code terms.

I have some additional hardware designs to test anyway, so hopefully tomorrow I'll be able to work on it more. If it really is that simple, I'll be pretty happy.

Great work so far on the odometer stuff!

**steveo** · 09-30-2021

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

here are some notes on mode 5/6 and programming

some of this stuff you already know but might help to review or for others that might want to help, some might be broken in the CCM if it's not up to GM's usual standards, some things have names i've invented because of lack of documentation.

mode 5 generally is 'enter programming mode' and mode 6 is 'upload and execute' which you already know.

you call mode 5 and then the ECM executes from a special loop for a very short time that really only is intended to respond to mode 6.

it's standard GM practice that if you make a mode 6 request without calling mode 5 first, or because mode 5 has timed out, it replies with mode 5 and a failure status code to your mode 6 request. if this logic functions for the CCM you can use it to know when you haven't called mode 5 yet, or if mode 5 has timed out and needs to be called again.

as far as the actual code goes, the maximum code segment size you can upload and execute with mode 6 is 167 bytes (because of the aldl protocol's max message size, and the overhead of the memory location specifier bytes, etc)

you can do some really cool stuff with mode 6 just with small code segments since the instruction set for these processors is so compact.

it looks like you already figured it out, but if you don't call 0x39 (return from sub) after your code, undefined things will happen, it keeps executing whatever happens to be in ram.

something that is critical for more advanced operations is being able to upload to ram without actually executing the code

in the other stuff i've worked on, we prefix with a code segment that does execute and returns a proper reply but allows us to continue more programming right away, i did understand partially how it works at one time, but maybe kur4o remembers better, you could do something like this for the CCM for sure. i'd call it your non-execution header. excuse the ugly manual disassembly.

Code:

86 AA  (LDAA $AA)
 36 (PSHA)
 18 30 (TSY)
 86 06 (LDAA $06)
 C6 01 (LDAB $01)
 FE FF BC (LDX @FFBC)
 AD 00 (JSR 00,x)
 32 (PULA)
 39 (RTS)

now that you have a method that'll dump something in ram without executing it and return cleanly (your payload is obviously at an offset of 16 bytes due to the size of that header) you can leverage this ability to load larger program segments into ram.

the trick to running a large continuous program is you need to land the end of each uploaded code segment so it writes over the above non-execution header, which is still in ram, and lines up with the existing code you have uploaded. this is done by writing your program into memory backwards, so the final segment you write is the first one, which then does NOT contain your no-execute header, executes.

obviously you have an extra xx bytes of overhead from that above message, so you have to resize your messages appropriately.

flashhack has some carefully designed code that does this automatically for large program segments, so you just have to worry about the program, and a large enough area of RAM to put it in, in fact you can just write an entire program into a bin file and run it by name. it makes decisions based on the program size, but it does require a functional non-execution header like the above to work properly.

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

**steveo** · 09-30-2021

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

ok that's done , i made kind of a reflash sub-tool with no kernel, kind of like the mode 2 read tool. i'll test it out a bit and get you a copy, then we'll play around with working the bugs out.

just for the hell of it, can you see what happens if you execute the above code with mode 6 on the CCM? if they set that FFBC vector the same maybe we'll get lucky and it'll just work. it should return 06 AA as a reply. more likely it'll crash.

86 AA 36 18 30 86 06 C6 01 FE FF BC AD 00 32 39

**kur4o** · 09-30-2021

I can confirm that the vector is there and is the same. It jumps to mode6 response that is not referenced in the main code.
In the response it will be [f1] [56+lenghtof message] [06]. [0,y loop] I see it will read all bytes from y pointer and send them on the bus. You need to specify the lenght of the response at the request message.
You can store the length of the repsonse at byte_FC

This one looks as a reading routine built in the ccm code.

The header will be store length to byte_FC, load y with start address of reading, load x with ffbc pointer, jump to sub to 0,x , rtn.

**spfautsch** · 09-30-2021

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** · 09-30-2021

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.

**steveo** · 09-30-2021

Originally Posted by 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.

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.

**spfautsch** · 09-30-2021

Originally Posted by 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.

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** · 09-30-2021

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.

Code:

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** · 09-30-2021

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** · 09-30-2021

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.