OBDX Development - Developer Tools and Suggestions

[ironduke]

Stumbled upon some big library of iso documents. Hope it helps someone.

link attached

Damn... That's a lotta files... THANKS!!!!!!

Has anyone found any automotive documents in this? I gave up... lol .. good pile of them though..

[Tazzi]

Damn that is alot of docos!! I imagine that should cover most things I will ever look at!

While working with DPDU, I have got it to the point that tech2win does display the OBDX in its tool selection box, but thats it for now. Not a fan of how DPDU runs, but... clearly someone though it should be done.

I have to have all the commands in place to then monitor what Tech2win calls to.. and make sure thats working before moving to the next one. The 1 by 1 approach seems to be more effective then trying to add everything at once, then having little mistakes that make it hard to know where it went wrong. Biggest problem is memory management, have to ensure the size of the variable is correct, and the SAE documents are very vague on describing what a long/int are in terms of size (32 bit or 64 ect).

Itll certainly be cool to see tech2win pulling up live data with it once its done though. I believe the OBDX VT is the cheapest tool on the planet to work with VPW on J2534 also now... soon to be DPDU!

[antus]

thats great well done. and good luck with the D-PDU! Agree 1 by 1 and getting it right is easier than many then chase the bugs. Chasing bugs is mind destroying and slooooow.

[Tazzi]

Thats how I felt with J2534, It worked with PCMHammer straight up, but that uses actual logic and sense. Whereas engineers of Techline do not.
I believe next requests are for more hardware details (Opening the port to the tool), then it waits till correct vehicle is selected to open the protocol/set filters ect. Fingers crossed theres not a shit storm of other settings made inbetween.

[ironduke]

They must have been reading your posts, jk..
Techline connect just pushed thru a big update last night.. Big gui change, not sure what changed behind the scenes, haven't tried connecting to a scan tool yet..

[Tazzi]

They must have been reading your posts, jk..
Techline connect just pushed thru a big update last night.. Big gui change, not sure what changed behind the scenes, haven't tried connecting to a scan tool yet..

I will load up techline tomorrow and check it out. Interested to see if they have fixed anything in the backend with their j2534 on VPW if it’s been causing people that much drama.

[Tazzi]

have managed to go backwards with DPDU support somehow. I believe I actually had my initial connection screwed up, but tech2win just kinda ignored and proceeded forward.

After reimplementing everything correct, tech2win hangs up when it goes to show the initial tool selection/connection screen.. then crashes.

Its failing when it goes into the function:

Code: Select all

PDUGetModuleIds(PDU_MODULE_ITEM **pModuleIdList)

The description of the parameter 'pModuleIdList' is:

Code: Select all

Pointer for storing the pointer to Module Type Ids and the Module handles for all
modules that are connected to the D-PDU API. The data structure is described in
11.1.4.6. 

The PDU_MODULE_ITEM structure setup is as follows:

Code: Select all

typedef struct {
T_PDU_IT ItemType; /* value= PDU_IT_MODULE_ID */
UNUM32 NumEntries; /* number of entries written to the pModuleData array */
PDU_MODULE_DATA *pModuleData; /* pointer to array containing module types and module handles */
}

Now breaking this down... its a pointer... thats stores the pointer of the type PDU_MODULE_ITEM.

So things kinda like doing:

PDU_MODULE_ITEM MyCustomItem;
int* PointerForItem = MyCustomItem;
int* PointerforPointer = PointerForItem;

Or something really stupid like that... I think??

When I dump the pointer memory, that is passed into the function, this is what I see:

Code: Select all

C8 , AD , DD , 0A , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00 , 00

I actually tried dumping hundreds of bytes, and it is all 00's after the first 4 bytes. So... this would make me believe the first 4 bytes MUST be a pointer.. that then points to another pointer. (What a head fuck).
When I try read from the address it provides, it errors out. I have tried MSB and LSB formats (0xC8ADDD0A) and (0x0ADDADC8) but neither want to work nicely.

[Tazzi]

Dear old Murphies Law strikes again.

Just as I clicked submit... tech2win decides to display this...

Typical_JustAfterMessaging.PNG (8.57 KiB) Viewed 5217 times

The connection command above is using a pointer that then 'points' to another pointer.

What really screwed me over, was the internal pointer was just a random number, tech2win did not actually allocate any valid space to the value it entered as the internal pointer which was resulting in crashing the application when I tried to write the scantool data to it.

To resolve, I have made a brand new pointer which the required scantool data saved to the memory location, and then update the internal pointer address to the new address.
Absolutely stupid way of doing things.. but.. we are 3 commands down of a potential 29.

*Edit
To top it off, tech2win actually runs a cycle of:
PDUConstruct
PDUGetModuleIds
PDUDestroyItem
PDUDestruct

It does these multiple times.... receiving the same information each time regardless.. and then finally does a PDUModuleConnect which is the official request to connect to the scantool (actually open comport ect).

So.. if thats any insight on the kind of programming tech2win uses.. then this is going to be quite a shitstorm.

The cherry on it all, is GM UART (ALDL) does not appear to be defined in the D-PDU datasheet I have (From 2009). Previews of the 2017 don't seem to give much details either, so Id rather not waste $300usd on a document which isnt going to provide any useful details!

[antus]

that doesnt actually sound too bad. sending you an point that not initialised is probably ok, though it'd be better hygine to make it null if its junk. and the sequence of 4 PDU calls is probably OK too, becuase its probably buried and library they just want to call from the top level, and it does those things to do what it does without storing the data. it should be cheap to call and run, so while it is a little wasteful it might be better then over complicating tech2win on the inside. Having said that, I wouldnt be that its programmed well, either

[Tazzi]

Wasteful is a perfect explanation of it.
But the explanation of how the function works just was not written to well. At least the example shows it as passing the variable type PDU_MODULE_ITEM, but instead is a pointer to a pointer that then maps to that variable type.

Im sure theres going to be more stupidity.. I can feel it!