[Bug 1001897] lpc2xxx CAN driver improvements / enhancements

[bugzilla-daemon@bugs.ecos.sourceware.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 14480 bytes --]

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

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

--- Comment #8 from Bernard Fouché <bernard.fouche@kuantic.com> ---
(In reply to comment #3)
> manual snippet ------------------->
> If the Transmit Error counter contains 255 and another error occurs, the CAN
> Controller is forced into a state called Bus-Off. In this state, the
> following register bits are set: BS in CANSR, BEI and EI in CANIR if these
> are enabled, and RM in CANMOD. RM resets and disables much of the CAN
> Controller. Also at this time the Transmit Error Counter is set to 127 and
> the Receive Error Counter is cleared.
> <----------------------

The manual is unclear: in some places it states that bus off is reached when
the tx counter error is 255, and in what you show (in what is also in LPC17xx
manual section 16.8.1), that bus off is reached only when the counter reaches
255+1.

For instance the definition of BS is:

"7 BS[6] Bus Status. 0 0
0 (Bus-On) The CAN Controller is involved in bus activities
1 (Bus-Off) The CAN controller is currently not involved/prohibited from bus
activity
because the Transmit Error Counter reached its limiting value of 255."

By readins this one could understand that BS is set when TEC reaches 255, but
the complete bus off state is reached only when the counter is incremented
another time.

> 
> That means: 
> 
> 1. Bus error interrupt
> 2. RM in CANMOD set (RM - Reset Mode resets and disables much of the CAN
> Controller)
> 3. TX counter is set to 127 and RX counter is cleared.
> 
> That means according to the manual the hardware should do exactly what my
> patch does in case of a Bus-off confition. The problem is, although it is
> written in the manual, it does not happen for my LPC2xxx. Via debug output I
> can see the following:
> 
> 1. Bus error interrupt occures (BS in CANSR and GSR is set)
> 2. RM in CANMOD is NOT set (controller remains active)
> 3. TX counter is NOT set to 127 and RX counter is NOT cleared.
> 
> So the hardware acts differently than the manual states. I could not find
> anything in the errata sheets and I don't know if this also happens for
> newer (i.e. LPC3xxx) devices - but for the LPC2294 controller on the olimex
> board, this is reality. Because the controller does not enter RM (Reset
> Mode) and because the counters are not cleared by hardware, the Bus error
> interrupt will happen immediatelly again as soon as the ISR / DSR processing
> has finished. This will block application from running because the ISR /DSR
> code will fire again and again. So my patch simply does, what it is written
> in the manual:

Still about BS, there is a note [6] that states:

"[6] Mode bit '1' (present) and an Error Warning Interrupt is generated, if
enabled. Afterwards the Transmit Error Counter is set to '127', and
the Receive Error Counter is cleared. It will stay in this mode until the CPU
clears the Reset Mode bit. Once this is completed the CAN
Controller will wait the minimum protocol-defined time (128 occurrences of the
Bus-Free signal) counting down the Transmit Error
Counter. After that, the Bus Status bit is cleared (Bus-On), the Error Status
bit is set '0' (ok), the Error Counters are reset, and an Error
Warning Interrupt is generated, if enabled. Reading the TX Error Counter during
this time gives information about the status of the
Bus-Off recovery."

Why did they wrote "afterwards" ? Does it mean that parts of the processing
(TEC set to 127 and REC to zero) only occurs *after* the interrupt?

If so a possibility of what you observe is that TEC reaches 255, BS is set to
one, ISR is triggered, but TEC/REC aren't modified yet. RM is still zero since
TEC just got 255, and didn't crossed yet 255+1 so full bus off isn't reached.

In the meaning time the bus is idle (AFAIK when you debug the CAN cell is still
running), the controller sees 128 'bus free' bits, TEC goes down until the
controller restart trying to send a frame that nobody acknowledge. Or the bus
can't handle recessive bits, etc. From that moment TEC goes up, until the ISR
is fired again.

What is the frequency of the ISR being triggered? Did you test how this
frequency is related to the bus bit rate ? Just to know if when the ISR fires
"again and again" it fires immediately one ISR after the other, or if there is
time for 128 bus free bits on the bus...

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10551-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Sep 03 10:48:28 2013
Return-Path: <ecos-bugs-return-10551-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 27523 invoked by alias); 3 Sep 2013 10:48:28 -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 27499 invoked by uid 89); 3 Sep 2013 10:48:28 -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; Tue, 03 Sep 2013 10:48:28 +0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2
X-HELO: mail.ecoscentric.com
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id BEF344680001; Tue,  3 Sep 2013 11:48:24 +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: [Bug 1001897] lpc2xxx CAN driver improvements / enhancements
Date: Tue, 03 Sep 2013 10:48:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: uwe_kindler@web.de
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-1001897-777-ertm1Wijaf@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001897-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001897-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00582.txt.bz2
Content-length: 3885

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

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

