OBDX Development - Developer Tools and Suggestions

[kur4o]

You may already know that.

Code: Select all

    ChannelID:                                    9 
    pMsg [Write]:                                 4DBFE2B8 
    pMsg [Write]:                                 
      PASSTHRU_MSG (1 of 1)
        ProtocolID:                               ISO15765
        RxStatus:                                 No Flags Set
        RxStatus:                                 0 
        TxFlags:                                  ISO15765_FRAME_PAD
        TxFlags:                                  64 ($40) 
        Timestamp:                                $00000000 (0) 
        DataSize:                                 6 
        ExtraDataIndex:                           6 
        Data [Write]:                             00 00 07 E0    12 01 

    pNumMsgs:                                     4DBFF2F4 
    pNumMsgs [IN]:                                1 ($1) 
    pNumMsgs [OUT]:                               1 ($1) 
    Timeout:                                      0 
    Return Value:                                 STATUS_NOERROR              Function call successful

When a TxFlags: ISO15765_FRAME_PAD is set.

The tool handles the multiframe response and compiles the result to a single message fed to PC. It can be used on sending and receiving data.
Offloading pc to tool communication to some big chunks of data.

[Tazzi]

The tool handles the multiframe response and compiles the result to a single message fed to PC. It can be used on sending and receiving data.
Offloading pc to tool communication to some big chunks of data.

Yep, thats how I have the OBDX handling the responses now with auto formatting on. It automatically reads/writes the data into chunks.
The only difference is I have the length byte still in my command set, since it is nice to validate the length received against 'padded' frames.

So Adding the read and writing is not actually too bad. Its more adding in the "TX Indication" and "RX Start Message" notifications.
Adding these two requires adding an event queue, similar to that of DPDU, so that the queue is always in order, and will pass on all queued messages together when requested.

Something that I know the MDI is doing incorrectly, is its return status message when it does not find the correct number of frames as per the J2534.
Here is an example of an empty PassThruReadMsgs request:

Code: Select all

  ChannelID:                                    5 
    pMsg [Read]:                                  34C3D80C 
No Message List.
    pNumMsgs [IN]:                                300 ($12c) 
    pNumMsgs [OUT]:                               0 ($0) 
    Timeout:                                      0 
    Return Value:                                 ERR_BUFFER_EMPTY 

This is correct, there were 0 messages to pass back out. Do note that GDS2 requested to read up to 300 messages.

Now.. here is an example of it reading 1 response:

Code: Select all

 ChannelID:                                    5 
    pMsg [Read]:                                  34C3D80C 
    pMsg [Read]:                                  
      PASSTHRU_MSG (1 of 1)
        ProtocolID:                               ISO15765
        RxStatus:                                 TX_MSG_TYPE|TX_INDICATION
        RxStatus:                                 9 
        TxFlags:                                  No Flags Set
        TxFlags:                                  0 
        Timestamp:                                $1D819995 (495032725) 
        DataSize:                                 4 
        ExtraDataIndex:                           0 
        Data [Read]:                              00 00 07 E0    

    pNumMsgs [IN]:                                300 ($12c) 
    pNumMsgs [OUT]:                               1 ($1) 
    Timeout:                                      0 
    Return Value:                                 STATUS_NOERROR 

This is a message indicating TX was successful, but what we care about here is the pNumMsgs at the bottom. GDS2 wanted 300 messages, but only received 1. This is SUPPOSE to trigger a "TIMEOUT" error, since the read routine did not find the desired amount of messages (300). The MDI has been purposely and incorrectly forced to put STATUS_NOERROR otherwise GDS2 never sees any responses as it always requests 300.

Its just a perfect example of how a SAE document can be bluntly ignored.

[Tazzi]

Some of our first frames processed by GDS2 on J2534 are calling to the engine computer to request freeze data (mode 12).
It took me a moment to recognise it, since its been quite some time since looking, but exmaple request is:

00 00 07 E0 12 01

which responds with
00 00 07 E8 52 01 00 00 02 23 00 01 04 63 00 02 04 52 00 03 00 10 00 04 04 43 00 05 04 49 00

From here, I believe gds2 then requests individual information about the freeze data faults saved using:
00 00 07 E0 12 02 00 02 23 00

And response is:
00 00 07 E8 52 02 00 02 23 00 00 02 02 23 12 35

Code: Select all

                                                  00 00 12 36    00 00 12 37    00 12 38 00    12 39 00 00    
                                                  03 00 00 00    04 00 00 05    00 00 06 80    00 07 80 00    
                                                  08 80 00 09    80 00 0A 85    00 0B 0F 00    0C 00 00 00    
                                                  0D 00 00 0E    94 00 0F 00    00 10 00 00    00 11 FE 00    
                                                  12 04 00 14    5A 80 00 15    5A FF 00 18    5A 80 00 19    
                                                  5A FF 00 1E    00 00 1F 00    00 00 2C 00    00 2D 80 00    
                                                  2E 00 00 2F    00 00 30 00    00 31 00 00    00 32 F6 EE    
                                                  00 33 56 00    3C 01 90 00    3D 01 90 00    42 30 ED 00    
                                                  43 00 00 00    44 1F A0 00    45 DE 00 46    28 00 47 FF    
                                                  00 49 01 00    4A 02 00 4C    01 00 52 00    11 23 20 11    
                                                  24 4C 11 25    02 11 27 02    11 28 0C 11    29 00 11 30    
                                                  20 11 31 04    11 35 00 11    52 00 11 6F    3C 11 78 FF    
                                                  11 90 0E 11    C9 BB 12 97    00 ED 12 B0    00 12 B1 05    
                                                  8D 12 C3 00    00 12 C4 00    00 12 D9 00    13 1E 00 23    
                                                  13 1F 00 00    13 2A 00 00    13 65 01 13    66 01 13 67    
                                                  15 13 B5 FF    FF 13 EA 00    14 20 00 00    14 21 00 00    
                                                  14 6A 01 14    6B 01 14 6C    01 14 6D 01    14 70 00 14    
                                                  78 E8 14 79    E8 14 8D 7D    15 0C 00 15    39 00 15 3A    
                                                  00 15 3B 00    15 3C 00 15    3E 00 15 59    00 15 5A C0    
                                                  15 7A 00 00    16 8D 00 16    8E 00 16 8F    00 16 90 00    
                                                  16 91 00 16    92 00 16 93    00 16 94 00    19 40 28 19    
                                                  42 00 00 19    5D 10 00 1A    2D FE 77 20    02 00 20 05    
                                                  00 20 06 28    20 09 00 20    0B 00 20 0E    00 00 20 0F    
                                                  00 00 20 1F    00 20 27 00    20 29 00 20    50 00 00 28    
                                                  10 00 28 22    00 11 4D 00    11 58 00 11    75 00 11 9C    
                                                  00 12 B9 FE    12 BA 01 12    BC 01 12 BD    01 12 DA 00    
                                                  00 13 36 00    00 13 37 F1    57 13 B1 1F    13 B2 1F 13    
                                                  C6 00 13 C8    00 20 00 20    20 03 00 20    07 00 20 0C    
                                                  3F 20 0D 3F    20 28 00

We can see at the top data after the highlighted red item that we have 00 02 02 23 12 35 00 00,
00 02 = freeze DTC which is 2bytes long of value 0223 (our fault code), then next is 1235=mileage since last fail which has corresponding data of 0000 ect ect.

That is 471 bytes of data there (including header), so its quite alot of data to process. This block of data would have the fault code, and each individual PID and its corresponding saved value in there.
471bytes is quite alot of data.. its about 58 lines of CAN transmitted. The OBDX pro should auto format the received chunk of data and pass through similar to that of the MDI.

[Tazzi]

Eh... have to do quite a big remodel of the OBDX GT CAN firmware to accept doing:
1) Pass filter only
2) Flow filter
3) Block filter

Currently we are setup with pass filters (Pattern and Mask), and 1 flow filter.
J2534 wants to have a flow filter for every Pattern+Mask combination.

Block filters are nice and simple. Its the last process to run which will block any frame even if its in a pass/flow list.

Have just spent the last 8hours today trying to optimise the coding in the GT to salvage a few thousand more bytes of space so that ALDL,CAN and VPW can have some filtering updates applied.

*Edit
29bit can is being a headache. The processor is only capable of 8 hardware filters for 29bit frames.
So.. next best thing is to set a software filter in the processor. I am implementing a custom function that allows switching between hardware and software filter. This then allows us to open up the 29bit filter to have 28+ 29bit filters.
Technically DPDU wants to have 64 filters... I have yet to see anything use more then around 16.

[Tazzi]

Filtering implemented, and.. we have proper compliance now with J2534 to support a heap of filters on 11bit and 29bit.

I do have it working with communication to an E38 ECU I have on the bench using GDS2
There is a mistake in my 'large block' coding which is 1 byte out that I need to suss out first, but appears this should be enough to keep GDS2 happy.

Once I fix the large block section, it should be ready to do a full SPS update flash. From here, we should be able to then test GMLAN out to add support for that specific protocol (HV wakeup ect).

I realise theres quite a few following the CAN support for this.. we are almost there.

[Tazzi]

Now, I just remembered that DPDU has an absolutely stupid filtering requirement.. of 64 filters per protocol.

Since that requires being all software based, that will use a good couple thousand bytes in RAM to cover ALDL,VPW and CANBus.
I honestly cannot foresee any application using all 64filters... ever... at least no dealership tool. So possibly nudging that down to.. say.. 32.. might be best.

Couple questions I have been asked is if the GT will support MSCAN, Kline, Keyword2000 and SCI.
None of the above protocols will be supported this is for two reasons:
1) Adding both DVI and ELM command sets for each protocol takes up HUGE amount of programming space. Roughly we use around 40k per protocol, and currently theres only around 10k left in space.
2) We are running out of space. Pete has done everything he can with the current design, and we do not have the space to fit another relay (for mscan) or other required parts for the other protocols.

Our next revision after the GT is going to be a custom case. This allows us to optimize the current design and allocate that little bit extra room to get those last few protocols on the board.

[Tazzi]

Another 6hours of painful filter reconstruction.. and CANbus is now setup to accept 32 filters with unique pattern, mask, flow and filter type. With each now being able to be individually edited/modified.
Previous implementation was working, but still was not ideal for what J2534 was requiring.

Im sure I could have had a working DLL for the GT by now if I skipped the above.. but I would rather just have it done right the first time so its never a problem in the future.

With that said, its 12:51AM... time to call it a night!

[Tazzi]

And there we have it.. OBDX GT is now working nicely in GDS2
This is with all the filtering working the way it should. I was playing around with the voltage dial on my bench setup and can see it moving on screen which appears to update the same timing as the MDI.. so Im pretty happy with that.

Next up... flashing

[Tazzi]

After a massive overhaul on how serial is now being processed (moved to a background thread), we now have GMLAN also working
Connected module was a Holden VF Mylink

And for those waiting to hear about it... yes.. I have successfully flashed using J2534 as well. I programmed a VF BCM and VF Mylink using my own software successfully. Next up is using techline SPS

[Cincinnatus]

Impressive work Tazzi!