E92 PCM Reverse Engineering

[kur4o]

There is one way but depends on the quality of the tool you are working with.

You can open a second protocol for CAN and it should output all data traffic. Be prepared to get like 20 messages per 1ms.
Raw can is very hard to trace and log, and most tools just freaks out.


I will add a preset that works with MDI, hopefully openport will be good enough to support that kind of configuration.

I think openport have some echo_back set all the time, since it resembles MDI loop_back response. We will need some debug log to see how they are formatted and likely filter them from log.

[kur4o]

Here is the setup, and the preset.

When you load the preset, make sure you check the use protocol1 channel.

Usually the rate is very fast and be prepare to send multiple times a message, and it will likely will be not visible on screen when send. You can also send data on per protocol based on protocol selection marked in red.

[kur4o]

bubba2533,

Can you make some debug logs with openport, using a utility that comes with mdi manager.

It will log all communication between tool and program.

Here is some links
https://www.boschdiagnostics.com/softwa ... -and-mdi-2

WIth that debugging we can improve overall performance with openport, and add some specific features if needed.

[turbo_v6]

Here is a test of the first thing you sent.

2 Protocol Test.PNG (49.86 KiB) Viewed 2023 times

[kur4o]

When you connect protocol1, than hit the connect button on protocol2.

They are separate and needs separate connect/disconnect sequence.

[turbo_v6]

Ah ok, missed that.

The color is really hard to read, so I would change that to something with more contrast.

[kur4o]

Ah ok, missed that.

The color is really hard to read, so I would change that to something with more contrast.

I completely agree, it is not the best to read. I think some settings for console color will be nice addition for next release.

Now we need to fix the message loopback, it might interact with some scripts.


This version have some initial CAN logger. You can give it a try.
settings tab->protocol-CAN->connect
profile tab ->select pids ->+-> start logging button.

[turbo_v6]

Yeah, I would like to make sure any scripts I use won't be impacted by that loop back.

I'm at the point where I want to try and start sending Mode 34 & Mode 36 messages to try and upload code (kernel) for the PCM to execute.

I have up to the Mode A5 message working. There is some weirdness going on with the timing and/or message order.

Unlock Capture Test.PNG (54.54 KiB) Viewed 2002 times

Script File:

pcm_unlock_test 2.txt

(178 Bytes) Downloaded 135 times

[turbo_v6]

Hmm, I just noticed that it timed out and the last 2 commands failed. Not sure why that periodic tester present message isn't working.

Edit: It works fine if I get all the messages in before the internal timer resets (aka shorten the delay between the messages).

Unlock Capture Test Reduced Delay.PNG (53.24 KiB) Viewed 1984 times

pcm_unlock_test 3.txt

(178 Bytes) Downloaded 143 times

[kur4o]

When using 5 byte header [00 00 01 01 fe]in iso15765 protocol it needs special flags added, to be sent successfully.
We already added that, and should be set like that.
ISO15765_ADDR_TYPE set as txflag, says the tool to use extended header formatting.

00 00 01 01 fe 3e:ISO15765_FRAME_PAD|ISO15765_ADDR_TYPE

There is also a way to setperiodic in script.

Startperiodic:<message>:<interval>:<txflags>
Stopperiodic:<message>:<interval>:<txflags>
Clearperiodic


In the script you have tested, you need to specify how many responses the program should expect, before moving to next frame.

For example

00 00 07 E0 28:2:100

:2=program will wait for 2 responses
:100= some timeout if it don`t get 2

With that messages echoed back you will need to set :2 for most cases, until we found a way to filter it or find why it is spamming the bus with it. Maybe hey have some special function that can be set.

This is definitely not in j2534 standard, open a case with manufacturer. they will provide needed data how to turn it off. Or we can debug the communication with mdi manager and find another solution.