From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1865 invoked by alias); 30 Aug 2013 14:27:45 -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 1851 invoked by uid 89); 30 Aug 2013 14:27:45 -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; Fri, 30 Aug 2013 14:27:45 +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 D62A7468001F for ; Fri, 30 Aug 2013 15:27:40 +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 DvVwigLeX32S; Fri, 30 Aug 2013 15:27:38 +0100 (BST) 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 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: cc 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-08/txt/msg00020.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001897 Bernard Fouch=C3=A9 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernard.fouche@kuantic.com --- Comment #2 from Bernard Fouch=C3=A9 --- 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 counte= rs 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 call= ed 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 control= ler // is in TX error passive mode and that it does not flood the C= AN // 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 cle= ars the TX buffer that made the controller to go into BUS OFF mode and the DSR/application isn't made aware of this. --=20 You are receiving this mail because: You are on the CC list for the bug.