Interrupt Controller

Name

AT91 interrupt controller -- Advanced Interrupt Controller definitions and usage

Interrupt Controller Support

The AT91 variant HAL contains generic support for the AIC (GIC on SAM7XA1 and -A2). It queries the interrupt controller to identify the current interrupt and vectors to the matching service routine. If the device supports the SYSTEM interrupt then the devices that raise this interrupt will be queried individually and vectored to their own interrupt handlers. The mapping between interrupts and vector numbers is defined in the hal_platform_ints.h file in either the platform HAL or the AT91SAM7 variant HAL.

As indicated above, further decoding is performed on the SYSTEM interrupt to identify the cause more specifically. Note that as a result, placing an interrupt handler on the SYSTEM interrupt will not work as expected. Conversely, masking a decoded derivative of the SYSTEM interrupt will not work as this would mask other SYSTEM interrupts, but masking the SYSTEM interrupt itself will work. On the other hand, unmasking a decoded SYSTEM interrupt will unmask the SYSTEM interrupt as a whole, thus unmasking interrupts for the other units on this shared interrupt.

Interrupt Controller Functions

The source file src/at91_misc.c within this package provides most of the support functions to manipulate the interrupt controller. The hal_IRQ_handler queries the IRQ status register to determine the interrupt cause. Functions hal_interrupt_mask and hal_interrupt_unmask enable or disable interrupts within the interrupt controller.

Interrupts are configured in the hal_interrupt_configure function, where the level and up arguments are interpreted as follows:

levelupinterrupt on
00Falling Edge
01Rising Edge
10Low Level
11High Level

To fit into the eCos interrupt model, interrupts essentially must be acknowledged immediately once decoded, and as a result, the hal_interrupt_acknowledge function is empty.

The hal_interrupt_set_level is used to set the priority level of the supplied interrupt within the Advanced Interrupt Controller.

Note that in all the above, it is not recommended to call the described functions directly. Instead either the HAL macros (HAL_INTERRUPT_MASK et al) or preferably the kernel or driver APIs should be used to control interrupts.

Interrupt handling within standalone applications

For non-eCos standalone applications running under RedBoot, it is possible to install an interrupt handler into the interrupt vector table manually. Memory layouts are platform-dependent and so the platform documentation should be consulted, but in general the address of the interrupt table can be determined by analyzing RedBoot's symbol table, and searching for the address of the symbol name hal_interrupt_handlers. Table slots correspond to the interrupt numbers defined in the platform or AT91SAM7 HAL. Pointers inserted in this table should be pointers to a C/C++ function with the following prototype:

extern unsigned int isr( unsigned int vector, unsigned int data );
For non-eCos applications run from RedBoot, the return value can be ignored. The vector argument will also be the interrupt vector number. The data argument is extracted from a corresponding table named hal_interrupt_data which immediately follows the interrupt vector table. It is still the responsibility of the application to enable and configure the interrupt source appropriately if needed.

2017-02-09
Documentation license for this page: eCosPro License