Corvette CCM Reverse Engineering Anyone?

[steveo]

well, i drank a bunch, and the flash tool works perfectly now.

it's not fast, and i'm sure it has bugs, but i'm pretty happy that the assembly code end of things worked, and that flashhack would flash something so odd is just great...it would be good enough to read an old CCM and flash its eeprom contents to a new one.

i spent a good few hours being abused by my own handmade assembly code faults incl. stupid typo in the address of the eeprom control register

i guess we can work on the xdf and i will put a page on fbodytech that describes what to do, what to jumper, all that stuff, and post a new version of flashhack once i clean up the mess

[NomakeWan]

  if (Serial.available()) {
    for (uint8_t i = 0; i < 5; i++) {
      Serial1.write(M1Cmd[i]);
    }
    Serial.read();
  }

this means if there is data to read on the 9600 baud port (your PC), then you write to the aldl port. you then read a single byte from the 9600 baud port (your PC) to nowhere.

this would technically work, if he is monitoring the serial data, then manually smacking a key in his serial terminal at the correct time to send the message (assisted by the fact that the write would only happen during a time when the bus was not fully saturated and the while() loop has exited)

Ah, that's what I missed, that the second was Serial.available() and not Serial1.available(). You're correct, it only fires if something comes in via the terminal.

I'm not doing that, though; I'm actually waiting until the appropriate command has come into the buffer programmatically, and then responding to it in that loop. I figure I'll just toss my code up here for the shit of it, even though at present it does not work. Maybe someone will spot something I missed. (EDIT: To be clear, it's only the transmit that hasn't worked. I've already confirmed everything else in the code works. It can read, correctly detect the $40 poll, correctly respond, and correctly responds only once per received $40 poll)

/* CCM Interaction Test Sketch for Arduino Mega 2560
This sketch pretends to be the PCM for a 1994 to 1995 Chevrolet Corvette.
It listens for the CCM poll request bytes (40 57 XX XX Checksum),
then sends the appropriate diagnostic string upon receipt.
The diagnostic string is idle values except for coolant temp,
which is either static (154C) or variable (based on ADC0 input).

This sketch only works on the 1994 to 1995 Corvette. It may work for 1996.
1990 Corvettes use shorter polls (40 55 6B) and have shorter responses.
To use for a 1990 Corvette, change the sliding window to 3 bytes
and just use the following match code without checksum ifs:
((window[0] == 0x40) && (window[1] == 0x55) && (window[2] == 0x6B))
Then comment out the top lines for output[21] and use output[15].

This sketch only works on the Arduino Mega 2560 family.
This is because we're using Serial1, UCSR1B, RXEN1, RXCIE1.
If you want to try it on a different board, change these accordingly.

*/

#include <avr/io.h>
#include <wiring_private.h>

byte window[5]; //define the 5-byte-wide sliding window
byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0xCD, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x40}; //define the static CTS message
//byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0x87, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x86}; //define the standard message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0xCD, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x45); //define 1990 Corvette CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0x39, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x12); //define 1990 Corvette standard message

void setup() {
  analogReference(DEFAULT); //Switch to default reference explicitly
  pinMode(A0, INPUT); //Make sure A0 is an input explicitly
  bitSet (DIDR0, ADC0D); //Disable digital buffer on A0
  bitSet (DIDR0, ADC1D); //Disable digital buffer on A1
  bitSet (DIDR0, ADC2D); //Disable digital buffer on A2
  bitSet (DIDR0, ADC3D); //Disable digital buffer on A3
  bitSet (DIDR0, ADC4D); //Disable digital buffer on A4
  bitSet (DIDR0, ADC5D); //Disable digital buffer on A5
  bitSet (DIDR0, ADC6D); //Disable digital buffer on A6
  bitSet (DIDR0, ADC7D); //Disable digital buffer on A7
  bitSet (DIDR1, AIN0D); //Disable digital buffer on AIN0
  bitSet (DIDR1, AIN1D); //Disable digital buffer on AIN1
  bitSet (DIDR2, ADC8D); //Disable digital buffer on A8
  bitSet (DIDR2, ADC9D); //Disable digital buffer on A9
  bitSet (DIDR2, ADC10D); //Disable digital buffer on A10
  bitSet (DIDR2, ADC11D); //Disable digital buffer on A11
  bitSet (DIDR2, ADC12D); //Disable digital buffer on A12
  bitSet (DIDR2, ADC13D); //Disable digital buffer on A13
  bitSet (DIDR2, ADC14D); //Disable digital buffer on A14
  bitSet (DIDR2, ADC15D); //Disable digital buffer on A15
  analogRead(0); //Burn an analog reading on pin0
    Serial1.begin(8192); //Open UART1 at 8192 baud
    UBRR1H = (uint8_t)(121>>8);
    UBRR1L = (uint8_t)121;
    cbi(UCSR1A, U2X0); //disable 2x mode
    cbi(UCSR1A, MPCM0); //disable multi-processor mode
}

