OBDX Development - Developer Tools and Suggestions

[Tazzi]

For those with the keen eye, that is J2534 DLL being used with the OBDX.
Have finally gotten the OBDX J2534 compliant (At least the bare essentials for VPW!), next up is canbus and ALDL!

This means it also works with J2534 dealership software (such as SPS/Techline).
Later down the road will be adding DPDU (For tech2win) as well.

J2534WithOBDX.PNG

[Tazzi]

Interesting developments when using GMs Techline.

So, regardless of what vehicle you try to connect to, techline will ALWAYS try use CANbus first. It must complete trying to use canbus otherwise it hard locks up the application since it doesnt know what to do.
J2534 compliancy is "suppose" to make you support CANbus, but clearly the OBDX Pro VT does not, so this might be a limiting factor for the VT.

The OBDX Pro GT that should (hopefully) have the first lot produced does support canbus, so I am just adding in the requirements to have that in J2534 to see if it will allow proceeding with VPW.

[Tazzi]

it gets even more stupid... as part of J2534 compliance, you must be able to support a maximum of 10 filters.
That is a SAE requirement, 10 is suppose to be the max. Not the minimum... the maximum.

But what does SPS do? Oh.. it tried to setup 16!!!!!!!!!

I am sure there is a gm tech just laughing his ass off right now. Since the value 0x10... is 16, but thats not what the standard says, it says a maximum of "ten", which is written as a word to prevent confusion.

The next troll ontop of that, is all these filters are 29bit filters. The actual physical processor on the OBDX GT only supports 8 29bit filters... so... this means some hack about software filter has to be implemented in either hardware or software.

[Tazzi]

So.. damn... close...

Code: Select all

11:58:50 PM Wednesday, 23 March 2022  : PassThruReadMsgs Called:  timeout: 0
  Num Msgs: 300
11:58:50 PM Wednesday, 23 March 2022  : PassThruReadMsgs Called:  timeout: 0
  Num Msgs: 300
11:58:51 PM Wednesday, 23 March 2022  : PassThruIoctl Called :  READ_VBATT
11:58:51 PM Wednesday, 23 March 2022  : Return OK with Voltage
11:58:51 PM Wednesday, 23 March 2022  : IOCTL Successful
11:58:51 PM Wednesday, 23 March 2022  : PassThruReadMsgs Called:  timeout: 0
  Num Msgs: 300

This is all its calling to and infinite looping.
It reads voltage.. its hardcoded to 14000 (14.000 volts), and passthruReadmsg returns ERR_BUFFER_EMPTY, since there is no data to receive on CANbus.
As it cannot get anywhere further, it comes up saying "VCI did not respond, would you like to retry"... but theres no messages to respond with.

For those technically included, timeout is set to 0 by SPS, this indicates to return immediately after finding desired messages. And the number of messages from SPS is 300, which does seem to be alot...

[Tazzi]

3 hours later.. its connecting and read/writing to techline (almost).

Its sending requests and receiving back, but its looking for some sort of status bit which I believe Im missing. Ill need to send the same request to the MDI and see what its exact responses are, since it should be correct based on the SAE datasheet.

Although in saying all that, it appears the SAE doco is more a guideline then actual exact rules. Techline attempts to set a 1 byte filter for VPW which is mandated to be 3byte, along with doing a variety of other stupid things. Another being setting filters incorrectly and expecting the tool to still find the response (Which it shouldnt). So I know for a fact, hardware manufactures have had to jerry rig their DLLs to satisfy these fails from the dealership software otherwise they do not connect and work.

Thats it for me.. hopefully Ill notice the missing thing when I wake up tomorrow!

[Tazzi]

To the coder/s who made the Techline application, just quit your job.. right now... you should not be working there.

They set single byte filters... for a protocol that requires 3 bytes to be sent.. this is so broken..

But... with enough patience... we have successful SPS reflash

SPS2Reflash_WithOBDX.PNG

[Tazzi]

Next dilemma. Its not mandatory for tools to do it, but using a VPW transceiver usually causes it to drop back in 1x mode when it detects too many invalid bits when in 4x mode.
As the OBDX Pro does not use a transceiver, it does not do this automatically, it has been up to the application to change the speed back to 1x.

The issue here is SPS tries to communicate to the ECU after the reflash. The ECU drops back to 1x mode after it reboots, but the OBDX remains in 4x mode since it has not been told to go to 1x.

Potential solutions here are:
1) Update OBDX firmware to try detect X number of invalid bits while in 4x mode, then auto switch to 1x
2) Try create a patch in the DLL to detect last frame.. and switch to 1x mode.

Option 2 is the fastest and easiest method, although this might not work for P series ecus (Would have to see all GM kernels). Option 1 is the preferred method, BUT... the OBDX Pro VT does not support canbus, and Techline SPS does not allow proceeding without having accepted CAN requests/commands/messages. Once its done the CAN setup/checks and receives no responses, it moves onto VPW and fires off commands to get responses.

Currently I am using the OBDX Pro GT, this has canbus thus accepts all the commands required.

Not too sure how to proceed, since now the OBDX Pro VT will work with J2534, but can't proceed in SPS since it has its own set checks to auto identify the vehicle (Enen when manually selecting vehicle).

[Tazzi]

Ok... its a hack.. but forcing it to always be in 1x seems to fix it all the problems.. so maybe... forcing 1x on VT is a solution.

*Edit
Yep, that works well enough that I am happy with it.
The DLL is going to need to do some simulating of responses to get past CANbus crap, but after that it seems to be pretty smooth sailing.
The VT will need to be kept at 1x, I have achieved this by searching for the value of 0xA1, which is the request to 4x high speed, and make it skip sending that message. This keeps the bus at 1x and still allowed to to complete flashing.

On newer scantools, will add some sort of 1x detection to auto switch so 4x can be maintained. But overall, this means VTs can keep J2534 compliance without any major mucking around
The filtering techline does is still a bit broken. I have it a 'little' jerry rigged, but I think its actually made it better.. since techline usually crashes if it receives frames it wasnt expecting, and the filtering they had setup results in unwanted frames on most J tools.

[kur4o]

Who cares for 20 years old protocol that is long time marked End Of Life.

For Can checks you can always do some emulations in the dll that will make techline happy.
About the 4x- to 1x switching, it is always a hardware feature. Not in priority now since you are dialing the dll, but should be done at some point.

[antus]

there is still lots of interest in the P01/P59 controllers and I think there will be for a long time yet. and I think soon pcmhammer will have P12 which will be a good doner for projects with fewer than 8 cyl.