Corvette CCM Reverse Engineering Anyone?

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

[spfautsch]

We'll see (erasing eeproms). Before I get too far along I wanted to share a picture of the reman pin. But my lawyer (who also happens to be my wife) has advised me to proceed with caution. So you're not going to get lead right to the pot o' gold.

Spoiler alert, it's a deceptive aspect you won't be able to find with passive forensics.

reman-pin.jpg

I'll give one more hint - it is floating, but it's not floating at 12 volts.

Here's what I've learned. While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply. I've tried uploading nop commands as well as plain ascii to the $00 scratchpad area and to the last few digits of the (ram) VIN with no apparent success.

I feel like I've only conquered 5% of the problem and it was completely non-trivial. I'm open to any suggestions, especially protocol focused interrogation. I have no interest in profiting from this endeavor, but I will stop at nothing until I can minimally change a few bytes of ram.

[kur4o]

Finally cracked the m5 loop.

It is some loop that expire if there is no activity on the bus. When that happen the pcm is crasher and reset.
Before that happen memory from 6000-600b3 is cleared. I suppose that is the target ram for uploading code.

When in mode5 only mode5 and mode6 messages can be sent.

Mode 5 will just reply with AA and keep the bus alive.
Mode6 is to upload and execute some code.

It needs to be in a format like this

06 XX XX [YYYYYYYYYYYYYY] chks

xxxx= data where the upload will be stored and executed.

YYYY= upload code. No need to specify length, it is taken automatically, also there is no checksum verification, so if the message is corrupt the pcm will likely crash.

For now a snigle upload can be worked fairly easy. A multi message upload will need some tweaking as the execute needs to return to m5 loop.{i think EE upload apporach will work without issue- just some tweaking of the addresses].

Now someone needs to write some code to program the eerpom with custom data. i am sure gm have something on t1 but where to get is beyond me.

[spfautsch]

While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply.

Let me correct this one. It appears that mode 5 will stay active without keeping the bus active.

What I've found is that if I upload a routine that doesn't end with an RTS instruction, the processor resets. Also sending anything other than 05 and 06 commands while in mode 5 resets the processor as kur4o noted.

I'm pretty sure what I'm sending is working, but have no way to know other than the fact that mode 5 stays active as long as I don't send anything other than 05 or 06. I know this because the reman pin only needs to be shorted momentarily and responses to 05 remain AA until it resets whether the pin is shorted or not. I'd try turning on an output like the courtesy lamp pin, but I think the processor has to send commands over spi to handle this and that's way outside of my machine language skillset.

I'm tempted to try my hand at disassembly, but thus far that's never ended well. Otherwise I'm at your mercy guys - any ideas on the entry point for the eeprom routine?

[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