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>]

Stéphane ANCELOT wrote:
> Hi,
> only one comment :
> It is not anbsolutely necessary to disable bus error interrupt  " a new 
> bus error in terrupt is not possible until the ecc register is read out 
> once".
> 
> only disabling reading of ecc in isr will disable new bei generation.

Ah, good hint. It might make the implementation simpler. I have to check.

Wolfgang.

> Wolfgang Grandegger wrote:
>> Hi Sebastian,
>>
>> 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.
>>
>> Well, I got it working. Reading the ECC register after re-enabling the 
>> bus error interrupts fixed the problem:
>>
>>     if (CAN_STATE_OPERATING(dev->state)) {
>>        chip->write_reg(dev, SJA_IER, chip->ier); /* update on the fly */
>>        chip->read_reg(dev, SJA_ECC);
>>     }
>>
>>>>> 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.
>>
>> Back to our preferred solution 1. Attached is a patch for review 
>> including some other fixes and suggestions accumulated over time:
>>
>>      * ksrc/drivers/can/*: To avoid unnecessary bus error interrupt
>>      flooding, the option CONFIG_XENO_DRIVERS_CAN_BUS_ERR now allows to
>>      enable bus error interrupts "on demand" only if an application is
>>      interested in such errors. It is automatically selected for CAN
>>      controllers supporting bus error interrupts like the SJA1000.
>>
>>      * include/rtdm/rtcan.h: Add some doc on bus-off and bus-error error
>>      conditions and the restart policy.
>>
>>      * src/utils/can/rtcanconfig.c: Controller mode settings and doc
>>      has been corrected.
>>
>>>> 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.
>>
>> Let's wait if solution 1. is sufficient. maybe we need 2. later as well.
>>
>> Wolfgang.
>>
> 
>