Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
I have checked what has happened when nothing plugged on canbus:
a bus error occured .
when bus error occurs the ecc register contains possible error information.
once we read the ecc register (in isr routine) the error code register
mechanism is enabled again . Thus another bus error interrupt appears
again and a new BEI ocurs
In this case, the system spend time in the ISR routine of the CAN
driver.It gives you enough time to run a linux console , but not to
launch other tasks like X...
It would be necessary to find a way to manage this kind of problem and
avoiding enabling forever Bus Error Interrupt.
Note that the current implementation of RT-Socket-CAN shows this behaviour on
purpose. See also [1] ("may flood!"). Whether this is the right handling or
not may be discussed here. I admit that the current implementation forces an
application developer to take more responsibility but that is not a bug of
the underlying driver/stack per se. Look, you don't connect anything to the
CAN bus, start a *real-time* application which sends a message to a
non-existent CAN node. This is an error situation an it is more than ever for
a real-time task. So the proper reaction for a RT-application would be to
handle those errors and e.g. shut down the CAN interface which in this case
will force the CAN hardware to stop its endless attempts to send the message.
I agree and this is what I was doing , however this does not seem to
work as expected in the driver.
[1]http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html#g0b068b1221129441b89967ee2ddb9f44
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
