This is the mail archive of the ecos-discuss@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]

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


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