[ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Mervin J]

Hi,
  My requirement is to handle the interrupt every 1ms. So I tried with 
FIQ. But while using FIQ, My program got hang with in an hour and it is 
not traceable. The same code with the modification of FIQ to IRQ is 
working without any problem. 
    Please help to solve the problem.
   

-- 
Regards,

Mervin J,
R&D Division,
CMS Computers Ltd.,
44 Santhi Nagar, Trivandrum,
Kerala, India, PIN:695001.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Martin Laabs]

Hi,

> working without any problem.    Please help to solve the problem.

We can't help you with so little information. Give us more information. 
Whats your system consist of, which eCos version do you use, which 
configuration (HAL only, Kernel etc.) Have you wrote the FIQ handler in 
assembler, how is the FIQ handeled (via the eCos interrupt system or 
dedicated?)
What did you tried until yet to find the bug, post your code if it's not 
to big. (Or at least the important parts.) If in C - post also the 
initialization of the FIQ.

Greetings,
  Martin Laabs


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Mervin J]

Hi
    I am using the latest version taken from CVS. The Board is 
AT91SAM7X256 Development Board. I am using the default configuration 
with FIQ treated as IRQ. The code is attached.
    Initialization code:
    /* Configure FIQ */
    HAL_ARM_AT91_PIO_CFG(AT91_INT_FIQ);
    HAL_WRITE_UINT32(AT91_PIOA + AT91_PIO_PPUER,AT91_PIO_PSR_FIQ);
    cyg_interrupt_create(CYGNUM_HAL_INTERRUPT_FIQ, 7, 0, ui32FiqIsr,
                                             NULL, &fiq_handle, &fiq_space);
    cyg_interrupt_configure(CYGNUM_HAL_INTERRUPT_FIQ,0,0);
    cyg_interrupt_attach(fiq_handle);
    cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_FIQ);

Handler code:

static cyg_uint32 ui32FiqIsr(cyg_vector_t vector, cyg_addrword_t word)
{
    ade_int_proc_fp++;
    // Tell the processor that we have received
    // the interrupt.
    cyg_interrupt_acknowledge(vector);
    return(CYG_ISR_HANDLED);
}

Please suggest the handling way if it is wrong.

Regards,


Mervin J,

Martin Laabs wrote:
> Hi,
>
>> working without any problem.    Please help to solve the problem.
>
> We can't help you with so little information. Give us more 
> information. Whats your system consist of, which eCos version do you 
> use, which configuration (HAL only, Kernel etc.) Have you wrote the 
> FIQ handler in assembler, how is the FIQ handeled (via the eCos 
> interrupt system or dedicated?)
> What did you tried until yet to find the bug, post your code if it's 
> not to big. (Or at least the important parts.) If in C - post also the 
> initialization of the FIQ.
>
> Greetings,
>  Martin Laabs
>
>
 




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Martin Laabs]

Hi,

Mervin J wrote:

> static cyg_uint32 ui32FiqIsr(cyg_vector_t vector, cyg_addrword_t word)
> {
>    ade_int_proc_fp++;
>    // Tell the processor that we have received
>    // the interrupt.
>    cyg_interrupt_acknowledge(vector);
>    return(CYG_ISR_HANDLED);
> }

Can you please look at the stackpointer just before exiting of the FIQ? 
Is it constant every time? And is its address correct?
In FIQ mode some registers are shadowed and eCos tries to convert a fiq 
to an irq in vectors.S. However - maybe there is a seldom occurring bug. 
(However - most times the bug is in the user program.)

What happens in the user program when ade_int_proc_fp++ overflows? Might 
this be a problem?

Greetings,
  Martin L.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Mervin J]

Hi Martin,
    As you told, there is some problem with stack pointer handling.Since 
the program behavior is not predicable with FIQ but works well with IRQ. 
How can i handle FIQ as it is,without taking it to IRQ level.

Thanks and Regards,
    Mervin J
Please
Martin Laabs wrote:
> Hi,
>
> Mervin J wrote:
>
>> static cyg_uint32 ui32FiqIsr(cyg_vector_t vector, cyg_addrword_t word)
>> {
>>    ade_int_proc_fp++;
>>    // Tell the processor that we have received
>>    // the interrupt.
>>    cyg_interrupt_acknowledge(vector);
>>    return(CYG_ISR_HANDLED);
>> }
>
> Can you please look at the stackpointer just before exiting of the 
> FIQ? Is it constant every time? And is its address correct?
> In FIQ mode some registers are shadowed and eCos tries to convert a 
> fiq to an irq in vectors.S. However - maybe there is a seldom 
> occurring bug. (However - most times the bug is in the user program.)
>
> What happens in the user program when ade_int_proc_fp++ overflows? 
> Might this be a problem?
>
> Greetings,
>  Martin L.
>
>
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Paul D. DeRocco]

