Question about PCAN USB and Error Counters

[pavlumik]

Hello,

would you please help me in answering on couple of questions?

We are using the following product https://www.peak-system.com/PCAN-USB.199.0.html?&L=1 attached to the Linux based system with standard Linux kernel - 4.14.68
Generally available peak_usb driver and SocketCAN are enough in part of interface/device management and sending/receiving CAN messages in our application.

What we need is to retrieve an information about errors might happen in the line and/or detected by CAN Controller. Here I am talking about errors as they are defined in the Linux kernel header
https://github.com/torvalds/linux/blob/ ... an/error.h

At the moment we are using the following tools to retrieve state and statistics for this device
$ ifconfig can0
and
$ ip -details link show can0

and noticed that RX-errors and TX-errors never changed even we are trying to simulate erroneous cases in the line, for example
- Shorting CAN_Low to GND for around 10 seconds
- Shorting CAN_High to GND for around 10 seconds
It seems such tests have influence, since error-warn, error-pass, bus-off - increased. However error counters not.

Please refer to the output of the commands:

Code: Select all

root@intel-corei7-64:~# ip -details -statistics link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state ERROR-ACTIVE restart-ms 100 
	  bitrate 500000 sample-point 0.875 
	  tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          6          6          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    665847     83247    0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    529725     66703    0       0       0       0       
root@intel-corei7-64:~# 
root@intel-corei7-64:~# ip -details -statistics link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc fq_codel state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state ERROR-ACTIVE restart-ms 100 
	  bitrate 500000 sample-point 0.875 
	  tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  12         0          0          10         12         12        numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    711407     88968    0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    1560828    196540   0       100     0       0       
root@intel-corei7-64:~# 

My questions are:
- Does PCAN-USB device (Linux kernel driver) supports reporting of RX/TX errors?
- Is there any difference in this part (RX/TX errors detection and report) between PCAN-USB device and PCAN-USB Pro FD (https://www.peak-system.com/PCAN-USB-Pr ... .html?&L=1)?
- We noticed that Error Frames might be passed to the user space in case if CAN_RAW_ERR_FILTER socket option set. Does PCAN-USB device (Linux kernel driver) support transfer of this Error Frames to user space application?

Thank you!

[S.Grosjean]

Hello,

You're right: up to now, the peak_usb driver doesn't forward the error counters of the PCAN-USB adapter to the upper layer. This functionality came later in the hardware and the mainline driver has not been updated to include it. We are going to prepare a patch to push this into the next Kernel to fix that. Meanwhile, what you an do:

• use our pcan driver in netdev mode (see https://www.peak-system.com/fileadmin/m ... /index.htm)
• send an email to linux@peak-system.com, requesting for the modified driver, so that we will be able to send to you a package as soon as it will be ready

Thank you for your interest in PEAK-System products.

Regards,

[pavlumik]

Hello Stéphane!

Thanks for the support and quick answer!
Just to confirm that my understanding is correct (please add if I miss/misinterpret something):
- in general, Peak System is recommending to use mainline driver (officially delivered with Linux kernel sources)
- in Driver Package for Proprietary Purposes support of netdevice interface is disabled by default, btw was it tested enough with fresh kernels (4.x)?
- in Driver Package for Proprietary Purposes similar set of statistics provided as it is in mainline driver available if process Error Frames in application (rx-tx errors detected based on the queue overflow or or some physical frames corruption, - switches from error-active to error-warning, error-passive and bus-off). I.e. extended statistic with shorting GND and CAN_HI or CAN_LO is not monitored / available, right?

What is your view how much time would be required to update mainline driver (peak_usb) in linux kernel (part of error statistics calculation/reporting)?

[S.Grosjean]

Hi,

- in general, Peak System is recommending to use mainline driver (officially delivered with Linux kernel sources)

PEAK-System recommends to use mainline drivers for a socket-CAN usage, mainly because:

• they don't need to be built (nor cross-built)
• they always are up-to-date with the latest changes and improvements that are brought to the Kernel

For example, CAN-FD in the socket-CAN support of the proprietary pcan driver came later than in the official drivers.

- in Driver Package for Proprietary Purposes support of netdevice interface is disabled by default, btw was it tested enough with fresh kernels (4.x)?

We do test the so-called netdev interface with the same test platforms than those used for the mainline drivers. pcan v8.9 has been tested with fresh kernels 5.0.x.

I.e. extended statistic with shorting GND and CAN_HI or CAN_LO is not monitored / available, right?

Right.

The time to import the management of the PCAN-USB Rx/Tx errors counters in the mainline peak_usb driver mainly depends on the linux-can maintainers time to include the patch into the next-linux Kernel process, rather than the time to write the code itself.

Regards,

[pavlumik]

Thanks for the prompt reply and support!