AM3505 Spurious interrupts from GPT12

The initial post was inaccurate.  When the spurious interrupt occurs the contents of MPU_INTC.INTCPS_SIR_IRQ = 0xFFFFFFDF, which has an ACTIVEIRQ value of 95.  However, the TRM states that when a spurious interrupt occurs, the contents of this register become invalid.  So how do we determine which interrupt caused the spurious interrupt?

As stated previously, the manual does not provide sufficient details as to how to determine which IRQ caused the spurious interrupt.  The TRM also states the following:

NOTE:
1. The MPU_INTC.INTCPS_SIR_IRQ[31:7] SPURIOUSIRQFLAG field is a copy of
the MPU_INTC.INTCPS_IRQ_PRIORITY[31:7] SPURIOUSIRQFLAG field.
2. The MPU_INTC.INTCPS_SIR_FIQ[31:7] SPURIOUSFIQFLAG field is a copy of
the MPU_INTC.INTCPS_FIQ_PRIORITY[31:7] SPURIOUSFIQFLAG field.

(Yes, I can quote the manual just as well as you can)  Which means only the flags in the PRIORITY registers actually mean anything since the flags in the SIR registers are just copies of the PRIORITY registers.  There are only 26 bits in each of these SPURIOUSIRQFLAGS and SPURIOUSFIQFLAGS, yet there are a total of 96 IRQs.  Using basic math 26+26 = 52.  So what about the other 44 IRQs?  Or is this note an error? Additionally, the manual does not state which bit corresponds to M_IRQ_0. Is it MPU_INTC.INTCPS_IRQ_PRIORITY[6].SPURIOUSIRQFLAG or MPU_INTC.INTCPS_FIQ_PRIORITY[6].SPURIOUSFIQFLAG?  If the note is erroneous, then what is the mapping of spurious IRQ/FIQ flag to IRQ number?

Furthermore, if a 0 indicates valid and 1 indicates invalid, then this does not provide any information as to which IRQ caused the spurious interrupt, since by definition, any spurious interrupt (a.k.a. "The interrupt that triggered the sorting is no longer active during the sorting") would be invalid.  Hence, the IRQ bit that caused the spurious interrupt would be a 1 in the spurious flags, meaning invalid.  And guess what, the spurious flags are all 1's for every IRQ that is disabled/masked as well.  This does not exactly narrow down the cause a spurious interrupt.  It only provides enough information to process other active interrupts that were not spurious.

As the manual is very vague regarding the handling and debugging of a spurious interrupt, it would be very helpful if you could provide some information or insight that is not in the manual.

Still waiting on a response here.  Any ideas as to how to find the cause of a spurious interrupt?

Hi Oscar, there may be a misunderstanding of how the spurious interrupts are defined. A spurious interrupt will occur when a problem in the interrupt sorting occurs.  This can happen especially when the interrupt masks are changed during the sorting.  If you change the values in the MIR, ILR, or SET registers in the 10 clock cycle window that the TRM describes, there is a possibility that you might mask the only active interrupt in the sort.  The resulting SIR value would be invalid.  This is flagged using the SPURIOUSxxxFLAG bit field.  All the bits will turn to 1 when the associated active IRQ is invalid.  Thus, it is easy for software to check if the SIR is negative, then it is an invalid IRQ.

So the cause of the spurious interrupt is what i described above, not necessarily an offending interrupt that may had a glitch on it for example (which is probably a better known definition).  My guess is that when you changed from strongly ordered, you changed the timing of you code such that you are violating the above rule and you are changing one of those registers immediately after an interrupt assertion. 

Regards,

James

Hi James,

I do understand how spurious interrupts are defined, and I have ruled out the case where a change in one of the interrupt masks is cause.  We only modify the MIR and SET/CLR registers, and this only occurs during application startup.  However, the spurious interrupts we encounter occurs well after startup, say a few hours, where these registers are not being modified, or even read for that matter.  We have concluded that the source is due to an offending interrupt, but the question is which interrupt is it and what is the best way to determine which interrupt caused the problem?

As an example, I was able to fix a spurious interrupt resulting from DMA transfers by updating the DMA ISR handler to read back the status register after clearing the status bit for the specified DMA channel.  The only reason I suspected the DMA was because we would always get a spurious interrupt whenever we performed a touch on the touch screen, and our touch screen driver utilizes DMA.

Thanks,

Oscar