OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
Tazzi
Posts: 3425
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Whiteford wrote: Fri Mar 08, 2024 9:35 am I’ll also assume it’s fixed because I no longer risk using it.
Thats not a problem. Each to their own!
Since our focus is working with willing developers and individuals, we cannot expect everyone to be like that or be willing to take time away to email logs. :thumbup:

Regardless, back to it!

This morning I have been lucky enough to have a cardaq3 and MDI2 on loan, we have some interesting results flashing some of the trouble some GMLAN based modules.

The main points for cardaq3:
1) When the module requests 1ms, it is doing approximately 2-4ms
2) Out of 30 flashes on one of these modules, we have had 12 failures (37% failure rate)
3) When forcing it to 2ms (I am sending the flow control before the module responds), we are seeing 5-8ms delay (0% failure rate)
4) We see random spikes of longer delay times, I would guess this is interrupts running in the scantool operating system.

The main points for MDI2:
1) 100% failure rate with Techline, it would not accept flashing the bootloader. Appears to be too large for its memory??
2) Similar delays to what the MDI1 does. Occasionally had next to no delay directly after a tester present message which appears to be a fault/timing issue.
3) When flashing with my own software, only 1 failure out of 30.

With that said, I believe I am out of options for tools to test against that I know supports GMLAN :lol:
I can genuinely understand why technicians have a dozen different J2534 tools now since every tool manufacture has a different delay multiplier that they follow as a safety barrier.

I don't believe having to use OEM specific tools is needed, the MDI2 is meant to be GMs flagship tool and it technically doesnt seem to even support this properly :shock:

I guess I am just going to keep going through module after module with delaership tools and OBDX tools until I find something that doesnt work to repeat all the tests again! :D
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: 3425
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Updates have rolled out for VX, GT and FT scantools.

This update is to help address to the controllers that request a slower communication between CAN frames which the OBDX adds a bit of a 'buffer zone' ontop of.

I have flashed several thousands of times with a bunch of OBDXs all hooked up to the bench between various GM/Ford/FCA modules, so I am feeling very confident on it.

The latest release of the OBDX Pro VX J2534 API driver is also up, along with an update for both the FT and GT J2534 APIs.
All of these J2534 APIs will require the tools on their latest versions to be able to run, a warning message will pop up indicating an update is required if running old firmware.

The OBDX Pro FT developers guide has also been updated and uploaded to the downloads page too.
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: 3425
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

An update for the GT J2534 (v1.5) will be available shortly, I am going to be marking it as 'beta' on the website since I need to find some more VPW based ECUs to test with GM Techline/GDS2 and other J2534 tools before I feel confident pushing it to the core API.

This update makes a small edit to how filters are dealt with for VPW to jerry rig a fix for PCMHammers current 021 release.
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: 3425
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Ahhhhh HA!! I have finally found a VERY incompatible ECU that affects all scantools that I have found so far.. Finally something the GM MDI absolutely cannot handle.

Im working on a FCA based ecu currently, and it does the following:

Code: Select all

07E8  8  30 08 00 AA AA AA AA AA 

07E0  8  21 00 00 0C 00 00 00 20 
07E0  8  22 00 00 00 00 00 00 00  
07E0  8  23 00 00 00 00 00 00 00 
07E0  8  24 00 00 00 00 00 00 00 
07E0  8  25 00 00 00 00 00 00 00  
07E0  8  26 00 00 00 00 00 00 00  
07E0  8  27 00 00 00 00 00 00 00  
07E8  8  30 08 00 AA AA AA AA AA 
07E0  8  28 00 00 00 00 00 00 00  
(Stops here and errors) 
Looking at our first flow control (FC) message from the engine computer:
07E8 8 30 08 00 AA AA AA AA AA
Where
7E8 = engine computer ID
30 = flow control message
08 = Send only 8 frames only, and then I MUST send another FC before you can proceed. (I call this FC mini blocks)
00 = Send as fast as you can

Now... after 7 frames... the flow control got sent.. yet the MDI was waiting to send 8 fames and THEN receive the FC.
When it doesn't see the FC after the 8th frame, it errors.

As far as I am aware, only the factory witech tool seems to handle this and actually work.
My guess is the ECU is incorrectly counting, so the 8th frame technically is the start of the next FC mini block, and the witech tool is seeing the message then restarting its counter instead of erroring.

Not a single tool seems to handle this so far, since it completely breaks the SAE standard.

But.. easy to fix when you know what your looking for.
Next tool update will have a check if any CAN frames are received while writing in a FC mini block.
If it detects a flow control message early, it will update its internal counter to reset and continue writing.

A simple yet effective fix.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply