public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
@ 2012-01-16 14:26 bugzilla-daemon
2012-01-24 16:11 ` [Bug 1001456] " bugzilla-daemon
` (7 more replies)
0 siblings, 8 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-01-16 14:26 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Summary: HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
Product: eCos
Version: CVS
Platform: Other (please specify)
OS/Version: Cortex-M
Status: UNCONFIRMED
Severity: major
Priority: low
Component: HAL
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: bernard.fouche@kuantic.com
CC: ecos-bugs@ecos.sourceware.org
Class: Advice Request
The way the Cortex-M3 manages peripheral interrupts require handling these
registers, otherwise an interrupt may be triggered multiple times.
I was looking for spurious interrupts on the LPC17XX CAN driver, and my error
was to skip handling of ICPR0 and ICPR1. The Cortex-M HAL must provide a
function like this:
//===========================================================================
// Clear pending interrupt.
//===========================================================================
__externC void hal_interrupt_clear_pending(cyg_uint32 vector )
{
HAL_WRITE_UINT32(
CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_CPR(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL),
CYGARC_REG_NVIC_IBIT(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL) );
}
This also means that when writing a driver, especially a driver with some kind
of FIFO mechanism, special care must be taken:
- it is impossible to have a general function able to fully acknowledge an
interrupt since the NVIC knows nothing of the inner details of all peripherals
and each peripheral is very different from the other. Hence
cyg_drv_interrupt_acknowledge() should not be used in Cortex-M drivers: it
resolves to an empty statement while letting the programmer think he/she had
done something useful while the situation is the exact opposite: nothing was
done, and an important step has been skipped. IMHO this function should
generate a message on diag_printf() and freeze the system (after some cdl
setting) on the Cortex arch.
- see next point why cyg_drv_interrupt_acknowledge() is different from the
function provided above: clearing the pending interrupt condition must be done
at a particular time, not at anytime during DSR processing, nor during ISR
processing. If the name 'acknowledge' is kept, it is likely that some design
flaw will occur in driver writing.
- when a driver reads a peripheral register to know what kind of job to do, the
corresponding ICPR register must be used to clear the pending interrupt state
first, before reading the driver specific interrupt register. Otherwise a race
condition may occur, at least in cases where the DSR is not looping until it
has completed everything that requires work to do: DSR clears reads the
peripheral register, thinks it knows everything, and just before clearing ICPR,
a new event occurs. By clearing ICPR at this time, an event may be missed
(depends probably of the kind of peripheral and of the way the MCU designed
cabler ICPR to the peripherals).
- IMHO it is necessary to have DSR to perform loops until they see no reason to
continue processing: a simple one time scanning of a peripheral with FIFO
registers will very probably lead to ISR/DSR being fired uselessly.
- even when doing loops but not handling ICPR, an other interrupt will be
triggered and in many cases the DSR will be fired just to discover that there
is nothing to do, the job has been done in the previous run. Sometimes I had
30% of the calls to the CAN DSR that were done without use, so it can be a real
waste.
- if the hardware has two different bits to reports two different conditions
(typically RX and Overrun), don't assume for instance that overrun shows up
only after a RX, unless explicitly stated in the datasheet. I've seen this on
the generic serial driver (made a report: bug #1001392 but nobody reacted about
it) and also on the CAN driver. This is because of the need to have loops in
DSR for efficient processing: if for some reasons the conditions are unrelated
but the code thinks they are, a loop based DSR may be stuck.
I did not investigate the generic serial driver behavior yet regarding ICPR but
I have seen ICPR issues on the SPI and CAN driver: I would be surprised to not
see this problem in the generic serial driver since it has a FIFO.
Checking the issue for any driver is rather simple: count the number of times
the DSR is fired without doing any processing. A non zero count means an ICPR
issue. The count value depends of a number of conditions hard to reproduce. For
instance an ISR may be fired 1000 times, the DSR 1032 times, it depends
entirely of what's going on the concerned peripheral, what the remote end is
doing, etc.
Conclusion:
- cyg_drv_interrupt_acknowledge() is misleading for Cortex-M.
- not handling IPCR -> wasted processing.
- handling IPCR incorrectly -> lost events.
- using a loop in a DSR that incorrect combines unrelated conditions -> stuck
program.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
@ 2012-01-24 16:11 ` bugzilla-daemon
2012-02-09 9:40 ` bugzilla-daemon
` (6 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-01-24 16:11 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 16:10:54 GMT ---
Some ASCII art to try to better explain the issue:
HW | E1 E2
---|----------------------------
ISR| I1 I2
---|----------------------------
DSR| D1 D2
E1: a 1st event occurs
I1: ISR related to E1 triggered, ISR masks interrupt and asks
for a DSR run.
E2: a 2nd event occurs but since interrupt is masked, pending
interrupt register bit is set and ISR is not run.
D1: DSR processes everything it can (for instance it empties a RX
FIFO). DSR unmasks interrupt at the end of processing.
I2: because E2 occurred while interrupt was masked and since
pending interrupt bit is set, I2 now occurs.
D2: DSR runs, and find no work to do because D1 did all the work.
In this example, there were 1 ISR (I2) and 1 DSR (D2) that ran for
nothing.
--
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-8696-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 16:11:24 2012
Return-Path: <ecos-bugs-return-8696-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29161 invoked by alias); 24 Jan 2012 16:11:20 -0000
Received: (qmail 29150 invoked by uid 22791); 24 Jan 2012 16:11:18 -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, 24 Jan 2012 16:11:05 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 75C031518931
for <ecos-bugs@ecos.sourceware.org>; Tue, 24 Jan 2012 16:11:04 +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 juX7TTrtVdqu; Tue, 24 Jan 2012 16:11:00 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
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:
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Tue, 24 Jan 2012 16:11:00 -0000
Message-Id: <20120124161100.0DD841518936@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/msg00125.txt.bz2
Content-length: 1180
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 16:10:54 GMT ---
Some ASCII art to try to better explain the issue:
HW | E1 E2
---|----------------------------
ISR| I1 I2
---|----------------------------
DSR| D1 D2
E1: a 1st event occurs
I1: ISR related to E1 triggered, ISR masks interrupt and asks
for a DSR run.
E2: a 2nd event occurs but since interrupt is masked, pending
interrupt register bit is set and ISR is not run.
D1: DSR processes everything it can (for instance it empties a RX
FIFO). DSR unmasks interrupt at the end of processing.
I2: because E2 occurred while interrupt was masked and since
pending interrupt bit is set, I2 now occurs.
D2: DSR runs, and find no work to do because D1 did all the work.
In this example, there were 1 ISR (I2) and 1 DSR (D2) that ran for
nothing.
--
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-8698-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 19:25:45 2012
Return-Path: <ecos-bugs-return-8698-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 29857 invoked by alias); 24 Jan 2012 19:25:43 -0000
Received: (qmail 29831 invoked by uid 22791); 24 Jan 2012 19:25:43 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
tests=AWL,BAYES_00,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, 24 Jan 2012 19:25:29 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
id D0F1315189C3; Tue, 24 Jan 2012 19:25:27 +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 1001453] CAN IO package: wider flags field, flag to report
return to 'error active' mode
X-Bugzilla-Reason: AssignedTo
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:
In-Reply-To: <bug-1001453-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001453-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, 24 Jan 2012 19:25:00 -0000
Message-Id: <20120124192524.E49D515189C3@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/msg00127.txt.bz2
Content-length: 2124
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001453
--- Comment #9 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-24 19:25:16 GMT ---
(In reply to comment #8)
>
> So far only one comment.
>
> Still try to be very careful when planning to change generic CAN I/O
> API. There is not only a dependence (LPC2XXX).
>
> % ecosconfig list | grep DEVS_CAN
> Package CYGPKG_DEVS_CAN_AT91SAM7 (AT91SAM7 CAN device drivers):
> Package CYGPKG_DEVS_CAN_LOOP (Loop CAN device drivers):
> Package CYGPKG_DEVS_CAN_LPC2XXX (LPC2xxx CAN device drivers):
> Package CYGPKG_DEVS_CAN_MCF52xx_FLEXCAN (MCF52xx FlexCAN device drivers):
>
> Sergei
I've seen this. The only change that impacts other packages is the
CYGNUM_CAN_EVENT_OVERRUN_RX event.
Today this event has two meaning: 1) because the eCos RX queue is overwritten
by a new message 2) a hardware related overrun. So when the event occurs, one
can't know if it's because the receive queue is undersized (or the application
is to slow to empty the queue), or if the driver isn't fast enough to process
CAN bus activity, which is very different. So I've made a
CYGNUM_CAN_EVENT_OVERRUN_RX_HW event for the second case.
I've modified the AT91SAM7 and MCF52XX driver accordingly (one line is patched
just to change the name of the event since this event is generated only in one
place. Since all CAN drivers have been written by Uwe Kindler and follow the
same logic it's easy to understand the code from a driver to the other).
LPC2XXX driver I'll patch without my other changes, so every driver will be
kept coherent with the CAN IO package.
The loop driver does not require any change since it does not handle hardware.
Everything else I added is supported by older driver since it's just a matter
of API convention defaulting to the set of features supported by older drivers.
--
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-8700-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 24 19:47:20 2012
Return-Path: <ecos-bugs-return-8700-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 2882 invoked by alias); 24 Jan 2012 19:47:19 -0000
Received: (qmail 2873 invoked by uid 22791); 24 Jan 2012 19:47:18 -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, 24 Jan 2012 19:46:59 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 5806715189D0
for <ecos-bugs@ecos.sourceware.org>; Tue, 24 Jan 2012 19:46:58 +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 uBYa+MwxE8VX; Tue, 24 Jan 2012 19:46:57 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
and NXP flash checksum
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ilijak@siva.com.mk
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Resolution
In-Reply-To: <bug-1001395-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001395-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, 24 Jan 2012 19:47:00 -0000
Message-Id: <20120124194656.BC17015189D5@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/msg00129.txt.bz2
Content-length: 689
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001395
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |CURRENTRELEASE
--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-24 19:46:53 GMT ---
Checked in.
--
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
2012-01-24 16:11 ` [Bug 1001456] " bugzilla-daemon
@ 2012-02-09 9:40 ` bugzilla-daemon
2012-02-09 11:30 ` bugzilla-daemon
` (5 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-02-09 9:40 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #4 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:39:50 GMT ---
Created an attachment (id=1570)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1570)
logic analyzer trace showing that interrupt_clear_pending() is badly needed for
Cortex-M core
--
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-8809-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:21 2012
Return-Path: <ecos-bugs-return-8809-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6797 invoked by alias); 9 Feb 2012 09:40:20 -0000
Received: (qmail 6788 invoked by uid 22791); 9 Feb 2012 09:40: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; Thu, 09 Feb 2012 09:40:03 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 7A5462F78006
for <ecos-bugs@ecos.sourceware.org>; Thu, 9 Feb 2012 09:40:02 +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 Ryf6XT3XlkjS; Thu, 9 Feb 2012 09:39:55 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
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:
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 09:40:00 -0000
Message-Id: <20120209093954.BCCD52F78004@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/msg00238.txt.bz2
Content-length: 595
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #4 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:39:50 GMT ---
Created an attachment (id=1570)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1570)
logic analyzer trace showing that interrupt_clear_pending() is badly needed for
Cortex-M core
--
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-8811-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:38 2012
Return-Path: <ecos-bugs-return-8811-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6970 invoked by alias); 9 Feb 2012 09:40:38 -0000
Received: (qmail 6958 invoked by uid 22791); 9 Feb 2012 09:40:37 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
tests=AWL,BAYES_00,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; Thu, 09 Feb 2012 09:40:24 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
id ED6252F78001; Thu, 9 Feb 2012 09:40:22 +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 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
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:
In-Reply-To: <bug-1001456-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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: Thu, 09 Feb 2012 09:40:00 -0000
Message-Id: <20120209094020.1E1C82F78001@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/msg00240.txt.bz2
Content-length: 2518
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:40:16 GMT ---
Final demonstration done with a logic analyzer on a serial channel. The trace
has been done with the fix described in bug #1001480 otherwise the result is
even worse.
More exactly, I applied the fix but I removed a call to
interrupt_clear_pending().
Trace description:
- channel 0: ISR: a GPIO pin is set a low level when entering ISR, to a high
level when ISR exits.
- channel 1: a GPIO pin changes of state each time the DSR runs without doing
any processing.
- channel 2: DSR: a GPIO pin is set a low level when entering DSR, to a high
level when DSR exits.
- channel 3: start_xmit: a GPIO pin is set a low level when entering
start_xmit(), to a high level when start_xmit() exits.
- the other channels show serial link activity (RTS/TX/RX/CTS)
What the trace shows:
- start_xmit() is called, the fix described in bug #1001480 makes this function
to first fill the TX FIFO before activating the TX interrupt.
- 'A' is clocked out on the serial link. When it is nearly completely output,
TX interrupt fires ISR.
- ISR (first run) masks interrupt (so the interrupt is disabled), and return
value tells eCos to post DSR. However the interrupt source hasn't been
processed yet in the concerned peripheral, so the Cortex-M core raises the
interrupt pending bit!
- DSR is fired (first run). It sees that it was triggered because of a TX int,
however there is no more byte to output at that time. DSR unmask interrupts but
pending interrupts for that vector where not cleared: a new ISR is fired during
DSR execution.
- ISR (second run) does as always: mask interrupt, post DSR.
- Note that during the first DSR run, the 'flip/flop' reporting DSR running for
nothing wasn't toggled at this time: this is because the DSR did real work: it
processed the TX int.
- as soon as DSR ends, because of the intermediary ISR that occurred while DSR
was running, DSR runs again (second run).
- however there is nothing to do since latest ISR/DSR did the TX interrupt
processing job: flip/flop pin shows that DSR did nothing.
I don't have any feedback from any eCos maintainer... what's going on :-) ?
--
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-8812-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 09:40:39 2012
Return-Path: <ecos-bugs-return-8812-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 6997 invoked by alias); 9 Feb 2012 09:40:38 -0000
Received: (qmail 6960 invoked by uid 22791); 9 Feb 2012 09:40:37 -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; Thu, 09 Feb 2012 09:40:23 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 410DD2F78005
for <ecos-bugs@ecos.sourceware.org>; Thu, 9 Feb 2012 09:40:22 +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 Yh8hLMNdGDRj; Thu, 9 Feb 2012 09:40:20 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
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:
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Thu, 09 Feb 2012 09:40:00 -0000
Message-Id: <20120209094020.48EE62F78004@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/msg00241.txt.bz2
Content-length: 2520
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-09 09:40:16 GMT ---
Final demonstration done with a logic analyzer on a serial channel. The trace
has been done with the fix described in bug #1001480 otherwise the result is
even worse.
More exactly, I applied the fix but I removed a call to
interrupt_clear_pending().
Trace description:
- channel 0: ISR: a GPIO pin is set a low level when entering ISR, to a high
level when ISR exits.
- channel 1: a GPIO pin changes of state each time the DSR runs without doing
any processing.
- channel 2: DSR: a GPIO pin is set a low level when entering DSR, to a high
level when DSR exits.
- channel 3: start_xmit: a GPIO pin is set a low level when entering
start_xmit(), to a high level when start_xmit() exits.
- the other channels show serial link activity (RTS/TX/RX/CTS)
What the trace shows:
- start_xmit() is called, the fix described in bug #1001480 makes this function
to first fill the TX FIFO before activating the TX interrupt.
- 'A' is clocked out on the serial link. When it is nearly completely output,
TX interrupt fires ISR.
- ISR (first run) masks interrupt (so the interrupt is disabled), and return
value tells eCos to post DSR. However the interrupt source hasn't been
processed yet in the concerned peripheral, so the Cortex-M core raises the
interrupt pending bit!
- DSR is fired (first run). It sees that it was triggered because of a TX int,
however there is no more byte to output at that time. DSR unmask interrupts but
pending interrupts for that vector where not cleared: a new ISR is fired during
DSR execution.
- ISR (second run) does as always: mask interrupt, post DSR.
- Note that during the first DSR run, the 'flip/flop' reporting DSR running for
nothing wasn't toggled at this time: this is because the DSR did real work: it
processed the TX int.
- as soon as DSR ends, because of the intermediary ISR that occurred while DSR
was running, DSR runs again (second run).
- however there is nothing to do since latest ISR/DSR did the TX interrupt
processing job: flip/flop pin shows that DSR did nothing.
I don't have any feedback from any eCos maintainer... what's going on :-) ?
--
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-8814-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 11:30:47 2012
Return-Path: <ecos-bugs-return-8814-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 21275 invoked by alias); 9 Feb 2012 11:30:47 -0000
Received: (qmail 21256 invoked by uid 22791); 9 Feb 2012 11:30:46 -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; Thu, 09 Feb 2012 11:30:27 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 3448C2F78001
for <ecos-bugs@ecos.sourceware.org>; Thu, 9 Feb 2012 11:30:26 +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 TcQdyJSpHJap; Thu, 9 Feb 2012 11:30:25 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ilijak@siva.com.mk
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
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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: Thu, 09 Feb 2012 11:30:00 -0000
Message-Id: <20120209113024.5D0012F78005@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/msg00243.txt.bz2
Content-length: 925
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001456
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ilijak@siva.com.mk
--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-09 11:30:20 GMT ---
(In reply to comment #5)
> I don't have any feedback from any eCos maintainer... what's going on :-) ?
Hi Bernard
I am following your posts, but I am little-bit busy so I can't respond. My plan
is to try to reproduce your cases on Kinetis and compare. I hope to have more
time following week.
Ilija
--
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
2012-01-24 16:11 ` [Bug 1001456] " bugzilla-daemon
2012-02-09 9:40 ` bugzilla-daemon
@ 2012-02-09 11:30 ` bugzilla-daemon
2012-02-16 15:30 ` bugzilla-daemon
` (4 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-02-09 11:30 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ilijak@siva.com.mk
--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-09 11:30:20 GMT ---
(In reply to comment #5)
> I don't have any feedback from any eCos maintainer... what's going on :-) ?
Hi Bernard
I am following your posts, but I am little-bit busy so I can't respond. My plan
is to try to reproduce your cases on Kinetis and compare. I hope to have more
time following week.
Ilija
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
` (2 preceding siblings ...)
2012-02-09 11:30 ` bugzilla-daemon
@ 2012-02-16 15:30 ` bugzilla-daemon
2012-02-23 9:58 ` bugzilla-daemon
` (3 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-02-16 15:30 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-16 15:29:18 GMT ---
(In reply to comment #14)
> (In reply to comment #13)
> > Changes to the Kernel should be done with caution. I think that this addition
> > is not necessary. The desired functionality, for a given platform, can be
> > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
>
> There are two problems:
>
> - clearing the pending interrupt bit is completely different from acknowledging
> an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> clearing the pending interrupt bit must be done *before* reading the peripheral
> registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> a solution.
>
> - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> how can one share a driver between an arch not requiring clearing pending
> interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> correct place so the driver can work in different arch.
Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
interrupts. Here is what's Cortex-M NVIC doc saying about it.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html
Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
do it on LPC17xx variant or, if the problem appears on other variants consider
Cortex-M architecture level, and avoid patching kernel files. FYI as i
mentioned earlier I'll do some tests on Kinetis during next week.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
` (3 preceding siblings ...)
2012-02-16 15:30 ` bugzilla-daemon
@ 2012-02-23 9:58 ` bugzilla-daemon
2012-04-02 21:22 ` bugzilla-daemon
` (2 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-02-23 9:58 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-23 09:58:31 GMT ---
(In reply to comment #17)
> If you have at hand "The definitive guide to the ARM Cortex-M3" by Joseph Yiu:
> see chapter 7, "Interrupt Inputs and Pending Behavior" section, especially
> figure 7.13, this is exactly what I observed.
I guess that in context of this bug you probably mean fig 7.14. (i guess the
number at the bottom of fig.).
For solution I would return to cyg_drv_interrupt_acknowledge() since that's
what it's supposed to do: "Perform any processing required at the interrupt
controller and in the CPU to cancel the current interrupt request on the
vector. An ISR may also need to program the hardware of the device to prevent
an immediate re-triggering of the interrupt."
Only, it should be called later than it is called now. I acknowledge your
concern about generic serial driver but it has some conditional code already so
adding little-bit more wouldn't harm (or IMO the impact will be lower than
adding functions on Kernel level).
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
` (4 preceding siblings ...)
2012-02-23 9:58 ` bugzilla-daemon
@ 2012-04-02 21:22 ` bugzilla-daemon
2012-09-26 16:15 ` bugzilla-daemon
2012-09-26 21:44 ` bugzilla-daemon
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-04-02 21:22 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Jonathan Larmour <jifl@ecoscentric.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickg@ecoscentric.com
--- Comment #22 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-02 22:22:16 BST ---
Any changes in this area to either Cortex-M arch HAL or the kernel, especially
the API, would definitely need to be approved by Nick. I'm adding him to CC.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
` (5 preceding siblings ...)
2012-04-02 21:22 ` bugzilla-daemon
@ 2012-09-26 16:15 ` bugzilla-daemon
2012-09-26 21:44 ` bugzilla-daemon
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-09-26 16:15 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Phil <pme.neratec@gmx.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pme.neratec@gmx.ch
--- Comment #24 from Phil <pme.neratec@gmx.ch> 2012-09-26 17:15:10 BST ---
If the situation is as described by Bernard Fouché, this means eCos is not well
suited for Cortex-M3 (e.g. STM32 or LPC17xx) platform!
Why is no eCos proponent reacting on this bug?
When is the NVIC_ClearPendingIRQ function needed, only if this is an external
interrupt that needs to be handled?
@Bernard Fouché: In the Cortex-M3 (e.g. STM32 or LPC17xx) the processor
automatically clears the pending bit when it calls the interrupt handler (see
STM32 Programming Manual (CD00228163.pdf) page 128, "A pending interrupt
remains pending until one of the following: The processor enters the ISR for
the interrupt..."). Why do you think this must be done programmatically?
--
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-9831-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Sep 26 16:15:45 2012
Return-Path: <ecos-bugs-return-9831-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 1966 invoked by alias); 26 Sep 2012 16:15:40 -0000
Received: (qmail 1828 invoked by uid 22791); 26 Sep 2012 16:15:37 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
tests=AWL,BAYES_00,KHOP_THREADED
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; Wed, 26 Sep 2012 16:15:25 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id E2BF22F7800A
for <ecos-bugs@ecos.sourceware.org>; Wed, 26 Sep 2012 17:15:23 +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 BEdTduubPtcB; Wed, 26 Sep 2012 17:15:23 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: pme.neratec@gmx.ch
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
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Wed, 26 Sep 2012 16:15:00 -0000
Message-Id: <20120926161515.879072FB082C@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/msg01260.txt.bz2
Content-length: 1302
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Phil <pme.neratec@gmx.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pme.neratec@gmx.ch
--- Comment #24 from Phil <pme.neratec@gmx.ch> 2012-09-26 17:15:10 BST ---
If the situation is as described by Bernard Fouché, this means eCos is not well
suited for Cortex-M3 (e.g. STM32 or LPC17xx) platform!
Why is no eCos proponent reacting on this bug?
When is the NVIC_ClearPendingIRQ function needed, only if this is an external
interrupt that needs to be handled?
@Bernard Fouché: In the Cortex-M3 (e.g. STM32 or LPC17xx) the processor
automatically clears the pending bit when it calls the interrupt handler (see
STM32 Programming Manual (CD00228163.pdf) page 128, "A pending interrupt
remains pending until one of the following: The processor enters the ISR for
the interrupt..."). Why do you think this must be done programmatically?
--
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-9833-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Sep 26 21:44:14 2012
Return-Path: <ecos-bugs-return-9833-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 26184 invoked by alias); 26 Sep 2012 21:44:14 -0000
Received: (qmail 26175 invoked by uid 22791); 26 Sep 2012 21:44:13 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0
tests=AWL,BAYES_00,KHOP_THREADED
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; Wed, 26 Sep 2012 21:44:00 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id ED56E2F7800D
for <ecos-bugs@ecos.sourceware.org>; Wed, 26 Sep 2012 22:43:58 +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 WcK9fYMVXz8X; Wed, 26 Sep 2012 22:43:58 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: jifl@ecoscentric.com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: nickg@ecoscentric.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status CC AssignedTo Ever Confirmed
In-Reply-To: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-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: Wed, 26 Sep 2012 21:44:00 -0000
Message-Id: <20120926214356.A74FF2FB082C@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/msg01262.txt.bz2
Content-length: 1491
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001456
Jonathan Larmour <jifl@ecoscentric.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
CC| |jifl@ecoscentric.com
AssignedTo|unassigned@bugs.ecos.source |nickg@ecoscentric.com
|ware.org |
Ever Confirmed|0 |1
--- Comment #25 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 22:43:50 BST ---
I still think this needs to be commented on by Nick as it involves a
significant change to the HAL definition, and he's both the HAL in general and
specifically Cortex-M HAL architect. So I'm assigning this to him and see if he
grumbles :-). He can always assign it away if he's not interested in commenting
on the API change.
But I wouldn't overstate the problem, as far I can tell this will only happen
with certain designs of devices, and only then if certain situations combine,
which therefore makes it uncommon. That's not to say it's irrelevant, but it's
not like it happens every interrupt or anything like that.
--
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
` (6 preceding siblings ...)
2012-09-26 16:15 ` bugzilla-daemon
@ 2012-09-26 21:44 ` bugzilla-daemon
7 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-09-26 21:44 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Jonathan Larmour <jifl@ecoscentric.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
CC| |jifl@ecoscentric.com
AssignedTo|unassigned@bugs.ecos.source |nickg@ecoscentric.com
|ware.org |
Ever Confirmed|0 |1
--- Comment #25 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 22:43:50 BST ---
I still think this needs to be commented on by Nick as it involves a
significant change to the HAL definition, and he's both the HAL in general and
specifically Cortex-M HAL architect. So I'm assigning this to him and see if he
grumbles :-). He can always assign it away if he's not interested in commenting
on the API change.
But I wouldn't overstate the problem, as far I can tell this will only happen
with certain designs of devices, and only then if certain situations combine,
which therefore makes it uncommon. That's not to say it's irrelevant, but it's
not like it happens every interrupt or anything like that.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power
@ 2012-01-16 14:26 bugzilla-daemon
0 siblings, 0 replies; 10+ messages in thread
From: bugzilla-daemon @ 2012-01-16 14:26 UTC (permalink / raw)
To: ecos-bugs
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456
Summary: HAL misses Interrupt Clear-Pending Registers handling:
wasted processing power
Product: eCos
Version: CVS
Platform: Other (please specify)
OS/Version: Cortex-M
Status: UNCONFIRMED
Severity: major
Priority: low
Component: HAL
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: bernard.fouche@kuantic.com
CC: ecos-bugs@ecos.sourceware.org
Class: Advice Request
The way the Cortex-M3 manages peripheral interrupts require handling these
registers, otherwise an interrupt may be triggered multiple times.
I was looking for spurious interrupts on the LPC17XX CAN driver, and my error
was to skip handling of ICPR0 and ICPR1. The Cortex-M HAL must provide a
function like this:
//===========================================================================
// Clear pending interrupt.
//===========================================================================
__externC void hal_interrupt_clear_pending(cyg_uint32 vector )
{
HAL_WRITE_UINT32(
CYGARC_REG_NVIC_BASE+CYGARC_REG_NVIC_CPR(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL),
CYGARC_REG_NVIC_IBIT(vector-CYGNUM_HAL_INTERRUPT_EXTERNAL) );
}
This also means that when writing a driver, especially a driver with some kind
of FIFO mechanism, special care must be taken:
- it is impossible to have a general function able to fully acknowledge an
interrupt since the NVIC knows nothing of the inner details of all peripherals
and each peripheral is very different from the other. Hence
cyg_drv_interrupt_acknowledge() should not be used in Cortex-M drivers: it
resolves to an empty statement while letting the programmer think he/she had
done something useful while the situation is the exact opposite: nothing was
done, and an important step has been skipped. IMHO this function should
generate a message on diag_printf() and freeze the system (after some cdl
setting) on the Cortex arch.
- see next point why cyg_drv_interrupt_acknowledge() is different from the
function provided above: clearing the pending interrupt condition must be done
at a particular time, not at anytime during DSR processing, nor during ISR
processing. If the name 'acknowledge' is kept, it is likely that some design
flaw will occur in driver writing.
- when a driver reads a peripheral register to know what kind of job to do, the
corresponding ICPR register must be used to clear the pending interrupt state
first, before reading the driver specific interrupt register. Otherwise a race
condition may occur, at least in cases where the DSR is not looping until it
has completed everything that requires work to do: DSR clears reads the
peripheral register, thinks it knows everything, and just before clearing ICPR,
a new event occurs. By clearing ICPR at this time, an event may be missed
(depends probably of the kind of peripheral and of the way the MCU designed
cabler ICPR to the peripherals).
- IMHO it is necessary to have DSR to perform loops until they see no reason to
continue processing: a simple one time scanning of a peripheral with FIFO
registers will very probably lead to ISR/DSR being fired uselessly.
- even when doing loops but not handling ICPR, an other interrupt will be
triggered and in many cases the DSR will be fired just to discover that there
is nothing to do, the job has been done in the previous run. Sometimes I had
30% of the calls to the CAN DSR that were done without use, so it can be a real
waste.
- if the hardware has two different bits to reports two different conditions
(typically RX and Overrun), don't assume for instance that overrun shows up
only after a RX, unless explicitly stated in the datasheet. I've seen this on
the generic serial driver (made a report: bug #1001392 but nobody reacted about
it) and also on the CAN driver. This is because of the need to have loops in
DSR for efficient processing: if for some reasons the conditions are unrelated
but the code thinks they are, a loop based DSR may be stuck.
I did not investigate the generic serial driver behavior yet regarding ICPR but
I have seen ICPR issues on the SPI and CAN driver: I would be surprised to not
see this problem in the generic serial driver since it has a FIFO.
Checking the issue for any driver is rather simple: count the number of times
the DSR is fired without doing any processing. A non zero count means an ICPR
issue. The count value depends of a number of conditions hard to reproduce. For
instance an ISR may be fired 1000 times, the DSR 1032 times, it depends
entirely of what's going on the concerned peripheral, what the remote end is
doing, etc.
Conclusion:
- cyg_drv_interrupt_acknowledge() is misleading for Cortex-M.
- not handling IPCR -> wasted processing.
- handling IPCR incorrectly -> lost events.
- using a loop in a DSR that incorrect combines unrelated conditions -> stuck
program.
--
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-09-26 21:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-16 14:26 [Bug 1001456] New: HAL misses Interrupt Clear-Pending Registers handling: wasted processing power bugzilla-daemon
2012-01-24 16:11 ` [Bug 1001456] " bugzilla-daemon
2012-02-09 9:40 ` bugzilla-daemon
2012-02-09 11:30 ` bugzilla-daemon
2012-02-16 15:30 ` bugzilla-daemon
2012-02-23 9:58 ` bugzilla-daemon
2012-04-02 21:22 ` bugzilla-daemon
2012-09-26 16:15 ` bugzilla-daemon
2012-09-26 21:44 ` bugzilla-daemon
-- strict thread matches above, loose matches on Subject: below --
2012-01-16 14:26 [Bug 1001456] New: " bugzilla-daemon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).