Corvette CCM Reverse Engineering Anyone?

[spfautsch]

... when I do that, I do not see the transmission. None of it. Not a single byte from the Mega shows up in EEHack's idle scan. So it's not that the CCM isn't reading the whole message and thus the checksum isn't matching...it's that the message does not appear on the line at all.

So you most likely have an issue with your circuit. Try the diode and resistor arrangement and see what happens while running an idle scan. Doesn't need to be a zener - any diode will do the trick just make sure the cathode (stripe) is pointing towards the arduino TX pin.

Nice work steveo. Is there anything I can test that you haven't already?

COMM::Sent message: F1580370CA7A
COMM::Recieved reply: F15703FEB7
CCM Software unlock: NO
COMM::Sent message: F15803644B05
COMM::Recieved reply: F157032293
CCM Hardware unlock: YES

Very elegant, checking if there will be a problem before requesting an unlock.

[spfautsch]

Here's an updated .xdf - fixed the odometer conversion formula in the description. I copied it directly from the datastream document and didn't bother to check if it was correct. It was not...

[steveo]

Very elegant, checking if there will be a problem before requesting an unlock.

thanks,these modules would be way less fun to work with if we weren't able to read their memory. before we figured the code for the challenge/response for EE when i was writing eehack, kur4o found where the challenge/response was stored, and i just stole the correct value from RAM.

i doubt i'll need much more testing, i plan to abuse the CCM to test/finish my more advanced eeprom write routine then i'll probably be bored of the thing.

right now it has a really bright annoying security light and i can't find my box of resistors

i'm thinking this is pretty close to what i want to write the eeprom, haven't tested/debugged/verified it yet but you get the idea

CE 61 E9 F6 61 E6 5A C1 FF 27 0C F7 61 E6 3A A6 00 FE 61 E7 3A 8D 0C 18 CE F4 9D C6 01 CE FF B0 AD 00 39 C6 03 37 33 A1 00 27 04 5A 37 26 01 39 C6 16 8D 0A 81 FF 27 04 C6 02 8D 02 20 E8 F7 10 3B A7 00 CA 01 F7 10 3B 3C CE 0D 06 09 26 FD 38 86 55 F7 10 3A 86 55 F7 10 3A 7F 10 3B 39

        ; PROGRAM BLOCK(START)

        ; INPUT MUST GO AT 61E6 OR MUST REALIGN ALL 61E VALUES.
        ; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]

CE 61E9 ; LDX X = 61E6+3 (START OF DATA)
F6 61E6 ; LDAB BLK_SIZE
5A      ; DECB - decrease blk size - we are using it as a counter now.
C1 FF   ; CMPB 0xFF
27 0C   ; BEQ ALDL_REPLY (if B=0xFF then counter has wrapped and we are done.)
F7 61E6 ; store decreased blk size
3A      ; ABX - add blk size to x
A6 00   ; LDAA,x - A=data to write
FE 61E7 ; LDX write offset
3A      ; ABX - add current blk size to offset location - X=write address
8D 0C   ; BSR PROGRAM

        ; PROGRAM BLOCK(END)

        ; ALDL_REPLY(START)

18 CE F4 9D ; LDY 0xF49D
C6 01       ; LDAB 0x01
ce ff b0    ; LDX loc_FFB0
ad 00       ; JSR,x+00
39          ; RTS

        ; ALDL_REPLY(END)

        ; PROGRAM_BYTE(START) - A=VALUE X=ADDRESS

        ; CONFIGURE:
C6 03   ; LDAB 0x0B - number of retry attempts + 1.
37      ; PSHB - store retry counter on stack

        ; VERIFY:
33      ; PULB  - pull retry counter
A1 00   ; CMPA,X - compare target value with existing value
27 04   ; BEQ COMPLETE - if value is already correct.
5A      ; DEC B (B--)  - decrement counter
37      ; PSHB  - push retry counter back onto stack
26 01   ; BNE - if B!=0 (retry count not exceeded) goto ERASE
        ; FIXME: might be a good idea to create a failure reply if the verify loop fails.
        ; COMPLETE:
