ECU flashing with M2

Developer Projects
#28

May take me a little while to do this since I am still working on getting 2 M2’s talking to one another while dealing with Calculus in college and working full time… I will get to it and with the tech 2 I should have the tools available to look at it but I have some work to do before I can dig into this.

I do have the software already that is used with the tech 2 to program modules so I suspect the J2534 may already be in there somewhere since it will do up to 2013 GM’s. Unless this is built into the Tech 2.

Wireshark will also sniff USB ports now so I could try to track everything that is going on.

I know I searched on this before and nothing came up but now you do a search on it and a bunch of stuff comes up. I will have to look at it later. Downloaded the SAE document describing it…

Rodney

#29

I have a knock off Tech 2 with the tech2win software. I believe the J2534 info is in the tech2win software as the tech2 is used as a pass through. Here is a setup/walkthrough doc for the factory updates. http://www.drewtech.com/technician/Installing_Tech2Win.pdf
I believe GM started changing some sort of protocol around 2011 and they went to the MDI VCI (Multipul Diagnostic Interface, Vehicle Diagnostic Interface). It still uses J2534 but the tech 2 can no longer handle it. They also require you use their SPS (service programming system)which is a subscription asked service. Not sure how this will impact the use with the M2 but to echo back what a lot of others are saying it will be a heck of an undertaking that will only be useful for a small number of vehicles. That being said, it would be cool, good luck.

#30

Here is some very helpful info on GM programming.

1 Like
#32

Yes, those documents look pretty neat. It’s a shame that scribd charges money but I suppose it isn’t a fortune.

#33

Aaaaaaa… http://techposts.org/how-to-download-documents-from-scribd-for-free-100-working/ …choo!!
Oh sorry, probably its the weather. :laughing:

Ok, i am by no means an expert…Please dont ask how i know these. I cant say. Its top secret stuff. :grin:
No seriously, i am no expert.:roll_eyes: But please do ask any questions, if you want to.

J2534 is an SAE (Society of Automotive Engineers) protocol, created under the right to repair act, aiming to break the monopoly of dealerships.

After passing the court and law of right to repair, a unified protocol was created compiling a new dll covering the following:

ISO9141
ISO14230 (KWP2000)
J1850
CAN (ISO11898)
ISO15765
SAE J2610
J1939 (since 2005)

Note that each manufacturer has a J2534 API (Application Programming Interface) dll (Dynamic Link Library). If you want to search it up and mess around a bit with. Trust me, it can swallow your time without you noticing as you mess around.

The standard has two sub-standards to it (well actually its three, J2534 included), J2534-1 and J2534-2.
So basically simply put, what it does is unifying in a way all the current communication protocols that were made from manufacturers.

With this said though, J2534 interfaces is by no means equal to OEM’s interface.
J2534 interfaces are pretty much used under a paid license of the OEM software, which then can control automatically the interface.
Again, with this said, this means that the software can ask the interface to play dead while fetching a stick.
J2534 in simultaneous communications most of the times falls short.

For example (i am located in EU), BMW online system while going through any type of programmings, using the OEM interface, especially on Fxx and Gxx series vehicles, can set to bootloader, program, code, restore user specific data (radio stations, seat memories etc) in multiple ecus (average of 50 control units give or take a couple), all at the same time.
Just looking at the screen doing its thing, is absolutely terrifying.

If you ask this from a J2534 interface (again i am in EU which means full coverage on ecus not just emissions like in US), it will just simply fall short. Not only by the multitasking, but on the protocols as well.
There is no interface out there that will cover it all on all manufacturers. Nope. If one was manufactured, then everyone including the manufacturers would use that. Plus there are new protocols available now that J2534 interfaces don’t have due to hardware limitations.

IF you managed to read thus far…:clap::clap::clap: :rofl:

I would happily share any knowledge i have with you guys.
Just @ me on your post and i can reply to anything i can and know (and have the time to do so) . :upside_down_face:

#34

Forgot a small (important, well somewhat of important) detail.

All OEMs must comply to J2534 standard, but none said about new developments of protocols or this sort of things soooooo…that is a good window left open for OEMs to always keep us chasing. :slight_smile:

#35

There is an active effort right now to reflash GM’s 12200411 PCM via open-source software. Most of the excitement is toward the end of this thread:
https://pcmhacking.net/forums/viewtopic.php?f=4&t=1566

The short version is that the kernel development and proof-of-concept app were done some time ago, but the app had some reliability and maintainability issues, and we’re now rewriting the app to address those problems.

I would love to get the Macchina M2 working with this project, but it’s not going to be a good option without support for high speed / 4x VPW. I don’t have the Arduino skills to make that happen, but I really hope someone else does… I’ll be very happy to add whatever is needed in the Windows app to support the M2.

#36

You will certainly be interested in what I will be working on this summer. Full integration of J1850VPW is planned.

1 Like
#37

Actually turns out to Flash J1850 files won’t be that big a deal. Will see how it goes. Will be working with a group that is bringing a solution up and it should be available as an option for the M2. Long ways away so far. They have gotten the program to be able to read the binary, change the vin and almost where they can change the serial number. So will see how things go. Flashing applications will likely be options to add since there is only so much room within an m2. Still could be done via a PC even if not accessible otherwise. The software also makes some devices J2534 compliant as well so a PC running it connecting to most ELM based hardware will be able to connect to is as J2534 devices.

#38

J2534 : there is a copy of the -1 part on archive.org, specifically the one passed as US law and covers J2534 API v2.02 . IIRC the most recent published by SAE might have a few minor differences, and accordingly a different protocol v4.04 last I checked.

