public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001897] lpc2xxx CAN driver improvements / enhancements
Date: Fri, 30 Aug 2013 14:27:00 -0000	[thread overview]
Message-ID: <bug-1001897-104-80IoLlMN96@http.bugs.ecos.sourceware.org/> (raw)
In-Reply-To: <bug-1001897-104@http.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 on the CC list for the bug.

  parent reply	other threads:[~2013-08-30 14:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29  9:37 [Bug 1001897] New: " bugzilla-daemon
2013-08-30 12:37 ` [Bug 1001897] " bugzilla-daemon
2013-08-30 12:38 ` bugzilla-daemon
2013-08-30 14:27 ` bugzilla-daemon [this message]
2013-09-02  7:22 ` bugzilla-daemon
2013-09-02 16:22 ` bugzilla-daemon
2013-09-03  6:18 ` bugzilla-daemon
2013-09-03  6:38 ` bugzilla-daemon
2013-09-03  8:20 ` bugzilla-daemon
2013-09-03  8:22 ` bugzilla-daemon
2013-09-03  9:06 ` bugzilla-daemon
2013-09-03 10:48 ` bugzilla-daemon
2013-09-03 12:20 ` bugzilla-daemon
2013-09-03 12:22 ` bugzilla-daemon
2013-09-03 12:31 ` bugzilla-daemon
2013-09-03 12:37 ` bugzilla-daemon
2013-09-03 12:53 ` bugzilla-daemon
2013-09-03 18:52 ` bugzilla-daemon
2013-09-06  8:19 ` bugzilla-daemon
2013-09-06 14:20 ` bugzilla-daemon
2013-09-11 21:23 ` bugzilla-daemon
2013-09-17  6:10 ` bugzilla-daemon
2013-09-17  6:35 ` bugzilla-daemon
2013-09-17 18:39 ` bugzilla-daemon
2013-09-17 18:42 ` bugzilla-daemon
2013-09-18  5:45 ` bugzilla-daemon
2013-09-18  6:46 ` bugzilla-daemon
2013-09-18 16:08 ` bugzilla-daemon
2013-11-05 15:41 ` bugzilla-daemon
2013-11-06  9:30 ` bugzilla-daemon
2013-11-06 15:28 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1001897-104-80IoLlMN96@http.bugs.ecos.sourceware.org/ \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).