E92 PCM Reverse Engineering
Re: E92 PCM Reverse Engineering
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.
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.
Re: E92 PCM Reverse Engineering
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.
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.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: E92 PCM Reverse Engineering
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.
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.
Re: E92 PCM Reverse Engineering
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.
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.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: E92 PCM Reverse Engineering
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:
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.
I don't fully understand the reason for that format, but I'm pretty sure it's correct.
Any help would be appreciated.
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);
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 });
Any help would be appreciated.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
-
- Posts: 590
- Joined: Thu Feb 13, 2020 11:32 pm
- cars: Mainly GM trucks, a Cruze and an Equinox for dailys..
Re: E92 PCM Reverse Engineering
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.
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.
Re: E92 PCM Reverse Engineering
I didn’t know it was an Extended frame. Thanks for that. I can look into that more.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: E92 PCM Reverse Engineering
Ok I figured it out. I just needed to add this "TxFlag.ISO15765_ADDR_TYPE" to the txflags.
Updated:
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 }); ;
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: E92 PCM Reverse Engineering
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.
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.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
- antus
- Site Admin
- Posts: 8261
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: E92 PCM Reverse Engineering
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.
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.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396