Open source GM OBD2 flash tool using a ELM327 device

[160plus]

The name Thaniel has come up in this thread a couple of times, if you look close you will see he did actually make one post well over a month ago.

I have been working with him in great detail to "Create" a suitable VPW interface and to unravel the mystery's of how to read and writing a pcm. After several attempts to convince Thaniel to make some type of "Public" post regarding the project we have been working on; he has chosen to remain in the shadows and has tasked me with "passing on" and sharing the details of the work being done.

With that being said I feel Thaniel and his Son have done some amazing work here with very few tools and almost nothing to work with. While I have contributed to the code and done extensive testing Thaniel and his son are responsible for the vast majority of the programming that got this working.

There are also a number of other people that have contributed to this both directly and indirectly, with out their contributions this likely would never have made it this far in the first place.

NSFW - With out his conversion Software we would have never been able to turn the hex we read out into a bin file

Tazzi - I'm going to say your what inspired me to purse this for as long as I have. I nearly gave up on this idea a couple of times but somehow you always found a way to change my mind.

Antus - I'm not even sure where to begin.......with out your help this would have died a long time ago.


Once the program is stable and working with 4x for read and write the full sketch and circuit diagram will be posted to the Github project.

In 1x mode the best read time I have been able to get was just a touch under 8 minutes on the 512K pcm. It can read any where from 1 byte blocks all the way up to 4096 byte blocks. Well....it's actually capable of larger blocks but the P1 and P59 pcm's max out reading 4096 byte blocks. Perhaps that's just the limit of the flash kernel we are using right now or it may be a hardware limit of the pcm. The sketch can be modified to interact the same way as an Elm, so once the program Nsfw is working on gets a bit further along we'll start pulling the "Program" if you will out of the Arduino sketch we have and change the setup so that it is directly interchangeable with what ever driver the Allpro use's.

4X mode is working for monitoring currently but we are experiencing trouble transmitting larger blocks over 4x. We are getting an incorrect byte translation when we send the third part of the flash kernel we've been using. Some more tweaking of the circuit and timings and there's a good chance we'll have 4x working in the next week or two. While in 4x mode we can "Poke" the pcm so to speak to keep it in 4x mode and even after running for quite sometime the smaller blocks are still working fine so we figure it's close.

VPW_MEGA_V015
Set to 1x
enter any character to continue

E8 FF 10 03 B3 - ECU to All - Diagnostic Trouble Codes (03)
6C 10 F0 27 01 B0 - Tester to ECU - Requesting Seed **********************************************************
6C F0 10 67 01 00 6C 8F - ECU to Tester - Seed is: 6C ****************************************************
6C 10 F0 27 02 10 F0 F1 - Tester to ECU - Attempting Key: 10 F0 ****************************************************
6C F0 10 67 02 34 4B - ECU to Tester - Key Accepted ********************************************************************************************
6C FE F0 A0 97 - Tester to All Request High Speed Mode: **********
6C F0 10 E0 AA 7F - ECU to Tester Ready for High Speed Mode: **************
E8 FF 10 03 B3 - ECU to All - Diagnostic Trouble Codes (03)
6C FE F0 A1 8A - Tester to All Begin High Speed Mode: **********Set to 4x

6C F0 10 74 00 44 1E - ECU to Tester Read to Receive write resp. (74):
boot1 send
6D F0 10 76 00 73 42 - ECU to Tester Data Received- Transfer request resp. (76):
boot2 send
6D F0 10 76 00 72 5F - ECU to Tester - Transfer request resp. (76):

76 00 72 5F is not the response we should get.....

512K Pcm Full Bin Read




1Mb Pcm Full Bin Read
*This has been posted on a number of other forums for several weeks
[youtube]https://www.youtube.com/watch?v=_lN201rOZqE[/youtube]

[antus]

Interesting stuff. Got any pics of the hardware?

[160plus]

Interesting stuff. Got any pics of the hardware?

This is a hacked up version of the original 2 Arduino Vpw circuit that I sent Nsfw for testing just so he wasn't using a bread board. Once we have 4x working I'll have another round of pcb's made for people to use while working on this project. We've have somewhere around 40 notable program revisions and some significant hardware revisions over the course of this.

20180306_220536 (1).jpg

This was most recent version on a bread board I was working with over the weekend, however the design has changed again slightly since starting on the 4x mode.

20180313_001237 (1).jpg

The simple version of the circuit

Schematic_elmv2_my-draw-elm-j1850vpw_20180313002450.png

[Gareth]

Biggvl has just donated a 1mbyte pcm to the cause so I can develop and test against that. It'll be great having one on hand. Thanks Biggvl! It will get there.

If there is any other hardware anyone requires please just let me know

[Tazzi]

