Chip-send-buffer full

This forum covers PCAN-Linux and Linux development issues concerning our products
petark
Posts: 7
Joined: Fri 26. Mar 2021, 19:14

Chip-send-buffer full

Post by petark » Fri 26. Mar 2021, 19:30

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.

M.Heidemann
Sales & Support
Sales & Support
Posts: 673
Joined: Fri 20. Sep 2019, 13:31

Re: Chip-send-buffer full

Post by M.Heidemann » Mon 29. Mar 2021, 10:33

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
Posts: 7
Joined: Fri 26. Mar 2021, 19:14

Re: Chip-send-buffer full

Post by petark » Mon 29. Mar 2021, 20:35

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.
Last edited by M.Gerber on Tue 30. Mar 2021, 09:29, edited 1 time in total.
Reason: Removed full quote from previous post.

M.Heidemann
Sales & Support
Sales & Support
Posts: 673
Joined: Fri 20. Sep 2019, 13:31

Re: Chip-send-buffer full

Post by M.Heidemann » Tue 30. Mar 2021, 09:25

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
Posts: 7
Joined: Fri 26. Mar 2021, 19:14

Re: Chip-send-buffer full

Post by petark » Tue 30. Mar 2021, 10:05

M.Heidemann wrote:
Tue 30. Mar 2021, 09:25

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.

M.Heidemann
Sales & Support
Sales & Support
Posts: 673
Joined: Fri 20. Sep 2019, 13:31

Re: Chip-send-buffer full

Post by M.Heidemann » Tue 30. Mar 2021, 10:30

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
Posts: 7
Joined: Fri 26. Mar 2021, 19:14

Re: Chip-send-buffer full

Post by petark » Fri 2. Apr 2021, 12:02

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?

User avatar
S.Grosjean
Software Development
Software Development
Posts: 302
Joined: Wed 4. Jul 2012, 17:02

Re: Chip-send-buffer full

Post by S.Grosjean » Tue 6. Apr 2021, 13:56

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,
— Stéphane

petark
Posts: 7
Joined: Fri 26. Mar 2021, 19:14

Re: Chip-send-buffer full

Post by petark » Tue 6. Apr 2021, 14:22

S.Grosjean wrote:
Tue 6. Apr 2021, 13:56
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

User avatar
S.Grosjean
Software Development
Software Development
Posts: 302
Joined: Wed 4. Jul 2012, 17:02

Re: Chip-send-buffer full

Post by S.Grosjean » Tue 6. Apr 2021, 14:53

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,
— Stéphane

Post Reply