Chip-send-buffer full

[petark]

Hallo

I am having an issue with my PCAN module (miniPCIe-FD). My device is run in blocking mode.
I am using all 4 available CAN Channels to communicate to different Devices. After My Application is running around 20min-1h, I am not able to write to a specific CAN Channel, but the read still works.
The issue has happened on different CAN Channels.
It also looks like that the thread using the pcanfd_send_msg(...) function is blocked in that function when the issue happens.

When the issue happens, I can see in the cat /proc/pcan output that the status is "0x0001" which means "Chip-send-buffer full" but the error counter is still at 0.
I am using the 8.10.2 driver Version.

Any feedback is highly appreciated.

[PEAK-Supporter]

Hello,

Is this issue replicable using the latest PCAN-Linux driver 8.11.0?

http://www.peak-system.com/fileadmin/me ... 1.0.tar.gz

Is this issue replicable if another channel of your PCAN-miniPICe FD using the same bitrate is the receiving end (For example running "receivetest" or "pcanfdtst" from the test folder)?

Please report back to us regarding this.

Best Regards

Marvin

[petark]

Hello

Thanks a lot for the fast answer.

I will update my PCAN-Linux driver to 8.11.0 and do some tests again, thanks for the suggestion.

I forgot to mention that I am using RTAI.
I am not sure if I will be able to replicate the issue with your tests contained in the test folder, since the Problem seems to occur after 100'000++ messages have been successfully written and received on multiple CAN Channels.
I added some more logging in my application using the pcanfd_get_state(...) function. The tx_pending_msgs seem to be 0 or 1 most of the time. How indicated before, after 100'000+ of successful writes and reads the tx_pending_msgs seem to go from 0 to 500 within 5-10 seconds (which makes sense considering my send rate). After that the tx_pending_msgs seem to be stuck at 500, while I am still able to read from the Channel. If I power off the other CAN Device connected to the Channel such that there is no traffic on the CAN-bus anymore, the tx_pending_msgs still stays at 500. The error count shown in cat /proc/rtai also is 0 all the time. Any suggestions what can lead to such behaviour? How can the tx_pending_msgs stay at 500 even though there is no traffic on the CAN-bus while the error count stays at 0 (e.g. no write tries with missing ACK)? My CAN-Analyser shows a bus-load of 20-30%.

Thanks in advance for any feedback or suggestions.

[PEAK-Supporter]

Hello,

Make sure you follow the documentation regarding builds for rtai-environments:
http://www.peak-system.com/fileadmin/m ... an_eng.pdf

when building and installing driver 8.11.0.

Please give us feedback, if this had any effect on your issue.

Whats the output for

Code: Select all

 cat /proc/pcan

once this issue occurs?

The intention behind using a test-application to receive messages is to check wether or not the issue is replicable without your current setup being involved, so one might assess if the issue always occurs when writing messages.


Best Regards

Marvin

[petark]

Whats the output for

Code: Select all

 cat /proc/pcan

once this issue occurs?

Marvin

Hello

Here you can see the output of 2 different times when the issue occured.

https://www.directupload.net/file/d/613 ... ew_png.htm

https://www.directupload.net/file/d/613 ... d4_png.htm

As mentioned before, the issue occures on different channels. The errors count stays at 0 while the status is 0x0001 on the channel on which the issue occures.

[PEAK-Supporter]

Hello,

is this issue replicable when reloading via

Code: Select all

sudo rmmod pcan

Code: Select all

sudo modprobe pcan

the driver after having the "fdusemsi" option set,
as described on page 11 of the pcan-driver documentation?

http://www.peak-system.com/fileadmin/me ... an_eng.pdf

Please report back to us regarding this.

Best Regards

Marvin

[petark]

Hallo

I have updated the driver to the 8.11.0 Version and the issue still occurs.

I am thinking about if I use ur driver wrong. As mentioned before I use RTAI and open your driver in blocking mode.

Are the send and receive function from your driver thread save? Can they be called from different threads?

[S.Grosjean]

Hello,

Please check whether you really run v8.11.0: both of your screenshots show v8.10.0 and v8.10.2:

https://www.directupload.net/file/d/613 ... ew_png.htm
https://www.directupload.net/file/d/613 ... d4_png.htm

Regards,

[petark]

Hello,

Please check whether you really run v8.11.0: both of your screenshots show v8.10.0 and v8.10.2:

https://www.directupload.net/file/d/613 ... ew_png.htm
https://www.directupload.net/file/d/613 ... d4_png.htm

Regards,

Hallo,

You are right, on that tests I did use v8.10.0 and v8.10.2.

I updated the driver to v8.11.0 and did the tests again, unfortunatly I have not saved the cat /proc/pcan output.
It did show me that I use v8.11.0 and the output was very similar to the screenshots that I already sent (status was at 1 and 0 errors after thousends of read and writes).
I can send you the cat /proc/pcan output using v8.11.0 in the next days, as I am not able to test with the hardware today.

Anyway, are the send and receive function from your driver thread save? Can they be called from different threads?

Regards

[S.Grosjean]

Hi,

Yes, the driver is thread-safe, in linux or RTDM mode (Xenomai and RTAI): you can handle two threads, one for the writing side, one for the reading one.

status = 0x0001 means that the *driver* Tx fifo is full. If opened in blocking mode, then the writing thread will wait until receiving an unblocking signal/event from the interrupt handler.

Does the reading thread still receives any CAN frames?
Are you able to reproduce the issue in non-RT mode?
Which skin are you using?
How do you un-block the writing thread?
What does "dmesg | grep pcan" say please?

Regards,