Corvette CCM Reverse Engineering Anyone?

[spfautsch]

So why would something creating an additional, not-accounted-for delay require increasing the existing delay? That's the only thing I'm confused about.

Not the existing delay - with the ALDL and debugging being echoed to the serial console as well as capturing and writing diy-ltcc debugging, I was able to maintain semi-reliable comms with a OCR3A value as low as 18 (1.152ms). I worked up to the current 28 / 1.78ms after a good bit of trial and error.

That said I'm using 2ms already in my own code so, hey, close enough.

I was only sharing the timer code in case you wanted to be able to do something else in those 2ms. Your application can probably live without it. Mine needs to service the diy-ltcc logging on uart2 as well as writing to the sd card over spi.

It would be interesting to see if using your timer ISR set to 1 tick would be sufficient when the code isn't doing anything else during transmission. Though as another note, even though their waveform diagram shows 20 microseconds, and their SXR (discrete IC) shows 20 microseconds, the diagram using a non-SXR circuit specifies a minimum of 108.1 microseconds and a maximum of 147.1 microseconds. It's not explained in the text where this discrepancy is coming from.

I can experiment, but I think there may be additional unpublished timing requirements for the protocol - this is definitely not just a matter of the electrical characteristics of the bus. Even with > 2.0ms transmit delay I'm still seeing intermittent reply message "lethargy" for lack of a better term. In what testing I've been able to do I've seen the PCM message timeout (at the time ~200ms) exceeded immediately after going into closed loop - the last message in the log is literally the only one with the BLM Learn bit set. I'm not sure I haven't formatted the SD and lost this one, but I'm sure it happened.

I'll keep posting updates since it seems to be valuable info for you. Yesterday was mostly spent moving stuff to and setting up my storage unit. I did manage to add debug logging of the logger itself to a file, as well as timezone rules and a callback to the RTC so file timestamps are correct. Hopefully today will be more productive on the timing and reliability side.

I mistakenly ordered the wrong solid state relay, waiting for the correct one from DigiKey so the power-on latch circuit can be completed and system will be ready for final debugging. The idea is to power the logger on from the courtesy lamp circuit as well as the switched ignition, and then let the arduino hold the same relay on with a digital pin and then shut itself off after it sees that the CCM has gone to sleep. This satisfies my other need which is feedback that the CCM has shut the hell up after a drive cycle instead of sitting and draining my battery.