[Bug 1001439] New: can_lpc2xxx.c: CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems

[Bug 1001439] New: can_lpc2xxx.c: CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems

[bugzilla-daemon]

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

           Summary: can_lpc2xxx.c:
                    CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: minor
          Priority: low
         Component: CAN
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


In function lpc2xxx_can_DSR():

...
#if CYGINT_IO_CAN_CHANNELS > 1
    cyg_uint8 i = 0;
    while (lpc2xxx_global_can_info.active_channels[i])
#endif // CYGINT_IO_CAN_CHANNELS > 1
    {
        cyg_uint32   icr;
        can_channel *chan = LPC2XXX_GET_CAN_CHANNEL(lpc2xxx_global_can_info,
i++);
        CAN_DECLARE_INFO(chan);

        HAL_READ_UINT32(CAN_CTRL_ICR(info), icr);      // this read clears ICR
#ifdef CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP
        // Set ICR_LUT_ERR flag only for controller which cause LUT error
        if ((luterr_chan0 == i) || (luterr_chan1 == i))
...

1) 'i' is declared only if more than one CAN channel. 'i' is referenced always
if CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP is defined.

2) On MCU counting CAN channels from 0: 'i++' is performed at beginning of
while(...), and if CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP is defined,
luterr_chan[0/1] are compared to 'i': the LUT fault won't be reported to the
correct CAN channel for such MCUs (luterr_chan[0/1] have values directly
provided by the hardware). can_accfilt_lpc2xxx.c has macro
LPC2XXX_CAN_FIRST_IN_LUT that could be moved to can_lpc2xxx.h to help solve
this.

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

[Bug 1001439] can_lpc2xxx.c: CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems

[bugzilla-daemon]

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-05 18:38:04 GMT ---
Previous comment was erroneous, it took me some time to figure the CAN
controller table in the driver.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8612-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Jan 05 18:38:35 2012
Return-Path: <ecos-bugs-return-8612-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 19689 invoked by alias); 5 Jan 2012 18:38:34 -0000
Received: (qmail 19647 invoked by uid 22791); 5 Jan 2012 18:38:33 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 18:38:16 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 7E50C2F7800A
	for <ecos-bugs@ecos.sourceware.org>; Thu,  5 Jan 2012 18:38:15 +0000 (GMT)
Received: from mail.ecoscentric.com ([127.0.0.1])
	by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id TZqpQNNeRzuM; Thu,  5 Jan 2012 18:38:07 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001439] can_lpc2xxx.c:
 CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: CAN
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001439-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001439-13@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Thu, 05 Jan 2012 18:38:00 -0000
Message-Id: <20120105183807.753F12F78009@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00041.txt.bz2
Content-length: 504

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-05 18:38:04 GMT ---
Previous comment was erroneous, it took me some time to figure the CAN
controller table in the driver.

-- 
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.
>From ecos-bugs-return-8615-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Jan 06 11:56:53 2012
Return-Path: <ecos-bugs-return-8615-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 755 invoked by alias); 6 Jan 2012 11:56:52 -0000
Received: (qmail 748 invoked by uid 22791); 6 Jan 2012 11:56:52 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 11:56:37 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 5F17F2F78006; Fri,  6 Jan 2012 11:56:36 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001447] New: can_lpc2xxx.c: race condition (Tx events may be
 missed), DSR efficiency
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: CAN
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001447-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Fri, 06 Jan 2012 11:56:00 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00044.txt.bz2
Content-length: 2962

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

           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 the assignee for the bug.

[Bug 1001439] New: can_lpc2xxx.c: CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems

[bugzilla-daemon]

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

           Summary: can_lpc2xxx.c:
                    CYGOPT_DEVS_CAN_CAN_LPC2XXX_LUT_ERR_SUPP problems
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: minor
          Priority: low
         Component: CAN
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


In function lpc2xxx_can_DSR():

...
#if CYGINT_IO_CAN_CHANNELS > 1
    cyg_uint8 i = 0;
    while (lpc2xxx_global_can_info.active_channels[i])
#endif // CYGINT_IO_CAN_CHANNELS > 1
    {
        cyg_uint32   icr;
        can_channel *chan = LPC2XXX_GET_CAN_CHANNEL(lpc2xxx_global_can_info,
i++);
        CAN_DECLARE_INFO(chan);

        HAL_READ_UINT32(CAN_CTRL_ICR(info), icr);      // this read clears ICR
#ifdef CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP
        // Set ICR_LUT_ERR flag only for controller which cause LUT error
        if ((luterr_chan0 == i) || (luterr_chan1 == i))
...

1) 'i' is declared only if more than one CAN channel. 'i' is referenced always
if CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP is defined.

2) On MCU counting CAN channels from 0: 'i++' is performed at beginning of
while(...), and if CYGOPT_DEVS_CAN_LPC2XXX_LUT_ERR_SUPP is defined,
luterr_chan[0/1] are compared to 'i': the LUT fault won't be reported to the
correct CAN channel for such MCUs (luterr_chan[0/1] have values directly
provided by the hardware). can_accfilt_lpc2xxx.c has macro
LPC2XXX_CAN_FIRST_IN_LUT that could be moved to can_lpc2xxx.h to help solve
this.

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