Comtrol eCos - Manual (Page 301)

Chapter 10. Exception Handling
Most of the HAL consists of simple macros or functions that are called via the interfaces described in the previous
section. These just perform whatever operation is required by accessing the hardware and then return. The exception
to this is the handling of exceptions: either synchronous hardware traps or asynchronous device interrupts. Here
control is passed first to the HAL, which then passed it on to eCos or the application. After eCos has finished with
it, control is then passed back to the HAL for it to tidy up the CPU state and resume processing from the point at
which the exception occurred.
The HAL exceptions handling code is usually found in the file vectors.S in the architecture HAL. Since the reset
entry point is usually implemented as one of these it also deals with system startup.
The exact implementation of this code is under the control of the HAL implementer. So long as it interacts correctly
with the interfaces defined previously it may take any form. However, all current implementation follow the same
pattern, and there should be a very good reason to break with this. The rest of this section describes these operate.
Exception handling normally deals with the following broad areas of functionality:
• Startup and initialization.
• Hardware exception delivery.
• Default handling of synchronous exceptions.
• Default handling of asynchronous interrupts.
HAL Startup
Execution normally begins at the reset vector with the machine in a minimal startup state. From here the HAL
needs to get the machine running, set up the execution environment for the application, and finally invoke its entry
point.
The following is a list of the jobs that need to be done in approximately the order in which they should be accom-
plished. Many of these will not be needed in some configurations.
• Initialize the hardware. This may involve initializing several subsystems in both the architecture, variant and
platform HALs. These include:
• Initialize various CPU status registers. Most importantly, the CPU interrupt mask should be set to disable
interrupts.
• Initialize the MMU, if it is used. On many platforms it is only possible to control the cacheability of address
ranges via the MMU. Also, it may be necessary to remap RAM and device registers to locations other than
their defaults. However, for simplicity, the mapping should be kept as close to one-to-one physical-to-virtual
as possible.
• Set up the memory controller to access RAM, ROM and I/O devices correctly. Until this is done it may not be
possible to access RAM. If this is a ROMRAM startup then the program code can now be copied to its RAM
address and control transferred to it.
197