[Bug 1001435] CAN documentation (docs-latest) issues

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

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001435

--- Comment #6 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-10 16:27:57 GMT ---
I met other issues while porting the LPC2XXX CAN driver to LPC17XX.

These issues aren't related to the port itself, but by the CAN controller cell
from NXP, and can be solved by a bit of documentation, hence I report them
here:

1) missing flag bit definitions in CYPKG_IO_CAN

If the CAN controller reports that it has regained bus access (for instance it
leaves 'bus off' state) or if it reports that it's moving from ERROR PASSIVE to
ERROR ACTIVE state, there are no flags defined in CYGPKG_IO_CAN to describe
this: there are flags to report that the controller entered an error
state/level, but no flags to report that the error state/level is exited. 

However a major feature of the CAN bus is to define conditions to enter error
states/levels, and to automatically exit from these.

The event handler is called because it's in the event handler that the driver
processes the details of the different situations. When an error state/level is
exited, the controller state is set to 'ACTIVE', but no flags are raised.

The result is that the user callback function is triggered with a flag value of
zero, or an event obtained from cyg_io_read() can have a value of zero for its
'flags' field.

There are 3 solutions:

- add more flags, but since the 16 bits of an event flag are all used, this
means moving from a 16 bits value to represent flags to a 32 bits value. I'm
not sure this is a good short term solution, because if such flags are added,
then existing drivers must be modified to support these new flags. However not
supporting such an important feature of the CAN bus should be fixed
sometimes...

- have the driver to avoid reporting such events, but it does not seem good
either, because the user event handler won't be able to get all relevant events
from the controller, some events of importance will be magically discarded.

- document this as a 'feature':

"If the event callback function is triggered with a flag value of zero, or if
an event read from cyg_io_read() provides a value of zero for the flags, then
the user code must check the controller state because it may have changed. If
it's not the case, then the event can simply be discarded, it can have been
triggered by the underlying hardware without always useful at the application
level."

(English isn't my mother language, please reformulate!)

2) spurious interrupts

Doing many tests, I observed that sometimes an interrupt is triggered, but in
the DSR the interrupt cause has vanished. I think that I reach such weird
situations because the CPU is clocking slowly (16MHz) compared to the CAN bit
rate I use (500Kb/s).

The result is the same than above: an event with flags set to zero.

The only explanation I have is related to the way the Interrupt and Capture
register works (ICR) is designed: it is described as being made mostly of 'AND'
gates between interrupt sources and the Bit Stream Processor of the CAN
controller.

If the interrupt cause has disappeared when this register is read, then the
register bits are set to zero but for the RX interrupt. See bug #1001447 for
another reason to think that the AND gate logic has side effects not
sufficiently described in the datasheet.

Reading ICR in the ISR is not a good solution either, the issue is clearly time
related, so reading ICR in the ISR will only increase the chance to get the
interrupt source, but not to get it 100% of the time.

Anyway, the result is similar to the first point, and solution 3 really seems
to be the only reasonable solution. (For this particular case, I think I'll
offer a CDL option to filter such interrupts directly in the DSR since the
controller state did not change, and because the upper layer code has no mean
to understand what's going on.)

Comments welcome...

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
>From ecos-bugs-return-8648-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 16:28:24 2012
Return-Path: <ecos-bugs-return-8648-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 16013 invoked by alias); 10 Jan 2012 16:28:23 -0000
Received: (qmail 16005 invoked by uid 22791); 10 Jan 2012 16:28:22 -0000
X-SWARE-Spam-Status: No, hits=-1.3 required=5.0
	tests=AWL,BAYES_00,SARE_LWSHORTT,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Jan 2012 16:28:04 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id DB8552F78001; Tue, 10 Jan 2012 16:28:02 +0000 (GMT)
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 1001435] CAN documentation (docs-latest) issues
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: CAN
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001435-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001435-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Tue, 10 Jan 2012 16:28:00 -0000
Message-Id: <20120110162801.07D802F78001@mail.ecoscentric.com>
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
X-SW-Source: 2012/txt/msg00077.txt.bz2
Content-length: 4200

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001435

--- Comment #6 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-10 16:27:57 GMT ---
I met other issues while porting the LPC2XXX CAN driver to LPC17XX.

