Re: [ECOS] Spurious interrupt on ARM.

[Andrew Parlane <andrewp@carallon.com>]

Excellent thanks. I guess we're a bit out of date.

Thanks again,
Andrew

On 01/11/2013 17:42, Nick Garnett wrote:
>
> On 01/11/13 17:20, Andrew Parlane wrote:
>> Sorry, I should have been a bit more clear.
>> First we skip the ISR by jumping to the spurious_IRQ label, and then we
>> switch stacks if necessary, then we have (line numbers may vary):
>>
>> 941        // The return value from the handler (in r0) will indicate
>> whether a
>> 942        // DSR is to be posted. Pass this together with a pointer to the
>> 943        // interrupt object we have just used to the interrupt tidy
>> up routine.
>> 944
>> 945                              // don't run this for spurious interrupts!
>> 946        cmp     v1,#CYGNUM_HAL_INTERRUPT_NONE
>> 947        beq     17f
>> 948        ldr     r1,.hal_interrupt_objects
>> 949        ldr     r1,[r1,v1,lsl #2]
>> 950        mov     r2,v6           // register frame
>> 951
>> 952        THUMB_MODE(r3,10)
>> 953
>> 954        bl      interrupt_end   // post any bottom layer handler
>> 955                                // threads and call scheduler
>> 956        ARM_MODE(r1,10)
>> 957 17:
>>
>> So it compares the result of hal_IRQ_handler (stored in v1) with
>> CYGNUM_HAL_INTERRUPT_NONE, and jumps forwards to label 17: which is
>> after interrupt_end. if it was a spurious IRQ.
>
> Hmm. You're right. That is clearly wrong. Our own sources have the
> following code, which is slightly different:
>
>          // The return value from the handler (in r0) will indicate
> whether a
>          // DSR is to be posted. Pass this together with a pointer to the
>          // interrupt object we have just used to the interrupt tidy up
> routine.
>
>          // For a spurious interrupt, pass a NULL object. interrupt_end()
> will
>          // handle that and still unlock the scheduler.
>          cmp     v1,#CYGNUM_HAL_INTERRUPT_NONE
>          moveq   r1,#0
>          beq     17f
>          ldr     r1,.hal_interrupt_objects
>          ldr     r1,[r1,v1,lsl #2]
> 17:
>          mov     r2,v6           // register frame
>
>
> So interrupt_end does get called, but with a NULL interrupt object pointer.
>
>



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