From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27101 invoked by alias); 3 Sep 2013 10:48:24 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 27088 invoked by uid 89); 3 Sep 2013 10:48:24 -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:24 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: mail.ecoscentric.com Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id D6A924680012 for ; Tue, 3 Sep 2013 11:48:19 +0100 (BST) 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 91uuFJqwPLjd; Tue, 3 Sep 2013 11:48:15 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001897] lpc2xxx CAN driver improvements / enhancements Date: Tue, 03 Sep 2013 10:48:00 -0000 X-Bugzilla-Reason: CC 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: In-Reply-To: References: 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-09/txt/msg00007.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001897 --- Comment #9 from Uwe Kindler --- > The manual is unclear: in some places it states that bus off is reached w= hen > 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. >=20 > For instance the definition of BS is: >=20 > "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." >=20 > 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 ente= r a state known as Error Passive and when the Transmit Error Counter raises abo= ve 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." >=20 > Why did they wrote "afterwards" ? Does it mean that parts of the processi= ng > (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 follow= ing register bits are set: BS in CANSR, BEI and EI in CANIR if these are enable= d, and RM in CANMOD. RM resets and disables much of the=C2=B4CAN Controller. A= lso 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" >=20 > 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 ze= ro > 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.=20 >=20 > 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. --=20 You are receiving this mail because: You are on the CC list for the bug.