Unable to send messages after sending a 11-bit CAN ID

[damiend]

Hello,

I have an issue with a PCAN-USB and the PCAN-PassThru API.

I configured the PassThru API to recieve/transmit both CAN 29-bits and 11-bits IDs.

Time Function TPCANTPStatus Extra message
6453640 PassThruOpen STATUS_NOERROR (0x00) PARAMS={pName=J2534-2:PEAK 0x51, *pDeviceID=81}
6453875 PassThruConnect STATUS_NOERROR (0x00) PARAMS={DeviceID=81, ProtocolID=5, Flags=256, BaudRate=250000, *pChannelID=1358954501}
6453875 PassThruStartMsgFilter STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, FilterType=1, pMaskMsg=0x8b7dce4, pPatternMsg=0x8b7ed1c, pFlowControlMsg=0x0, *pFilterID=139816280}
" --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 00 00 ]}"
" --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 00 00 ]}"
" --> * pFlowControlMsg=NULL"
6453875 PassThruStartMsgFilter STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, FilterType=1, pMaskMsg=0x8b7dce4, pPatternMsg=0x8b7ed1c, pFlowControlMsg=0x0, *pFilterID=139828752}
" --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x100, TxFlags=0x100, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 00 00 ]}"
" --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x100, TxFlags=0x100, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 00 00 ]}"
" --> * pFlowControlMsg=NULL"

Everything is normal when I send 29-bits CAN ID messages with the PassThru API.
When I send a 11-bits ID CAN message, the message is processed and then the PCAN-USB device stops sending anyother messages (29 and 11-bits CAN ID messages).
I noticed that the 11-bit CAN ID message is echoed and appears in my recieved messages (no loopback was configured and this message is never recieved, always sent by my application).

6467500 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}
6467593 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}
6467687 PassThruReadMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=1/1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x100, TxFlags=0x00, Timestamp=2172884575, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[18 ef ff 8c 64 01 ff ff ff ff ff ff ]}"
6467796 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}
6467812 PassThruWriteMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0x9efea54, *pNumMsgs[In]=1, *pNumMsgs[Out]=1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=2173000416, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[00 00 01 23 18 27 36 45 54 63 72 81 ]}"
6467812 PassThruReadMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=1/1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=2173001517, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[00 00 01 23 18 27 36 45 54 63 72 81 ]}"
6467921 PassThruWriteMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0x9efea54, *pNumMsgs[In]=1, *pNumMsgs[Out]=1, Timeout=100}
6467921 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=2173112730, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[00 00 01 23 18 27 36 45 54 63 72 81 ]}"
6468000 PassThruReadMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=1/1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x100, TxFlags=0x00, Timestamp=2173184457, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[18 ef ff 8c 64 01 ff ff ff ff ff ff ]}"
6468031 PassThruWriteMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0x9efea54, *pNumMsgs[In]=1, *pNumMsgs[Out]=1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=2173223043, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[00 00 01 23 18 27 36 45 54 63 72 81 ]}"
6468093 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}
6468140 PassThruWriteMsgs STATUS_NOERROR (0x00) PARAMS={ChannelID=1358954501, pMsg=0x9efea54, *pNumMsgs[In]=1, *pNumMsgs[Out]=1, Timeout=100}
" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x05, RxStatus=0x00, TxFlags=0x00, Timestamp=2173333167, DataSize=0x0c, ExtraDataIndex=0x0c, Data=[00 00 01 23 18 27 36 45 54 63 72 81 ]}"
6468187 PassThruReadMsgs ERR_BUFFER_EMPTY (0x10) PARAMS={ChannelID=1358954501, pMsg=0xa03e750, *pNumMsgs=0/1, Timeout=100}

Below is the corresponding CAN traces, with the 11-bits CAN ID message flagged as Rx and not Tx:

157) 13799.7 Rx 18EFFF8C 8 64 01 FF FF FF FF FF FF
158) 13916.6 Rx 0123 8 18 27 36 45 54 63 72 81
159) 14099.5 Rx 18EFFF8C 8 64 01 FF FF FF FF FF FF

