# Exception (Overview)

## Introduction

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

### Initialize for Display of Exceptions

NitroSDK includes a system for displaying information when processor exceptions occur. The register and type of exception get displayed. The exception display system is enabled by initialization using `OS_InitException()`. But since this function gets called from `OS_Init()`, it does not need to be called if `OS_Init()` has been called by the application.

This initialization function sets the SDK exception vector (the address for transfer of control when an exception occurs) to the address of the function that displays exceptions. IS-NITRO-DEBUGGER does not perform this exception display process because some debug features make use of exceptions. The current operating environment is determined automatically, so nothing is required from the application.

The exception display system is a debug feature, so it is disabled in the FINALROM build.

### Positioning the Exception Vector

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

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

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

NitroSDK uses the high vectors by default. Unless you have a special reason, use the high vectors and do not change the settings.

### Setting a User Handler

When exceptions occur, control can be transferred to a user-specified exception handler. To do this, register the handler with `OS_SetUserExceptionHandler()`.

### Process Flow After an Exception Occurs

The following exceptions exist for ARM:

Exception type | Normal vector address | High vector address
--- | --- | ---
Reset | `0x00000000` | `0xFFFF0000`
Undefined instructions | `0x00000004` | `0xFFFF0004`
Software interrupt | `0x00000008` | `0xFFFF0008`
Pre-fetch abort | `0x0000000C` | `0xFFFF000C`
Data abort | `0x00000010` | `0xFFFF0010`
IRQ | `0x00000018` | `0xFFFF0018`
FIQ | `0x0000001C` | `0xFFFF001C`

Because IRQ exceptions are used as interrupts, they are excluded from the process flow described below. (For more details, see Interrupts (overview).)

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.

After that, if IS-NITRO-DEBUGGER is being used, control is transferred to a special debugger process routine. The program is reset for this debugger process, so the flow steps described below are for cases where IS-NITRO-DEBUGGER is not being used.

If IS-NITRO-DEBUGGER is not being used, control is transferred to the address stored in DTCM's `HW_EXCP_VECTOR_BUF`. In the ARM9, this address takes position at the DTCM offset `0x3FDC`. In the ARM7, this address takes position at the dedicated work RAM offset `0x7FDC`. Here, what gets set is the address of the NitroSDK function for displaying exception information. (This is set by `OS_InitException()`.)

The user handler is called within this routine (if a user handler was registered with `OS_SetUserExceptionHandler()`). The program then stops.

### Example

In the example below, a data abort exception has occurred. The high vector fake address for a data abort exception is `0xFFFF0010`, so the process jumps to `0xFFFF0010`. This leads to the address stored in `HW_EXCP_VECTOR_BUF`, and control is transferred to the SDK's exception display routine. After the register information and other information about the exception are displayed, the user handler is called. This process flow is shown schematically below.

## See Also

List of OS Functions (Exception)

## Revision History

11/16/2004 Initial version