E92 PCM Reverse Engineering

[turbo_v6]

Well, unfortunately I believe in my OS Mode 36 is not implemented. At least that's the way the code looks.

Code: Select all

/* Transfer Data */

void Mode_36_Func(undefined8 param_1)

{
  Diag_Response(param_1,0x22);
  return;
}

So, I'm not really sure how to go about trying to upload code.

[Gatecrasher]

Mode 36 is definitely implemented. That's how the utility file transfers the kernel and calibration data. 0x22 just means conditions not correct or sequence error.

I don't have the exact details worked out for the E92 yet, but I believe the ECM reboots into the boot block when it gets a mode 34 message. The real mode 36 handler runs out of the boot block.

[turbo_v6]

Ah, thanks for the nudge. Looks like I may have found some code in the boot block for it.

[turbo_v6]

Playing with Mode 23 I am not able to request more than 2 bytes in one message (due to the limit of the CAN message size).

I see in the can info that a Flow Control frame is sent to continue receiving the remaining messages with the data requested. I have tried to do that, but I am not getting any more responses after sending the flow control message.

Here is a snippet from the log (Universal Patcher Logger)

[19:00:35.981] [638178732359819160] 00 00 07 E0 01 28 FF FF FF FF FF FF
[19:00:35.999] [638178732359996649] 00 00 07 E0 01 28 FF FF FF FF FF FF
[19:00:35.999] [638178732359996649] 00 00 07 E8 01 68 AA AA AA AA AA AA
[19:00:37.109] [638178732371096847] 00 00 07 E0 07 23 40 00 00 00 00 06
[19:00:37.125] [638178732371253525] 00 00 07 E0 07 23 40 00 00 00 00 06
[19:00:37.125] [638178732371253525] 00 00 07 E8 10 0B 63 40 00 00 00 00
[19:00:37.234] [638178732372347103] 00 00 07 E0 30 00 00
[19:00:37.250] [638178732372503536] 00 00 07 E0 30 00 00
[19:00:37.742] [638178732377428582] 00 00 01 01 FE 01 3E
[19:00:39.742] [638178732397429804] 00 00 01 01 FE 01 3E

I've colored the lines that UP colors red so that just in case that matters. I'm using a script to run these commands and I've attached that below.

Mode_23_Test.txt

(112 Bytes) Downloaded 112 times

If anyone has any idea what I am doing wrong please let me know, because I'm sure It's something I am doing.

[antus]

Yeah I think mode 23 is two bytes. When I implemented Cal read with Mode 23 on the P01 it was 2 bytes. Thats was older and VPW, but its all the same OBD2 when your at the protocol level.

[Tazzi]

Playing with Mode 23 I am not able to request more than 2 bytes in one message (due to the limit of the CAN message size).

I see in the can info that a Flow Control frame is sent to continue receiving the remaining messages with the data requested. I have tried to do that, but I am not getting any more responses after sending the flow control message.

Here is a snippet from the log (Universal Patcher Logger)

[19:00:35.981] [638178732359819160] 00 00 07 E0 01 28 FF FF FF FF FF FF
[19:00:35.999] [638178732359996649] 00 00 07 E0 01 28 FF FF FF FF FF FF
[19:00:35.999] [638178732359996649] 00 00 07 E8 01 68 AA AA AA AA AA AA
[19:00:37.109] [638178732371096847] 00 00 07 E0 07 23 40 00 00 00 00 06
[19:00:37.125] [638178732371253525] 00 00 07 E0 07 23 40 00 00 00 00 06
[19:00:37.125] [638178732371253525] 00 00 07 E8 10 0B 63 40 00 00 00 00
[19:00:37.234] [638178732372347103] 00 00 07 E0 30 00 00
[19:00:37.250] [638178732372503536] 00 00 07 E0 30 00 00
[19:00:37.742] [638178732377428582] 00 00 01 01 FE 01 3E
[19:00:39.742] [638178732397429804] 00 00 01 01 FE 01 3E

I've colored the lines that UP colors red so that just in case that matters. I'm using a script to run these commands and I've attached that below.

Mode_23_Test.txt

If anyone has any idea what I am doing wrong please let me know, because I'm sure It's something I am doing.

Its odd your needing to send the request more then once.
Do you have a terminating resistor on your bench setup?

[Gatecrasher]

Here's a log of mine using an OBDLink MX. It can be set to send the flow control automatically. I think the extra 0s in the FC frame are just padding. Dunno if they're strictly necessary. Couldn't hurt to try adding them. I don't know how to translate this into a UP script.

10:25.761839,CAN,0x00000000,00 00 07 E0 07 23 40 00 00 00 00 06
10:25.767607,CAN,0x00000000,00 00 07 E8 10 0B 63 40 00 00 00 00
10:25.767901,CAN,0x00000000,00 00 07 E0 30 00 00 00 00 00 00 00
10:25.774567,CAN,0x00000000,00 00 07 E8 21 FF 00 FF 00 FF AA AA

[turbo_v6]

Its odd your needing to send the request more then once.
Do you have a terminating resistor on your bench setup?

I'm not as far as I'm aware. I think It's just how Universal Patcher shows it.

UP_Capture.PNG (17.29 KiB) Viewed 1543 times

Here's a log of mine using an OBDLink MX. It can be set to send the flow control automatically. I think the extra 0s in the FC frame are just padding. Dunno if they're strictly necessary. Couldn't hurt to try adding them. I don't know how to translate this into a UP script.

10:25.761839,CAN,0x00000000,00 00 07 E0 07 23 40 00 00 00 00 06
10:25.767607,CAN,0x00000000,00 00 07 E8 10 0B 63 40 00 00 00 00
10:25.767901,CAN,0x00000000,00 00 07 E0 30 00 00 00 00 00 00 00
10:25.774567,CAN,0x00000000,00 00 07 E8 21 FF 00 FF 00 FF AA AA

That's nice it sends it automatically. It looks like your software is sending it much faster, so that might be it. I think there is a 100ms timeout for the FC message after the ECU responds to the original request. So in yours it shows only 2 ms between those times where mine is 109 or 125 depending on what message is the correct one to calculate with.

[Tazzi]

OHHHHH Now I understand.
Red is what you write.
Green is what is happening on the bus?

Ok, so.. I believe you need to send your flow control frame (7E0 30 00 00) faster. The SAE standard indicates its suppose to be within 50milliseconds.

[turbo_v6]

Yeah, I think that's as fast as UP is able to send it. I'm not adding any delays or anything between messages, so I'm not sure what else I can do without starting to write my own application.