[ECOS] Re: AT91 bad IRQ/FIQ priority handling?

[daniel dot neri at sigicom dot se (Daniel Néri)]

"Andrea Michelotti" <amichelotti@atmel.com> writes:

> I think there is a bug in irq fiq priority when a FIQ and an IRQ are
> arised together. In this case IVR reading updates ISR but with the
> IRQ number not with the FIQ one. Then the irq is served instead of
> fiq (changing SMR priority doesn't change order always IRQ before
> FIQ) .

Yes, I have noticed this too. But since FIQ handling isn't really well
supported by the ARM architecture HAL, I didn't find it worthwhile to
try to make it work on the AT91 specifically.

> Is this behavior considered a bug? I did several trials with my jtst
> board a new Atmel board with an ARM7+DSP embedded (where the DSP
> generates almost simulataneous FIQs and IRQs). I did a simple patch
> that solve my problem that is a mix of old and new ecos irq handling
> method.

In our platform HAL, I solved it with a simple VSR, that triggers the
software interrupt in the AIC (see below).

The interrupt handler for the hardware device is then attached to the
SWIRQ interrupt source instead.


Best wishes,
  --Daniel



#include <pkgconf/hal_arm_at91.h>
#include <cyg/hal/hal_platform_ints.h>
#include <cyg/hal/var_io.h>

#include <cyg/hal/arch.inc>

        .text
        .code   32

FUNC_START(platform_fiq_vsr)
        ldr     r8,=AT91_AIC
        ldr     r9,[r8,#AT91_AIC_FVR]   // clear interrupt (if edge triggered)

        ldr     r9,=(1 << CYGNUM_HAL_INTERRUPT_SW)
        str     r9,[r8,#AT91_AIC_ISCR]

        subs    pc,lr,#4


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