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.