www.riscos.com Technical Support: |
|
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... |
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.
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.
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:
The data abort vector is called when the MEMC chip detects an illegal attempt to fetch data. There are two possible reasons for this:
The address exception vector is called when a data reference is made outside the range 0 - &3FFFFFF.
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.
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.
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.
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.
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 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.
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 |