CAN frames spamming with listen only option activated

[nico34]

Hi,

We are using PCAN-USB adapter.
We have an issue when activating the Listen only option. Then we receive a huge amount of CAN frames, most of them being invalid (or series of the same CAN frame repeated endlessly).
When removing this listen only option, everything goes find again.

Would you have any idea of what could happen?

(Tests run under Windows 64 with the 32 bits PCAN-Basic API)
(same effect under Linux Ubuntu 64 and the PCAN drivers after having slightly modified libpcan.h and libpcan.c to handle the listen only option in CAN_Init:
DWORD CAN_Init(HANDLE hHandle, WORD wBTR0BTR1, int nCANMsgType, int listenOnly)
{
PCAN_DESCRIPTOR *desc = (PCAN_DESCRIPTOR *)hHandle;
int err = EBADF;

errno = err;
if (desc)
{
TPCANInit init;

init.wBTR0BTR1 = wBTR0BTR1; // combined BTR0 and BTR1 register of the SJA100
init.ucCANMsgType = (nCANMsgType) ? MSGTYPE_EXTENDED : MSGTYPE_STANDARD; // 11 or 29 bits
init.ucListenOnly = listenOnly; // listen only mode when != 0


Thanks in advance

[nico34]

Update:

We are using 2 PEAK interfaces to send from one to the other.
When the emitter is PCANView, the receiver in listen only mode is not spammed.
When the emitter comes from our own code, we get spammed in listen only mode while everything is ok if listen only option is not set...

We'll inquire about what may go wrong at the emitting stage. No idea for now.

Any help or hint appreciated anyway.

Best,

[PEAK-Support]

please keep in mind that you need minimum 2 active CAN nodes in a running network - if you use one of them in listen only mode, and send from the other node, the CAN Controller will retry sending in a endless loop...

[nico34]

Thanks for your answer. That may be part of an explanation as for our tests, we are connecting 2 PCAN USB adapters together with a single CAN cable (with termination resistors).

However we still don't understand why sending from PCAN View does not produce the problem on the receiver side, whereas sending with our own code using PCANBasic or the Linux API does.

Hope it helps,
Thanks.

[PEAK-Support]

i do not know how your own application work...so how could i answer your question?
maybe you send the code to our support team and we could take a look at it

[nico34]

True.
I was just wondering if it were some standard mistake many people already made.
We'll perform some addtional tests and will send the code if the problem remains.

Thanks again,

[PEAK-Support]

! please always check the MsgType after you have received a CAN Frame !
Our driver could also send CAN Messages which are no real CAN Messages - they called status Messages.

Code: Select all

PCAN_MESSAGE_STATUS    = 0x80,

If you receive such a Message, the first 4 data bytes of the message contain the Error Code. The MSB of the Error Code is in data byte 0, the LSB is in data byte 3.

See Online Help (search for Status messages)

The message type (see TPCANMessageType) of a CAN message indicates if the message is a 11-bit, 29-bit, RTR, or status message. This value should be checked every time a message has been read successfully. If the bit PCAN_MESSAGE_STATUS is set in the TPCANMsg.MSGTYPE field, the message is a status message. The ID and LEN fields do not contain valid data. The first 4 data bytes of the message contain the Error Code. The MSB of the Error Code is in data byte 0, the LSB is in data byte 3.

Examples:

Data0 Data1 Data2 Data3 Error Error Code Description
00h 00h 00h 02h PCAN_ERROR_OVERRUN 0002h CAN controller has been read out too late.
00h 00h 00h 04h PCAN_ERROR_BUSLIGHT 0004h Bus error: An error counter has reached the 'Light' limit.
00h 00h 00h 08h PCAN_ERROR_BUSHEAVY 0008h Bus error: An error counter has reached the 'Heavy' limit.
00h 00h 00h 10h PCAN_ERROR_BUSOFF 0010h Bus error: CAN Controller is in 'Bus Off' state.