Hardware Vectors

Programmer's Reference Manuals

» Vectors

» Hardware Vectors

Overview

Hardware vectors, like their software counterparts (Software Vectors), contain an address of a routine that will be called in specific situations. Hardware vectors are called when a privileged mode is entered or when a hardware error occurs. These conditions are known as exceptions.

Each vector will usually hold an address of a routine that will deal with the exception. Each vector has a different priority which is used to determine the order in which exceptions should be handled (if there are simultaneous exceptions).

The ARM processor handles exceptions by:

1. Using the registers to save the processor state; thus PC and PSR are copied to R14 and SPSR
2. PC and Processor Mode bits are forced to a value (dependent on exception)
3. Interrupt disable flags are set where required (to prevent unmanageable nestings of exceptions)
4. Re-enable the interrupt (if it is a re-entrant interrupt handler, R14 should be saved onto a stack in main memory beforehand)

List of hardware vectors

The following table list each of the different hardware vectors.

The offset given in the table above is relative to the vector base address. Under RISC OS this will either be &0 or &FFFF0000, as indicated by the flag returned in bit 20 of OS_PlatformFeatures 0.

Reset Vector

This vector is used to specify that the computer is reset. The ARM processor can be reset by pulling its RESET pin HIGH. When RESET goes LOW again, the following will occur:

1. Save R15 in R14_svc and CPSR in SPSR_svc
2. Force mode bits to SVC mode and set F and I bits in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &00)

Undefined Instruction Vector

This vector is called when the ARM processor attempts to execute an instruction that is unknown. If a co-processor (software or hardware) is present on the system such as a floating point emulator, the ARM will pass it onto it (when the co-processor is ready). Any instruction still unknown is passed on, and this vector is called.

The ARM processor will:

1. Save R15 in R14_und and CPSR in SPSR_und
2. Force mode bits to UND mode and set the I bit in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &04)

SWI vector

This vector is called when a SWI instruction is issued. It contains an address of the routine used by RISC OS to decode the SWI number. Due to the importance of this vector it is strongly recommended not to replace it.

The ARM processor will:

1. Save R15 in R14_svc and CPSR in SPSR_svc
2. Force mode bits to SVC mode and set I bit in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &08)

Prefetch abort vector

This vector is called when an illegal attempt to prefetch an instruction has been detected. The cause of this could be:

• An attempt to access protected memory from within insufficiently privileged mode
• An attempt to access a non-existent logical page

The ARM processor will:

1. Save R15 in R14_abt and CPSR in SPSR_abt
2. Force mode bits to ABT mode and set the I bit in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &0C)

Data abort vector

This vector is called when an illegal attempt to fetch data has been detected. The cause of this could be:

• An attempt to access protected memory from within insufficiently privileged mode
• An attempt to access a non-existent logical page

The ARM processor will:

1. Save R15 in R14_abt and CPSR in SPSR_abt
2. Force mode bits to ABT mode and set the I bit in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &10)

Address exception/Hypervisor trap vector

On 26-bit only CPUs this was the address exception vector, which would be called when an attempt was made to transfer data from an address outside the range supported by the 26-bit address bus.

With the introduction of 32-bit processor modes in ARMv3 this vector was deprecated and became unused.

With the virtualisation extensions introduced with ARMv7, this vector entry is now being re-used for handling hypervisor traps.

Currently RISC OS does not make use of hypervisor mode, and so the vector has no practical use on any version of RISC OS from 3.5 and above.

IRQ vector

This vector is called when an interrupt request is received by the ARM processor.

The ARM processor will:

1. Save R15 in R14_irq and CPSR in SPSR_irq
2. Force mode bits to IRQ mode and set the I bit in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &18)

FIQ vector

The FIQ vector is called when a Fast Interrupt Request is received by the ARM processor. The FIQ vector is entered in FIQ mode.

The ARM processor will:

1. Save R15 in R14_fiq and CPSR in SPSR_fiq
2. Force mode bits to FIQ mode and set F and I bits in the PSR
3. Force the Program Counter to fetch next instruction from Address (Vector base + &1C)

RISC OS provides the owner of the FIQ vector with 228 bytes of workspace to use as they see fit (from vector base +&1C to +&FF, inclusive). If your FIQ handler is small enough you can fit its code within this space, avoiding the need to start the handler with a branch instruction.

Vector priorities

Each vector has a different priority which is used to determine the order in which exceptions should be handled (if there are simultaneous exceptions). We list the hardware vectors in order of priority.

Pre-veneers