These issues aren't related to the port itself, but by the CAN controller cell
from NXP, and can be solved by a bit of documentation, hence I report them
here:

1) missing flag bit definitions in CYPKG_IO_CAN

If the CAN controller reports that it has regained bus access (for instance it
leaves 'bus off' state) or if it reports that it's moving from ERROR PASSIVE to
ERROR ACTIVE state, there are no flags defined in CYGPKG_IO_CAN to describe
this: there are flags to report that the controller entered an error
state/level, but no flags to report that the error state/level is exited. 

However a major feature of the CAN bus is to define conditions to enter error
states/levels, and to automatically exit from these.

The event handler is called because it's in the event handler that the driver
processes the details of the different situations. When an error state/level is
exited, the controller state is set to 'ACTIVE', but no flags are raised.

The result is that the user callback function is triggered with a flag value of
zero, or an event obtained from cyg_io_read() can have a value of zero for its
'flags' field.

There are 3 solutions:

- add more flags, but since the 16 bits of an event flag are all used, this
means moving from a 16 bits value to represent flags to a 32 bits value. I'm
not sure this is a good short term solution, because if such flags are added,
then existing drivers must be modified to support these new flags. However not
supporting such an important feature of the CAN bus should be fixed
sometimes...

- have the driver to avoid reporting such events, but it does not seem good
either, because the user event handler won't be able to get all relevant events
from the controller, some events of importance will be magically discarded.

- document this as a 'feature':

"If the event callback function is triggered with a flag value of zero, or if
an event read from cyg_io_read() provides a value of zero for the flags, then
the user code must check the controller state because it may have changed. If
it's not the case, then the event can simply be discarded, it can have been
triggered by the underlying hardware without always useful at the application
level."

(English isn't my mother language, please reformulate!)

2) spurious interrupts

Doing many tests, I observed that sometimes an interrupt is triggered, but in
the DSR the interrupt cause has vanished. I think that I reach such weird
situations because the CPU is clocking slowly (16MHz) compared to the CAN bit
rate I use (500Kb/s).

The result is the same than above: an event with flags set to zero.

The only explanation I have is related to the way the Interrupt and Capture
register works (ICR) is designed: it is described as being made mostly of 'AND'
gates between interrupt sources and the Bit Stream Processor of the CAN
controller.

If the interrupt cause has disappeared when this register is read, then the
register bits are set to zero but for the RX interrupt. See bug #1001447 for
another reason to think that the AND gate logic has side effects not
sufficiently described in the datasheet.

Reading ICR in the ISR is not a good solution either, the issue is clearly time
related, so reading ICR in the ISR will only increase the chance to get the
interrupt source, but not to get it 100% of the time.

Anyway, the result is similar to the first point, and solution 3 really seems
to be the only reasonable solution. (For this particular case, I think I'll
offer a CDL option to filter such interrupts directly in the DSR since the
controller state did not change, and because the upper layer code has no mean
to understand what's going on.)

Comments welcome...

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8650-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 18:44:27 2012
Return-Path: <ecos-bugs-return-8650-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6521 invoked by alias); 10 Jan 2012 18:44:25 -0000
Received: (qmail 6493 invoked by uid 22791); 10 Jan 2012 18:44:19 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Jan 2012 18:44:06 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 7DF752F78011
	for <ecos-bugs@ecos.sourceware.org>; Tue, 10 Jan 2012 18:44:05 +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 sZbJoPR+t2Rm; Tue, 10 Jan 2012 18:44:02 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001452] New: Select doesn't work correctly when Cyg_FlagValue
 > 32 bit
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Filesystem support
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: savin.zlobec@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:
Message-ID: <bug-1001452-13@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Tue, 10 Jan 2012 18:44:00 -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
X-SW-Source: 2012/txt/msg00079.txt.bz2
Content-length: 1181

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001452

           Summary: Select doesn't work correctly when Cyg_FlagValue > 32
                    bit
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: minor
          Priority: low
         Component: Filesystem support
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: savin.zlobec@gmail.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id\x1510)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id\x1510)
Fix for select() when Cyg_FlagValue > 32 bit

If eCos flags value is configured to be > 32 bits (CYGIMP_FLAGS_64BIT)
select() breaks if called from thread with id >= 32. Attached patch fixes this.
BTW since there is no regular way to change flags value size this is a no issue
for most.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.