PEAK-System Forum

Hello Folks,
my question is about the CAN error flags - which ones are created and how are they transferred to the application when using the PEAK PCAN SocketCAN driver on Linux.

I am using the PCAN-USB Device with socketcan on Linux Kernel 3.18.11 with device Firmware Version 02.8.01. My network contains only two nodes (each PCAN-USB) at 250kBits with two times 120Ohm Termination at the ends. I am running the CANopen protocol on the bus. Node A is the linux device, Node B is connected to Windows and uses PCAN-View just for having a seccond node.

Node A cyclic sends a heartbeat at 250ms interval. Node B is enabled (sends ACK) and error active but only listens to the bus. Now I unplug the CAN cable directly at the interface of Node A.

My application continues to send frames to the SocketCAN interface until I get the following message:

Code: Select all

root@device:~ cansend can0 "my_frame"
write: No buffer space available

When I reconnect the bus, the SocketCAN continues to send, and will send the frames in the buffer first.

Using a patched version of candump (see http://git.pengutronix.de/?p=tools/canu ... f2df1618e6 ) I can visualize the error frames from SocketCAN (!= CAN Error Frames) on terminal. I observe:

Code: Select all

root@device: candump can0 --error
interface = can0, family = 29, type = 3, proto = 1
// Normal Operation
<0x710> [1] 7f 
// Unplug CAN Cable
<0x710> [1] 7f 
<0x004> [8] 00 0c 00 00 00 00 00 00
<0x710> [1] 7f 
<0x004> [8] 00 30 00 00 00 00 00 00 
<0x710> [1] 7f 
[...]
<0x710> [1] 7f 
<0x004> [8] 00 30 00 00 00 00 00 00 
<0x710> [1] 7f 
[...]
// Repeats until SocketCAN "No buffer space available"
// Then silence
// Plug in CAN again
<0x710> [1] 7f // repeatedly as the buffer contains a bunch of them
<0x004> [8] 00 0c 00 00 00 00 00 00 
<0x710> [1] 7f // normal operation

Applying the CAN_ERR_MASK (see can.h) to the can_id we get Error Type: CAN_ERR_CRTL
Controller Status [byte 1] (see error.h) is: CAN_ERR_CRTL_RX_PASSIVE, CAN_ERR_CRTL_TX_PASSIVE, CAN_ERR_CRTL_RX_WARNING, CAN_ERR_CRTL_TX_WARNING

The following questions arise:

1) I can observe the transitions Error Active -> Error Warning --> Error Passive? Why don't we transit to CAN_ERR_BUSOFF?
2) When reconnecting we return to Error Warning. Why is there no error frame for return to Error Active (flag is cleared)?
3) How can I dump the buffer of the SocketCAN to avoid sending these old messages? And when shall I do it? I would execute the dump when busoff happens, but if it doesn't happen what trigger could I use?

Your help is appreciated. By the way, thanks for the outstanding linux support of the Peak devices

Greetings, Martin

Hi!

Thanks for using our products.

Responses to your questions are:

1/ BUS_OFF state cannot be reached by "simply" unplugging the CAN cable. CAN controller will run into busoff when he will not see his own transmit signal on the CAN bus. A simple unplug will not cause a busoff, this is just an acknowledge error. To really get a BUS-OFF the CAN-H and CAN-L could be shorten by a wire (!)

2/ Unfortunately, there is currently no way to monitor the return to the ERROR-ACTIVE state without changing the source files of the driver in the Kernel

3/ This is a socket-CAN as well as network layer related question. As far as we know, we don't know any existing socket option nor command that can flush any outstanding buffer. But you might ask the socket-CAN community for help...

Regards,

Stéphane

Hello Stéphane,
thanks for your reply. Appreciate your input,
Regarding issue 1) oh yeah, ups

seems like some details of my CAN knowledge got mixed up. Bus Off cannot be reached by a missing ACK. Thanks for the reminder

Regarding issue 3) ok, so maybe I have to look more in to the direction of linux socket control.
Regarding issue 2) So this seems to be a driver specific implementation details. Your response sounds like you have had some experience in this field. Can you point to some good resource or a specific file of the driver where I would have to make changes?

Greetings Martin

Hello folks,
so if someone may run into similar problems, here are some solutions of mine.
Topic 1) see above

Topic 2) As we don't get error flag clear messages, I decided to resume to manual polling the error state of the transceiver. As soon as the first error flag set is received I start monitoring the state until we return to Error_Active (i.e. flag reset).
In my project I am using libsocketcan from Pengutronix http://www.pengutronix.de/software/libs ... /download/ to simplyfy lots of the low level socketcan works. Take a look at the function can_get_state() which returns the error state of the controller. It shows an example how you can get this info.
Topic 3) My current observation is that only restarting from bus_off or complete new socket initialization clears the transmit buffer currently. This topic is still open, let's hope the socketcan users have some great ideas: http://socket-can.996257.n3.nabble.com/ ... d7716.html

Cheers and greetings,
Martin

Hi Martin,
thank you !

Was poking around a little more on topic 3) and found this discussion:
http://thread.gmane.org/gmane.linux.can/2181
Essentially it says: Netlink interface has to go UP->DOWN->UP to clear all internal buffers.
Tested it with PEAK PCAN USB (the old ones, not the new FD ones) and it works. Also the pending TX frame in the PEAK driver or hardware is cleared.
So that works for me, as I can detect a CAN cable disconnect from the loss of external heartbeats and myself going from Error_Active to Error_Passive.
Cheers

PEAK-System Forum

Error Flags and bus off on SocketCAN

Error Flags and bus off on SocketCAN

Re: Error Flags and bus off on SocketCAN

Re: Error Flags and bus off on SocketCAN

Re: Error Flags and bus off on SocketCAN

Re: Error Flags and bus off on SocketCAN

Re: Error Flags and bus off on SocketCAN