Corvette CCM Reverse Engineering Anyone?

[spfautsch]

I will say I completely forgot that the CCM has a VSS line. D'oh. That's probably exactly what drives the speedometer

I'd always assumed that since I've never had trouble with the speedo while logging with eehack. At most, I'd imagine the VSS it's getting from the aldl is used for fuel economy calcs.

I cannot actually share the complete document.

No worries, thanks for what you have shared.

I'm still figuring out the details on how the odometer is stored, but ironically it's not really even scrambled, byte swapped or stored in some oddball unit of measure. FF bytes seem to be ignored, presumably because there's some logic to prevent exceeding the maximum erase cycles. If you look at yours, the fifth byte is FF. But it wasn't back in April 2020. The low mileage salvage unit I have has a7 at $b602. 0x0a70 = 2672 and the unit read 2675 when I had it in the car. It's definitely something unique, and I think the 6 mile error is probably more of a side-effect of someone at Delco having a case of Friday afternoon when the programmer logic was specified.

By the way, I think the reason the odometer is stored in three places was due to some sort of federal mandate for digital odometers. Everybody seems to understand it to mean it's stored in three different physical places, but I think it's just a failsafe requirement in case an eeprom cell dies.

Edit: Btw kur4o, I think the eeprom starts at $b5fe and is 514 bytes. It's possible the initialize routine is skipping the first two bytes when it copies the structure to $7000. That would be a useful piece of information because there are lots of zeros following the odometer structure so it's difficult to tell how long it actually is.

[NomakeWan]

Yeah, big hand-meet-palm moment. Of course the speedo worked while logging; only the fuel economy stuff didn't work, but that's probably not even related to speed, but more related to the CCM not being able to get the injector constants and all that jazz. I wonder why VSS is even included in the stream in the first place? Sanity check?

Also, it does make me wonder if there's some other location in the CCM that is storing the "precision" byte for the odometer. Clearly the CCM alone knows the odometer, and clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading? Curious.

[kur4o]

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

If you can simulate the signal you can monitor registers while the mileage increase and when is written to eeprom. On soft shut down or at specific interval or is not stored at all if power is lost to ccm.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

[spfautsch]

... clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading?

Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

The ultimate goal would be to reprogram these completely with open source tools.

[steveo]

Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.



I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.



The ultimate goal would be to reprogram these completely with open source tools.

i believe both the eeprom and uv prom would be addressed memory so both should be fully visible in the dump we get via the aldl.

i cant believe gm would leave the memory dump enabled. it defies all logic.

[spfautsch]

i cant believe gm would leave the memory dump enabled. it defies all logic.

To quote Kid Rock, it was 1989, my thoughts were short, my hair was long. Perhaps the guys that engineered this thing weren't exactly the top of the class.

Can any of the uveprom based ECMs be dumped thusly?

[NomakeWan]

I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

That's not it. No modules connected to the CCM require the CCM to broadcast vehicle speed. The Cruise Control Module on the Y-body has a direct 4000 ppm signal input straight from the PCM, and has no connections to the CCM whatsoever.

[spfautsch]

Actually kur4o is correct. The actual hall effect sensor connects to the (our) PCM on a31 and a32. Then it converts it to 4000ppm and outputs it throughout the vehicle on b8. The CCM (and any other modules that need it) gets this conditioned signal on e2, not the actual hall effect sensor. Otherwise the CCM would also need to be programmed for diff gear ratio. This is completely independent of the aldl.

Edit: I think I see the method behind the madness on the odometer storage. I'll need to run up some test bench miles to confirm, but it looks like a 1 in the third (possibly first) byte indicates one of the three odometer bytes has been filled to capacity (FF) and incremented again and is flagged as "skip". If the first byte is not 0 the ff is a part of the stored value. I'm hearing two border collies barking and having trouble focusing, but I'll post more details when I can confirm. This would allow for storing about 268 million miles in four eeprom bytes with minimal single byte erases.

[NomakeWan]

Actually kur4o is correct. The actual hall effect sensor connects to the (our) PCM on a31 and a32. Then it converts it to 4000ppm and outputs it throughout the vehicle on b8. The CCM (and any other modules that need it) gets this conditioned signal on e2, not the actual hall effect sensor. Otherwise the CCM would also need to be programmed for diff gear ratio. This is completely independent of the aldl.

Yeah, I had to re-read what he typed a few times before I realized my mistake. I was reading it in the context of our current discussion, which was regarding ALDL comms via the CCM. But he wasn't talking about that at all, he was talking about the PCM independent of the CCM, a completely different unrelated topic.

My bad. Anyway, the local electronics shop didn't have the components I needed......so I ended up buying a huge kit that had them plus a bunch of other random shit I can keep in my lab for a rainy day. Sucks paying $16 more than intended, but at least I'm good to go. Should have a new interface ready by tomorrow.

EDIT: As to the memory dump, there are only two address spaces that are rejected by the memory dump routines (both Mode 2 and Mode 3). These are:

$1000~$103F: CPU registers. These are restricted because attempting to access them via ALDL could lead to the CPU crashing.

VATS: All VATS memory locations are restricted and will return 00 unless the correct key for the vehicle is inserted and the ignition is set to run. My dumps were all done with the key in and the ignition in run, so these locations should be populated. My datasheet doesn't specify the memory locations, but it should be fairly trivial to find them by just taking a dump with the key in and ignition on, then immediately taking another with the VATS connector disconnected. I can do that later.

[spfautsch]

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

[kur4o]

That`s pretty awesome.

Now it is time to wipe out some eeproms.

[NomakeWan]

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

F1 57 05 AA

ohhhhh snap