Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

Your math is correct. The 62.5 us period comment was copied and pasted from an example I found somewhere, and I never bothered to verify even though I have a 1024 prescaler in the diy-ltcc code that is showing the correct time period.

The 1.792 ms / 28 ticks may need more fine-tuning. I found that when the controller was writing to a file without echoing a bunch of debugging noise to the console, this value had to be increased. In other words the time involved in sending to the console was creating a delay that has to be accounted for in order to get the fastest acquisition rate. Sd card write latency is another factor (though much smaller).

Okay, cool. Glad I had read it right. 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. That said I'm using 2ms already in my own code so, hey, close enough. The GM spec sheet suggests the rise/fall time is only 20 microseconds, but without an oscilloscope I can't really confirm what's going on in reality-land. 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.

Point being, while 2ms works fine, it's likely actually cutting into the error-related buffer period of the transmission rather than merely accounting for the inherent electrical delays associated with the ALDL bus design. At the moment my car has no electrical power since I'm doing work on the alternator and some other stuff, but once it's back together enough to fire up the CCM again, I'll do some more tests.

Wakaeman is on the right track, just don't forget about transport delay since it's analog. It's a tough environment and GM did spend a bunch of time to make sure it is halfway reliable for the generation of 30 yrs ago.

Yeah, and if we were using GM's IC, this problem would be taken care of for us. I have a very, very strong feeling that that IC is actually what Torqhead is salvaging from those PCMs they get as core charges for adding CCM integration. That's why they give you a $100 discount if you decide you don't want CCM integration at all, but toss in a core charge if you do. Because without CCM integration there's no need for that chip at all. With it, their solution is clearly relying on transmission tech from the time rather than creating their own discrete circuit. Perhaps they don't know as much about the bus as we now do.

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

[NomakeWan]

Oh, no no, don't take my reply the wrong way; I was in no way being critical of your code or suggesting that my method was better or anything like that. I was just noticing that I had a larger delay than your code already, so we were pretty close to one another in terms of the existing "settle" delay. Nothing more, nothing less.

Anyway it definitely sounds like I need to buy myself a 'scope in 2022. It's really getting to the point where I can't go much further in researching these sorts of old cars without one. I'm working on another unrelated project for the GT-R related to solenoid feedback that is also going to need a 'scope anyway, so yeah, I'm way overdue. Hopefully that'll both help try to figure out what's going on with 8192 ALDL, and maybe even what's so different about the '94 Vette's "dirty" bus versus my '95s "clean" one. More than worth it.

As for your latching relay thing, I was thinking of handling it without one. I mean with a latching relay you can go to completely 0 power draw, I agree, but the power draw of an Arduino-based chip in full sleep is what, 10 microamps or something? Why not just set an interrupt for the RX pin going from low to high to wake it, and have the Arduino just go into full smash sleep mode after a certain time of the CCM dropping offline?

[spfautsch]

Oh, no no, don't take my reply the wrong way; I was in no way being critical of your code

Not taken that way at all. Just making sure we're on the same page. I wanted to push the timing envelope while servicing other devices in the main loop and that required a hardware timer.

As for your latching relay thing, I was thinking of handling it without one. I mean with a latching relay you can go to completely 0 power draw, I agree, but the power draw of an Arduino-based chip in full sleep is what, 10 microamps or something? Why not just set an interrupt for the RX pin going from low to high to wake it

Tried that and it does work. But the SD card in particular, the miscellaneous smc leds and the dual voltage regulators on the mega board draw a lot - 75ma in idle mode according to my best meter with all but uart1 (ALDL) turned off. Not worth designing my own board so I'll just flip the breaker after the CCM goes to sleep. It adds some code and component complexity but the last thing I need is to trade convenience for more parasitic draw on the battery.

As always life happened today so didn't make as much progress as I'd hoped to. Still need to resolve an occasional CCM timeout after killing the ignition (and power to the PCM).

[NomakeWan]

Have you tried shutting down all the ADC registers before dropping into sleep? Apparently just using

ADCSRA = 0;

reduces power consumption by three orders of magnitude. It'd be like Sketch J here: http://www.gammon.com.au/power

Apparently that sketch on a bog standard Arduino draws only 0.15 microamps while sleeping, which is two orders of magnitude less than I thought. Should work on the Mega.

[spfautsch]

Nick's examples were done using a 328p on a custom board without voltage regulators, leds, peripherals, etc.

The mega boards have two voltage regulators, one of which I believe is linear and therefor very inefficient. According to this [link] the lowest power consumption it's capable of while using the on-board regulators is ~27 ma. That's with the adc turned off and processor in PWR_SAVE mode. Meh. Add on the logger shield and sd card and it uses even more power.

Was able to clean up a few issues and it looks like latching relay will work as planned with the possible exception of key in + key on after the CCM has gone to sleep. But I don't generally sit in the car with the door closed without the key in the ignition.

[NomakeWan]

Ah, fair enough. Guess it's yet another thing for me to experiment with on my own. I enjoy that though so, hey!

It took me a second to figure out why "key-in+key-on after CCM sleeps" would be a problem, then I remembered that the logger was being triggered from the courtesy lights. Considering the use case for this device, I highly doubt that will be an issue. An errata to make sure to spell out in documentation, sure, but I think anyone who would have one of these left plugged in is going to get in and out of their car for drive cycles.