ARM FIQ handling problem

ARM FIQ handling problem

[R&D4]

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?

Thanks in advance!

RE: ARM FIQ handling problem

[Curtis Whitley]

In case you did not already know, on the ARM7TDMI, there are multiple
register sets, with different registers in use during different CPU states.
(Some registers are shared across states.)

The IRQ state and the FIQ state are separate. They have different stack
pointers and could (if programmed properly) use separate areas of memory for
their stacks. If this is not done, then problems could arise. However, the
ARM won't handle a second interrupt until the first one is acknowledged. The
eCos code might be counting on that. (I have not looked at it.)

Feel free to correct any wrong understanding on my part.

-----Original Message-----
From: ecos-devel-owner@sources.redhat.com
[mailto:ecos-devel-owner@sources.redhat.com] On Behalf Of R&D4
Sent: Thursday, October 28, 2004 9:51 AM
To: eCosDevel
Subject: ARM FIQ handling problem

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?

Thanks in advance!

Re: ARM FIQ handling problem

[Gary Thomas]

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

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: diffs --]
[-- Type: text/x-patch, Size: 1761 bytes --]

Index: hal/arm/arch/current/src/vectors.S
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/arm/arch/current/src/vectors.S,v
retrieving revision 1.54
diff -u -5 -p -r1.54 vectors.S
--- hal/arm/arch/current/src/vectors.S	28 Oct 2003 18:08:06 -0000	1.54
+++ hal/arm/arch/current/src/vectors.S	28 Oct 2004 14:19:55 -0000
@@ -765,15 +765,15 @@ FIQ:
         msr	spsr,r8
         subs	pc,lr,#4
     1:
         // If FIQ interrupted other non-user mode, switch to IRQ mode and
         // fall through to IRQ handler.
-        ldr     sp,.__exception_stack   // get good stack to save lr and spsr
+        ldr     sp,.__FIQ_exception_stack   // get good stack to save lr and spsr
         stmdb   sp,{r8,lr}
         mov     r8,#CPSR_IRQ_MODE|CPSR_FIQ_DISABLE|CPSR_IRQ_DISABLE
         msr     cpsr,r8			// switch to IRQ mode
-        ldr     sp,.__exception_stack   // get regs saved in FIQ mode
+        ldr     sp,.__FIQ_exception_stack   // get regs saved in FIQ mode
         ldmdb	sp,{sp,lr}
         msr     spsr,sp
 
         // now it looks like we got an IRQ instead of an FIQ except that
         // FIQ is disabled so we don't recurse.
@@ -1086,10 +1086,11 @@ _sp:
 PTR(__GDB_stack_base)
 PTR(__GDB_stack)
 #endif
 PTR(__startup_stack)
 PTR(__exception_stack)
+PTR(__FIQ_exception_stack)
 PTR(__undef_exception_stack)
 PTR(__bss_start)
 PTR(__bss_end)
 PTR(_end)
 PTR(__rom_data_start)
@@ -1161,10 +1162,14 @@ hal_interrupt_objects:
 __exception_stack_base: 
         .rept   32
         .long   0
         .endr
 __exception_stack:
+        .rept   32
+        .long   0
+        .endr
+__FIQ_exception_stack:
         .rept   32
         .long   0
         .endr
 __undef_exception_stack:
 

Re: ARM FIQ handling problem

[R&D4]

[-- 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