This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Interrupt stacking issues
Le 19/07/2012 11:46, Alan Bowman a écrit :
I am using a board based upon an STM3210E development board, only with
the processor clocked much slower (8MHz). I am seeing problems with
interrupt handling when using the serial ports. I believe that my
system should be fast enough to handle the data coming in.
Hello Alan,
I spent considerable time about ISR related issues with the NXP LPC17XX
family (also a Cortex M3). My target also clocks at 8MHz.
It seems you hit this problem:
- because we clock slowly, we increase the possibility of having an IRQ
triggered while the corresponding DSR code is running, or even before
the ISR was triggered.
- the Cortex-M3 keeps track of pending interrupts: processing an IRQ
does not clear the pending interrupt bit and if this bit isn't cleared,
then as soon as the core can trigger a new interrupt even for the same
interrupt source, it will.
- eCos does not provide a platform independent way to clear the pending
interrupt bit. So if you use drivers that comes from another
environment, these drivers will do nothing regarding handling the
pending interrupt bit.
- clearing the pending interrupt bit must be done at the correct time. I
don't know about the STM3210E, but in my case the UART driver is based
on the generic serial driver but I can't use the generic serial driver
as it is provided by eCos, because of this pending interrupt bit
problem: to solve the issue, I reorganized the DSR to :
for (;;){
- read interrupt sources (more than one can be triggered when
DSR code is scheduled)
- if no interrupt to process, exit loop
- clear pending interrupt bit
- do the job related to interrupts.
}
Of course the number of iteration is checked to avoid being stuck in the
DSR, for instance if some connection error occured on the hardware, for
instance if RTS is connected to a signal that changes of state very
frequently, one can stay in the DSR forever.
- I had to modify UART, CAN and SPI drivers in a similar way.
- I did a lengthly bug report describing all of this
(http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456). I submited a
patch to add into eCos kernel a supplementary call to handle the
interrupt pending bit problem, but it's stuck in bugzilla since February
since it's a kernel API change..
Hope it helps!
Bernard
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss