User guide

ManualsBrandsARM ManualsComputer HardwareVERSION 1.2

Data Abort

Occurs when a data transfer instruction attempts to load or store data at an illegal address.

Interrupt (IRQ)

Occurs when the processor external interrupt request pin is asserted (LOW) and IRQ interrupts

are enabled (the I bit in the CPSR is clear).

Fast Interrupt (FIQ)

Occurs when the processor external fast interrupt request pin is asserted (LOW) and FIQ

interrupts are enabled (the F bit in the CPSR is clear). This exception is typically used where

interrupt latency must be kept to a minimum.

In general, if you are writing an application such as an embedded application that does not rely on an operating

system to service exceptions, you must write handlers for each exception type.

In cases where an exception type can have more than one source, for example SWI or IRQ interrupts, you can chain

exception handlers for each source. See Chaining exception handlers for more information.

On Thumb-capable processors, the processor switches to ARM state when an exception is taken. You can either

write your exception handler in ARM code, or use a veneer to switch to Thumb state. See Handling exceptions on

Thumb-capable processors for more information.

1.3.5 Writing Code for ROM

Many applications written for ARM-based systems are embedded applications that are contained in ROM and

execute on reset. There are a number of factors that you must consider when writing embedded operating systems,

or embedded applications that execute from reset without an operating system, including:

• address remapping, for example initializing with ROM at address 0, then remapping RAM to address 0

• initializing the environment and application

• linking an embedded executable image to place code and data in specific locations in memory.

The ARM core usually begins executing instructions from address 0 at reset. For an embedded system, this means

that there must be ROM at address 0 when the system is reset. Typically, however, ROM is slow compared to RAM,

and often only 8 or 16 bits wide. This affects the speed of exception handling. Having ROM at address 0 means that

the exception vectors cannot be modified. A common strategy is to remap ROM to RAM and copy the exception

vectors from ROM to RAM after startup. See Memory map considerations for more information.

After reset, an embedded application or operating system must initialize the system, including:

• initializing the execution environment, such as exception vector, stacks, and I/O peripherals

• initializing the application, for example copying initial values of nonzero writable data to the writable data region

and zeroing the ZI data region.

See Initializing the system for more information.

Embedded systems often implement complex memory configurations. For example, an embedded system might use

fast, 32-bit RAM for performance-critical code, such as interrupt handlers and the stack, slower 16-bit RAM for

application RW data, and ROM for normal application code. You can use the linker scatter loading mechanism to

construct executable images suitable for complex systems. For example, a scatter load description file can specify

the load address and execution address of individual code and data regions. See Chapter 6 Writing Code for ROM

for a series of worked examples, and for information on other issues that affect embedded applications, such as

semihosting.

1.3.6 Caches and tightly coupled memory

Many ARM cores such as ARM920T have caches integrated onto the same chip as the CPU. Some ARM cores such

as ARM966E-S have tightly coupled memory integrated onto the same chip as the CPU.

Both caches and tightly coupled memory can improve system performance and reduce power consumption by

reducing off-chip memory accesses. Tightly coupled memory has more predictable real-time behavior, and requires

less area of silicon than caches. Caches can provide improved performance over the whole address range.

See Chapter 7 Caches and Tightly Coupled Memories for more information.

1.3.7 Using the Debug Communications Channel

The EmbeddedICE® logic in ARM cores such as ARM7TDMI® and ARM9TDMI™ supports a debug communication

channel. This enables data to be passed between the target and the host debugger using the JTAG port and a

protocol converter such as Multi-ICE®, without stopping the program flow or entering debug state. See Chapter 8

Debug Communications Channel for more information.

Introduction