39      ; RTS

        ; ERASE:
C6 16   ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A   ; BSR EEPROM_PROG  - call program subroutine

        ; SKIP 0xFF:
81 FF   ; CMPA 0xFF   - see if A = 0xFF
27 04   ; BEQ VERIFY  - jump to verify if equal

        ; PROGRAM:
C6 02   ; LDAB 0x02 - program mode ELAT
8D 02   ; BSR EEPROM_PROG - call program subroutine

20 E8   ; BRA VERIFY - loop back to verify (-24 bytes)

        ; PROGRAM_BYTE(END)
        
        ; EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.

        ; LATCH AND SET BYTE
F7 103B ; STAB 0x103B  - set eeprom control register from B
A7 00   ; STAA,x  - store A (value) at X (location) (write byte)

        ; SET EPGM (PROGRAM VOLTAGE)
CA 01   ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B  - set eeprom control register from B

        ; DELAY
3C      ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09      ; DEX  - x--
26 FD   ; BNE REL-3 IF > 0
38      ; PULX  - restore X register

        ; RESET COP (for every 10ms delay)
86 55   ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
86 55   ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)

        ; COMPLETE
7F 103B ; CLR eeprom control register
39      ; RTS return

        ; EEPROM_PROG (END)

[steveo]

so it turns out i had programmed spfautsch-orig-ccm-178385mi-2.bin for testing and for some reason B6A2 (which is what the XDF says is the VATS byte) is 0

any idea what happened?

i wonder what the best way to recover would be. maybe i'll try no resistor at all.

[spfautsch]

You've changed the VATS code and then dumped the eeprom without changing the VATS resistor so mode 2 or 3 reads of that region return 0x00 per NomakeWan's documentation. You now need a 11.8k resistor (code 15) to make VATS happy. You should be able to override all the read / compare checks and just blindly erase the VATS code byte(s) and reprogram them back to 0x0B (4.75k / code 11) without the correct resistor though. The module will unlock for mode 6 regardless, but mode 2 / 3 reads are giving you zeros because VATS didn't pass.

Good find, this would surely have come up with someone programming an unknown VATS code unit on a test bench.

Edit: I think working around this might not be terribly complex. I'm just thinking in microcontroller mode at the moment (see next comment).

I'd go further with my help but I'm about 2 hours away from a generic arduino logger proof-of-concept that I hope will help NomakeWan immensely. Already have a "fast forward to first valid message" routine. New thread upcoming on that one.

This is what I have on that:

0 
10 59 00 00 00 00 97 
n7 
40 57 00 00 69 
n12 
10 59 00 00 00 00 97 
n19 
40 57 00 00 69 
n24 
10 59 00 00 00 00 97 
n31 
40 57 00 00 69 
n36 
10 59 00 00 00 00 97 
n43 
40 57 00 00 69 
n48 
10 59 00 00 00 00 97 
n55 
40 57 00 00 69 
n60 
10 59 00 00 00 00 97 
n67 
40 57 00 00 69 
n72 
10 59 00 00 00 00 97 
n79 
40 57 00 00 69 
n84 
10 59 00 00 00 00 97 
n91 
40 57 00 00 69 
n96 
10 59 00 00 00 00 97 
n103 
40 57 00 00 69 
n108 
10 59 00 00 00 00 97 
n115 
40 57 00 00 69 
n120 
10 59 00 00 00 00 97 
n127 
40 57 00 00 69 
n-124 
0 
10 59 00 00 00 00 97

This is with the micro finding the first valid message via checksum validation. The only issue I have to fix is that my input buffer is a 255 byte ringbuffer and the message pump isn't correctly handling the wraparound from 255 to 0 (yet).

[steveo]

but i haven't dumped the eeprom - i programmed that byte to 0 because 0 was in the bin i was writing from, im not getting thar from a mode 2 or 3 ram dump

if that byte is actually 15 i have no idea how it would have ended up that way

i hope you're right about being able to enter mode 5/6 with the wrong vats resistor

[steveo]

