From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6796 invoked by alias); 3 Sep 2013 09:06: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 6783 invoked by uid 89); 3 Sep 2013 09:06: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 09:06: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 D0609468000F for ; Tue, 3 Sep 2013 10:06: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 xOBm0PyQwfGu; Tue, 3 Sep 2013 10:06:14 +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 09:06: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: 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: 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/msg00006.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001897 --- Comment #8 from Bernard Fouch=C3=A9 --- (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 LPC17= xx manual section 16.8.1), that bus off is reached only when the counter reach= es 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, b= ut the complete bus off state is reached only when the counter is incremented another time. >=20 > That means:=20 >=20 > 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. >=20 > 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 outpu= t I > can see the following: >=20 > 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. >=20 > 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 olim= ex > 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 process= ing > has finished. This will block application from running because the ISR /D= SR > code will fire again and again. So my patch simply does, what it is writt= en > 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 C= PU 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 Stat= us bit is set '0' (ok), the Error Counters are reset, and an Error Warning Interrupt is generated, if enabled. Reading the TX Error Counter du= ring 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 si= nce TEC just got 255, and didn't crossed yet 255+1 so full bus off isn't reache= d. In the meaning time the bus is idle (AFAIK when you debug the CAN cell is s= till 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 b= us can't handle recessive bits, etc. From that moment TEC goes up, until the I= SR 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 fir= es "again and again" it fires immediately one ISR after the other, or if there= is time for 128 bus free bits on the bus... --=20 You are receiving this mail because: You are on the CC list for the bug.