void loop() {
    if (Serial1.available()) {
        // Slide the 5-byte window
        for (uint8_t i = 0; i < 4; i++) {
            window[i] = window[i + 1];
        }
        // Add new bytes as they come in
        window[4] = Serial1.read();

        // Check the first two bytes for a match
        if ((window[0] == 0x40) && (window[1] == 0x57)) {
            // Calculate the checksum byte
            byte cs = 0;
            for (uint8_t i = 0; i < 4; i++) {
                cs += window[i];
            }
            cs = 0xFF - cs;
            cs += 0x01;
            // If checksum byte matches, send diagnostic data
            if (cs == window[4]) {
                window[0] = 0x00; //poison the sliding window
                Serial1.write(output, sizeof(output));
                Serial1.flush(); //wait until transmit completes
            }
        }
    }
    //Read A0 to check status of potentiometer, save to cts byte
    //output[5] = analogRead(0)>>2;
    //Calculate new checksum and save to checksum byte
    //byte checksum = 0;
    //for (uint8_t i = 0; i < 20; i++) {
      //checksum += output[i];
    //}
    //checksum = 0xFF - checksum;
    //checksum += 0x01;
    //output[20] = checksum;
}

[spfautsch]

How? If the code you posted is your entire code, how did it know to transmit only after the F0 poll?

I sent it a linefeed on the other serial port. This is simply a hello world that proves it's possible to transmit with two components, non-inverted. And that's not a zener, just a plain small signal diode. A 1N4001 would work as well.

I'll play with your sketch tonight if you haven't figured it out by then.

[spfautsch]

... waiting until the appropriate command has come into the buffer programmatically, and then responding to it in that loop.

Just a "first glance" observation, but you might need to add some delay before transmitting after the checksum is verified. This AVR is so much faster than the motorola in the CCM you're probably writing to the bus before it's capable of hearing the response.

I've already confirmed everything else in the code works. It can read, correctly detect the $40 poll, correctly respond, and correctly responds only once per received $40 poll)

I'm not seeing any kind of debugging code to demonstrate how you know this. I hope I'm preaching to the converted, but the serial console is your friend when it comes to debugging firmware.

[spfautsch]

do you want me to write you a function or two for handling aldl comms? i could port you over the super important elements like 'fast forward to first valid message', 'find bus master ID' and 'wait for hole to send mode 8 request', also the checksum/length calcs

I might enlist your help on that if I can't figure out something simple and fast. But for now I'll play with it because it's the best way for me to learn.

What's the gist of finding bus master id? Is it just listening for a device that's sending the F0 5x Fn cc message?

Am I correct to assume I should be prepared to buffer messages 0xAA + 2 bytes long?

your diode/resistor arrangement seems to make sense - is this about right? |< being a diode of course.

Yes, the TX pin on the arduino is an output and I believe is set to active high when not transmitting. The diode keeps that 5v from killing the bus' floating state and only conducts when TX is driven low.

Nice work on flashhack btw. I always do my best coding after drinking "a lot". The problem is afterwards I rarely remember it. :-)

I'm debating whether to include the odometer triplet in the .xdf (non-decoded of course). I'll get that to you over the weekend or I'm sure you could handle it if you wanted to.

[steveo]

considering any moron can go to the wrecker and swap the ccm to change his mileage i would just say get it all mapped out.
honestly most owners would be happy to know if their ccm died they could correct the mileage
i doubt we will find many people that are capable of such things that would use it to scam unsuspecting buyers but if they do thats their responsibility

anyway the new version is in the usual place, i made a pdf explaining the reman pin and bundled it, also the current xdf because im too lazy to make a separate thing for that

[In-Tech]

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 :)

[NomakeWan]

Just a "first glance" observation, but you might need to add some delay before transmitting after the checksum is verified. This AVR is so much faster than the motorola in the CCM you're probably writing to the bus before it's capable of hearing the response.

I thought of that as well, but I'm not willing to just put a delay (or for the savvy, a time - millis() function) in. That's dumb. That's not how real hardware detects an idle line. They don't just sit there looking at their proverbial watch, they have a way to know that the line is idle. So instead of putting in a delay and playing hope chess, I'd rather have code that's just as robust as what's in the car....if that is in fact the problem.

I'm not seeing any kind of debugging code to demonstrate how you know this. I hope I'm preaching to the converted, but the serial console is your friend when it comes to debugging firmware.

