Re: ARM FIQ handling problem

[R&D4 <r&d4@dave-tech.it>]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

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 #2: __fiq_stack.patch --]
[-- Type: text/plain, Size: 896 bytes --]

--- vectors-prepatch.S	2004-10-28 16:36:01.000000000 +0200
+++ vectors.S	2004-10-28 14:41:20.000000000 +0200
@@ -877,6 +877,8 @@ FIQ:
         ldr     sp,.__FIQ_exception_stack   // get regs saved in FIQ mode
         ldmdb sp,{sp,lr}
         msr     spsr,sp
+        ldr			sp,.__FIQ_exception_stack   // amon:  use the correct interrupt stack
+        b IRQ1
 
         // now it looks like we got an IRQ instead of an FIQ except that
         // FIQ is disabled so we don't recurse.
@@ -884,6 +886,7 @@ IRQ:
         // Note: I use this exception stack while saving the context because
         // the current SP does not seem to be always valid in this CPU mode.
         ldr     sp,.__exception_stack   // get good stack
+IRQ1:
         stmfd   sp!,{r0-r5}             // save some supervisor regs
         sub     r0,lr,#4                // PC at time of interrupt
         mrs     r1,spsr