4X mode is working for monitoring currently but we are experiencing trouble transmitting larger blocks over 4x. We are getting an incorrect byte translation when we send the third part of the flash kernel we've been using. Some more tweaking of the circuit and timings and there's a good chance we'll have 4x working in the next week or two. While in 4x mode we can "Poke" the pcm so to speak to keep it in 4x mode and even after running for quite sometime the smaller blocks are still working fine so we figure it's close.

This was what I was referring to, where timings become so small and critical, that a single bit that is out will ruin an entire block send as then the VPW crc checksum will be invalid. Whether its the sending or receiving at 4x, its likely both are causing dramas, as your in the low microsecond level of timing

Id rather wait 8mins, then risk reliability for 4x.

[160plus]

4X mode is working for monitoring currently but we are experiencing trouble transmitting larger blocks over 4x. We are getting an incorrect byte translation when we send the third part of the flash kernel we've been using. Some more tweaking of the circuit and timings and there's a good chance we'll have 4x working in the next week or two. While in 4x mode we can "Poke" the pcm so to speak to keep it in 4x mode and even after running for quite sometime the smaller blocks are still working fine so we figure it's close.

This was what I was referring to, where timings become so small and critical, that a single bit that is out will ruin an entire block send as then the VPW crc checksum will be invalid. Whether its the sending or receiving at 4x, its likely both are causing dramas, as your in the low microsecond level of timing

Id rather wait 8mins, then risk reliability for 4x.

It's funny....but kind of sucks at the same time. The issue is actually being caused by the optocoupler. The timing is well past anything it was designed to handle and the optocoupller can't make the pulses defined enough for the ecu to read them. Moving to a 6 pin version were we can go directly to the photocell to alter the "speed" that it can pulse may solve the issue or we may have to move to a mosfet but that will require some rework of the interrupts currently being used.


This is the normal wave pattern we see while in 1x mode

unnamed.jpg

This is the signal in 4x mode, as you can see sending more then just a very short message causes some pretty good distortion to the signal.

unnamed (1).jpg

[NSFW]

Sunday night I wired a PCM to an ObdLink SX and a power supply, and did not smell smoke. Good sign, right?

Tonight I got the VIN and OS to display in the app, and I still don't smell smoke, so I'm quite proud of myself at this point.

I'm just using plain old ELM AT commands, but there's enough plumbing in place that I'm starting to feel like I know what I'm doing.

[Tazzi]

Sunday night I wired a PCM to an ObdLink SX and a power supply, and did not smell smoke. Good sign, right?

Tonight I got the VIN and OS to display in the app, and I still don't smell smoke, so I'm quite proud of myself at this point.

I'm just using plain old ELM AT commands, but there's enough plumbing in place that I'm starting to feel like I know what I'm doing.

Can you commit that, so I can get a feel for how your laying it out?

As what Iv current shoved in for J2534 is probably going to be wildly different. Be nice to try follow an example so the same 'logic' can be followed between them all.

*Edit
Oh also, swapping around where it has port and type would maybe make more sense. As if selecting J2534 as the type, then the port would then be used to display the J2534 devices currently installed/available on the computer.

[Tazzi]

It's funny....but kind of sucks at the same time. The issue is actually being caused by the optocoupler. The timing is well past anything it was designed to handle and the optocoupller can't make the pulses defined enough for the ecu to read them. Moving to a 6 pin version were we can go directly to the photocell to alter the "speed" that it can pulse may solve the issue or we may have to move to a mosfet but that will require some rework of the interrupts currently being used.

Yeah, itll be the delay between it opening/closing the connection. Could even be the delay between the arduino even switching the pin fro low/high depending on how thats being doing in code (direct port manipulation?).
Most devices like that arent designed for that high speed, unless it specific states its used for high voltage transmission signal controls.

If continuing with that design, I wouldnt bother with 4x. Who cares, I think everyone could agree that a free option to read/write the ecu that takes a whopping 6min longer (Yes, thats sarcasm) is honestly nothing lost.

In 8mins, you could.. grab a coffee, answer back to one of these wacky messages, chat to mate... or just completely zone out and enjoy 8mins of peace and quiet

[NSFW]

Yes, I'll commit in just a few minutes.

And I hear you about the UI needing a swap, in fact I was writing about that at the same time you were, and the forum asked me to read replies before posting this.

The drop-down lists in the UI were designed around the idea that users would pick a serial port, then a device type, with J2534 tacked on as an afterthought, and some of the under-the-hood design followed from that. Those seemed like good ideas at the time, but the more I work on this, the less happy I am with those decisions. It would probably be better to have the user pick a device type first, and then pick a serial port only if the device really needs a serial port.

Also, the Device classes that need a serial port could just create the SerialPort object directly, rather than going through the IPort interface, since IPort kind of gets in the way and isn't really adding much value.

But those changes would be kind of disruptive and I don't want to interrupt anyone who is actively work on the app right now, and they're not urgent. And it's not terrible, and better ideas might come later. But at some point I might want to ask everyone to check in what you have, and then I'll take a day or two to revamp this, and then we can keep going.