Interrupts and the GIC

Configure a Zynq interrupt from its source to the processor, write a short ISR and analyze latency.

Interrupts and exceptions

An interrupt usually comes from a peripheral and is asynchronous to the running program. An exception is caused by processor execution, such as an invalid instruction or forbidden memory access.

The processor saves a minimal context, identifies the source, executes an Interrupt Service Routine, or ISR, and resumes the interrupted program. The vector table provides the entry points for processor exceptions.

The complete path

A timer interrupt crosses several layers.

1. The timer detects an event and sets a status bit.
2. Its local mask enables the interrupt output.
3. The Generic Interrupt Controller receives the request.
4. The GIC checks enable state, priority and processor target.
5. The processor enters the common handler.
6. The GIC handler calls the registered ISR.
7. The ISR acknowledges the source before returning.

Enabling only the GIC is not enough. The peripheral source must also be enabled.

Initializing the GIC

The code uses XScuGic and connects its common handler to the processor exception logic.

XScuGic_Config *config;
 
config = XScuGic_LookupConfig(XPAR_SCUGIC_SINGLE_DEVICE_ID);
XScuGic_CfgInitialize(&gic, config, config->CpuBaseAddress);
 
Xil_ExceptionRegisterHandler(XIL_EXCEPTION_ID_IRQ_INT, (Xil_ExceptionHandler)XScuGic_InterruptHandler, &gic);
Xil_ExceptionEnable();

The Triple Timer Counter is configured in interval mode. A prescaler divides the input clock to obtain a slower timer rate. The ISR reads and clears the status, an operation called acknowledgement, then sets a flag.

static volatile u8 update_flag;
 
static void tick_handler(void *reference)
{
    XTtcPs *timer = (XTtcPs *)reference;
    u32 status = XTtcPs_GetInterruptStatus(timer);
 
    XTtcPs_ClearInterruptStatus(timer, status);
    if ((status & XTTCPS_IXR_INTERVAL_MASK) != 0U) {
        update_flag = 1U;
    }
}

Time calculation and UART output stay in the main loop. The ISR remains short and predictable.

Trigger type and latency

An interrupt can be edge-sensitive or level-sensitive. A level request remains active until its cause is cleared. An ISR that forgets this acknowledgement is called again immediately.

Latency includes temporary masking, GIC arbitration, context save and cache misses. A critical ISR stored in DDR may incur a large first-access cost. A constrained design can place selected code in OCM or manage cache placement, but it should first measure the actual latency.

Shared state needs careful handling. volatile is appropriate for a simple flag modified by the ISR. Complex structures may require an atomic operation or a critical section.

Diagnosis

If the ISR never runs, check peripheral status, local mask, the identifier in xparameters.h, GIC connection, GIC enable and global exception enable. If it runs continuously, check source acknowledgement and edge or level configuration.

Official references

The SCU GIC driver guide documents the API. The official XScuGic example shows the initialization sequence.

Key points

An interrupt is a complete chain through the source, GIC and processor. The ISR quickly acknowledges the peripheral and defers long work. Memory and cache behavior also affect latency.

Test your knowledge - Chapter quiz