Preaching to the choir on this one. The second version of the debug code was removed before I posted it here for clarity. The first version was my sanity check and was done as a separate INO file; I removed all the code related to analog readouts or transmission and replaced the $40 detection response with just an LED blink at 0.5 second intervals. Once I confirmed that that part of the code was working, I then added a routine into my actual INO to accept serial data at 8192 baud on Serial3, and then transmit the contents of Serial3's read buffer on Serial at 9600 (for serial monitor printout). Then wired the Serial1 TX to Serial3 RX. Sure enough, the serial monitor flashed my intended response if I plugged Serial1 RX into the ALDL bus.

[spfautsch]

Damn, nice work steveo. Documentation too!

Here's an .xdf with the odometer triplet as a 3x18 table, and the vss counter / lsb. You might take a look at my warnings / notes on the two and see if they can be translated to something that might make sense to a broader audience. I'm the absolute worst at writing documentation.

[steveo]

with aldl stuff there can be a brief a transitional period, independent of the state of the serial link,between when a message is finished and aldl devices are ready to start receiving another one. thats just how it works because these are really slow old synchronous devices. if you look at native aldl messages there is always a few ms of space between them. its a protocol thing not a hardware thing. if your dont delay a tiny bit you might find your messages are randomly ignored.

[spfautsch]

I thought of that as well, but I'm not willing to just put a delay (or for the savvy, a time - millis() function) in. That's dumb.

I wasn't implying using the arduino delay() routine as a permanent solution, and maybe not even as a troubleshooting aid. Crude stuff there. I wouldn't even consider using a non-blocking mechanism that watches millis() as something "savvy". There are plenty of timer / counters available in the mega.

Preaching to the choir on this one.

Good deal. I figured as much but wouldn't have personally gone to the trouble of removing all of my debugging assistance (any of it actually) until I had a working proof-of-concept firmware. Having evidence that your message was received by the other devices on the bus is a critical part of that milestone. Thus my reason for questioning whether the sliding window logic was known to be working.

As steveo mentioned, this is a time-sensitive protocol on a bus with no hardware collision avoidance mechanism. The only way the nodes of the network can detect if they've read a bogus message is the checksum byte. Everything you've mentioned thus far points to the possibility that the receiving nodes aren't finding the checksum to be valid and are therefore ignoring the message. Please don't shoot the messenger, I'm genuinely trying to help because I want your project to work.

When you think about it, it's pretty impressive that GM was able to make something as fast and reliable as it is at 8192 baud given the hardware available circa 1985-ish.

[steveo]

the original protocol draft also had a preamble byte FF before the device byte as a way for devices to get ready, but ive never seen it actually used.

[steveo]

ive decided i will write a block rather than byte program for the eeprom. i want to use it on EE too where speed is critical but the ccm will be a good testbed. other than punching the COP occasionally, it should be pretty easy. unfortunately my dumb ass reprogrammed the thing and changed the vats resistor value, so for the moment, she's disabled.

[NomakeWan]

I wasn't implying using the arduino delay() routine as a permanent solution, and maybe not even as a troubleshooting aid. Crude stuff there. I wouldn't even consider using a non-blocking mechanism that watches millis() as something "savvy". There are plenty of timer / counters available in the mega.

I'm afraid I'm not familiar with directly addressing timers for the AVR. I do consider non-blocking mechanisms like watching millis() to be savvy, at least compared to something blocking like delay().

Good deal. I figured as much but wouldn't have personally gone to the trouble of removing all of my debugging assistance (any of it actually) until I had a working proof-of-concept firmware. Having evidence that your message was received by the other devices on the bus is a critical part of that milestone. Thus my reason for questioning whether the sliding window logic was known to be working.

As steveo mentioned, this is a time-sensitive protocol on a bus with no hardware collision avoidance mechanism. The only way the nodes of the network can detect if they've read a bogus message is the checksum byte. Everything you've mentioned thus far points to the possibility that the receiving nodes aren't finding the checksum to be valid and are therefore ignoring the message. Please don't shoot the messenger, I'm genuinely trying to help because I want your project to work.

It may seem like I'm shooting the messenger, but I'm really not. I'm just responding to what's posted with the information on hand.

The issue with that theory is that I've plugged my laptop into the ALDL port and ran idle scans while letting the Mega fire up using the PCM's blue connector for both power and ALDL connection. And 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.

[steveo]

you know, theres no shame in blocking if there's nothing to do

everything you do blocks in one way or another

sometimes the task at hand is just hanging around for a bit waiting for the smoke to clear

its not like you have a user interface to service here, the program you're writing barely has any work to accomplish

anyway for your arduino issues i think a bigass regular diode will solve it. you're right that the tx line is holding the bus high you just need to kill that