very interesting, grounding the reman pin actually kills the security light...
edit: despite the security light being on, you're correct, it programs fine. that's helpful.

[spfautsch]

That must have been a bin I dumped early on the test bench without a vats resistor, before finding the reman pin.

Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.

[NomakeWan]

Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.

This would make sense; you wouldn't want VATS getting in the way at a remanufacturing facility, or on the factory floor. VATS is for a car, which a new/reman CCM is not a part of.

I'd go further with my help but I'm about 2 hours away from a generic arduino logger proof-of-concept that I hope will help NomakeWan immensely. Already have a "fast forward to first valid message" routine. New thread upcoming on that one.

This is what I have on that:

0 
10 59 00 00 00 00 97 
n7 
40 57 00 00 69 
n12 
10 59 00 00 00 00 97 
n19 
40 57 00 00 69 
n24 
10 59 00 00 00 00 97 
n31 
40 57 00 00 69 
n36 
10 59 00 00 00 00 97 
n43 
40 57 00 00 69 
n48 
10 59 00 00 00 00 97 
n55 
40 57 00 00 69 
n60 
10 59 00 00 00 00 97 
n67 
40 57 00 00 69 
n72 
10 59 00 00 00 00 97 
n79 
40 57 00 00 69 
n84 
10 59 00 00 00 00 97 
n91 
40 57 00 00 69 
n96 
10 59 00 00 00 00 97 
n103 
40 57 00 00 69 
n108 
10 59 00 00 00 00 97 
n115 
40 57 00 00 69 
n120 
10 59 00 00 00 00 97 
n127 
40 57 00 00 69 
n-124 
0 
10 59 00 00 00 00 97

This is with the micro finding the first valid message via checksum validation. The only issue I have to fix is that my input buffer is a 255 byte ringbuffer and the message pump isn't correctly handling the wraparound from 255 to 0 (yet).

I see what you're doing here. Pretty neat. Yes, the issue I had had on the original EEHack idle logs is that while it would display a gap time, there was never any gap time between actual messages (that is, there was never a gap between $10, $40 and $41 messages, only after those messages). This shows the actual gap timing. Whether n is nanoseconds or microseconds, it appears to average around 9. Very neat.

I apologize for not responding yesterday. Another race day meant I was out of commission. But I'm back so today I'll be experimenting more with the Arduino to see what's going on. To clarify again, when I mentioned that "the Arduino transmission doesn't appear on the line," I wasn't referring to plugging the Arduino TX directly in. That kills the line completely, which is a different problem (as steveo points out, the Arduino TX idling high is killing the line entirely). The problem I was having was that when I connected the TX line to the bus using a transistor array (which is a rough emulation of the CMOS open drain buffer setup GM uses), that transmission never appeared on the bus. EEHack recorded all the $10 and $40 messages without issue, so the line was live, but the transmissions never appeared.

I do not recall if I did idle logging with the Arduino connected via a diode. I did test the ultra-basic circuit (4.7k resistor between RX and bus, IN914A resistor between TX and bus with stripe towards TX) and the CCM still wasn't happy, but I do not recall if I actually did an idle log with EEHack while it was in that configuration. I will do just that today.

[spfautsch]

You might want to do yourself a favor and just drop a delay(1); between the 40 broadcast receive and the transmit. You can use a timer later if you must, but the micro isn't going to be needing that 1ms.

F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
3553
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1
F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
9625
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1
F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
15697
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1

I'm not sure why the 08 command is being echoed twice, but you can see it sleep for about 4 seconds and then wakes up and starts broadcasting again until the micro sees the F0 query / heartbeat, and then it shuts up for another 4 seconds. Without the delay the CCM ignored the message.

    if (msgfound) {
      // valid msg rcvd
      if (msg[0] == 0xF0 && msg[2] == 0xF1) {
        delay(1);
        transmit = 1;
        Serial1.write(silence, sizeof(silence));
        Serial.println(millis());
        transmit = 0;
      }
      printMsg(msg, sizeof(msg));
    }

I'll post the whole sketch when I have a chance to clean it up some.

[spfautsch]

