--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/crashanalysis/crashanalyser/com.nokia.s60tools.crashanalyser/raw_data/Exceptions.htm	Thu Feb 11 15:06:45 2010 +0200
@@ -0,0 +1,204 @@
+<h1>Exceptions</h1>
+<p>Exceptions are generated by internal and external sources to cause the processor to handle an event, such as
+an externally generated interrupt or an attempt to execute an Undefined instruction. The processor state just
+before handling the exception is normally preserved so that the original program can be resumed when the
+exception routine has completed. More than one exception can arise at the same time.</p>
+<p>The ARM architecture supports seven types of exception. When an exception occurs, execution is forced from a fixed
+memory address corresponding to the type of exception. These fixed addresses are called the exception
+vectors.</p>
+<code>Reset</code>
+<p>When the Reset input is asserted on the processor, the ARM processor immediately stops execution of the
+current instruction. When Reset is de-asserted, the following actions are performed:</p>
+<code>R14_svc = UNPREDICTABLE value<br>
+SPSR_svc = UNPREDICTABLE value<br>
+CPSR[4:0] = 0b10011 /* Enter Supervisor mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+CPSR[6] = 1 /* Disable fast interrupts */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+CPSR[8] = 1 /* Disable Imprecise Aborts (v6 only) */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if high vectors configured then<br>
+PC = 0xFFFF0000<br>
+else<br>
+PC = 0x00000000</code><br>
+<p>
+After Reset, the ARM processor begins execution at address 0x00000000 or 0xFFFF0000 in Supervisor mode
+with interrupts disabled.</p>
+<code>Undefined Instruction exception</code>
+<p>
+If the ARM processor executes a coprocessor instruction, it waits for any external coprocessor
+to acknowledge that it can execute the instruction. If no coprocessor responds, an Undefined Instruction
+exception occurs.</p><p>
+If an attempt is made to execute an instruction that is UNDEFINED, an Undefined Instruction exception occurs.</p><p>
+The Undefined Instruction exception can be used for software emulation of a coprocessor in a system that
+does not have the physical coprocessor (hardware), or for general-purpose instruction set extension by
+software emulation.</p><p>
+When an Undefined Instruction exception occurs, the following actions are performed:
+</p><code>
+R14_und = address of next instruction after the Undefined instruction<br>
+SPSR_und = CPSR<br>
+CPSR[4:0] = 0b11011 /* Enter Undefined Instruction mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+/* CPSR[6] is unchanged */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+/* CPSR[8] is unchanged */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if high vectors configured then<br>
+PC = 0xFFFF0004<br>
+else<br>
+PC = 0x00000004</code>
+<p>To return after emulating the Undefined instruction use:</p>
+<code>
+MOVS PC,R14
+</code>
+<p>
+This restores the PC (from R14_und) and CPSR (from SPSR_und) and returns to the instruction following
+the Undefined instruction.</p><p>
+In some coprocessor designs, an internal exceptional condition caused by one coprocessor instruction is
+signaled imprecisely by refusing to respond to a later coprocessor instruction. In these circumstances, the
+Undefined Instruction handler takes whatever action is necessary to clear the exceptional condition, then
+returns to the second coprocessor instruction. To do this use:
+</p><code>
+SUBS PC,R14,#4
+</code>
+<code>Software Interrupt exception</code>
+<p>
+The Software Interrupt instruction (SWI) enters Supervisor mode to request a particular supervisor (operating
+system) function. When a SWI is executed, the following actions are performed:
+</p><code>
+R14_svc = address of next instruction after the SWI instruction<br>
+SPSR_svc = CPSR<br>
+CPSR[4:0] = 0b10011 /* Enter Supervisor mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+/* CPSR[6] is unchanged */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+/* CPSR[8] is unchanged */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if high vectors configured then<br>
+PC = 0xFFFF0008<br>
+else<br>
+PC = 0x00000008</code>
+<p>
+To return after performing the SWI operation, use the following instruction to restore the PC
+(from R14_svc) and CPSR (from SPSR_svc) and return to the instruction following the SWI:
+</p><code>
+MOVS PC,R14
+</code>
+<code>Prefetch Abort</code>
+<p>
+A memory abort is signaled by the memory system. Activating an abort in response to an instruction fetch
+marks the fetched instruction as invalid. A Prefetch Abort exception is generated if the processor tries to
+execute the invalid instruction. If the instruction is not executed (for example, as a result of a branch being
+taken while it is in the pipeline), no Prefetch Abort occurs.</p><p>
+In ARMv5 and above, a Prefetch Abort exception can also be generated as the result of executing a BKPT
+instruction.</p><p>
+When an attempt is made to execute an aborted instruction, the following actions are performed:
+</p><code>
+R14_abt = address of the aborted instruction + 4<br>
+SPSR_abt = CPSR<br>
+CPSR[4:0] = 0b10111 /* Enter Abort mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+/* CPSR[6] is unchanged */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+CPSR[8] = 1 /* Disable Imprecise Data Aborts (v6 only) */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if high vectors configured then<br>
+PC = 0xFFFF000C<br>
+else<br>
+PC = 0x0000000C</code>
+<p>
+To return after fixing the reason for the abort, use:
+</p><code>
+SUBS PC,R14,#4
+</code><p>
+This restores both the PC (from R14_abt) and CPSR (from SPSR_abt), and returns to the aborted
+instruction.
+</p>
+<code>Data Abort</code>
+<p>
+A memory abort is signaled by the memory system. Activating an abort in response to a data access (load
+or store) marks the data as invalid. A Data Abort exception occurs before any following instructions or
+exceptions have altered the state of the CPU. The following actions are performed:
+</p><code>
+R14_abt = address of the aborted instruction + 8<br>
+SPSR_abt = CPSR<br>
+CPSR[4:0] = 0b10111 /* Enter Abort mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+/* CPSR[6] is unchanged */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+CPSR[8] = 1 /* Disable Imprecise Data Aborts (v6 only) */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if high vectors configured then<br>
+PC = 0xFFFF0010<br>
+else<br>
+PC = 0x00000010
+</code><p>
+To return after fixing the reason for the abort use:
+</p><code>
+SUBS PC,R14,#8
+</code><p>
+This restores both the PC (from R14_abt) and CPSR (from SPSR_abt), and returns to re-execute the aborted
+instruction.</p><p>
+If the aborted instruction does not need to be re-executed use:
+</p><code>
+SUBS PC,R14,#4
+</code>
+<code>IRQ</code>
+<p>
+The IRQ exception is generated externally by asserting the IRQ input on the processor. It has a lower priority
+than FIQ, and is masked out when an FIQ sequence is entered.</p><p>
+Interrupts are disabled when the I bit in the CPSR is set. If the I bit is clear, ARM checks for an IRQ at
+instruction boundaries.</p><p>
+When an IRQ is detected, the following actions are performed:
+</p><code>
+R14_irq = address of next instruction to be executed + 4<br>
+SPSR_irq = CPSR<br>
+CPSR[4:0] = 0b10010 /* Enter IRQ mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+/* CPSR[6] is unchanged */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+CPSR[8] = 1 /* Disable Imprecise Data Aborts (v6 only) */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if VE==0 then<br>
+if high vectors configured then<br>
+PC = 0xFFFF0018<br>
+else<br>
+PC = 0x00000018<br>
+else<br>
+PC = IMPLEMENTATION DEFINED
+</code><p>To return after servicing the interrupt, use:</p><code>
+SUBS PC,R14,#4
+</code><p>This restores both the PC (from R14_irq) and CPSR (from SPSR_irq), and resumes execution of the
+interrupted code.</p>
+<code>FIQ</code>
+<p>
+The FIQ exception is generated externally by asserting the FIQ input on the processor. FIQ is designed to
+support a data transfer or channel process, and has sufficient private registers to remove the need for register
+saving in such applications, therefore minimizing the overhead of context switching.</p><p>
+Fast interrupts are disabled when the F bit in the CPSR is set. If the F bit is clear, ARM checks for an FIQ
+at instruction boundaries.</p><p>
+When an FIQ is detected, the following actions are performed:
+</p><code>
+R14_fiq = address of next instruction to be executed + 4<br>
+SPSR_fiq = CPSR<br>
+CPSR[4:0] = 0b10001 /* Enter FIQ mode */<br>
+CPSR[5] = 0 /* Execute in ARM state */<br>
+CPSR[6] = 1 /* Disable fast interrupts */<br>
+CPSR[7] = 1 /* Disable normal interrupts */<br>
+CPSR[8] = 1 /* Disable Imprecise Data Aborts (v6 only) */<br>
+CPSR[9] = CP15_reg1_EEbit /* Endianness on exception entry */<br>
+if VE==0 then<br>
+if high vectors configured then<br>
+PC = 0xFFFF001C<br>
+else<br>
+PC = 0x0000001C<br>
+else<br>
+PC = IMPLEMENTATION DEFINED
+</code><p>To return after servicing the interrupt, use:</p><code>
+SUBS PC, R14,#4
+</code><p>
+This restores both the PC (from R14_fiq) and CPSR (from SPSR_fiq), and resumes execution of the
+interrupted code.</p><p>
+The FIQ vector is deliberately the last vector to allow the FIQ exception-handler software to be placed
+directly at address 0x0000001C or 0xFFFF001C, without requiring a branch instruction from the vector.
+</p>
\ No newline at end of file