BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Pass-Thru API and connection of Pass-Thru software to PEAK CAN interfaces.
Post Reply
projix
Posts: 6
Joined: Mon 18. Jan 2021, 00:19

BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by projix » Tue 16. Mar 2021, 15:11

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
Software Development
Software Development
Posts: 179
Joined: Mon 9. Sep 2013, 12:21

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by F.Vergnaud » Tue 16. Mar 2021, 16:46

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..
Best regards,
Fabrice

projix
Posts: 6
Joined: Mon 18. Jan 2021, 00:19

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by projix » Tue 16. Mar 2021, 17:33

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
Software Development
Software Development
Posts: 179
Joined: Mon 9. Sep 2013, 12:21

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by F.Vergnaud » Wed 17. Mar 2021, 10:39

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.
Best regards,
Fabrice

projix
Posts: 6
Joined: Mon 18. Jan 2021, 00:19

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by projix » Tue 30. Mar 2021, 14:30

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
Software Development
Software Development
Posts: 179
Joined: Mon 9. Sep 2013, 12:21

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by F.Vergnaud » Tue 30. Mar 2021, 15:08

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.
Best regards,
Fabrice

projix
Posts: 6
Joined: Mon 18. Jan 2021, 00:19

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by projix » Thu 29. Apr 2021, 13:08

1 month passed.

News?

K.Wagner
Software Development
Software Development
Posts: 769
Joined: Wed 22. Sep 2010, 13:36

Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

Post by K.Wagner » Thu 29. Apr 2021, 13:18

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.
Best regards,
Keneth

Post Reply