User guide

ManualsBrandsARM ManualsComputer HardwareVERSION 1.2

6.3 Initializing the system

There are two initialization stages:

1. Initializing the execution environment, for example exception vectors, stacks, I/O.

2. Initializing the C library and application (C variables for example).

For a hosted application, the execution environment was initialized when the OS starts (initialization is done by, for

example, Angel, an RTOS, or ARMulator). The application is then entered automatically through the main()

function. The C library code at __main initializes the application.

For an embedded application without an operating system, the code in ROM must provide a way for the application

to initialize itself and start executing. No automatic initialization takes place on reset, so the application entry point

must perform some initialization before it can call any C code.

After reset, the instruction located at address 0x0, must transfer control to the initialization code. The initialization

code must:

• set up exception vectors

• initialize the memory system

• initialize the stack pointer registers

• initialize any critical I/O devices

• change processor mode if necessary

• change processor state if necessary.

After the environment has been initialized, the sequence continues with the application initialization and should enter

the C code.

These items are described in more detail below. See Example 6-3 and Example 6-4 for code examples.

6.3.1 Initializing the execution environment

There are some aspects of the execution environment that must be initialized before the application starts. If the

application is hosted by an operating system, the initialization will be done by the application loader. If the application

runs standalone, the C library can perform the initialization of the environment and call the application entry point at

main(). If you are using scatter loading, however, you must retarget __user_intial_stackheap() to initialize

the stack and heap. An example of how to do this is in retarget.c.

The state of ARM processor cores after reset is:

• SVC mode

• interrupts disabled

• ARM state.

Identifying the entry point

An executable image must have an entry point. An embedded image that can be placed in ROM usually has an entry

point at 0x0. An entry point can be defined in the initialization code by using the assembler directive ENTRY. It is

possible to have multiple entry points in an embedded application. When there are multiple entry points, one of the

points must be specified as the initial entry point by using -entry. See also the section on linker selection of entry

points in the Linker and Utilities Guide

If you have created a C program that includes a main() function, there is also an entry point within the C library

initialization code. See also the library chapter in Linker and Utilities Guide

for more information on creating

applications that use the library.

Setting up exception vectors

Your initialization code must set up the required exception vectors, as follows:

• If the ROM is located at address 0x0, the vectors consist of a sequence of hard-coded instructions to branch to

the handler for each exception.

• If the ROM is located elsewhere, the vectors must be dynamically initialized by the initialization code. Typically

this is done by copying the vector table from ROM to RAM (See Using both scatter loading and remapping).

See Example 6-4 for a listing of typical initialization code.

Initializing the memory system

If your system has a Memory Management or Protection Unit, you must make sure that it is initialized:

• before interrupts are enabled

• before any code is called that might rely on RAM being accessible at a particular address, either explicitly, or

implicitly through the use of stack.

Writing Code for ROM