Trying to understand Interrupts. Where does ID 1023 come from ?

[svenssonjoel]

Hello,

I am trying to understand PL -> PS interrupt on the zynq 7000. In my setup I have a GPIO-block with interrupt enabled and hooked to the IRQ_F2P.

Since this is the only interrupt that  is connected from the PL, I assume that the ID of this will be 61.  So that is what I go by when trying to configure it. I use it in this command for example:

status = XScuGic_Connect(&gic, 61,(Xil_ExceptionHandler)irqHandler,(void *)&gic);

Now, if I execute this command inside my "irqHandler":

IntID = XScuGic_ReadReg(XPAR_SCUGIC_CPU_BASEADDR, XSCUGIC_INT_ACK_OFFSET) & XSCUGIC_ACK_INTID_MASK;

the value of "IntID" is set to 1023. 

Where does this number come from? Should it not be 61?

Ok. I can share more code if needed. Its a composite of pieces I found (and tried to extrapolate from) spread over the internet. Is there a guide that in a newbie friendly way explains these interrupts on zynq or I guess it may be very ARM general as well?

Thank you and have a great day !

[novec_16]

In my recollections the value is 61 for standalone only.

It's defined from xparameters.h and then used in SDK:

#define INTC_INTERRUPT_ID  XPAR_FABRIC_BRAM_INTERFACE_0_INTR_INTR

Under Linux it could be 1023 but I am not an expert.

Useful info is in Xilinx Wiki and code in Vivado SDK  ...\embeddedsw\XilinxProcessorIPLib\drivers\scugic

Cheers!

[svenssonjoel]

Thanks for the input.

I am writing a standalone app. So no linux involved. Should have included that information from the beginning, sorry.

[wpmoorenasa]

From ARM GIC Architecture Specification:

3.2.5 Special interrupt numbers

The GIC architecture reserves interrupt ID numbers 1020-1023 for special purposes. In a GICv1 implementation
that does not implement the GIC Security Extensions, the only one of these used is ID 1023. This value is returned
to a processor, in response to an interrupt acknowledge, if there is no pending interrupt with sufficient priority for
it to be signaled to the processor. It is described as a response to a spurious interrupt.

Note

A race condition can cause a spurious interrupt. For example, a spurious interrupt can occur if a processor writes a
1 to a field in an GICD_ICENABLERn that corresponds to a pending interrupt after the CPU interface has signaled
the interrupt to the processor and the processor has recognized the interrupt, but before the processor has read from
the GICC_IAR.

For more information about the special interrupt numbers see Special interrupt numbers when a GIC supports
interrupt grouping on page 3-50.