--- Comment #9 from Uwe Kindler <uwe_kindler@web.de> ---
> The manual is unclear: in some places it states that bus off is reached when
> the tx counter error is 255, and in what you show (in what is also in
> LPC17xx manual section 16.8.1), that bus off is reached only when the
> counter reaches 255+1.
> 
> For instance the definition of BS is:
> 
> "7 BS[6] Bus Status. 0 0
> 0 (Bus-On) The CAN Controller is involved in bus activities
> 1 (Bus-Off) The CAN controller is currently not involved/prohibited from bus
> activity
> because the Transmit Error Counter reached its limiting value of 255."
> 
> By readins this one could understand that BS is set when TEC reaches 255,
> but the complete bus off state is reached only when the counter is
> incremented another time.

The CAN standard from Bosch and also the manual of the LPC2xxx is clear in this
point:

Manual:
If the Transmit Error counter contains 255 and another error occurs, the CAN
Controller is forced into a state called Bus-Off.

This is also the same that is written here
http://www.kvaser.com/zh/about-can/the-can-protocol/23.html:
When any one of the two Error Counters raises above 127, the node will enter a
state known as Error Passive and when the Transmit Error Counter raises above
255, the node will enter the Bus Off state.

And that is how it is implemented in LPC2xxx CAN controller.



> "[6] Mode bit '1' (present) and an Error Warning Interrupt is generated, if
> enabled. Afterwards the Transmit Error Counter is set to '127', and
> the Receive Error Counter is cleared. It will stay in this mode until the
> CPU clears the Reset Mode bit. Once this is completed the CAN
> Controller will wait the minimum protocol-defined time (128 occurrences of
> the Bus-Free signal) counting down the Transmit Error
> Counter. After that, the Bus Status bit is cleared (Bus-On), the Error
> Status bit is set '0' (ok), the Error Counters are reset, and an Error
> Warning Interrupt is generated, if enabled. Reading the TX Error Counter
> during this time gives information about the status of the
> Bus-Off recovery."
> 
> Why did they wrote "afterwards" ? Does it mean that parts of the processing
> (TEC set to 127 and REC to zero) only occurs *after* the interrupt?

The LPC2xxx manual is more precise here:


--------------> manual snippet
If the Transmit Error counter contains 255 and another error occurs, the CAN
Controller is forced into a state called Bus-Off. In this state, the following
register bits are set: BS in CANSR, BEI and EI in CANIR if these are enabled,
and RM in CANMOD. RM resets and disables much of the´CAN Controller. Also at
this time the Transmit Error Counter is set to 127 and the Receive
Error Counter is cleared.
<--------------

So they write: "Also at this time the..." and not "afterwards"

> 
> If so a possibility of what you observe is that TEC reaches 255, BS is set
> to one, ISR is triggered, but TEC/REC aren't modified yet. RM is still zero
> since TEC just got 255, and didn't crossed yet 255+1 so full bus off isn't
> reached.

No. BS is set if TX counter raises above 255. 

> 
> What is the frequency of the ISR being triggered? Did you test how this
> frequency is related to the bus bit rate ? Just to know if when the ISR
> fires "again and again" it fires immediately one ISR after the other, or if
> there is time for 128 bus free bits on the bus...

As soon as DSR processing has finished and interrupt is unmasked at the end of
DSR via cyg_drv_interrupt_unmask, the ISR fires again. And that is normal
because Bus-Off condition still exists and RM (Reset Mode) is not activated and
BS in CANSR is still set.

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10552-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Sep 03 12:20:19 2013
Return-Path: <ecos-bugs-return-10552-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 10002 invoked by alias); 3 Sep 2013 12:20:19 -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 9953 invoked by uid 89); 3 Sep 2013 12:20:18 -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; Tue, 03 Sep 2013 12:20:18 +0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2
X-HELO: mail.ecoscentric.com
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 4E196468000F; Tue,  3 Sep 2013 13:20:15 +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: [Bug 1001897] lpc2xxx CAN driver improvements / enhancements
Date: Tue, 03 Sep 2013 12:20:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Patches and contributions
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: sergei.gavrikov@gmail.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: attachments.isobsolete
Message-ID: <bug-1001897-777-WqKSq0qmGd@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001897-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001897-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00583.txt.bz2
Content-length: 888

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

http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001897

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2352|0                           |1
        is obsolete|                            |

--- Comment #10 from Sergei Gavrikov <sergei.gavrikov@gmail.com> ---
Created attachment 2353
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id#53&actioníit
Force hadling "Bus-off" logic for some LPC22xx parts

This is cleaned up and a bit fixed version of attachment 2352.

NOTE: By default CDL option CYGHWR_DEVS_CAN_LPC2XXX_BUSOFF_WORKAROUND is set to
1 for "LPC22xx", and "LPC22xx/00" parts only.

--
You are receiving this mail because:
You are the assignee for the bug.