No Error is return by the Passthru API, and the debug log of the Pass-thru API continues to record the reception and transmission activity.
A soft reset of the PCAN-USB device is required to recover Tx communications.

My CAN Bus has 2 controllers and the PCAN-USB
Device & API versions:
PassThru v04.04 API: 3.0.2.153
PCAN-Basic API: 4.6.1.728
PCAN_USB driver: 4.3.0.16563
PCAN-USB FW: 5.3.2

Did you noticed that behavior before ? Is this an issue regarding my message flags or my API configuration ?
Please find attached the full logs.

[K.Wagner]

Hello,

thanks for the detailed information and files. No, we have never seen this behaviour before. We will try to reproduce the issue and will post then here our results.

[F.Vergnaud]

Hello,

Unfortunately, we were not able to reproduce the issue. If you can share a minimalistic sample, we could analyze your source code and replay it.
Please feel free to send us any private source code to "support [at] peak-system.com".

Also, you mention that "A soft reset of the PCAN-USB device is required to recover Tx communications". Could you clarify what kind of soft reset you imply:
- calling PassThruDisconnect/PassThruConnect on the device in your PassThru application (or PassThruClose/PassThruOpen),
- calling PassThru's IOCTL CLEAR_TX_BUFFER and CLEAR_RX_BUFFER?

Finally, when the issue is triggered, could you try to connect with PCAN-View on that initialized device and send a frame? If the frame is not successfully sent, enabling trace with "Log Error frames" could provide extra information.

[damiend]

Hello,

Thank you for you reply.

I send by private message the source code exemple, with few logs attached.

The reset required to recover the communication is a PassThruDisconnect/PassThruConnect.
PassThru's IOCTL CLEAR_TX_BUFFER and CLEAR_RX_BUFFER has no effect on the issue.

Once the issue triggered, PCAN-View is not able to send any message (same behaviour as the application).
No Error Frame is displayed by PCAN-View (see logs attached in private message).
I also notice that the "reset" button from PCAN-View is able to recover the communication too.

Thanks,
Damien

[K.Wagner]

Hello,

Once the issue triggered, PCAN-View is not able to send any message (same behaviour as the application).
No Error Frame is displayed by PCAN-View (see logs attached in private message).
I also notice that the "reset" button from PCAN-View is able to recover the communication too.

Just to clarify: does it means, that you can trigger the sending of a message within the PCAN-View attached to the same PCAN-USB as your applicaiton, but the message doesn't go out and no error are shown in PCAN-View? Added to this, the status bar of it doesn't show any bad status like Bus-Off or Warning?

[K.Wagner]

Hello,

I send by private message the source code exemple, with few logs attached.

We did not get any message from you. Please send the files to support[at]peak-system.com making reference to this topic.

Thanks.

[damiend]

Hello,

Hello,

Once the issue triggered, PCAN-View is not able to send any message (same behaviour as the application).
No Error Frame is displayed by PCAN-View (see logs attached in private message).
I also notice that the "reset" button from PCAN-View is able to recover the communication too.

Just to clarify: does it means, that you can trigger the sending of a message within the PCAN-View attached to the same PCAN-USB as your applicaiton, but the message doesn't go out and no error are shown in PCAN-View? Added to this, the status bar of it doesn't show any bad status like Bus-Off or Warning?

Yes this is right.
I made a picture to resume the log from PCAN view.

Image_description.png (134.93 KiB) Viewed 6714 times

I also just noticed that is related to my Hardware.
I have an old PCAN-USB device with a Firmware 5.3, that is triggering the issue.

I tried with a recent one (Firmware 8.4.0) and two older ones too (Firmware 5.3), which did not show the issue.

So, seems to be an isolated case...

[K.Wagner]

Hello,

Many thanks for the files. We were able to reproduce the issue with your example and a similar device. We are now investigating the cause of this malfunction and will let you know our founds as soon as we get more info on this.

Thanks again for bringing this to our attention.

[K.Wagner]

Hello,

we have identified the problem in the firmware. Our engineers will check and fix the problem.

Thanks for helping us finding the problem.