OBDX Development - Developer Tools and Suggestions

[Tazzi]

Just wanted to thank you tazzie and Pete for all your hard work.

I just purchased your latest new OBDX Pro GT device this morning and I'm looking forward to trying it out. When the GT arrives, I will download the OBDXplorer software and do some testing.

I also own two of your VT devices. Hope these purchases help!

David

Thanks David! The advancements are only possibly with the support of the community

Speaking of the GT, I have begun the Tech2win DPDU implementation, VPW is working straight off the bat since that has already been completed previously with the VT. Next is to get ALDL working correctly which so far appears to be fairly simple.
Tech2win does basically the following commands:
1) Set protocol to GM UART (ALDL)
2) Set filter and mask to 0 (Allow everything)
3) Open the protocol (connect to the actual ALDL bus)
4) Initiate read/write to the bus

Assuming there are no extremely weird sideballs when sending/receiving, ALDL should hopefully be implemented pretty quickly. (I know saying this... is just asking for more pain )

[Tazzi]

OBDX GT now working with VPW and ALDL with tech2win.

I noticed it actually loads quite a bit faster compared to the MDI so thats a win.

Next up is CANBus/GMLAN which I am honestly dreading. It has some pretty crazy methods of setting "acceptance IDs" to go with the filters. Its not yet very certain how it deals with setting the flow control IDs and things like that, so its going to be alot of analysing the MDI setup and breaking that down.
To add support for ALDL, all I had to do was add in the filter control and writing a network message. Tech2win actually sends the entire ALDL frame including length and checksum so had to turn on raw mode for the ALDL protocol which now works perfectly.

tech2aldlOBDX.PNG

[Tazzi]

I already hate tech2win with how its handling CANBs.

So.. start with PDUCreateComLogicalLink, this is where it sets the protocol (canbus) and also the pins its going to use. And some fucking backwards world, they using pin 3 and 11 which is what is used with MSCAN for Fords... we are expecting to see 6 and 14 for normal CAN for our Holdens.
It does those a good dozen times... before it attempts pin 6/14 which is just absolutely stupid.

It also manually sets the baud rate.. but I dont understand the math behind it yet.

From here we set a pass filter with an ID of 0, and a mask of FF FF F8 00.
This is kinda backwards to how I would normally deal with it, since we are only caring about 11bit frames, this would technically allow any frames from 0 to 7FF, blocking anything higher. Setting a mask like that will cause the GT to freak out since 11bit and 29bit filters are separated. That mask is the equivalent of a mask of 00 for 11bit... gonna have to do a bit of filter trickery to accommodate for that setup.

We then move onto: PDUSetUniqueRespIdTable, this appears to be where individual filters are set to search for specific IDs, and set the flow control responses ect (I think?).
I can see it does this:

Code: Select all

 PDU_PARAM_ITEM
                    ItemType:                     PDU_IT_PARAM
                    ComParamId:                   CP_CanRespUUDTId
                    ComParamDataType:             $00000105 (261) 
                    ComParamClass:                6 
                    pComParamData:                01A1E288 
                    *pComParamData:               1348 ($544) 

Where 544 appears to be the filter ID we would want to look for.
Now here comes the real kicker. All the filtering is going to have to be done in the DPDU DLL since it sets more then 32 filters, and thats the max that the OBDX GT supports in its firmware
When loading up a VZ V6 ECU, it does 64 filters....

Gonna have to keep going through it and deciphering.. since I dont think this is even the correct point where it opens the canbus connection and begins comes, this is like some precheck on the scantool I believe. Since the filter for the expected 7E8 for the ECU doesnt occur till WAY down the log, and all this stuff is in the top section. But since I know from previous work, if you do not satisfy every last step of Tech2win, it will have a full mental breakdown and not work correctly.

[Gatecrasher]

That's pretty crazy. Is it setting up a list of all possible filters, and then just picking the one to use based off an index into that list?

[Tazzi]

That's pretty crazy. Is it setting up a list of all possible filters, and then just picking the one to use based off an index into that list?

Just spent the last hour going through the log.. and I hate the tech2win devs, or whoever came up with this ridiculous setup.

In short we get the following occur:
1) Set global filter/masks.... delete these filters.. and repeat multiple times (for no reason)
2) Set a global Block filter to block everything (repeated multiple times and cancelled... for no reason)
3) Set our actual wanted filter (7E8)... cancel and repeat a dozen+ times.

After we get to step three... it repeats the whole process again multiple times. Basically.. filters are set and cleared around 50+ times. I have no fucking idea why.

Tech2win then sends its first few TXD messages of: 101 FE 01 3E.
This is a tester present message, so we should not expect to see a response from it, it sends this 3 times, and then moves to sending its first message to the ECU of 7E0 20, which is basically just a "are you there" message".

And this is as far as it gets due to not having any engine computer attached.

This genuinely has taken me well over an hour and a half to just go through this log that took about 25seconds to create

Like I said... I already hate how canbus has been implemented.

[Tazzi]

I *think* I have it worked out...

So it sets a global filter (Whatever that may be) using PDU_IOCTL_START_MSG_FILTER.

We then start our receive buffer using PDUStartComPrimitive ->PDU_COPT_SENDRECV which then narrows down the global filter further using pExpectedResponseArray which defines an ID,Mask and acceptable ID so that each receive message can be linked to a specific accepted filter.

