OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Post Reply
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

pointer to a pointer is fine, thats the spec **pModuleIdList thats why two *

Internally it probably means the first pointer is to some kind of data structure, which has a pointer to a pModuleIdList, which in this case is not initialized to null, so its just junk until you allocate and populate pModuleIdList and pass back the pointer to your data structure for it to store.
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
Tazzi
Posts: 3422
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 »

Yeah, after dealing j2534, its just not as straight forward. I'll need to make sure I pay attention to the double * as I know iv seen that a few times in the document.

The biggest unknown in all of this is dealing with call backs, as it allows registering them which will be in interesting conversion for c++ to unmanaged c#. It should be fine, it's just not something I have dealt with heaps.
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: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Damn, getting stuck on this callback stuff. I have either implemented it incorrectly or Im not doing the required actions it wants me to... to be honest... its probably both.

Since I am coding in C# and not C++.. theres a few differences in how some things are addressed, this includes callbacks. Callbacks are effectively just pointers to a specific function, I believe I have set this up correctly, but it appears the app is trying to use the callback and it crashes the whole dll. There is no log to follow since I believe the callback it attempts to use might have an invalid variable input.. which is resulting in it just instantly crashing.

I just found this snippit of coding showing how to use them between C# and C++.
https://www.codeproject.com/Tips/318140 ... -Cplusplus
I might need to play with that example application so I can debug it, and follow what its doing exactly.

The callback is something that the application code (tech2win) can execute at any time, so I do need to have it implemented properly. Technically tech2win could just call to one of the standardised functions.. but I guess they wanted to get fancy and use callbacks instead.

I *think* once the callback issue is fixed.. its next step will be to allow selecting the vehicle/module from tech2win screen... it should then set protocol/filters and finally start communication... I hope haha.
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: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Actually had someone call me up about this just now, figured Id update those here if thinking the same.

The comment/question was:
"Why not just use a debugger to attach to the process for the DLL? This is how DLLs are usually debugged".

And.. that is correct! But unfortunately when we try to attach to tech2win, it crashes the application when it tries to use the DLL. This could be due to a inbuilt software protection to prevent debuggers, or could be due to VS having issues dealing with the unmanaged functions in C#.
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

try printf debugging.. get your functions that are callbacks to do a debug printf to record that they were called, and another one for each argument, and another one for when the function ended. then you can monitor the debug output with debugview without a full debugger and you can see if the function is called, and if your getting what you expect passed to it.
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
Tazzi
Posts: 3422
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 »

antus wrote:try printf debugging.. get your functions that are callbacks to do a debug printf to record that they were called, and another one for each argument, and another one for when the function ended. then you can monitor the debug output with debugview without a full debugger and you can see if the function is called, and if your getting what you expect passed to it.
Thats basically what Im doing to a simple txt document.

I believe the issue is it faults as it enters the function due to a mismatched input variable.
Here is the main event callback function header:

Code: Select all

void EventCallback(T_PDU_EVT_DATA eventType, UNUM32 hMod, UNUM32 hCLL, void *pCllTag, void
*pAPITag) 
I believe one of these 5 items is not playing nicely with what I have put.. and the whole DLL is hard faulting when it tires to use the event callback, the first instruction inside of the eventcallback is to print "I made it here!", but its not even getting there.

Its either failing when it tried to execute the event callback, or my setup for the event callback is broken... just not sure which one it is yet!
Might try fire off the event callback from my own routine after its setup.. and see if it runs.
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

those voids dont add any clarity. A pointer... to something. cant tell you if its a byte, and int, a string... is it data sizes maybe with UNUM32? what sizes are you treating them as? Maybe you can use the sizeof() macro to just make sure your data sizes line up to what you think they should be. But really I think you do need a debugger. ida?
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
Tazzi
Posts: 3422
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 »

antus wrote:those voids dont add any clarity. A pointer... to something. cant tell you if its a byte, and int, a string... is it data sizes maybe with UNUM32? what sizes are you treating them as? Maybe you can use the sizeof() macro to just make sure your data sizes line up to what you think they should be. But really I think you do need a debugger. ida?
All fantastic questions.. which are all unknowns. :lol:
The T_PDU_EVT_DATA is a uint32, and Im treating the pCllTag and pAPITag as generic intptrs, which I was hoping was enough, but its not making it in to the function yet.

But I think I will need to debug using something like IDA and follow its progress in the DLL.. might get a better understand of what the hell is happening.
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

Thinking about how a void would make sense I think its some kind of identifier in your app. So you have a structure of your own type which is how your tracking your interface instance and you hand that back to t2w. It doesnt need to know how your doing it, it says "this one" and hands you back your own pointer. Pointer to an int, a string, a struct all make sense in that context. You could also take a look at the api other J2534 vendors are exposing from their DLLs.
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
Tazzi
Posts: 3422
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 »

antus wrote:Thinking about how a void would make sense I think its some kind of identifier in your app. So you have a structure of your own type which is how your tracking your interface instance and you hand that back to t2w. It doesnt need to know how your doing it, it says "this one" and hands you back your own pointer. Pointer to an int, a string, a struct all make sense in that context. You could also take a look at the api other J2534 vendors are exposing from their DLLs.
J2534 is nice and simple with the pointers, thats very logical.
I managed to get it through the event callback setup.
I fucked up the actual delegate setup for the event callback. I had an incorrect declared parameter in the delegate thus the call to the actual eventregister was causing a full crash.

For those following at home, the event callback is basically a way for the Application (tech2win) to pass a reference of a 'function' to the DPDU dll to use. The DPDU is then suppose to use that 'function' as a way to notify the application (tech2win) of thing such as new data or errors ect.

So.. I am now able to save the events... I have yet to actually try invoke them, as I don't even know when or where they are used.
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