Chip-send-buffer full

[petark]

Hello, thanks a lot for the fast answer!

Does the reading thread still receives any CAN frames?

Yes, as mentioned before the reading thread still receives CAN frames.
If I power off the other CAN Device connected to the Channel such that there is no traffic on the CAN-bus anymore (no receives), the tx_pending_msgs still stays at 500. The error count shown in cat /proc/rtai also is 0 all the time.

Is the pcan write function thread save? In the sense that the write function on the same channel can be called from different threads? Currently I dont do that, but I might want to do that in the future.


Are you able to reproduce the issue in non-RT mode?

Im not sure what exactly you mean with that. Do you mean running the threads that use the pcan functions in soft_real_time mode instead of hard_real_time mode? I have not tested that yet.

Which skin are you using?

Not sure what u mean with that. Are you talking about the Xenomai-skin? We dont use Xenomai, we use RTAI.

How do you un-block the writing thread?

Do you mean unblocking when the issue occures (tx buffer full)? Currently we dont recover from this condition (power-cycle is needed).

What does "dmesg | grep pcan" say please?

It only says the following when I boot my system:
[ 10.722442] pcan: Release_20210119_n (le)
[ 10.722445] pcan: driver config [mod] [pci] [pec] [rt]
[ 10.722630] pcan 0000:03:00.0: PCAN-miniPCIe FD sub-system id 14h (4 channels)
[ 10.737372] pcan: PCB v2h FPGA v3.2.1 (mode 3)
[ 10.737449] pcan: - pcie fd device minor 0 found
[ 10.737489] pcan: - pcie fd device minor 1 found
[ 10.737530] pcan: - pcie fd device minor 2 found
[ 10.737571] pcan: - pcie fd device minor 3 found
[ 10.738009] pcan: major 0.

When the issue occures it doesnt say anything.


Regards

[S.Grosjean]

Hi,

If the reading thread still receives CAN frames, then the interrupt handler works as it should. Therefore, there is no obvious reason why it doesn't unlock the writing thread too...

This version of pcan is not multi-session. This means that only one thread is allowed to write over a channel. More precisely, only one thread can be blocked waiting for space in Tx FIFO at the same time.

You can build the driver in normal mode (aka non-RT) and run the test applications in a (RTAI patched) kernel. This would permit to check if the card works as it should.

I wonder if you use the POSIX, RTDM or LXRT API.

Even a signal (^C for ex) doesn't unlock the writing thread? Maybe pthread_setcancelstate() and pthread_setcanceltype() can help.

Did you try using the "rt_dev_select()" call instead of blocking mode? See for example test/src/pcanfdtst.c

Regards,

[petark]

Hi,

If the reading thread still receives CAN frames, then the interrupt handler works as it should. Therefore, there is no obvious reason why it doesn't unlock the writing thread too...

This version of pcan is not multi-session. This means that only one thread is allowed to write over a channel. More precisely, only one thread can be blocked waiting for space in Tx FIFO at the same time.

You can build the driver in normal mode (aka non-RT) and run the test applications in a (RTAI patched) kernel. This would permit to check if the card works as it should.

I wonder if you use the POSIX, RTDM or LXRT API.

Even a signal (^C for ex) doesn't unlock the writing thread? Maybe pthread_setcancelstate() and pthread_setcanceltype() can help.

Did you try using the "rt_dev_select()" call instead of blocking mode? See for example test/src/pcanfdtst.c

Regards,

We use the LXRT API.

I have confirmed that calling thread_setcancelstate() and pthread_setcanceltype() allows the writing threads to be unlocked, thus ^C works when the issue occures.