Interrupt Controller — Interrupt Controller Definitions and Usage

Interrupt Vector Assignments

The file <cyg/hal/var_ints.h> (located at hal/arm/cortexa/bcm283x/VERSION/include/var_ints.h in the eCos source repository) contains interrupt vector number definitions for use with the eCos kernel and driver interrupt APIs.

The BCM283X interrupt controller is somewhat unsystematic and in order to derive some efficiency from it, the eCos interrupt vector table is large and in some places sparse. Some secondary decoding is also performed to demultiplex some shared vectors. The following table shows the overall interrupt mapping scheme.

0..31IRQ pending register 1
32..63IRQ pending register 2
64..84IRQ basic pending register
85..95Unused, reserved for expansion
96..111CPU0, per-CPU vectors
112..127CPU1, per-CPU vectors
128..143CPU2, per-CPU vectors
144..159CPU3, per-CPU vectors
160..162Auxiliary device vectors -- demultiplexed
163..216GPIO pin vectors -- demultiplexed

Interrupt Controller Functions

The BCM283X HAL exports the standard interrupt vector management functions which are in turn called by the generic interrupt management macros.

The hal_IRQ_handler() function queries the IRQ pending registers to determine the interrupt cause. Functions hal_interrupt_mask() and hal_interrupt_unmask() enable or disable interrupts within the interrupt controller.

The BCM283X does not have any provision for prioritizing interrupts, setting their edge/level, per-vector CPU affinity, or even acknowledge individual vectors. So the functions hal_interrupt_set_level, hal_interrupt_configure, hal_interrupt_set_cpu, hal_interrupt_get_cpu and hal_interrupt_acknowledge are all empty functions.

The only available mechanism in the BCM283X for redirecting interrupts to different CPUs is to move all device interrupt to a given CPU. This does not match the model to which eCos has been implemented. So, all device interrupts are directed to CPU0, which cannot be changed. CPUs 1 to 3 only handle explicitly multi-core interrupts.

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.