E92 PCM Reverse Engineering

[kur4o]

e92a are 2017+ and use 5 byte seed/key.

T87 are killed from factory, so not a big deal. With an e80 +t87 combo, you can swap them but it depends which year they are.
upto 2017 are swappable, later have different pcm OS requirements and engine controller freaks out.
Programming the valve body data is another matter.

Bubba I have looked at read routines on different Exx pcms and the code being used is very much the same. only some registers are updated per pcm. When you have the core data it can be ported to other pcms quite easy.

[bubba2533]

Yeah, it seems like maybe the part number is the only way to distinguish between them then. The 2017+ ones look physically identical when comparing them from pictures of ebay listings.

Yeah, at some point I might have to look at some of the other ECU's to see what it would take to read those.

I'm pretty sure I have a read kernel that's working, but using universal patcher isn't the most user friendly, so I'm going to try to work on a standalone application.

[kur4o]

Recent changes are much more user friendly and can be further automated if needed.

I can send you a test script for dumping a bin minus the read routines. You have to fill that on your own and specify the read requests loop, Not sure what format it will be used, but any specific format can be easily ported to current parse logic.

[bubba2533]

That's nice, but I'm trying to learn more about creating applications myself rather than use a tool like universal patcher.

With that said I've used it quite a bit in my testing and it's been helpful, but I think it's time to try my hand at creating an application in C#.

Next I need to do some research on the seed/key algos to implement that.

[bubba2533]

I'm having a little trouble with sending a tester present via a broadcast ID. Not sure if I'm wording that correctly.

Here is the current snippet I'm using sending directly to the ECU ID:

Code: Select all

 
using J2534DotNet;

J2534 passThru = new J2534();

passThru.LoadLibrary(J2534Device);
passThru.Open(ref deviceId);
passThru.Connect(deviceId, ProtocolID.ISO15765, ConnectFlag.NONE, BaudRate.ISO15765, ref channelId);

PassThruMsg maskMsg = new PassThruMsg(
                    ProtocolID.ISO15765,
                    TxFlag.ISO15765_FRAME_PAD,
                    new byte[] { 0xff, 0xff, 0xff, 0xff });
PassThruMsg patternMsg = new PassThruMsg(
                    ProtocolID.ISO15765,
                    TxFlag.ISO15765_FRAME_PAD,
                    new byte[] { 0x00, 0x00, 0x07, 0xE8 });
PassThruMsg flowControlMsg = new PassThruMsg(
                    ProtocolID.ISO15765,
                    TxFlag.ISO15765_FRAME_PAD,
                    new byte[] { 0x00, 0x00, 0x07, 0xE0 });
passThru.StartMsgFilter(channelId, FilterType.FLOW_CONTROL_FILTER, ref maskMsg, ref patternMsg, ref flowControlMsg, ref filterId);

passThru.ClearRxBuffer(channelId);

int msgID = 0;

PassThruMsg txMsg = new PassThruMsg(
   ProtocolID.ISO15765,
   TxFlag.ISO15765_FRAME_PAD,
   new byte[] { 0x00, 0x00, 0x07, 0xe0, 0x3e });

passThru.StartPeriodicMsg(channelId, ref txMsg, ref msgID, 1000);

That is working, but I'd like to send it via a broadcast ID so that I don't have to ignore the response from the ECU.

When I change the data portion to this it doesn't work and I am not sure what is wrong. It probably has something to do with J2534DotNet, but I'm not quite sure.

Code: Select all

   new byte[] { 0x00, 0x00, 0x01, 0x01, 0xfe, 0x3e });

I don't fully understand the reason for that format, but I'm pretty sure it's correct.

Any help would be appreciated.

[ironduke]

Someone who knows more than me will chime in but to send that 00 00 01 01 fe 3e You need to have extended addressing turned on..
I've messed with it but since 90% of my code I've just used raw can I can send whatever I want including that message but it does take more work in the end I suspect.

[bubba2533]

I didn’t know it was an Extended frame. Thanks for that. I can look into that more.

[bubba2533]

Ok I figured it out. I just needed to add this "TxFlag.ISO15765_ADDR_TYPE" to the txflags.

Updated:

Code: Select all

PassThruMsg txMsg = new PassThruMsg(
    ProtocolID.ISO15765,
    TxFlag.ISO15765_FRAME_PAD | TxFlag.ISO15765_ADDR_TYPE,
    new byte[] { 0x00, 0x00, 0x01, 0x01, 0xfe, 0x3e }); ;

[bubba2533]

This might seem like a crazy idea but... should I just fork PCM Hammer and try to create a CAN PCM Hammer???

I'm realizing now that there is a lot of architecture built into PCM Hammer and even though I could learn a lot trying to create something like that from scratch I don't think I have it in me to do it.

[antus]

Its a lot of work as VPW is baked in to it quite tightly but I'd be interested to help. If your C# skills are up to it, it would be great to abstract the comms further so it can support VPW and CAN (and I could help with ideas about how to do this) but it'd take pretty strong C# skills. Otherwise forking it and replacing VPW code with CAN would be the easier way to go. Problem would be that if one branch gets developed further the other doesn't get the same updates for free.

The more common VPW PCMs are either supported or close to being supported now. I am already starting to consider if/how/when to make the jump to CAN PCMs.