[Bug 1001897] lpc2xxx CAN driver improvements / enhancements

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001897

Bernard Fouchà <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernard.fouche@kuantic.com

--- Comment #2 from Bernard Fouchà <bernard.fouche@kuantic.com> ---
I've no experience with LPC2xxx but with LPC1765 that has the same CAN cell
from the LPC2xxx.

AFAIK, ICR_BUS_ERR shows an error on the bus, it may not be always a BUS OFF
condition.

To know about BUS OFF, you must check bit 7 of the GSR.

If you immediately clears the counters, the DSR can't know about the counters
value and has no way to help diagnose the problem occurring on the bus.

            // This ensures, that this ISR does not fire again and again and
            // blocks the application while the bus off condition is active.

I made many tests, for instance with a single node on a Hi-Z bus and I don't
remember having the bus OFF condition to make the interrupt code to be called
like in a spin loop.

The LPC1765 irq system is different but I don't see why a MCU would do that,
the problem must be elsewhere because the CAN controller is expected to exit
the bus off condition by itself, at least if there is activity on the bus.

            // Setting the TX error counter to 127 ensures that the controller
            // is in TX error passive mode and that it does not flood the CAN
            // bus with error messages

If your controller is flooding the bus with error frames, it is probably
because another node, or the bus itself, has problems since error frames are
sent by the receiving nodes.

What your patch does it to stop the CAN controller to send error frames as soon
as a single error, or any kind, is detected, which probably breaks the CAN spec
(which may be normal with CANopen, I don't know, but in that case the driver
becomes specific to CANopen).

Why not report simply BUS_ERR and a correct BUS_OFF to the DSR and let it
decide if it's time to reset the bus? The DSR could save the RX/TXREC before
performing a reset for instance. IIUC, because of the reset, your patch clears
the TX buffer that made the controller to go into BUS OFF mode and the
DSR/application isn't made aware of this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.