# Exceptions: Overview

This page explains the exception display system used by the TWL-SDK to show information about exceptions generated on the ARM processors.

## Exception Types

The following exceptions exist for the ARM processors.

Exception Type | Normal Vector Address | High Vector Address
--- | --- | ---
Reset | 0x00000000 | 0xFFFF0000
Undefined instruction | 0x00000004 | 0xFFFF0004
Software interrupt | 0x00000008 | 0xFFFF0008
Pre-fetch abort | 0x0000000C | 0xFFFF000C
Data abort | 0x00000010 | 0xFFFF0010
IRQ | 0x00000018 | 0xFFFF0018
FIQ | 0x0000001C | 0xFFFF001C

Out of this list, the reset interrupt and FIQ exceptions are used by the system or debugger, so they cannot be used by users.

The IRQ exception can be used as an interrupt. See the following for information about interrupts. Interrupts (Overview)

Some of the undefined instructions are used by the debugger for breakpoints and other such data.

When an exception occurs, control is transferred to the pertinent vector address, as shown in the table above. This normally involves use of high vector addresses.

## Positioning the Exception Vector

The ARM processor specifications allow you to set the exception vector addresses at either the range `0x00000000` to `0x0000001C` or the range `0xFFFF0000` to `0xFFFF001C`. The former are called normal vectors, and the latter are called high vectors.

The `OS_SetExceptionVectorLower` function sets the exception vectors to addresses `0x0000000` to `0x0000001C` (normal vectors).

The `OS_SetExceptionVectorUpper` function sets the exception vectors to addresses `0xFFFF0000` to `0xFFFF001C` (high vectors).

The TWL-SDK uses the high vectors by default. Unless you have a special reason, use the high vectors and do not change this setting.

## Displaying Contexts During Exceptions

The TWL-SDK contains a mechanism for displaying the context (the contents of the registers and the CPU status) to the debug window (console) when an exception occurs. This exception display mechanism is initialized using the `OS_InitException` function, but this function is called from the `OS_Init` function, so no real preparation is required in applications that use the `OS_Init` function.

The example below shows what is displayed. The error output from the `OS_FPrintf` function is used to display the information.

> `**** Exception Occurred ****
> R00=00000000 R01=12345678 R02=2000001F R03=02030340
> R04=200000D7 R05=0000000F R06=00000001 R07=00000002
> R08=02FFFFA8 R09=04000130 R10=00000001 R11=0201C25C
> R12=0200E240 SP =02FE3750 LR =02005130 PC =02005140
> CPSR=2000001F SPSR=00000000 CP15=0005707D`

Note that when an exception occurs on IS-TWL-DEBUGGER, the debugger itself will display this. (This is possible on IS-TWL-DEBUGGER v1.06 and later.) The format of the display will differ from that shown above. The example below shows what is displayed.

> `[[ Fatal error: Execution stopped because "data access exception" occurred on the ARM9CPU.]]
> Symbol:STATIC:0x02000C8C
> 02000C8C:E591B000 LDR R11, [R1]
> CPSR:6000001F
> R0:0000007B R1:00000000 R2:00000100 R3:000003E8
> R4:000007D0 R5:00000BB8 R6:00000FA0 R7:00001388
> R8:02000C84 R9:000000FF R10:000000EE R11:00000000
> R12:00000123 SP:027E3750 LR:02000C5C PC:02000C8C`

## Setting a User Handler

With IS-NITRO-DEBUGGER and actual Nintendo DS and TWL systems, when exceptions occur, control can be transferred to a user-specified exception handler. To do this, register the handler with the `OS_SetUserExceptionHandler` function. For details, see the function reference.

## Environments in Which Displaying Contexts During Exceptions and Calling Users' Exception Handlers Is Possible

The table below indicates whether the context can be displayed in the debug window (console) when an exception occurs and whether control can be moved to the user's exception handler. The table is broken down by operating environment.

As indicated in "Displaying Context During Exceptions," the SDK displays for IS-NITRO-DEBUGGER, and the debugger displays for IS-TWL-DEBUGGER, shown in the column entitled "Displaying Context During Exceptions" of the table. If the SDK displays the context, the `OS_FPrintf` function used for display cannot be used in the FINALROM build. Context cannot be displayed in the FINALROM build when it says OK (as displayed by the SDK). OK (as displayed by the debugger) means that the debugger displays the context. Therefore, displaying the context is possible even in the FINALROM build.

Also, items under "Calling User's Exception Handlers" in the table are not dependent on the type of build (whether or not it was a FINALROM build).

Note that this table is divided by the operating environment. For example, the context cannot be displayed on IS-TWL-DEBUGGER when an exception occurs with a hybrid ROM that is running in NITRO mode, but it can be displayed on IS-NITRO-DEBUGGER if the same ROM is running in the same mode.

For NITRO Mode:
Operating Environment | Displaying Contexts During Exceptions: | Calling Users' Exception Handlers:
--- | --- | ---
Actual DS unit | N/A (There is no console) | OK
Actual TWL unit | N/A (There is no console) | OK
IS-NITRO-DEBUGGER | OK (displayed by SDK) | OK
ENSATA EMULATOR | ??? | ???
IS-TWL-DEBUGGER(For standard development: ARM9) | OK (displayed by debugger) | N/A
IS-TWL-DEBUGGER (For component development: ARM9 + ARM7) | OK (displayed by debugger) | N/A
For TWL Mode:
Operating Environment | Displaying Context During Exceptions: | Calling Users' Exception Handlers:
Actual TWL unit | N/A (There is no console) | OK
IS-TWL-DEBUGGER (For general-purpose development: ARM9) | OK (displayed by debugger) | N/A
IS-TWL-DEBUGGER (for component development: ARM9 + ARM7) | OK (displayed by debugger) | N/A

## Process Flow When Exceptions Occur

The flow for the following exception is for IS-NITRO-DEBUGGER and the actual Nintendo DS and TWL systems. CPU operations stop at the point when the exception occurs on IS-TWL-DEBUGGER, and control shifts to the debugger. Operations, therefore, are as shown in the following figure.

When an exception occurs, control jumps to the exception vector region on IS-NITRO-DEBUGGER and the actual Nintendo DS and TWL systems. As previously mentioned, the high vectors are usually used for exception vectors, but for a data abort exception, control will move to `0xFFFFFF10`.

Control then moves to the address stored in `HW_EXCP_VECTOR_MAIN` (`0x2FFFFD9C`) in the system area. (In the ARM7, this address is located at the dedicated work RAM offset `0x7FDC`.) The address of the TWL-SDK's exception handler is set here.

The TWL-SDK's exception handler will display the context when an exception occurs, and then call the user-defined handler registered with the `OS_SetUserExceptionHandler` function, if such a handler exists.

The program then stops.

## See Also

`List of OS Functions (Exception)
`

## Revision History

2009/07/01 Described the differences in behavior depending on the environment.
2008/04/18 Added a table of context display environments when exceptions occur.
2005/03/08 Standardized the Japanese term for "interrupt."
2004/12/14 Revised terminology and word endings.
2004/11/16 Initial version.

CONFIDENTIAL