Ontop of this, we then have our CAN settings which get set using PDUSetUniqueRespIdTable. This is basically setting up what the ID's should be for automatic responses (I think) and things like that. The main one we care about is CP_CanPhysReqId which is where our 0x7E0 ID is being set... which would be the flow control response we would want to use, and then assigns it to a recieved frame ID with CP_CanRespUSDTId which is set to 7E8 (Expected response from ecu).

Implementing this is not exactly simple. Since it does it in this exact order:
1) Set the flow settings first
2) Start our receive buffer with desired sub filters (filter global filters)
3) Set global filter
4) Send can message

The issue here is for me to set the FLOW settings, I need to know what our sub filters are since its all done together to set what type of filter it is (pass, block or flow).
I think the best I can do is basically just set the global filter as an actual hardware filter of the scantool. Then use the DLL as a software filter to then further refine with the 'sub filters'. When the sub filters are changed, they can check if any of the set flow settings match the CP_CanRespUSDTId, and if a flow response is required, it can manually send it off.

This is the best I can come up with currently. Not going to lie, my head hurts from keeping ontop DPDUs stupid method of handling all this. I know this is meant to be a progression on J2534... but its so backwards, that I feel sorry for anyone thats actually had to work with it.

*Edit
Well.. I can rig it to work by forcing some filters... but Im still hung up trying to make a nice method to apply the flow filters. Its a real headache to do the global and sub filters after the flow, its really backwards.

[Tazzi]

Progress!

So.. looking at the last protocol open option has helped narrow this down quite a bit.

After opening the protocol (PDUCreateComLogicalLink) and setting to ISO_11898_2_DWCAN, this technically auto defaults to 500kpbs which is what we want.

It then moves to setting protocol specific settings including can filler byte handling (CP_CanFillerByteHandling) , termination type (CP_TerminationType), baud rate (CP_Baudrate), sample rate (CP_BitSamplePoint), samples per bit (CP_SamplesPerBit), sync width (CP_SyncJumpWidth) and Time between can frames (CP_P3Phys).

We then clear all filters (PDUIoCtl ->PDU_IOCTL_CLEAR_MSG_FILTER ), then open a pass filter (PDUIoCtl -> PDU_IOCTL_START_MSG_FILTER) with ID 5E8 and mask of DFF (binary 1101 1111 1111). Mask of DFF means it will allow 5E8 and also 7E8 to pass through.

Our next main step is setting up our flow controls using PDUSetUniqueRespIdTable. Each entry will set the following important parameters:
1) CP_CanPhysReqId (7E0) - Id we will send back with for flow control
2) CP_CanRespUSDTId (7E8) - Id we are looking for.
3) CP_CanRespUSDTFormat - Indicates if we are going to use flow control, and if 11bit or 29bit (default value being 5 which is 11bit with FC.)

There are two sub filters set here, the first is our expected 7E0, 7E8 which is set to enable flow control (5) at 11bit.
The next is set for 5E8 (CP_CanRespUUDTId) and its CP_CanRespUSDTFormat is set to 0 which means no flow control at 11bit. The 5E8 is whats used for live data monitoring on the engine computers so this makes sense.


Its odd that all previous occurrences of setting the protocol/filters is in a messed up order, whereas when it gets to the ACTUAL used programming, its all in order and makes sense.
Once the sub filters are received, I may wipe the 'global' and then set the sub filters directly as this will work.

As for dealing with all the rubbish before this, I believe if it receives more then 32filters, I will just get the DLL to overwrite the last filter since theres no way tech2win will use more then a few IDs at any time. Once it does all those filter cycles and protocol changes, we should finally get to our last protocol set where it all makes sense and should work perfectly.

[Tazzi]

Well.. Im not sure how I got this working before.. I must have actually tricked tech2win and got it to go through.. but Iv found a problem now with everything being implemented correctly.

This is beyond fucking stupid... I knew CANbus was going to be an absolute nightmare with DPDU.

Tech2win is basically running 4 instances of canbus at the same time.
Two are running on pins 3/11 and another two on 6/14.

Every single one uses the same 'global' filters, but then each individual instance has its own sub filters. Ontop of that, each individual instance then has its own settings, read/write buffers and notification systems.

It appears I can try 'reject' the 3/11 pin combinations, but there are two instances of the normal CAN (6/14) that are run that I have to account for. If I try reject the second instance of the normal CAN, tech2win will completely crash.

Next step is to create a separate class and throw all DPDU CANbus related variables into that so that a list of CANBus instances can be created. This way I can keep up with each instance, and fire off any required notifications correctly as tech2win is specifically requesting each instance to enable the communication and other settings.

This is why we get multiple filters being set during setup, since its placing them on different CAN instance. Im pretty stubborn with letting things go... but honestly.. question whether this is worth the effort.

[kur4o]

By instances do you mean different channels being opened at the same time for the same pins.

I doubt this exist on the actual t2->candi firmware and is implemented on tech2win level or it is indeed the candi emulation that is some weird as hell.

I am sure you can handle the channels id settings on hardware level if you have enough ram, and treat them as level1, since the level0{hardware ] will be the same.

[Tazzi]

The MDI does have multiple CAN channels, but the DPDU basically creates software based CAN channels which further refine the received messages.

It appears it’s designed that your suppose to basically just allow all frames through on a hardware level from the scantool, then apply all the filtering from each software can channel to work out which received frame goes to which channel.