Since the introduction of the full 32bit address space in ARMv3 / RISC OS 3.5, RISC OS has contained a set of “pre-veneers” which are executed prior to the abort environment handlers. These pre-veneers take on a number of responsibilities:

• On 26bit OS versions, they are responsible for switching the processor from 32bit CPU modes to the corresponding 26bit CPU mode, so that environment handlers written for the ARMv2 machines continue to function correctly
• With the introduction of “lazy task swapping” in RISC OS 3.8, the pre-veneers are responsible for mapping in pages of application space on-demand as the pages are accessed
• On ARMv7 machines it’s possible for some cache maintenance operations to trigger data aborts; these aborts can safely be ignored, and the RISC OS 5 data abort pre-veneer contains code to do this.
• On ARMv6 and later, the data abort pre-veneer will also reset the “local exclusive monitor” (see below) prior to invoking the Data Abort Handler. This is necessary because ARM state that the state of the local exclusive monitor is undefined upon taking a data abort (e.g. it’s possible the next LDREX instruction that’s executed could erroneously succeed).

Claiming hardware vectors

To claim a vector, you use OS_ClaimProcessorVector. You pass it the address of the replacement handler routine, which is installed on the vector. The address of the previous routine will be returned to you, so that your handler routine can use it to pass on a call if necessary.

Note that the FIQ vector cannot be claimed using OS_ClaimProcessorVector. Instead, Service_ClaimFIQ or Service_ClaimFIQinBackground must be used, on all versions of RISC OS.

ARMv6 considerations

The LDREX/STREX instructions that were introduced with ARMv6 rely on a component of the CPU called the ‘local exclusive monitor’. For the load/store exclusive instructions to work correctly, the ARM requires that operating systems manually reset the exclusive monitor to the ‘open’ state before returning to any pre-empted code. Failure to do this can result in the program malfunctioning.

Because taking a hardware vector is often a form of pre-emption, this means that several of the vector handlers may have to reset the exclusive monitor on exit, as outlined below.

For more information on how to reset the exclusive monitor, see the ARMv7 compatibility primer.

Undefined instruction, Prefetch abort

Undefined instruction and prefetch abort handlers which make use of load/store exclusive instructions are required to reset the exclusive monitor on exit – whether that exit is by returning to the program, or by passing on to the previous claimant. If the handler does not exit (i.e. it raises an error instead) then there is no need to reset the exclusive monitor.

Data abort

The requirements for data abort handlers are the same as for undefined instruction/prefetch abort handlers, with one addition: the exclusive monitor must be reset before any exclusive load/store instruction is used. This is necessary because ARM state that the state of the local exclusive monitor is undefined upon taking a data abort.

This means that the full set of rules are:

• If your handler makes use of load/store exclusive instructions (either directly or indirectly, e.g. via a SWI), the exclusive monitor must be reset prior to the instructions.
• If your handler returns from the exception, the exclusive monitor must be reset prior to the return (and after all load/store exclusive operations executed by your handler)
• If your handler passes control to the next claimant, the exclusive monitor can be left in an undefined state
• If your handler raises an error, the exclusive monitor must be reset at some point prior to executing the SWI (see first rule)

SWI and Hypervisor calls

ARM recommend that in order to avoid external factors causing the exclusive monitor to spuriously reset, the processing within an exclusive access sequence is kept as short and simple as possible (e.g. only use compare and ALU instructions). A SWI/hypervisor call is not a simple operation, and so they should not be used from within exclusive access sequences. Because they should not be used, there is no point in making sure the exclusive monitor is reset on exit. Therefore RISC OS defines the exclusive monitor state as being unknown on return from a SWI or HVC.

This has implications for other types of handler – if the handler either directly calls a SWI/HVC or calls some other code (e.g. an external callback function) which may use a SWI/HVC then the exclusive monitor state should now be considered as having been modified, and thus it is in need of resetting before the handler returns.

IRQ

IRQ handlers (as registered via OS_ClaimDeviceVector) do not need to worry about clearing the exclusive monitor on exit; the post-IRQ code within the kernel will clear it for you.

If handlers are installed via OS_ClaimProcessorVector (and they do not return via the kernel) then they must clear the exclusive monitor themselves, as appropriate.

FIQ

Because FIQ handlers return directly to the interrupted code, any FIQ handler which uses the exclusive access instructions must make sure it resets the exclusive monitor on exit.

Additionally, because FIQs can occur while inside data abort handlers, FIQ code which uses exclusive access instructions must reset the exclusive monitor on entry.

See also

• Processor Vector Numbers
• OS_ClaimProcessorVector
• Software Vectors