LMK if you need any help, i may or may not be of any when its comes to J2534 
Have a fair amount of experience with it.
Thanks skijump40, it seems you understand exactly what I am looking to do. If you have experience with this, would you be interested in a quick chat about it? Thanks
Yes sure i can help answer some questions.
J2534 is a protocol that works with UDS and allows you to program modules?
Hopefully once I get to that point it will be easy to see what is going on.
So far as I can tell (and I’m no expert), J2534 is essentially a standard that defines a Windows DLL interface. Everyone who wants to support it writes a windows driver for their hardware that turns J2534 calls into raw CAN traffic. It’s called a pass-through device because it kind of makes your CAN hardware just a dumb device that forwards traffic in both directions. That way the DLL and the program contain the actual logic and the underlying hardware is somewhat irrelevant. You can use a Kvaser or Peak or some other tool to do the flashing and it doesn’t matter which. All they’re doing is forwarding traffic back and forth. But, the problem I have with it is that it really boils down to what appears to be a Windows DLL. You can’t use Linux to flash your car, the manufacturer isn’t going to produce a linux program to do it. You can’t use OSX, that’ll never happen. Instead it locks everything into Windows and that makes me sad.
I’m more interested in what the end program is sending and receiving via the J2534 calls. In other words, I’m much more interested in the resultant raw CAN. That’s likely to be UDS messages going back and forth in a modern vehicle.
Thanks @CollinK. When I get my Tech 2 I will try to see what it does. Been getting bogged down with homework but still working on tying two M2’s together so I can make a bridge. The bridge will be transparent to SavvyCAN but still trying to figure it all out. When I get a little closer I will post a new thread for it. Basically I am hoping that I can track canbus traffic on either side of the bridge to allow RE a module on its own without affecting the traffic its self. This will be very helpful in trying to engineer the Tech 2 as it will make syncing commands to results much simpler.
The j2534 specifications basically tell you exactly everything you need to know and how the hardware should work, theres a few docs that you have to pay for(copyright, etc).
basically the J2534 doesnt really do any of the transport/application protocol logic, its just a bridge to the actual physical network(can) You must implement all the manufacturer specific “stuff”
UDS is pretty standard now, so thats where i would start, any test ecu on the bench should work thats modern(check first).
Sniffing the can is the way to go, rest will be up to you to decipher. Feel free to post up anything i may be of some help with deciphering some of it even if its not my exact expertise(bosch).
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
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.
Here is some very helpful info on GM programming.
1 Like
Yes, those documents look pretty neat. It’s a shame that scribd charges money but I suppose it isn’t a fortune.
Aaaaaaa… http://techposts.org/how-to-download-documents-from-scribd-for-free-100-working/ …choo!!
Oh sorry, probably its the weather. 
Ok, i am by no means an expert…Please dont ask how i know these. I cant say. Its top secret stuff. 
No seriously, i am no expert.
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…
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) . 
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.
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.
You will certainly be interested in what I will be working on this summer. Full integration of J1850VPW is planned.
1 Like
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.
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…
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.
@Marcm I have similar codes for J1850 VPW but i certainly am interested in doing the same with newer stuff.
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.