[uClinux-dev] mach-atmel (Atmel AT91) interrupt controller

Shaun Jackman sjackman at gmail.com
Fri Oct 14 18:06:34 EDT 2005


2005/10/14, Erwin Authried <eauth at softsys.co.at>:
> Hmmmm, strange, I can imagine that this is caused by the priority
> controller that maintains a stack of priority levels. Have you tried if
> the lockup can be resolved by issuing several writes to EOICR? If yes,
> that would proof that something is wrong in the kernel's interrupt
> handling. You can try to post the problem on the AT91 forum at
> www.at91.com too.

When the priority stack is empty, the AIC_ISR shows zero. The AIC_ISR
was showing zero, so I assumed the priority stack was empty. However,
writing to the AIC_EOI generated an interrupt!

(gdb) cisr
AIC_CISR: 0x0
(gdb) eoi
(gdb) cisr
AIC_CISR: 0x2 NIRQ

Perhaps the AIC_ISR was in fact showing a FIQ, which is also number
zero. FIQ is masked in both the AIC_IMR and the CPSR though. Or
perhaps if there was a double read of the AIC_IVR, the AIC_ISR was
showing a spurious interrupt. However, both of these possibilities
seem somewhat unlikely to me.

I've reverified that the interrupt handler is in fact writing the
AIC_EOI in at91_unmask_and_eoi:

(gdb) x/i $pc
0x1012dd0 <at91_unmask_and_eoi+36>:     str     r1, [r2, #-15]
(gdb) p/x $r2
$25 = 0xfffff13f
(gdb) isr
AIC_ISR: 5 TC1
(gdb) si
0x01012dd4      133             __raw_writel(0x1L, AIC_EOICR); /* AIC
don't care the value */
(gdb) isr
AIC_ISR: 0
(gdb) cisr
AIC_CISR: 0x2 NIRQ

This changes the value of the AIC_ISR from 5 (TC1) to 0 as expected.

Cheers,
Shaun



More information about the uClinux-dev mailing list