Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

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]

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.

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]

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]

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]

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.

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