[Bug 1001447] New: can_lpc2xxx.c: race condition (Tx events may be missed), DSR efficiency

[Bug 1001447] New: can_lpc2xxx.c: race condition (Tx events may be missed), DSR efficiency

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001447

           Summary: can_lpc2xxx.c: race condition (Tx events may be
                    missed), DSR efficiency
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: CAN
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Test config:

- LPC17XX @ 16Mhz, CAN bus CLK @ 8MHz, CAN bus bit rate: 500Kb/s
- sending 1 CAN message, expecting Tx done event in DSR.

1) race condition, Tx events missed bug description:

- No TX event received by DSR, even if ISR fired. Magically, even if checked in
the ISR, the register supposed to describe why an interrupt occurred (ICR) is
filled with 0's.

Explanation:

- DSR uses ICR to know what type of event to process. ICR is a register having
bits resulting of a logical 'AND' of enabled interrupts and occurred
interrupts.

- When the last packet is sent on the CAN bus (in my case it's the first and
last), CAN package calls _stop_xmit() in can_lpc2xxx.c . This function lowers
the TX1 bit in the enabled interrupt register.

- because of the logical AND done to generate the content of ICR, as soon as
TX1 is cleared in IER (enabled interrupts), the corresponding bit is also
cleared in ICR.

Fix: TX interrupt enable bits do not have to be modified in _start_xmit() and
_stop_xmit(): if no packet is sent, no tx related occurs, so changing these
bits trigger this bug while bringing nothing valuable.

2) DSR efficiency

DSR processes RX events one at a time while the hardware has a double receive
buffer. As soon as DSR release a message buffer, a second message may be
already available. Current DSR design will wait for a next interrupt to occur.
A supplementary side effect is increasing the chances of getting an overrun
condition.

Fix: DSR should loop until all interrupt conditions are cleared. Since the MCU
has a limited amount of buffers, in worst case condition DSR will consider 2 RX
buffers to read and 3 TX buffers to fill. But this is still much more efficient
than having to perform the same job after getting more ISR and DSR calls.

3) Misc

Driver should support the triple transmit buffers instead of being limited
using a single one because of a years old errata impacting a subset of the MCU
that can make use of this driver. LPC17XX CAN controllers have no such errata,
they must be able to use all 3 Tx buffers.

Fix: CDL option for triple buffering having default value 'no triple buffer'.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.