Without the delay before transmit, eehack sees the entire message, but the CCM doesn't reply / respond to it.

633ms to 645ms (12ms) :: 405700
::: GAP4ms
649ms to 660ms (11ms) :: 4DBF5D5D
::: GAP132ms
792ms to 804ms (12ms) :: F056F1C9F15608B1
::: GAP21ms
825ms to 836ms (11ms) :: 1059006802002D

Please note if you try this sketch out I set the console baud to 115200 so the transmit buffer is cleared faster,

[spfautsch]

This shows the actual gap timing. Whether n is nanoseconds or microseconds, it appears to average around 9. Very neat.

Thanks, but no. It was the position of the next message in the ringbuffer. I scrapped that because the code was too ugly and complicated and went to simply resetting the buffer when a valid message is located. This is a brutally quick + dirty proof of concept sketch.

[NomakeWan]

I'm not sure why the 08 command is being echoed twice, but you can see it sleep for about 4 seconds and then wakes up and starts broadcasting again until the micro sees the F0 query / heartbeat, and then it shuts up for another 4 seconds. Without the delay the CCM ignored the message.

It's because you didn't poison the receive buffer as soon as you matched the appropriate message, if I had to guess. That was the exact problem I made sure to avoid in my code; the Arduino runs so many orders of magnitude faster than the 8192 baud ALDL that it's entirely possible to go through the response code loop multiple times upon receipt of the correct message. So the first thing I do in my code upon matching the message I'm looking for is poison the first byte (oldest byte) of my 5-byte-wide sliding window. This way even if the code loops around again before the end, the contents of my buffer now start with 00, which won't match the checksum, which thus won't allow the code to enter the response loop anymore until the next time a full $40 message is received.

[steveo]

regarding delay times, an aldl byte is 1.22ms long, so a 1ms delay is less than one byte worth of dead air after you just blocked events for >1.22ms*pkt length, the cost is insignificant

[NomakeWan]

Hi guys,
I am loving following along. Am old school, just want to remind we are dealing analog/digital. Time is a huge factor.

Transport delay is a factor for a lot of things.

Thanks for the fun :)

You (and everyone else) were of course correct. I wasn't accounting for the analog traits of this circuit. Had I used GM's own circuit design, I have no doubt that I wouldn't have run into this problem at all, since their CMOS gate array would handle the analog shaping of the signal and thus the delay in question as the line changed signal levels. But since I didn't build GM's exact circuit, I was running into exactly that problem. And had I bothered to do idle scans of every single circuit layout I tested, rather than only one or two of the last ones, I would've noticed that issue a lot sooner. D'oh!

All I did this time was connect a 33k resistor between ALDL and RX (as specified by GM), and a standard IN914a diode between ALDL and TX with the stripe facing TX (as specified by spfautsch et al), then added delay(2); right before transmitting. The rest of the code remained identical. I connected my laptop to the ALDL port, started idle scanning, then turned the key. I expected to have to do some sleuthing using that idle log, but instead the dashboard jumped to life. The idle scan confirmed that the CCM/PCM polls were now functioning perfectly.

I can't believe a stupid 2ms delay was in my way this whole time. Of course, now I have to think about how best to utilize this newfound knowledge. Obviously the end goal is to be able to make a CCM happy even when the ECM/PCM the car came with is no longer present. How best to do that, though, I'm gonna have to give a good ol' fashioned think. On top of that, now that I know it was the delay at fault, I'm going to experiment with even better ways to connect to the car, such as attempting to control the serial data registers directly via interrupts so I can toss the resistor and diode entirely. For now, drinks all around.

IMG_2115.jpgIMG_2116.jpg

EDIT: It also points out that another difference between the '90 definition and the '95 reality is in how coolant temp is calculated. The $41 definition says it should be counts*0.75=DegC. But the 94-95 PCM ALDL datastream definition points out that for our cars it's (counts*0.75)-40=DegC. Not sure why they did that, but that lines up perfectly with reality (CD is 205, 205*0.75-40=113.75C=236.75F). I'll have to account for those differences too.