Re: [Xenomai-help] RT-Socket-CAN bus error handling (was CAN errors and real-time behaviour (IRQ raise forever and may lock system))

[Wolfgang Grandegger <wg@domain.hid>]

Sebastian Smolorz wrote:
> Wolfgang Grandegger wrote:
>> Sebastian Smolorz wrote:
>>> Last summer we had a discussion about the BEI issue on the socketcan-ML.
>>> Two additional handling policies popped up:
>>> 1. The interface could restart itself after an amount of BEIs, thus
>>> taking responsibility from the user application.
>>> 2. The BEI could be completely disabled if no one is interested in this
>>> type of error frame.
>> I tried to implement 2. for SJA1000, but re-enabling the BIE on the fly
>> does not work. :-(. The controller requires a re-start of the device to
>> get the bus error reporting back to work.
> 
> Oh, really? I wasn't aware of this.

I was surprised as well. The bus error interrupt can be disabled but not 
enabled in active mode.

> 
>>> Maybe it is time to think about the implementation of these policies as
>>> more and more users seem to run into the BEI issue with a disconnected
>>> bus. Wolfgang, Jan, what is your opinion?
>> Well, solution 2. with the limitations mentioned above is therefore less
>> attractive because it interrupts the CAN traffic.
> 
> True.
> 
>> The Socket-CAN 
>> implementation actually restarts the CAN controller after a certain
>> amount of bus error interrupts (200 by default) which matches your first
>> policy above. But in RT-Socket-CAN, we do not automatically re-start the
>> device by purpose. Therefore I tend to just stop the device. It's then
>> up to the application to restart it. What do you think?
> 
> No fundamental objections but it would be best if an application would be 
> informed of this special situation e.g. through an error frame with the 
> meaning "controller was stopped because of a disconnected bus after trying to 
> send 200 times the same message".

D'accord, but we need another error definition for it, e.g. 
CAN_ERR_BUSERROR_FLOOD. I also plan to reset the error count in case of 
a successful transmission (counting only successive errors).

> A question pops up in this context: Why do we define CAN_ERR_RESTARTED if we 
> never do this? Only to be compatible with Socket-CAN? Then I would propose to 
> extend the documentation by pointing out that this will not appear under 
> RT-Socket-CAN.

It's just copied from the Socket-CAN implementation and some doc would 
be nice, indeed.

Wolfgang.