pcmhacking.net

Posted: **Wed Oct 12, 2016 2:16 pm**

Happy to help any way I can.. I've been working my way though howto's on dotnet, reverse engineering with IDA and reverse engineering PCM's.. lots of reading.. Then I had to port a two stroke and got distracted for a bit.

Then I discovered PerlNet http://docs.activestate.com/pdk/6.0/Per ... rview.html and thought.. ohhhhh.. I could be using perl code with dotnet libs.. I'm far far more at home with Perl than C# and it has some possibilities.. not the least of which is that Perl compiles down to Microsoft IL. And then there is this: http://search.cpan.org/dist/Win32-CLR/lib/Win32/CLR.pm

probably I should just learn C# but for trail and error and test stuff Perl has always been my go to girl.

Posted: **Wed Oct 12, 2016 2:34 pm**

rolls wrote:Yeah I don't see any reason why you can't just write the VID block or partially write tables directly, I haven't actually tried it or investigated if the writes must lie on certain boundaries but it should be possible. My auto detect routine simply reads the VIN/strategy (only 36 bytes of data). I probably won't do it initially though as the BF PCM only takes 40 seconds to write which is pretty quick. Nothing stopping you downloading my source code and trying it out yourself. Anything is possible, all it requires is the time to implement and test it.

I have every line of code you've submitted to github. I'm certainly going to give it a try.. the whole new language thing is a little obstacle.. but not an insurmountable one. I had planned on getting fully versed in NodeJS for work, but this is more useful to me so I'm swapping to c# and visual studio.. something I never thought in my wildest dreams I'd do.. but I've seen you write python code and ask Perl questions on SE so I guess I can go the other way.

rolls wrote: Does BE require you to cycle the ignition power and FEPS to write the VID block? I'm wondering if they do a data transfer or if there is an OBD command that lets you write the VID via other means. I'll send you a copy with my new sniffing capabilities, be interesting to see what they do. The sniffer may only work with Open Port though as it uses some proprietary J2534 connect flags.

Yes, BE still does the "please turn off and on your ignition" before every write.. If you edit the vid block it then asks you if you want to write those changes and from there it's like a normal write. In fact if you use "module programming" in IDS to change VID block data it also asks for the KOEO stuff.

By all means yes, send it though.. I am happy to test with either VCX, Mongoose or VCM2 as I have all three and the drivers for all three are on my car laptop.

rolls wrote: I have an idea in my head of modifying the code to write the tables to RAM on bootup, then replace the ROM pointers to RAM pointers. I then write directly to the RAM to allow for live tuning. This is how they accomplished live tuning on the GM PCMs so I see no reason why it couldn't be done on the Ford ones with enough time put into it.

I have plans for tune compare but not until I get the editor software working well.

For some reason I find the idea of that a bit scary. I'm not sure that's how BE does it but it'd almost have to be something along those lines wouldn't it?

Posted: **Wed Oct 12, 2016 2:54 pm**

MeZmeriZe wrote:
I have every line of code you've submitted to github. I'm certainly going to give it a try.. the whole new language thing is a little obstacle.. but not an insurmountable one. I had planned on getting fully versed in NodeJS for work, but this is more useful to me so I'm swapping to c# and visual studio.. something I never thought in my wildest dreams I'd do.. but I've seen you write python code and ask Perl questions on SE so I guess I can go the other way.

The way I see it once you are a programmer you implicitly know all languages, the difference is simply syntax and style. Eg if you wrote C all your life you can still write an OO language such as C# as monolithic static class, it would be frowned upon but it would work fine.

I regularly have to pick up new language at work, eg I've had to have some experience in perl, python, C, C++, C# .NET, VB6, VBA, VB.NET, powershell, assembly (PIC, AVR and X86), structured text, ladder logic and function block programming for PLCs etc. With all the above I still stick to C# by choice even on Linux (using mono and Visual studio code) as the standard library is incredibly powerful. Even if I'm doing embedded ARM or AVR programming I will use .net if power consumption and RAM is not an issue. I just make more mistakes when I write C (memory management and pointers are simply too easy to get wrong).

Learning a new syntax these days is super easy with intellisense etc. Definitely give it a shot!

Code: Select all

Yes, BE still does the "please turn off and on your ignition" before every write..    If you edit the vid block it then asks you if you want to write those changes and from there it's like a normal write.  In fact if you use "module programming" in IDS to change VID block data it also asks for the KOEO stuff.

By all means yes, send it though.. I am happy to test with either VCX, Mongoose or VCM2 as I have all three and the drivers for all three are on my car laptop.

Good to know. Regarding the CAN sniffer I'll wait until the auto detect and BA write works before I send it so you can test that as well. Another guy tried the sniffing ISO15765 with 2 other devices and it doesn't work. I believe as J2534 by design isn't meant to have two testers (0x7E8) on the network at the same time, Tactrix have simply implemented this as a proprietary connect flag to allow better sniffing.

For some reason I find the idea of that a bit scary. I'm not sure that's how BE does it but it'd almost have to be something along those lines wouldn't it?

It is exactly how the others do it, not sure about BE but the other GM stuff I've read about is done that way. There is a thread in the GM section about it on this forum somewhere.

Basically I would read the ROM into RAM and then modify the RAM, once the user is happy they can write what is in the RAM back to ROM (via a normal flash). Nistune and others chip tuners do similar. You can't have the car running whilst writing to the ROM so I don't see any other way to do it.

Posted: **Wed Oct 12, 2016 4:33 pm**

rolls wrote: Learning a new syntax these days is super easy with intellisense etc. Definitely give it a shot!

Yes, you are correct, and I think I actually said the same thing to you in the msg of fordmods.. There are a couple of distinctions though.. I'd put assembly in a separate bucket to all the others. I must admit that looking at assembly makes my head hurt. I guess it's a practice thing.

rolls wrote: Good to know. Regarding the CAN sniffer I'll wait until the auto detect and BA write works before I send it so you can test that as well. Another guy tried the sniffing ISO15765 with 2 other devices and it doesn't work. I believe as J2534 by design isn't meant to have two testers (0x7E8) on the network at the same time, Tactrix have simply implemented this as a proprietary connect flag to allow better sniffing.

There might be another way.... J2534 specifies the overall API... but the underlying protocol is something else entirely.

I have an actual proper non OBD2 Can sniffer here... but I don't think Ford use CAN for this.. my understanding is that this stuff is J1850PWM and it's just a PWM signal from 0-5v 41kbps 12b length... could we listen in on that to see what is happening rather than at the higher level? a quick google shows people have been talking about sniffing pwm for a while now.. probably some libs I can use already.

Posted: **Wed Oct 12, 2016 8:07 pm**

rolls wrote: Good to know. Regarding the CAN sniffer I'll wait until the auto detect and BA write works before I send it so you can test that as well. Another guy tried the sniffing ISO15765 with 2 other devices and it doesn't work. I believe as J2534 by design isn't meant to have two testers (0x7E8) on the network at the same time, Tactrix have simply implemented this as a proprietary connect flag to allow better sniffing.

Think Im a little confused on what you mean with two testers? Do you mean two devices acting on the same ID? Ie.. having two ECU's hooked up onto the same CAN bus line?

MeZmeriZe wrote: There might be another way.... J2534 specifies the overall API... but the underlying protocol is something else entirely.

I have an actual proper non OBD2 Can sniffer here... but I don't think Ford use CAN for this.. my understanding is that this stuff is J1850PWM and it's just a PWM signal from 0-5v 41kbps 12b length... could we listen in on that to see what is happening rather than at the higher level? a quick google shows people have been talking about sniffing pwm for a while now.. probably some libs I can use already.

Off the top of my head, PWM is only used on the Ford AU's.
BA,BF and FG are all CAN based for all major components, and LIN for some of the less critical systems (Well.. Im sure I read LIN in the FG manuals).

Posted: **Wed Oct 12, 2016 9:38 pm**

MeZmeriZe wrote:There might be another way.... J2534 specifies the overall API... but the underlying protocol is something else entirely.

I have an actual proper non OBD2 Can sniffer here... but I don't think Ford use CAN for this.. my understanding is that this stuff is J1850PWM and it's just a PWM signal from 0-5v 41kbps 12b length... could we listen in on that to see what is happening rather than at the higher level? a quick google shows people have been talking about sniffing pwm for a while now.. probably some libs I can use already.

I use ISO15765 via CAN for everything in my program, all the ford programming is done via ISO15765 via CAN. Some stuff is read back by standard CAN but I haven't needed it for anything yet. The OpenPort does not support J1850PWM and nor does the BA/BF/FG afaik.

You can put a plain CANbus sniffer on the line and listen in but good luck deciphering anything from the ~1000 CAN packets you get per second.

I use canbus (physical layer), ISO15765 (datalink layer eg how the packets are formed) and either OBD2 (J1939) or Unified Diagnostic Services (UDS ISO14229) as the application layer. All the flash read/write and DMR access is ISO14229.
I can sniff CAN packets or ISO15765 packets via J2534 using an OpenPort. The packets are different and ISO15765 via CAN packets are the ones I am interested in and do all my comms via.

Have a look at the log I posted a few post back as an example of the UDS commands. The log has a combination of CAN and ISO15765 packets, the CAN packets are just chatter that I ignore, the ISO15765 packets are the PCM communicating with another tester that I am sniffing.

