Re: ARM FIQ handling problem

[R&D4 <r&d4 at dave-tech dot it>]

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
> context.
>
> Can you try the attached patch to see if it helps?
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates

Attachment: __fiq_stack.patch
Description: Text document