[Bug 1001897] lpc2xxx CAN driver improvements / enhancements

[bugzilla-daemon@bugs.ecos.sourceware.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 the assignee for the bug.
>From ecos-bugs-return-10543-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sun Sep 01 22:55:14 2013
Return-Path: <ecos-bugs-return-10543-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14109 invoked by alias); 1 Sep 2013 22:55:14 -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
Received: (qmail 14101 invoked by uid 89); 1 Sep 2013 22:55:13 -0000
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 01 Sep 2013 22:55:13 +0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.3.2
X-HELO: mail.ecoscentric.com
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 3B1114680002; Sun,  1 Sep 2013 23:55:09 +0100 (BST)
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: Your Bugzilla bug list needs attention.
X-Bugzilla-Type: whine
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Sun, 01 Sep 2013 22:55:00 -0000
Message-Id: <20130901225503.55A234680004@mail.ecoscentric.com>
X-SW-Source: 2013/txt/msg00574.txt.bz2
Content-length: 3002

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugs.ecos.sourceware.org/) that require
attention.

All of these bugs are in the CONFIRMED
state, and have not been touched in 7 days or more.
You need to take a look at them, and decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
    and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to
    someone else. (Hint: if you don't know who to reassign it to, make
    sure that the Component field seems reasonable, and then use the
    "Reset Assignee to default" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
    Accept the bug by setting the status to IN_PROGRESS.

To get a list of all CONFIRMED bugs, you can use this URL (bookmark
it if you like!):
http://bugs.ecos.sourceware.org/buglist.cgi?bug_status=CONFIRMED&assigned_to=unassigned@bugs.ecos.sourceware.org

Or, you can use the general query page, at
http://bugs.ecos.sourceware.org/query.cgi

Appended below are the individual URLs to get to all of your CONFIRMED bugs
that haven't been touched for 7 days or more.

You will get this message once a day until you've dealt with these bugs!

 STM32 USB driver unplugging/replugging issue
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001084
 Navigation of the documentation using PREV NEXT PARENT arrows broken
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001146
 help documentation tree does not correspond to viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001148
 documentation tree in navigation panel does not open at viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001149
 CAN loopback driver requires CYGPKG_DEVS_CAN_LOOP_CAN[01]
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001211
 eCos GNU tools 4.6.3
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001468
 Fix compiler warnings about mismatch between log() format string and argument values.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001510
 Array index out of bounds in tftp_server.c
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001522
 Cortex-M: Remote 'g' packet reply is too long
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001524
 BSD nc_test_slave chrashes
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001586
 [RFC] eCos FLASH startup from RedBoot
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001623
 Kinetis variant HAL patch: mostly cosmetic and descriptive improvements
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001783
 Kinetis DSPI, flash and platform HAL tidies
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001784
 Data not relocated to RAM during ROMINT startup
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001864