This is the mail archive of the 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: ARM FIQ handling problem

Are you some kind of clairvoyant? ;-)

I have just made the same changes a few minutes ago but still it's seems it is not enough: I have the same trouble, but it seems we are on the right way because it's seems (it's just a some kind of feeling...) the crash happen later on.

I have made another change to your same code as attached.

In other words: I use __FIQ_exception_stack in IRQ code too if I come from FIQ code.
In this way it never hangs but, sometimes, I see that interrupts are disabled (in my application code which is wrong).
If I re-enable it manually (via JTAG) it works good for a while and later I see interrupt disabled again... I am doing some mistake somewhere but I really cannot figure out where!

On Thu, 2004-10-28 at 07:50, R&D4 wrote:
> Hi all,
> I'm experiencing some problems in using FIQ and IRQ over and ARM7TDMI.
> I have a "slow" (10ms) timer used for eCos scheduling and one, faster
> (100us), used by my application to do its work.
> Due realtime constrain of my app I have to treat the faster as FIQ, so it
> is not delayed by others IRQ.
> Here is where my problems rise: everything works fine (IRQ and FIQ routine
> are called in the right way) only for a while, after that something goes
> wrong and an undefined exception is rised. The instruction is usually
> placed somewhere in user code (most of times in the thread idle routine).
> I have also noticed that when the exception is rised the __exception_stack
> is corrupted.
> Please also note that when setting the faster timer as IRQ too there are no
> problems at all...
> To me it sounds like there are some problems in the interaction between IRQ
> and FIQ, maybe in some situation that happen only not so often...
> I have noticed that FIQ are handled much like IRQ, only with the special
> care of setting FIQ disable flags too.
> So them both use the same __exception_stack as temporary stack: what if an
> IRQ is interrupted by a FIQ, which uses the same __exception_stack to save
> its status (or is it impossible to have such a kind of problem due FIQ
> disabling while the IRQ code is using that stack)?
> Any clue about where can be the problem?

It looks like there might be a window here.  If you were to get an FIQ
during the very early stages of the IRQ handler, it might destroy some

Can you try the attached patch to see if it helps?

Gary Thomas <>
MLB Associates

Attachment: __fiq_stack.patch
Description: Text document

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