BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

[projix]

When using ISO15765 extended addressing and the channel configured for it, the PeaK library does not set the 0x80 flag on reception.

J2534 call trace via shim about how the channel is set up and the exchange:

Code: Select all

0.000s ++ PTOpen(*NULL*, 0x070AE760)
  returning DeviceID: 81
  3.067s 0:STATUS_NOERROR
3.067s ** PTReadVersion(81, 0x18F45F30, 0x18F45F88, 0x18F460E8)
  Firmware: 4.5.3.505
  DLL:      2.0.6.91
  API:      04.04
  3.068s 0:STATUS_NOERROR
3.068s ++ PTConnect(81, 6:ISO15765, 0x00000000, 500000, 0x18F54348)
  returning ChannelID: 1358954502
  3.166s 0:STATUS_NOERROR
3.166s ** PTIoctl(1358954502, 10:CLEAR_MSG_FILTERS, 0x00000000, 0x00000000)
  3.166s 0:STATUS_NOERROR
3.166s ** PTIoctl(1358954502, 9:CLEAR_PERIODIC_MSGS, 0x00000000, 0x00000000)
  3.166s 0:STATUS_NOERROR
3.166s ** PTIoctl(1358954502, 7:CLEAR_TX_BUFFER, 0x00000000, 0x00000000)
  3.166s 0:STATUS_NOERROR
3.166s ** PTIoctl(1358954502, 8:CLEAR_RX_BUFFER, 0x00000000, 0x00000000)
  3.166s 0:STATUS_NOERROR