Tazzi wrote:Think Im a little confused on what you mean with two testers? Do you mean two devices acting on the same ID? Ie.. having two ECU's hooked up onto the same CAN bus line?

I mean having two PCs devices hooked up to one PCM. Eg two J2534 devices, one programming a PCM and another trying to sniff the communications. You can do it but if they both have the same address weird stuff happens, hence the OpenPort has a proprietary connect command that effectively acts as a passive listen device, kind of like a normal CAN device with the ISO comms turned off.

edit: Here is the J2534 connect string I use to sniff comunications:

Code: Select all

J2534Status = J2534Interface.PassThruConnect(DeviceId, ProtocolID.ISO15765, ConnectFlag.SNIFF_MODE | ConnectFlag.CAN_ID_BOTH, BaudRate.ISO15765, ref ChannelId);

    [Flags]
    public enum ConnectFlag
    {
        NONE = 0x0000,
        ISO9141_K_LINE_ONLY = 0x1000,
        CAN_ID_BOTH = 0x0800,
        ISO9141_NO_CHECKSUM = 0x0200,
        CAN_29BIT_ID = 0x0100,
        SNIFF_MODE = 0x10000000 //Only supported by OpenPort 2.0
    }

    public enum ProtocolID
    {
        J1850VPW = 0x01,
        J1850PWM = 0x02,
        ISO9141 = 0x03,
        ISO14230 = 0x04,
        CAN = 0x05,
        ISO15765 = 0x06,
        SCI_A_ENGINE = 0x07,
        SCI_A_TRANS = 0x08,
        SCI_B_ENGINE = 0x09,
        SCI_B_TRANS = 0x0A
    }

Posted: **Thu Oct 13, 2016 10:04 am**

Ah yep I see, must be a J2534 related issue with the IDs.

Since, if one device is simply listening and the other is performing the writing.. it shouldnt be an issue.
It could be that both devices have automated responses? As in, if they receive 7E8 10 XX YY ZZ ......., then the device automatically responds 7E0 30 00 00

I assume it would be something like that.

I have that issue with my own cable if everythings turns to auto formatting and control and both are set with the same filter (7E8)

Posted: **Thu Oct 13, 2016 10:16 am**

Tazzi wrote:Ah yep I see, must be a J2534 related issue with the IDs.

Since, if one device is simply listening and the other is performing the writing.. it shouldnt be an issue.
It could be that both devices have automated responses? As in, if they receive 7E8 10 XX YY ZZ ......., then the device automatically responds 7E0 30 00 00

I assume it would be something like that.

I have that issue with my own cable if everythings turns to auto formatting and control and both are set with the same filter (7E8)

Yep at the CAN level there is no defined behaviour, you can listen, write crap and do whatever you want. J2534 is a higher level wrapper over the top and it expects to be the only "tester" on the network. You can connect with flow control disabled (eg no 7E0 response) and CAN selected however J2534 then automatically filters all ISO15765 packets.

When sniffing you want ISO15765 packets and no flow control which isn't something the J2534 had in mind when it was designed. This is probably why a lot of flash devices don't use J2534 and just implement everything at the CAN layer as you have more control. As OpenPort has implemented this sniff function though it really has the best of both worlds.

I'm still learning the J2534/ISO15765 stuff so what I wrote above may not be entirely correct however it is my understanding to date. Probably something we would get a much better answer if we posted on the drewtech forums.

Posted: **Sat Oct 15, 2016 9:40 pm**

Ok should have something to you guys tomorrow that can sniff, read and write ba/bf/fg and any other ecu that is spanish or black oak.

Rewrote my uds flash library to be generic using lots of polymorphism so I can easily add other manufacturers or pcm types without making any changes to the gui code at all. The goal here is to make my library interchangeable with my simple WinForms flash gui and the full editor suite.

Is anyone here a full time programmer? Be good to get someone else involved but they would have to have a similar level of experience.

Posted: **Sun Oct 16, 2016 10:38 am**

rolls wrote: Yep at the CAN level there is no defined behaviour, you can listen, write crap and do whatever you want. J2534 is a higher level wrapper over the top and it expects to be the only "tester" on the network. You can connect with flow control disabled (eg no 7E0 response) and CAN selected however J2534 then automatically filters all ISO15765 packets.

Yep yep, that makes sense. The device must send tester present constantly on the network (or similar).. so two devices would freak each other out. That would be why the devs added that extra sniffing ability then.
Guess theres perks of both systems.. J2534 is structured throughout making it easy(ish) to support other J2534 devices.. but at CAN level it gives raw access.

pcmhacking.net

PCMTec Development Blog

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning

Re: Ford MPC565 Tuning