@CollinK
You are correct, J2534 does specify a windows DLL API. And of course OEMs only produce windows software, however there’s no reason why an open J2534 interface couldn’t also produce a linux library that exposes a compatible API. One thing that will be missing is the windows-exclusive mechanism for discovering available J2534 devices, namely a certain registry key. On linux it would just be a matter of agreeing to look for, say, in ~/.j2534 or something. Granted, some extra legwork would be required to run Win software with these (either under Wine or a VM).

I agree with the previous comments by pedal2metal and skijump40. Nothing really prevents OEMs from adding extra protocols that fit into the J2534 API without colliding into standardized protocols. I.e. there’s no winning, and just keeping up is very discouraging. But still, J2534 is IMHO the best we got - imagine the reflashing landscape without this ! Every OEM with their own incompatible software and hardware packages, etc…

#39

I have source code written in c++ That has full control of j2534 passthrough, I also have other various code to read diagnostic pid’s and perform various procedures like clear trouble codes and read vin, can, ect. I plan on using an m2 instead of my matrix, and obd wireless devices, eventually I will implement a flash reader, and flash kernel for most Bosch…I.E, Infinion processors.

#40

@Marcm I have similar codes for J1850 VPW but i certainly am interested in doing the same with newer stuff.

#41

The “fancy OBD2 cable” is the easy part.

To properly flash most ECUs that follow industry standards you will need:

  • Security Algorithm to enter a trusted state in the module (typically this is a seed / key challenge response where you request a “seed” from the ECU and then you do the proper calculation and return the corresponding “key” value

  • Write Bootloader - In many cases, the software necessary to perform the reflash operation is not present on the ECU. You typically upload this before the actually calibration files.

  • ECU calibration software - Typically this is fetched from OEM software / web service. In some cases, it is digitally signed making altering difficult. Earlier software typically employs a basic check sum routine for the purpose of ensuring the uploaded data wasn’t corrupted.

NOTE - If you goal is to edit the ECU, you also need to figure out the mapping of the software to make the changes you want.

  • Programming Steps - There are specific sequences of events that need to happen, including the previously mentioned items. If things are not done in the proper order, bad times.
#42

@beyerch You may be interested in a project that is currently being worked on.
This will allow you to read/write your PCM for a pre-CANBUS GM vehicle. All of the issues you mention have been addressed. They are working with a 411 PCM (512k LSx PCM) but the only difference for other models should be the kernel.

The M2 will have a sketch available that will be compatible with this as I work on building a new more modular firmware for the M2 in general. Once totally perfected, some members of this group will be looking to move on to CANBUS based PCM read/writes.

To Actually program for these will require using TunerPro which is a “begware” program. (Will work for free but to get rid of the nag notices you need to make a donation.)

So shortly you will be able to program your pre-CANBUS GM for the price of your interface. Currently working or almost working with AllPro, Scantool, MDI and AVT 832 devices. In the coming weeks I will be working with them to get the M2 basically working with it as I work to overhaul the over all structure of the M2 firmware. This will be a stopgap Sketch until I have something more concrete accomplished. Note I am not an active part of any part of that project yet other than tinkering with the M2 side of it.

Note I don’t have TunerPro and am not familiar with it but it is the program I was told they plan to use.

The program they have to do the programming is to be open sourced and there is an android app being worked on to accomplish this as well.

The Open Sourced software is actually written in .net so it is a windows only environment for now.

Rodney

#43

I have been tuning pre-CAN GM vehicles since 1998 and have written my own software. Currently working on CAN through MY17 for GM (and have support as far back as MY94). I’m on the fence as to whether I was going to open source this or not this time around. (I did open source the hardware recently) Getting past MY17 for tuning is going to be a bit harder since they transitioned to a 5byte seed/key which is harder. (I have all of the 2 byte stuff solved already)

On the scantool side, already have things mapped out through MY20/MY21. :slight_smile: (GM)

Also have Ford / Chrysler / Audi / VW in various stages…

Would love to see the current .net as I could probably provide guidance.

The reason I’m teetering on Open Source software is the sheer time involved in this stuff. A lot of people say they want to help but when you really want to get something done only a couple actually step up. I have way more work than time, though I don’t necessarily need money either.

We’ll see.

2 Likes
#44

As far as I know the Tactrix OpenPort just implements a J2534 pass-through. The RomRaider devs might be able to help with the actual read/write sequence.

#45

Just kicking the can up the road this might help get more of an understand or someone might be able to use the code to figure out how to program an ECU. GMLAN and BDM FLASH programmer Source

#46

Hey I have a 1994 jeep Cherokee xj 4.0. is there any chance you are working on something for it? Respectfully James

#47

Hey man,

How are things going with the 5byte seed/key implementation. Have you made any progress since this last post? Extremely interested in your findings, please report back.

Also, do you have any resources handy for practicing on the smaller 2 byte seed/key from older modules? Please let me know, thanks man!

#49

Can someone tell me about it and i don’t know what is this?
https://technoplanners.net/scribd-downloader-download-documents-scribd-free/
If you ask this from a J2534 interface (again i am in EU which means full coverage on ecus not just emissions like in US), it will just simply fall short. Not only by the multitasking, but on the protocols as well.
There is no interface out there that will cover it all on all manufacturers.

Nope. If one was manufactured, then everyone including the manufacturers would use that. Plus there are new protocols available now that J2534 interfaces don’t have due to hardware limitations.