Flashing the MK60 with ZCP software

[heinzboehmer]

Oh shit, I might have found CCP commands in the PT(?)-CAN table.

Table decodes out to a bunch of CAN IDs that I was going through and, after some indirection, I found a read of the presumed-CCP EEPROM flag through a function pointer. Fortunately 0x797 was the towards the top of the table

Looking through the payload handler:



tbl_0f2eb:



(I still don't know what the `_DAT_00400948` check is. Presumably a `wheel_speed == 0` check since it comes from RAM?)

So now we know the second conditional in `can_rx_797_payload()` will evaluate to true (because the CCP flag is set). If we go to the function that gets evaluated in the conditional, we see something that looks suspiciously like an interpreter:



Looking at a CCP command ref (e.g. https://mxhelp.danlawinc.com/ccp_xcp_reference.htm), the `UPLOAD` function (0x4) is immediately interesting. Follow the function call in `case 4:` and jackpot:




An unauthed, unbounded read in a loop that writes to a buffer (ignore the decompiled C code in that last screenshot, it's not looking all that great). Looks like the `UPLOAD` function to me!

Lots of words and code to say that I was wrong and I'm now pretty convinced that CCP is supported on the e5 AND it can dump flash.

Since the EEPROM flag is present on the MK60 dump, I'm pretty confident that it will be supported there too. Amazing.

I know what the first thing I'm going to do when I get that MK60 is!

[Bry5on]

Oh baby! Now we’re getting somewhere

[karter16]

Nice work Heinz - this is epic! very much enjoying following this along!

(ignore the decompiled C code in that last screenshot, it's not looking all that great)

FWIW pretty much all of the weirdness in the Ghidra C-code view can be resolved by making sure your function parameters (number and datatype) and return value (datatype) are correct. For example

int can_rx_797_payload(void)

I'm willing to bet if you follow where it's called the return value isn't actually used. If so, and you modify the function prototype in Ghidra to be a void return type you'll see a bunch of that weirdness clean itself up.

[heinzboehmer]

FWIW pretty much all of the weirdness in the Ghidra C-code view can be resolved by making sure your function parameters (number and datatype) and return value (datatype) are correct. For example

int can_rx_797_payload(void)

I'm willing to bet if you follow where it's called the return value isn't actually used. If so, and you modify the function prototype in Ghidra to be a void return type you'll see a bunch of that weirdness clean itself up.

That's good to know! First time using Ghidra for this kind of work, so still stumbling through it. Will try to fix all this weirdness now.

Edit: Oh man, it's so much nicer with these fixes. Thanks! Repo updated with this in mind, so any .0pa you feed the workflow will generate these nice Ghidra projects automagically.

[hobbit382]

Nice work heinzboehmer!

[heinzboehmer]

Non-M MK60 sent by George has arrived. I'm still waiting on some pins to finish up the bench harness, so haven't poked at the CCP thing yet, but I will soon. These are supposedly non-flashable, but we'll see about that

I did immediately cut it open, though, just to see what I could learn from probing the PCB:



Lowest hanging fruit in my mind was to figure out the M track mode input. Bry5on did some digging into this earlier, so a lot of this is just redoing his work. Here's the pin that would be used for M track mode and the DSC button input. Keep in mind that this is on the non-M board, the ZCP board has slightly different values for the components:



Math checks out with some previous measurements.

Poked around and found a few other input pins with similar layouts:




The last two are interesting. Same exact layout as pin 38, but with some more circuitry attached at the point that would usually be grounded. This makes me think the TI IC is keeping the pin attached to R14 pulled _up_ when the MK60 is powered on, but I haven't tested. I think that makes sense, cause otherwise you'd have a permanent pull up line running all the way to the brake fluid reservoir and the parking brake.

Anyway, I think getting the M track mode input working on a non-ZCP module is doable. The shunt resistor is different, but the RC filter is the same. If the input is too touchy, the SW debounce can be tweaked (once I figure out the reflashing of these modules) to make up for it. Worst case, you can cut a small access hole into the cover and swap the resistor out.

Re the TI chip I think it’s maybe a custom ASIC for controlling the hardware, it sits on the headers side of the board and some very similar part numbers are labeled on some 3rd party sites as “Teves PCU60”. I’m guessing “PCU” stands for “Pump Control Unit” or something similar.

I think you might be right. At least one of the pins on the TI chip is connected to the network of transistors/MOSFETs right by the pump connector, so that would make sense.