[ECOS] Possible fix for interrupt latency problems on Arm

Nick Garnett nickg@ecoscentric.com
Mon Jul 31 10:21:00 GMT 2006


> Mike wrote:
> 
> > I have been looking at why my Arm LPC2220 board occasionally gets
> > terrible interrupt latencies. This happens particularly when the
> > interrupt I'm interested in occurs whilst ecos is doing processing
> > after a TIMER0 (ecos RTC) interrupt.
> > It seems that interrupt_end() is called from
> > hal/arm/arch/current/src/vectors.s with interrupts disabled, whereas
> > it looks to me like interrupt_end() has been designed to run with
> > interrupts enabled in order for DSRs to be interruptible.
> > I have modified my own vectors.s by inserting the following
> > immediately before the call to interrupt_end():
> > // Enable interrupts
> > mrs r4,cpsr
> > bic r4,r4,#CPSR_IRQ_DISABLE|CPSR_FIQ_DISABLE
> > msr cpsr,r4
> > This seems to work for me, but I would appreciate feedback if this
> > is a sane and wise thing to do.
> > As a newbie, how do I submit such modifications for inclusion in the
> > repository?
> > Thanks,
> > Mike
> >

That change is not a good idea. It can introduce race conditions into
the system. I think you have been lucky so far.

Although interrupt_end() is entered with interrupts disabled, they
will be enabled to call DSRs, that's what
hal_interrupt_stack_call_pending_DSRs does. Interrupts will also be
re-enabled if a context switch is made. So interrupts will get turned
back on within a few microseconds of completing the ISR.

-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list