I'm using Digi Embedded Yocto 1.4 for Connect Core i.MX53 and I'm trying to recover a bus off in the can0 interface using the following command:
ip link set can0 type can restart-ms 100
but when I execute it I receive an error message:
root@ccimx53js:~# ip link set can0 type can restart-ms 100
RTNETLINK answers: Operation not supported
I can't found another alternative for that.
I'm developing an application which every second sent a configuration frame to the bus which doesn't have a connected node. So that a bus off occurs.
I want to configure the CAN interface in a way it be auto-recovered immediately after a bus off is detected.
I tried ifconfig can0 down/up. It seems to work because I starts to receive frames from the network but the frames sent by my application aren't seen in the network (although they are seen in the loopback).
I suspect the problem is in FlexCAN driver but I'm not sure. I read some people solved a similar problem updating the kernel version but in my case it is a bit complicated since we are using a specific distribution provided by Digi which only supports kernel version 18.104.22.168.
So my questions are:
Thanks for you help!
I am not sure if there is other way to recover from bus-off mode in user aplication level. But if you are able to recieve data from the network, then your procedue should be working. You mentioned that frames sent by your node are not seen in the network but in loopback mode, I wonder if you have checked with a scope if the frames are sent. Just to make sure the other nodes are not the problem.
Also I recommend you to check if the FlexCAN module for some reason is in Listen-Only Mode. In this mode, the transmission is disabled and only frames ACKed by other node are received. The bit you need to check is the LOM bit in the Control Register.
The Bus Off Recovery mode in the 2.6.35 FlexCAN driver is so thoroughly broken it "isn't even WRONG".
The "ip link set" stuff relies on an interface the driver doesn't support at all. You have to use the sysfs (/sys/devices/platform/FlexCAN.0/) interface to configure it.
In there you have the "boff_rec" variable which should allow "automatic recovery" when set to zero, which is the default. Unfortunately the driver gets this backwards, and gets the timer setting wrong, and gets the recovery wrong and so on, so it can't possibly work without a major rewrite. Details:
Check the pointers to other bug postings in the above.
If your transmitter isn't working it may be due to the interrupt hazard in the driver that results in the netif queue being locked off. The only recovery from this is a POWER CYCLE. If you have more than one transmit MB this is less likely to happen, but then you can't transmit messages in order. Details: