This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]