[Bug 1001463] New: LPC17XX supplementary code/option patch

[Bug 1001463] New: LPC17XX supplementary code/option patch

[bugzilla-daemon]

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

           Summary: LPC17XX supplementary code/option patch
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Hello.

This patch:

- allows configuration of all peripheral clocks.
- use the fractional baud rate divider for all UART, for all possible clocks
>300bps.
- using PLL0 is an option.
- using USB clock is an option.
- consider all LPC MCU known to have CAN bus support
- fixes some erroneous peripheral definitions and adds new ones
- brings the bit band macro in the LPC17XX code. Debate about where to define
these macros is not closed yet but I need to move on so better defining them
here at the moment ;-)

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

[Bug 1001463] LPC17XX supplementary code/option patch

[bugzilla-daemon]

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

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-25 16:18:31 GMT ---
Created an attachment (id=1533)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1533)
more peripheral options/handling patch

-- 
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-8714-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jan 25 17:54:37 2012
Return-Path: <ecos-bugs-return-8714-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 11551 invoked by alias); 25 Jan 2012 17:54:36 -0000
Received: (qmail 11518 invoked by uid 22791); 25 Jan 2012 17:54:35 -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; Wed, 25 Jan 2012 17:54:20 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 955812F78001; Wed, 25 Jan 2012 17:54:19 +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: Wed, 25 Jan 2012 17:54:00 -0000
Message-Id: <20120125175416.E5A7C2F78001@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/msg00143.txt.bz2
Content-length: 3758

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

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-25 17:54:10 GMT ---
Yet more information about this issue. I found relevant information in the
LPC17XX data sheet (UM10360). It is an excerpt from ARM documentation. Here it
is:

-----------------------
34.4.2.9.1 Hardware and software control of interrupts

The Cortex-M3 latches all interrupts. A peripheral interrupt becomes pending
for one of the following reasons:

• the NVIC detects that the interrupt signal is HIGH and the interrupt is not
active

• the NVIC detects a rising edge on the interrupt signal

• software writes to the corresponding interrupt set-pending register bit, see
Table 648, or to the STIR to make an SGI pending, see Table 652.

A pending interrupt remains pending until one of the following:

• The processor enters the ISR for the interrupt. This changes the state of the 
interrupt from pending to active. Then:

– For a level-sensitive interrupt, when the processor returns from the ISR, the
NVIC samples the interrupt signal. If the signal is asserted, the state of the
interrupt changes to pending, which might cause the processor to immediately
re-enter the ISR. Otherwise, the state of the interrupt changes to inactive.

– For a pulse interrupt, the NVIC continues to monitor the interrupt signal,
and if this is pulsed the state of the interrupt changes to pending and active.
In this case, when the processor returns from the ISR the state of the
interrupt changes to pending, which might cause the processor to immediately
re-enter the ISR.

  If the interrupt signal is not pulsed while the processor is in the ISR, when
the processor returns from the ISR the state of the interrupt changes to
inactive.

• Software writes to the corresponding interrupt clear-pending register bit.

For a level-sensitive interrupt, if the interrupt signal is still asserted, the
state of the interrupt does not change. Otherwise, the state of the interrupt
changes to inactive.

For a pulse interrupt, state of the interrupt changes to:
– inactive, if the state was pending
– active, if the state was active and pending.
-----------------------

An then the next section (34.4.2.10: NVIC design hints and tips) has this
sentence:

   An interrupt can enter pending state even it is disabled.

On cortex M3 HAL, cyg_drv_interrupt_mask() uses registers ICER0-3 to disable
the interrupt concerned, so we are clearly in this case: an interrupt is
disabled, but nothing is done to manage the pending state that will be raised
between the ISR run and the DSR run.

IMHO this is the full explanation of the behavior I've seen and continue to see
in drivers that do not take any precaution to clear the pending state of the
interrupt involved.

NXP does not document for each peripheral if it works with 'level' or 'pulse'
interrupt logic, but anyway the result is the same: the DSR must be able to
manage an interrupt pending state.

This is also a problem for shared drivers, like the generic serial driver
because the change must also be inserted in such a driver.

I understand this issue is a pain to manage since it breaks parts of the
generic interrupt handling in eCos, but I can't believe eCos can stick with its
current interrupt model (and face sometimes more than 100% interrupt overhead)
because the Cortex-M arch is becoming mainstream.

-- 
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-8713-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jan 25 17:54:36 2012
Return-Path: <ecos-bugs-return-8713-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 11521 invoked by alias); 25 Jan 2012 17:54:35 -0000
Received: (qmail 11434 invoked by uid 22791); 25 Jan 2012 17:54:33 -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; Wed, 25 Jan 2012 17:54:20 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id C8D6B2F78005
	for <ecos-bugs@ecos.sourceware.org>; Wed, 25 Jan 2012 17:54: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 xmqjw00gt+5e; Wed, 25 Jan 2012 17:54:17 +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: Wed, 25 Jan 2012 17:54:00 -0000
Message-Id: <20120125175417.1CB952F78003@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/msg00142.txt.bz2
Content-length: 3760

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

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-25 17:54:10 GMT ---
Yet more information about this issue. I found relevant information in the
LPC17XX data sheet (UM10360). It is an excerpt from ARM documentation. Here it
is:

-----------------------
34.4.2.9.1 Hardware and software control of interrupts

The Cortex-M3 latches all interrupts. A peripheral interrupt becomes pending
for one of the following reasons:

