Open source GM OBD2 flash tool using a ELM327 device

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
Locked
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 160plus »

Tazzi wrote:
160plus wrote: 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 :shock:

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
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 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.
Attachments
VinOsRead.png
VinOsRead.png (47.56 KiB) Viewed 4396 times
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

NSFW wrote: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. :thumbup:

*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.
Last edited by Tazzi on Tue Mar 13, 2018 3:56 pm, edited 2 times in total.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

160plus wrote: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. :thumbup:

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 :lol:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 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.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by NSFW »

I just merged my changes.

Just for the record, I really, really want to get rid of the a 250ms delay in ScanToolDevice.SendRequest(). I'll tackle that next.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

NSFW wrote:I just merged my changes.

Just for the record, I really, really want to get rid of the a 250ms delay in ScanToolDevice.SendRequest(). I'll tackle that next.
Quickest way is to check is there are any bytes available in the port, then readline as ELM based devices chuck a newline at the end of frames. :thumbup:

And.. walaaaaaa..Delays begone
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8238
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: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

For binary protocols such as the AVT you typically want a filo buffer, as they typically start with length bytes, so you pull those, then keep reading until you have the rest of the packet. Although maybe this will be handled by the serial layer, so reads are not likely to be partial. Worth considering though. Im back from my break and had a bit of a play for 30 minutes this morning but changes to the API would not be disruptive. I'd say if you have more understanding now go for it. I'll keep doing periodic pulls and stay in sync while I get my head around how to make the AVT code fit.
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
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by NSFW »

I just pushed up a change that adds a lot of comments, and fixes the VIN/OS features of the MockPCM class, because I learned a thing or two about message parsing when I was talking to an actual PCM.

It's midnight now so getting rid of that delay will have to wait 'til tomorrow.

Hopefully the ScantoolDevice class will help a little bit with the AVT development. The main thing is just that the SendRequest method chops up the incoming message byte array to fit the ELM protocol when it sends data... and when it receives data, it has to prepend a header to the data that came from the device, to make it look like it came directly from the PCM. The AVT protocol is different (you won't have any use for the SendRequest method that takes a string and returns a string) but the idea is roughly similar.

And since I'm kind of new to this, and I've only tested with one device so far, there's a chance that I didn't get the translation exactly right, especially on the data-coming-from-the-PCM side. If you find that you need to change the MessageParser class to get VIN/OS reading to work, there's a fair chance you're doing it right and I just got it wrong.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
redheadedrod
Posts: 4
Joined: Tue Apr 18, 2017 1:46 am
cars: '03 GM truck, '09 GM car, '94 GM car

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by redheadedrod »

So I apologize for not going back and reading the thread yet but I will try to do so in the next couple days.

I can help translate the code to the M2 which is a Due based Arduino.

So can someone explain how the 4x mode works? Other than it is just a faster speed?

I am still learning how to program for an Arduino and I am in school so my time is somewhat limited but once I figure stuff out I am sure to be an asset.

So what I am asking about for the 4x mode is, how to you get into that mode? Does it coincide with the standard 10k bus traffic?

If I am going to try translating the code I need to understand how the mode works in comparison to the standard baud.

Note, I noticed a lot of work is done in .net. My Senior Project for my degree was written in ASP.NET. So I have some experience writing in .NET if necissary. The first school I went to we used .NET extensively but I transfered to another school and due to graduate after fall semester. I am taking summer to further develop the M2 and possibly learn the new ASP.NET Core stuff for a couple other projects I have in mind.

I will look at the information recently posted to try and grab an ECM and make a harness. I MAY have harness connectors I can use since I pulled about 6" of harness when I pulled the PCM out of the 2002 Trailblazer. Assuming they use the same connectors.

Thank you for "letting me help" and I look forward to helping this work on the M2 and possibly further.

Rodney
Locked