Page 16 of 95
Re: OBDX Development - Developer Tools and Suggestions
Posted: Wed Apr 27, 2022 10:42 pm
by 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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu Apr 28, 2022 9:38 am
by Tazzi
kur4o wrote: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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Apr 29, 2022 12:53 pm
by 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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Apr 29, 2022 3:37 pm
by 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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Mon May 02, 2022 1:31 pm
by 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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Tue May 03, 2022 3:19 pm
by 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.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Wed May 04, 2022 2:51 am
by 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!
Re: OBDX Development - Developer Tools and Suggestions
Posted: Wed May 04, 2022 4:19 pm
by 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
Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu May 05, 2022 7:22 pm
by 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
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri May 06, 2022 6:54 am
by Cincinnatus
Impressive work Tazzi!