3.166s ++ PTStartMsgFilter(1358954502, 3:FLOW_CONTROL_FILTER, 0x0F3FD618, 0x0F3FA300, 0x0F402B40, 0x18F542D8)
  Mask[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ ff ff ff ff ff
  Pattern[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 12 f1
  FlowControl[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12
  returning FilterID: 421575160
  3.166s 0:STATUS_NOERROR
3.166s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1)
  read 0 of 100 messages
  3.168s 9:ERR_TIMEOUT
3.168s >> PTWriteMsgs(1358954502, 0x0A30C024, 0x0A30C020, 100)
  Msg[ 0] 6:ISO15765. 7 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12 3e 01
  sent 1 of 1 messages
  3.168s 0:STATUS_NOERROR
3.168s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1458.339606s. 6:ISO15765. Actual data 5 of 5 bytes. RxS=0x00000009
  RxStatus: 0:TX_MSG_TYPE 3:TX_INDICATION
  \__ 00 00 06 f1 12
  3.168s 0:STATUS_NOERROR
3.168s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1458.437944s. 6:ISO15765. Actual data 6 of 6 bytes. RxS=0x00000000
  \__ 00 00 06 12 f1 7e
  3.267s 0:STATUS_NOERROR
3.267s >> PTWriteMsgs(1358954502, 0x0A30C024, 0x0A30C020, 100)
  Msg[ 0] 6:ISO15765. 7 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12 1a 80
  sent 1 of 1 messages
  3.267s 0:STATUS_NOERROR
3.267s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1458.438780s. 6:ISO15765. Actual data 5 of 5 bytes. RxS=0x00000009
  RxStatus: 0:TX_MSG_TYPE 3:TX_INDICATION
  \__ 00 00 06 f1 12
  3.267s 0:STATUS_NOERROR
3.267s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1458.467896s. 6:ISO15765. Actual data 65 of 65 bytes. RxS=0x00000002
  RxStatus: 1:START_OF_MESSAGE
  \__ 00 00 06 12 f1 5a 80 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  3.296s 0:STATUS_NOERROR
3.296s << PTReadMsgs(1358954502, 0x0A30C024, 0x0A30C020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1458.487479s. 6:ISO15765. Actual data 65 of 65 bytes. RxS=0x00000000
  \__ 00 00 06 12 f1 5a 80 00 00 08 51 70 16 00 02 00 10 58 59 20 11 07 13 08 08 02 30 41 4c 4a 03 03 01 00 00 00 00 00 04 73 12 77 30 10 36 36 30 30 38 39 5a 4d 30 30 30 38 39 5a 4d 30 41 41 4c 4a 43
  3.316s 0:STATUS_NOERROR
3.316s -- PTDisconnect(1358954502)
  3.408s 0:STATUS_NOERROR
3.408s -- PTClose(81)
  3.410s 0:STATUS_NOERROR

Also after the first time this problem happens I have to unplug the device and plug it back in again, otherwise it stops working, there is no reply anymore at all. I don't know if it is somehow related.

Here is an example J2534 log from a different device for the same exchange, note how 0x80 is set every time in RX Flags:

Code: Select all

0.000s ++ PTOpen(*NULL*, 0x08BE22F8)
  returning DeviceID: 1
  6.366s 0:STATUS_NOERROR
6.367s ** PTReadVersion(1, 0x0FEB83F0, 0x0FEB8708, 0x0FEB8760)
  Firmware: 1.16.4769
  DLL:      1.02.4798 Jun 13 2016 17:16:24
  API:      04.04
  6.367s 0:STATUS_NOERROR
6.367s ++ PTConnect(1, 6:ISO15765, 0x00000000, 500000, 0x0FECD4D0)
  returning ChannelID: 3
  6.368s 0:STATUS_NOERROR
6.369s ** PTIoctl(3, 10:CLEAR_MSG_FILTERS, 0x00000000, 0x00000000)
  6.369s 0:STATUS_NOERROR
6.369s ** PTIoctl(3, 9:CLEAR_PERIODIC_MSGS, 0x00000000, 0x00000000)
  6.370s 0:STATUS_NOERROR
6.370s ** PTIoctl(3, 7:CLEAR_TX_BUFFER, 0x00000000, 0x00000000)
  6.370s 0:STATUS_NOERROR
6.370s ** PTIoctl(3, 8:CLEAR_RX_BUFFER, 0x00000000, 0x00000000)
  6.370s 0:STATUS_NOERROR
6.371s ++ PTStartMsgFilter(3, 3:FLOW_CONTROL_FILTER, 0x08C3D3B8, 0x08C3E4C0, 0x08C439E8, 0x0FECD460)
  Mask[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ ff ff ff ff ff
  Pattern[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 12 f1
  FlowControl[ 0] 6:ISO15765. 5 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12
  returning FilterID: 0
  6.372s 0:STATUS_NOERROR
6.373s << PTReadMsgs(3, 0x1CB8A024, 0x1CB8A020, 1)
  read 0 of 100 messages
  6.375s 16:ERR_BUFFER_EMPTY
6.378s >> PTWriteMsgs(3, 0x1CB8A024, 0x1CB8A020, 100)
  Msg[ 0] 6:ISO15765. 7 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12 3e 01
  sent 1 of 1 messages
  6.478s 9:ERR_TIMEOUT
6.478s ** PTGetLastError(0x0FEB8708)
  ERR_TIMEOUT
  9:ERR_TIMEOUT
6.481s >> PTWriteMsgs(3, 0x1CB8A024, 0x1CB8A020, 100)
  Msg[ 0] 6:ISO15765. 7 bytes. TxF=0x000000c0
  TxFlags: 6:ISO15765_FRAME_PAD 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 f1 12 1a 80
  sent 1 of 1 messages
  6.513s 0:STATUS_NOERROR
6.513s << PTReadMsgs(3, 0x1CB8A024, 0x1CB8A020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1322.405278s. 6:ISO15765. Actual data 0 of 5 bytes. RxS=0x00000089
  RxStatus: 0:TX_MSG_TYPE 3:TX_INDICATION 7:ISO15765_ADDR_TYPE
  \__ [00] [00] [06] [f1] [12]
  6.520s 0:STATUS_NOERROR
6.520s << PTReadMsgs(3, 0x1CB8A024, 0x1CB8A020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1322.434175s. 6:ISO15765. Actual data 0 of 5 bytes. RxS=0x00000082
  RxStatus: 1:START_OF_MESSAGE 7:ISO15765_ADDR_TYPE
  \__ [00] [00] [06] [12] [f1]
  6.542s 0:STATUS_NOERROR
6.542s << PTReadMsgs(3, 0x1CB8A024, 0x1CB8A020, 1000)
  read 1 of 1 messages
  Msg[ 0] 1322.453765s. 6:ISO15765. Actual data 65 of 65 bytes. RxS=0x00000080
  RxStatus: 7:ISO15765_ADDR_TYPE
  \__ 00 00 06 12 f1 5a 80 00 00 08 51 70 16 00 02 00 10 58 59 20 11 07 13 08 08 02 30 41 4c 4a 03 03 01 00 00 00 00 00 04 73 12 77 30 10 36 36 30 30 38 39 5a 4d 30 30 30 38 39 5a 4d 30 41 41 4c 4a 43
  6.561s 0:STATUS_NOERROR

In fact I tried another 3 different J2534 devices from 3 different manufacturers. All of them correctly set the RXFlags. Only PCAN J2534 library has this problem.

[F.Vergnaud]

Hello,

Thank you for your feedback, we have indeed internally reported and already fixed an issue related to a missing flag ISO15765_ADDR_TYPE for Rx messages.
It will be included in the next release, you can contact support [at] peak-system.com if you'd like to subscribe to beta testing.
We are in the last testing / validating step and the release date should be a matter of a few weeks.

Regarding the end of reply afterwards, this may be indeed a side effect within your application:
if the reception of the ISOTP extended message is required then the application can wait infinitely as the message was received but lacked the flag..

[projix]

Hello,

No, the problem is not my application. I wrote it. The application is used by hundreds of clients with more than 20 different J2534 interfaces.
Something happens to the PCAN J2534 DLL where even if I clear it and reset everything, I do not get any data back anymore from the J2534 DLL until I power cycle the interface.
But I will test with new version.

Either way I am developing a tool that uses J2534 in a generic form, and I have some customers using your interface.
So I bought one myself to test why it does not work...
For me to sign up for your Beta makes no sense because my customers will not all sign up for your beta, they just download your latest J2534 DLL from the website.

[F.Vergnaud]

Hello,

I was merely suggesting beta to speed up testing and validate the fix on your side, no worries.

Something happens to the PCAN J2534 DLL where even if I clear it and reset everything, I do not get any data back anymore from the J2534 DLL until I power cycle the interface.

While in this state, can you you launch PCAN-View and tell me if you are able to receive/transmit CAN frames with this device?
This test is to confirm if the hardware device is in an unstable state. Thank you.

[projix]

Hello,

Not really have had the time to look into this further.
Is there any ETA on the update?

I downloaded the latest version and I see that the files inside the archive are still last modified 10.02.2021.

[F.Vergnaud]

Hello,

We will have an internal release candidate in two weeks, it will include support to PassThru 04.04 and 05.00.
The official release should follow quickly. We will update this thread to let you know.

[projix]

1 month passed.

News?

[K.Wagner]

Hello,

As Mr. Vergnaud wrote, we have a RC version of PassThru that has a fix for this issue. The release was nevertheless delayed due to other fixes in components of PassThru (PCAN-Basic, PCAN-ISO-TP). When all issues are fixed, we will proceed to release the PassThru package.

[K.Wagner]

Hello,

a new version of PassThru was released on 25th May. A list of changes made and a link for downlaod can be found here: https://www.peak-system.com/PCAN-PassTh ... 404.0.html

Please let us know if this solves your issue.

[projix]

The extended mode seems to work now, but when using ISO-TP with high bus load the CPU usage is very high, it maxes 1.5 cores on a high end Ryzen processor.
If I switch to raw can mode and use my own ISO15765 stack then I have less than 2% CPU usage.

In my ISO15765 stack I am using a multimedia timer and signaling a wait handle to limit my loop to a 1ms raster. Could it be that in your implementation (since it's also done in SW) there is a continuous loop? This could explain why it immediately completely maxes a core.