[Bug 1001897] lpc2xxx CAN driver improvements / enhancements

[bugzilla-daemon@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

--- Comment #28 from Bernard Fouché <bernard.fouche@kuantic.com> ---
(In reply to comment #27)
> > Sorry, it took me ages to be able to go back to that topic.
> 
> Hi Bernard,
> 
> thank you for taking the time investigating this problem. 
> 
> > On the LPC1765, I just did something a bit different than what you wrote, I
> > unplugged the resistor on the CAN wires. Then I got BEI (Bus Error
> > Interrupt) in CAN1ICR.
> 
> what happpens if you do the same thing that I do - simply disconnect from
> CAN bus?

I can't do this, on my target the same connector provides power supply and CAN
connectivity :-(

However the only difference should be the length of wire after the CAN
transceiver.

Since you say that you also see BEI raised, maybe the problem you have is the
same than mine, you are stuck with a broken bus, not a real bus off condition
and that would explain why you don't see the documented behavior for bus off.

Did you try to xmit on a correct bus with no other node to acknowledge the
frames? If so, were you stuck on the ISR following this "bus off" condition?

> 
> > All in all I think it is better to have this kind of processing (taking the
> > decision to reset the CAN controller) to be handled by higher level code
> > instead of having the ISR or DSR to magically do things.
> 
> My patch does no do any magically things in ISR and DSR. It does exactly the
> thing that the hadware manual claims the CAN controller would do. So my
> implementation does something the CAN controller would do anyway.

On the LPC1765 datasheet, it is stated that if TxREC reaches 255 you enter bus
off mode and that means waiting 128 occurrences of Bus Free Condition when RM
is back to zero. If you write a value between 0 and 254, then only a single
occurrence of Bus Free Condition is waited for, whatever the value set in
TxREC.

If it is similar on LPC22xx it means you can't completely simulate the
hardware: writing 127 just set TxREC to the value it has when bus off is
generated by the hardware but not the full behavior (waiting 128 occurrences of
Bus Free Condition).

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10608-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sun Nov 10 18:33:21 2013
Return-Path: <ecos-bugs-return-10608-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 19481 invoked by alias); 10 Nov 2013 18:33:21 -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 19473 invoked by uid 89); 10 Nov 2013 18:33:20 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_20,RDNS_NONE autolearn=no version=3.3.2
X-HELO: mail.ecoscentric.com
Received: from Unknown (HELO mail.ecoscentric.com) (212.13.207.197)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 10 Nov 2013 18:31:27 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 5081B4680002
	for <ecos-bugs@ecos.sourceware.org>; Sun, 10 Nov 2013 18:31:18 +0000 (GMT)
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 1s-8iX4OB-KO; Sun, 10 Nov 2013 18:31:17 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001913] New: Calling restart_rx outside
 cyg_drv_dsr_lock/unlock in serial_get_config: possibly a race condition?
Date: Sun, 10 Nov 2013 18:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Serial
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vlad_a_pudovkin@hotmail.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: bug_id short_desc product version rep_platform
 op_sys bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-1001913-13@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/msg00639.txt.bz2
Content-length: 1518

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

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

            Bug ID: 1001913
           Summary: Calling restart_rx outside cyg_drv_dsr_lock/unlock in
                    serial_get_config: possibly a race condition?
           Product: eCos
           Version: 3.0
            Target: All
  Architecture/Host All
                OS:
            Status: UNCONFIRMED
          Severity: normal
          Priority: low
         Component: Serial
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: vlad_a_pudovkin@hotmail.com
                CC: ecos-bugs@ecos.sourceware.org

I'm not quite sure this is a bug, but this snippet below seems to be the only
place in the serial IO code where restart_rx (and the data it accesses) is used
outside of the cyg_drv_dsr_lock/unlock pair, which just stood out for me:

// File: packages/io/serial/<version>/src/common/serial.c
// Function: serial_get_config

        * * *
        cyg_drv_dsr_unlock();
        cyg_drv_mutex_unlock(&in_cbuf->lock);
#ifdef CYGPKG_IO_SERIAL_FLOW_CONTROL
        // Restart receiver if it was shutdown
        if ((chan->flow_desc.flags & CYG_SERIAL_FLOW_IN_THROTTLED) != 0) {
            restart_rx( chan, false );
        }
#endif


Wouldn't it be more correct (or at least more consistent) to move this
if-statement right prior to unlocking the DSRs and the mutex? If not, why?

--
You are receiving this mail because:
You are on the CC list for the bug.