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

[Sebastian Smolorz <ssm@domain.hid>]

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.

>
> > 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".

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.

-- 
Sebastian