> From: Mervin J
>
>     As you told, there is some problem with stack pointer handling.Since
> the program behavior is not predicable with FIQ but works well with IRQ.
> How can i handle FIQ as it is,without taking it to IRQ level.

I'm wondering why you're using FIQ at all. The only legitimate reason I can
think of for trying to get FIQ to invoke an eCos ISR is that you've got some
external device that's hard-wired to the FIQ pin, and you can't change the
board. Otherwise, if you don't mind the overhead of the standard eCos
ISR/DSR mechanism, then you'd do better to use a regular interrupt.
(Remember, you can make any PIO line an interrupt input, although all such
PIO lines would share an ISR.)

If you're using FIQ because you want the lower overhead, then routing it to
an ISR is probably not what you want. FIQ is most useful for implementing a
software-based smart DMA-like system, where the only thing the FIQ handler
does is some simple I/O, and not invoking an ISR until some buffer is full
or empty. In that case, you should be writing it in assembler.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Gary Thomas]

Paul D. DeRocco wrote:
>> From: Mervin J
>>
>>     As you told, there is some problem with stack pointer handling.Since
>> the program behavior is not predicable with FIQ but works well with IRQ.
>> How can i handle FIQ as it is,without taking it to IRQ level.
> 
> I'm wondering why you're using FIQ at all. The only legitimate reason I can
> think of for trying to get FIQ to invoke an eCos ISR is that you've got some
> external device that's hard-wired to the FIQ pin, and you can't change the
> board. Otherwise, if you don't mind the overhead of the standard eCos
> ISR/DSR mechanism, then you'd do better to use a regular interrupt.
> (Remember, you can make any PIO line an interrupt input, although all such
> PIO lines would share an ISR.)
> 
> If you're using FIQ because you want the lower overhead, then routing it to
> an ISR is probably not what you want. FIQ is most useful for implementing a
> software-based smart DMA-like system, where the only thing the FIQ handler
> does is some simple I/O, and not invoking an ISR until some buffer is full
> or empty. In that case, you should be writing it in assembler.

Indeed.  I tried to make the FIQ handling the same as IRQ handling
back when the ARM port was originally done (ca 1998).  Experience
has shown that this probably doesn't make sense and the best way
to handle FIQ (if you need them at all) is to install your own
IHR (interrupt handling routing), typically written 100% in assembler.

Try looking at the audio handling in the Cirrus EDB7xxx platform.
It uses an FIQ routine to perform DMA like feeding of the audio
chip.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Mervin J]

Hi,
The main reason for using FIQ is that,
    In Hardware, The external interrupt pin is connected to FIQ pin and 
also we want to get the interrupt within few ms.
 I succeed by handling  as GPIO Interrupt. But, While handling as 
FIQ,there is some stack overwrite issue.
One more question is that, Whether I can redirect the FIQ to a simple C 
routine and return to the User mode without more complexity.

Thanks a lot for Your suggestion in handling FIQ.

-- 
Regards,

Mervin J,




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Gary Thomas]

Mervin J wrote:
> Hi,
> The main reason for using FIQ is that,
>    In Hardware, The external interrupt pin is connected to FIQ pin and
> also we want to get the interrupt within few ms.
> I succeed by handling  as GPIO Interrupt. But, While handling as
> FIQ,there is some stack overwrite issue.
> One more question is that, Whether I can redirect the FIQ to a simple C
> routine and return to the User mode without more complexity.

No

> Thanks a lot for Your suggestion in handling FIQ.
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)

[Paul D. DeRocco]

> From: Gary Thomas [mailto:gary@mlbassoc.com]
>
> Indeed.  I tried to make the FIQ handling the same as IRQ handling
> back when the ARM port was originally done (ca 1998).  Experience
> has shown that this probably doesn't make sense and the best way
> to handle FIQ (if you need them at all) is to install your own
> IHR (interrupt handling routing), typically written 100% in assembler.
>
> Try looking at the audio handling in the Cirrus EDB7xxx platform.
> It uses an FIQ routine to perform DMA like feeding of the audio
> chip.

One problem I had with the FIQ handling in eCos is that the HAL macros that
enable/disable interrupts affect both FIQ and IRQ. If FIQ is used for what
it is really intended, you often want normal interrupt handling to disable
IRQ only, so that FIQ events can continue to be handled. There really ought
to be a CDL option for this. In the ARM AIC, the FIQ handler can report its
ultimate completion via an IRQ by setting a bit in the request register, and
the interrupt won't occur until the IRQ is later enabled.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss