OBDX Development - Developer Tools and Suggestions

[kur4o]

You can use a exe from mdi manager to monitor communication between tech2win and MDI or your device.

It is usually located at "C:\Program Files\GM MDI Software\J2534 Configuration\J2534ConfigApp.exe"

Set it up and start logging. It can give you and idea where it gives error and actual setting of protocols, filters and data logging.
The logs are very complete and you can pinpoint errors pretty fast.

[Tazzi]

You can use a exe from mdi manager to monitor communication between tech2win and MDI or your device.

It is usually located at "C:\Program Files\GM MDI Software\J2534 Configuration\J2534ConfigApp.exe"

Set it up and start logging. It can give you and idea where it gives error and actual setting of protocols, filters and data logging.
The logs are very complete and you can pinpoint errors pretty fast.

Thankyou for that! Thats probably reduced my reverse time by like 1/100th of the time!

Based on what I see here, it sets the mask/filter all to 00's, so it just lets everything through. It then watches the data and waits for the heartbeat, where it then sends its first ALDL frame.
Basically was on the right direction!

This is the code I was unsure how to deal with for sending a message

Code: Select all

On 04/06/2022 at 15:11:36.806, PDUStartComPrimitive O:24952 took 1974 us 
    hMod:                                         $00000001 (1) 
    hCLL:                                         $05000002 (83886082) 
    uiCoPType:                                    PDU_COPT_SENDRECV
    uiCoPDataSize:                                5 
    pCoPData:                                     0CCB0BD8 
    *pCoPData:                                    F1 57 01 00    B7 
    pCopCtrlData:                                 01A3F848 
    *pCopCtrlData:                                
      PDU_COP_CTRL_DATA
        Time:                                     $00000000 (0) 
        NumSendCycles:                            1 ($1) 
        NumReceiveCycles:                         0 ($0) 
        TempParamUpdate:                          0 
        TxFlag:                                   
          PDU_FLAG_DATA
            NumFlagBytes:                         4 
            pFlagData:                            No Flags Set
            pFlagData:                            01A3F8D8 
            *pFlagData:                           00 00 00 00    

        NumPossibleExpectedResponses:             1 
        pExpectedResponseArray:                   
            PDU_EXP_RESP_DATA
              ResponseType:                       0 
              AcceptanceId:                       0 
              NumMaskPatternBytes:                1 
              pMaskData:                          01A3F8DF 
              *pMaskData:                         00 
              pPatternData:                       01A3F8D1 
              *pPatternData:                      00 
              NumUniqueRespIds:                   0 
              pUniqueRespIds:                     NULL UNUM32s Pointer


    pCoPTag:                                      00F0A020 
    phCoP:                                        00F0A010 
    *phCoP:                                       $05100003 (84934659) 
    ReturnValue:                                  PDU_STATUS_NOERROR

[kur4o]

Some observations for ALDL and tech2win. It is not that god at all.

Usually all abs modules fail to communicate and some pcm for example 94 v6 pcm.
I still haven`t found what cause it to fail since bus communication seems complete. Maybe timings or some other lag time introduced by tech2win virtual com driver.

[Tazzi]

Some observations for ALDL and tech2win. It is not that god at all.

Usually all abs modules fail to communicate and some pcm for example 94 v6 pcm.
I still haven`t found what cause it to fail since bus communication seems complete. Maybe timings or some other lag time introduced by tech2win virtual com driver.

For our Holdens, when the ABS module fails, it holds the ALDL line to 0v so no communication happens.

Other modules in the car that fail can sometimes hold line at 9+v which is way outside of the range of ALDLs 5v range. Some scantools will disconnect from the protocol when detecting a short.

[Tazzi]

Quite amusing, going through the logs, theres a shit load of errors from the MDI DPU API, it sends off a tonne of event callbacks which result in multiple invalid calls for evet details from tech2win with invalid arguments. It works, just not the way it should haha.

I was almost onto it with my implementation, but just slightly off. The new DPDU document definitely is helping with better examples, which now match up with the MDIs parameters so they actually make sense now.

I have begun putting messages into a queue when received from the OBDX tool. Once they are put into the queue, it fires off a callback to tech2win indicating data is available. This should result in a GetEventDetails from tech2win so that the new received frame can be passed to it. Using the queue means data will be in order and released to tech2win in the correct order.

Something I need to manage correctly is clearing the pointers memory though, currently I have a list of intptrs for each custom pointer object which does not release resources. Simply because I have been using them for debugging and checking memory addresses. But when it does 100+ requests, its easy to see the memory size increase quickly.

[Tazzi]

Well.. it looks like it worked..

I simulated responses to tech2win.. it accepted my dummy event calls, which I then sent the BCM heart beat (08 55 A3), which tech2win then shot off the F1,57,01,00,B6 request to the BCM for live data.
So I would say thats success!!!!! Woohoo!!!

Now have to finish off the reading implementation. Since the serial processing needs to split config/system messages and network/bus messages into their own lists.
It appears the ALDL and VPW implementation in the OBDX tools are exactly how Tech2win are wanting to see the data, so Im very happy about that. Technically need 'more' filters for them both, but can get away using the filter/mask combination to allow all through and filter within software.

Overall, proof of concept is there and working. So damn happy with that!!!!!

[antus]

Congrats, that could have taken a lot longer, looks like you had some good wins there!

[Tazzi]

Congrats, that could have taken a lot longer, looks like you had some good wins there!

Yeah massive wins to be honest. The callbacks were my greatest worry.

I wouldnt say that what I have done is DPDU complaint, I would say its Tech2win compliant.
Same with J2534, its not full compliancy (yet), but its been explicitly designed around what SPS is requesting and expecting.

[Holden202T]

thats alright cause by the sounds of it everything thats happening in the SPS world at the moment is not very compliant

in all seriousness though, good work so far!

[Tazzi]

ALDL is what I first ever learnt about, so I am always drawn to working with it whenever the chance arrives. I guess its kinda nostalgic after messing with CAN bus for so damn long.
I have a prototype OBDX ALDL cable that supports passthrough mode (Normal ALDL cable) and also command structure by toggling a DTR pin to tell the CPU to switch into command mode. I have managed to use this cable with the DPDU API and successfully send/receive an ALDL frame with tech2win. So that has been the first successful usage that was using real communication to a bench bcm!!

Im certain I am missing a bunch of system status for indicating the tool is online/ready but it appears tech2win isnt actually caring if I do not send them.