• the NVIC detects that the interrupt signal is HIGH and the interrupt is not
active

• the NVIC detects a rising edge on the interrupt signal

• software writes to the corresponding interrupt set-pending register bit, see
Table 648, or to the STIR to make an SGI pending, see Table 652.

A pending interrupt remains pending until one of the following:

• The processor enters the ISR for the interrupt. This changes the state of the 
interrupt from pending to active. Then:

– For a level-sensitive interrupt, when the processor returns from the ISR, the
NVIC samples the interrupt signal. If the signal is asserted, the state of the
interrupt changes to pending, which might cause the processor to immediately
re-enter the ISR. Otherwise, the state of the interrupt changes to inactive.

– For a pulse interrupt, the NVIC continues to monitor the interrupt signal,
and if this is pulsed the state of the interrupt changes to pending and active.
In this case, when the processor returns from the ISR the state of the
interrupt changes to pending, which might cause the processor to immediately
re-enter the ISR.

  If the interrupt signal is not pulsed while the processor is in the ISR, when
the processor returns from the ISR the state of the interrupt changes to
inactive.

• Software writes to the corresponding interrupt clear-pending register bit.

For a level-sensitive interrupt, if the interrupt signal is still asserted, the
state of the interrupt does not change. Otherwise, the state of the interrupt
changes to inactive.

For a pulse interrupt, state of the interrupt changes to:
– inactive, if the state was pending
– active, if the state was active and pending.
-----------------------

An then the next section (34.4.2.10: NVIC design hints and tips) has this
sentence:

   An interrupt can enter pending state even it is disabled.

On cortex M3 HAL, cyg_drv_interrupt_mask() uses registers ICER0-3 to disable
the interrupt concerned, so we are clearly in this case: an interrupt is
disabled, but nothing is done to manage the pending state that will be raised
between the ISR run and the DSR run.

IMHO this is the full explanation of the behavior I've seen and continue to see
in drivers that do not take any precaution to clear the pending state of the
interrupt involved.

NXP does not document for each peripheral if it works with 'level' or 'pulse'
interrupt logic, but anyway the result is the same: the DSR must be able to
manage an interrupt pending state.

This is also a problem for shared drivers, like the generic serial driver
because the change must also be inserted in such a driver.

I understand this issue is a pain to manage since it breaks parts of the
generic interrupt handling in eCos, but I can't believe eCos can stick with its
current interrupt model (and face sometimes more than 100% interrupt overhead)
because the Cortex-M arch is becoming mainstream.

-- 
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-8715-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jan 25 20:07:32 2012
Return-Path: <ecos-bugs-return-8715-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 11708 invoked by alias); 25 Jan 2012 20:07:30 -0000
Received: (qmail 11700 invoked by uid 22791); 25 Jan 2012 20:07:29 -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; Wed, 25 Jan 2012 20:07:16 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 251692F78005; Wed, 25 Jan 2012 20:07:15 +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: sergei.gavrikov@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:
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"
MIME-Version: 1.0
Date: Wed, 25 Jan 2012 20:07:00 -0000
Message-Id: <20120125200711.53DFB2F78006@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/msg00144.txt.bz2
Content-length: 3186

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

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-01-25 20:07:05 GMT ---
(In reply to comment #9, comment #10, comment #11, comment #14)
> (In reply to comment #8)

References: Attachment 1527, Attachment 1528, Attachment 1531

> > 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).

[snip]

> 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.

It seems it makes sense. Agree with you.

> 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).

Ok. Attachment 1531 in this part looks safe. As I can only test builds I
hope I missed nothing and we will break nothing.

Minor: Attachment 1527: ChangeLog's record missed that you updated and
``can_driver_doc.html'' (No need to repost the patch).

> LPC2XXX driver I'll patch without my other changes, so every driver
> will be kept coherent with the CAN IO package.

I see. Sorry that you did not find volunteers that have the eCos CAN
hardware. However, with my own eyes, I have not found anything
suspicious. Tests for ea2468 target with applied patches were built
without any errors. (Next, I will continue to test builds for MCF52XX).

By the way, we may on occasion remove all the warnings in builds of CAN
tests. I found such annoying warnings (of course, they did exist before
the patching):

  cc1: warning: command line option "-Woverloaded-virtual" is valid for
C++/ObjC++ but not for C

Medicine: s/\$\(CFLAGS\)/$(ACTUAL_CFLAGS)/g for make rules in CAN config
files

  io/can/current/cdl/io_can.cdl
  devs/can/m68k/mcf52xx/current/cdl/can_mcf52xx.cdl
  devs/can/arm/lpc2xxx/current/cdl/can_lpc2xxx.cdl

and may be this can be fixed in another patch-set. Your decision.

> 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.

Bernard, your work looks great for me. In particular, thank you for
updated documentation.  I understand (agree with) your arguments. I
plan to accept all changes after further testing, if nobody objects.

Sergei

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

[Bug 1001463] LPC17XX supplementary code/option patch

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-25 21:42:23 GMT ---
Hi Bernard

Thank you for your contribution.

Past couple of days I have committed patches for Bug 1001395 (including bug
1001443) and Bug 1001432. You may need to synchronize your patches accordingly.

I could see that some patches cover issues reported (by you) in other bugs. Can
you submit them there (and obsolete some patches of my own of course)?
Splitting patches will speed up check in for some of them.

Also, on your initiative we have started some discussion on bit banding at Bug
1001442 so we can continue there with your patches.

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.