www.riscos.com Technical Support: Programmer's Reference Manual

Hardware vectors

Introduction

The hardware vectors are a set of words starting at logical address &0000000. The ARM processor branches to these locations in certain exceptional conditions - in general, either when a privileged mode is entered or when a hardware error occurs. These conditions are known as exceptions. Usually, each vector will contain a branch to a routine to handle the exception. The vectors, their addresses and their default contents are:

Addr	Vector	Default contents
&00	Reset	B branchThru0Error
&04	Undefined instruction	LDR PC, UndHandler
&08	SWI	B decodeSWI
&0C	Prefetch abort	LDR  PC, PabHandler
&10	Data abort	LDR PC, DabHandler
&14	Address exception	LDR PC, AexHandler
&18	IRQ	B handleIRQ
&1C	FIQ	FIQ code...

Reset vector

When the computer is reset, amongst other things:

• the ROM is temporarily switched into location zero
• the program counter is loaded with &00.

The reset vector is hence read from the ROM and will always be the same.

Any attempt to jump to location zero in RAM will result in a 'Branch through zero' error.

Hardware exception vectors

The middle group of vectors, except SWI, are under the control of various 'environment' handlers. When the exception occurs, before any of these vectors is called, the ARM processor saves the current program counter (R15) to R14_svc. The ARM is then forced to SVC mode, and interrupts are disabled.

The usual action of these exceptions is to cause an error. The default handlers for these exceptions also dump the aborting mode's registers into the current exception dump area, and test to see if the exception occurred while the processor was in FIQ mode. If it was then FIQs are disabled on the IOC chip so that the exception does not recur - this would overwrite the original register dump, and probably hang the machine.

These vectors may be set and read as described in the chapter entitled Program Environment. Very few programs need to take account of them.

Undefined instruction vector

The undefined instruction vector is called when the ARM attempts to execute an instruction that is not a part of its normal instruction set. If the floating point emulator (either hardware or software) is active, it intercepts the undefined instruction vector to interpret floating point instructions, and passes on those that it does not recognise.

Prefetch abort vector

The prefetch abort vector is called when the MEMC chip detects an illegal attempt to prefetch an instruction. There are two possible reasons for this:

• an attempt was made to access protected memory from an insufficiently privileged mode
• an attempt was made to access a non-existent logical page.

Data abort vector

The data abort vector is called when the MEMC chip detects an illegal attempt to fetch data. There are two possible reasons for this:

• an attempt was made to access protected memory from an insufficiently privileged mode
• an attempt was made to access a non-existent logical page.

Address exception vector

The address exception vector is called when a data reference is made outside the range 0 - &3FFFFFF.

SWI vector

The SWI vector is called when a SWI instruction is issued. It contains a branch to the RISC OS code which decodes the SWI number and branches to the appropriate location. Before calling this vector, the ARM processor saves the current program counter (R15) to R14_svc. The ARM is then forced to SVC mode, and interrupts are disabled.

You are strongly recommended not to replace this vector.

For full details, see the earlier chapter An introduction to SWIs.

IRQ vector

The IRQ vector is called when the ARM receives an interrupt request. It also contains a branch into the RISC OS code. This code attempts to deal with the interrupt by examining the IOC chip, to find the highest priority device that has interrupted the processor. If no interrupting device is found then the software vector IrqV is called.

Before calling the hardware IRQ vector, the ARM processor saves the current program counter (R15) to R14_irq, the ARM is forced to IRQ mode, and interrupts are disabled.

For full details, see the chapter entitled Interrupts and handling them.

FIQ vector

Finally, the FIQ vector is called when the ARM receives a fast interrupt request. For some claimants (such as ADFS) this is the first instruction of a RAM-based routine to deal with the fast interrupt requests. For other claimants (such as NetFS) this is a branch instruction to the code that deals with the fast interrupt requests. (NetFS uses FIQs to drive a state machine, so the overhead of copying code to the FIQ vector is much more than that of putting a Branch instruction there.)

Before calling this vector the ARM processor saves the current program counter (R15) to R14_fiq, the ARM is forced to FIQ mode, and both normal and fast interrupts are disabled.

For full details, see again the chapter entitled Interrupts and handling them.

Claiming hardware vectors

If you are the current application, you can change the effect of most of the hardware vectors by installing the appropriate handler. If you are not, then you will have to 'claim' the vector yourself. This is most likely to occur if you are a system extension module. There is no SWI to claim a hardware vector; instead you have to overwrite it with a

B myHandler

or an

LDR PC, [PC, #myHandlerOffset]

instruction, and do all the 'housekeeping' yourself.

Passing on calls to hardware vectors

You must make sure that if your own handler cannot process what caused the vector to be called, the 'next' handler for the vector is called. The address of the next handler can be dynamic, so you must be careful:

• If the instruction in the hardware vector location when you come to claim it is
  B oldHandler
  then you need to compute the address of the old handler and store it in your workspace. You then need to store a pointer to this address.
• If the instruction is
  LDR [PC, #oldHandlerOffset]
  then you need to compute the address of the variable where RISC OS stores the installed handler's address and store this pointer. You must not dereference this pointer to get the actual address of the handler, as this value may change as different applications are run.

In both cases above you now have a pointer to a variable which holds the address of the next handler to call; you can then use identical code in both cases to pass on a call to the hardware vector that you cannot handle.

Releasing hardware vectors

If your module is killed, so you need to release a hardware vector, you must first check to see that the instruction that is in the hardware vector location points to your own handler. If it does not, your module must refuse to die, as another piece of software has stored away the address of your handler, and may try to pass on a call to your handler or to restore you when it exits.

Vector priorities

The hardware vectors have different priorities, so that if exceptions occur simultaneously they are sensibly handled. This list shows the vectors in order of priority:

Reset
Address exception
Data abort	High priority
FIQ
IRQ
Prefetch abort	Low priority
Undefined instruction
SWI