Exception and

Interrupt
Handling
Prof.Vidyasagar Mulge
Sandstone Code Structure
• 1.Take the Reset exception
• 2 Start initializing the hardware
• 3 Remap memory
• 4 Initialize communication hardware
• 5 Bootloader—copy payload and relinquish control
Introduction:
• Exception handlers are responsible for handling errors,
interrupts, and other events generated by the external system.
• In this chapter we will cover the theory and practice of
handling exceptions, and specifically the handling of interrupts
on the ARM processor.
• The ARM processor has seven exceptions that can halt the
normal sequential execution of instructions:
• Data Abort,Fast Interrupt Request, Interrupt Request, Prefetch
Abort, Software Interrupt, Reset, and Undefined Instruction.
Exception Handling
• An exception is any condition that needs to halt the normal sequential
execution of instructions.
• Examples are:
• when theARMcore is reset, when an instruction fetch or memory access fails,
when an undefined instruction is encountered, when a software interrupt
instruction is executed, or when an external interrupt has been raised.
• Exception handling is the method of processing these exceptions.
• This section covers the following exception handling topics:
• ■ ARM processor mode and exceptions
• ■ Vector table
• ■ Exception priorities
• ■ Link register offsets
 ARM Processor Exceptions and
Modes
• Each exception causes the core to enter a specific mode. In addition,
any of the ARM processor modes can be entered manually by
changing the cpsr. User and system mode are the only two modes
that are not entered by a corresponding exception, in other words, to
enter these modes you must modify the cpsr.
• ■ saves the cpsr to the spsr of the exception mode
• ■ saves the pc to the lr of the exception mode
Vector Table:A table of addresses it indicates to the ARM core branches when
an exception is raised.
Address contains branch instructions in one of the following form.

• B <address>—This branch instruction provides a branch relative from

the pc.
• LDR pc, [pc, #offset]—This load register instruction loads the handler
address from memory to the pc.
• LDR pc, [pc, #-0xff0]—This load register instruction loads a specific
interrupt service routine address from address 0xfffff030 to the pc.
This specific instruction is only used when a vector interrupt
controller is present (VIC PL190).
• MOV pc, #immediate—This move instruction copies an immediate
value into the pc.
Vector table:
Exception Priorities:
• Exceptions can occur simultaneously, so the processor has to adopt a
priority mechanism.
• The Reset exception is the highest priority and occurs when power is
applied to the processor. Thus, when a reset occurs, it takes
precedence over all other exceptions.
• when a Data Abort occurs, it takes precedence over all other
exceptions apart from a Reset exception.
• The lowest priority level is shared by two exceptions, the Software
Interrupt and Undefined Instruction exceptions.
• Data Abort exceptions occur when the memory controller or MMU
indicates that an invalid memory address has been accessed
• An FIQ exception can be raised within a Data Abort handler since FIQ
exceptions are not disabled. When the FIQ is completely serviced,
control is returned back to the Data Abort handler.
• A Fast Interrupt Request (FIQ) exception occurs when an external
peripheral sets the FIQ pin to nFIQ. An FIQ exception is the highest
priority interrupt.
Link Register Offsets:
• When an exception occurs, the link register is set to a specific address
based on the current pc. For instance, when an IRQ exception is
raised, the link register lr points to the last executed instruction plus
8.
• Care has to be taken to make sure the exception handler does not
corrupt lr because lr is used to return from an exception handle.
• Example:This example shows that a typical method of returning from an IRQ and FIQ
handler is to use a SUBS instruction:
handler
<handler code>
...
SUBS pc, r14, #4 ; pc=r14-4
Example2:This example shows another method that subtracts the offset from the link
register r14 at the beginning of the handler.
handler
SUB r14, r14, #4 ; r14-=4
<handler code>
...
MOVS pc, r14 ; return
After servicing is complete, return to normal execution occurs by moving the link register
r14 into the pc and restoring cpsr from the spsr.
Interrupts:
• There are two types of interrupts available on the ARMprocessor.
• The first type of interrupt causes an exception raised by an external
peripheral—namely, IRQ and FIQ.
• The second type is a specific instruction that causes an exception—
the SWI instruction.
• Both types suspend the normal flow of a program.
• Assigning interrupts
• ■ Interrupt latency
• ■ IRQ and FIQ exceptions
• ■ Basic interrupt stack design and implementation
Assigning Interrupts:
• A system designer can decide which hardware peripheral can produce
which interrupt request. This decision can be implemented in hardware or
software (or both) and depends upon the embedded system being used.
• An interrupt controller connects multiple external interrupts to one of the
two ARM interrupt requests.
• When it comes to assigning interrupts, system designers have adopted a
standard design practice
• Software Interrupts are normally reserved to call privileged operating
system routines.For example, an SWI instruction can be used to change a
program running in user mode to a privileged mode.
• Interrupt Requests are normally assigned for general-purpose interrupts.
For example, a periodic timer interrupt to force a context switch tends to
be an IRQ exception
• Fast Interrupt Requests are normally reserved for a single interrupt source
that requires a fast response time—for example, direct memory access
specifically used to move blocks of memory.
• Interrupt Latency:
• Interrupt latency refers to the time delay between when a hardware
interrupt signal is generated and when the corresponding interrupt service
routine (ISR) begins execution.
• Interrupt-driven embedded systems have to fight a battle with interrupt
latency—
• Interrupt latency depends on a combination of hardware and software.
• System architects must balance the system design to handle multiple
simultaneous interrupt sources and minimize interrupt latency.
• If the interrupts are not handled in a timely manner, then the system will
exhibit slow response times.
• Software handlers have two main methods to minimize interrupt latency.
• The first method is to use a nested interrupt handler, which allows further
interrupts to occur even when currently servicing an existing interrupt .

This is achieved by reenabling the

interrupts as soon as the interrupt
source has been serviced (so it won’t
enerate more interrupts) but before
the interrupt handling is complete.
Once a nested interrupt has been
serviced, then control is relinquished
to the original interrupt service
routine.
fig:A three-level nested interrupt.
• The second method involves prioritization:
• The interrupt controller to ignore interrupts of the same or lower priority
than the interrupt you are handling, so only a higher-priority task can
interrupt your handler.
• The processor spends time in the lower-priority interrupts until a higher-
priority interrupt occurs. Therefore higher-priority interrupts have a
lower average interrupt latency than the lower-priority interrupts, which
reduces latency by speeding up the completion time on the critical time-
sensitive interrupts.
 IRQ and FIQ Exceptions
• IRQ and FIQ exceptions only occur when a specific interrupt mask is cleared in
the cpsr.
• An IRQ or FIQ exception causes the processor hardware to go through a
standard procedure:
• 1. The processor changes to a specific interrupt request mode, which reflects
the interrupt being raised.
• 2. The previous mode’s cpsr is saved into the spsr of the new interrupt request
mode.
• 3. The pc is saved in the lr of the new interrupt request mode.
• 4. Interrupt/s are disabled—either the IRQ or both IRQ and FIQ exceptions are
disabled in the cpsr. This immediately stops another interrupt request of the
same type being raised.
• 5. The processor branches to a specific entry in the vector table.
 Enabling and Disabling FIQ and IRQ Exceptions

• The ARM processor core has a simple procedure to manually enable

and disable interrupts that involves modifying the cpsr when the
processor is in a privileged mode.
• The procedure uses three ARM instructions.
• The first instruction MRS copies the contents of the cpsr into register
r1.
• The second instruction clears the IRQ or FIQ mask bit.
• The third instruction then copies the updated contents in register r1
back into the cpsr, enabling the interrupt request.
 Basic Interrupt Stack Design and Implementation
• Exceptions handlers make extensive use of stacks, with each mode having a dedicated
register containing the stack pointer. The design of the exception stacks depends upon
these factors:
• 1.Operating system requirements—Each operating system has its own requirements for
stack design.
• 2.Target hardware—The target hardware provides a physical limit to the size and
positioning of the stack in memory.
• Two design decisions need to be made for the stacks:
• ■ The location determines where in the memory map the stack begins. Most ARM-based
systems are designed with a stack that descends downwards, with the top of the stack at a
high memory address.
• ■ Stack size depends upon the type of handler, nested or nonnested. A nested interrupt
handler requires more memory space since the stack will grow with the number of nested
interrupts.
• A good stack design tries to avoid stack overflow—where the stack
extends beyond the allocated memory—because it causes instability in
embedded systems.
• There are software techniques that identify overflow and that allow
corrective measures to take place to repair the stack before irreparable
memory corruption occurs.
The two main methods are
• (1) to use memory protection and (2) to call a stack check function at the
start of each routine.
The first layout, A, shows a traditional
stack layout with the interrupt stack
stored underneath the code segment.
The second layout, B, shows the
interrupt stack at the top of the
memory above the user stack.
The main advantage of layout B over A
is that B does not corrupt the vector
table when a stack overflow occurs,
and so the system has a chance to
correct itself when an overflow has
been identified.
 Firmware
• Firmware and Bootloader:
• The firmware is the deeply embedded, low-level software that
provides an interface between the hardware and the
application/operating system level software.
• It resides in the ROM and executes when power is applied to the
embedded hardware system. Firmware can remain active after
system initialization and supports basic system operations.
• The bootloader is a small application that installs the operating
system or application onto a hardware target.
• The bootloader only exists up to the point that the operating system
or application is executing, and it is commonly incorporated into the
firmware.
• Diagnostics software provides a useful way for quickly identifying basic
hardware malfunctions. Because of the nature of this type of software, it tends
to be specific to a particular piece of hardware.
• Debug capabiliy is provided in the form of a module or monitor that provides
software assistance for debugging code running on a hardware target.
• This assistance includes the following:
• ■ Setting up breakpoints in RAM. A breakpoint allows a program to be
interrupted and the state of the processor core to be examined.
• ■ Listing and modifying memory (using peek and poke operations).
• ["peek" and "poke" are commands used to directly access memory addresses.
• Peek" retrieves the value stored at a specific memory location, while "poke"
writes a value into a specific memory location
• ■ Showing current processor register contents.
• ■ Disassembling memory into ARM and Thumb instruction mnemonics.
• you can either send the commands through a command line interpreter
(CLI) or through a dedicated host debugger attached to the target
platform.
• The second stage is to abstract the hardware. The Hardware Abstraction
Layer (HAL) is a software layer that hides the underlying hardware by
providing a set of defined pro_x0002_gramming interfaces.
• When you move to a new target platform, these programming interfaces
remain constant but the underlying implementation changes.
• The HAL software that communicates with specific hardware peripherals
is called a device driver. A device driver provides a standard application
programming interface (API) to read and write to a specific peripheral
 ARM Firmware Suite:
• ARM has developed a firmware package called the ARM Firmware Suite
(AFS). AFS is designed purely for ARM-based embedded systems. It
provides support for a number of boards and processors including the
Intel XScale and StrongARM processors.
• The package includes two major pieces of technology, a Hardware
Abstraction Layer called μHAL (pronounced micro-HAL) and a debug
monitor called Angel.
• μHAL provides a low-level device driver framework that allows it to
operate over dif_x0002_ferent communication devices (for example,
USB, Ethernet, or serial).
μHAL supports these main features:
• ■ System initialization—setting up the target platform and processor core.
Depending upon the complexity of the target platform, this can either be a
simple or complicated task.
• ■ Polled serial driver—used to provide a basic method of communication
with a host.
• ■ LED support—allows control over the LEDs for simple user feedback. This
provides an application the ability to display operational status.
• ■ Timer support—allows a periodic interrupt to be set up. This is essential
for preemptive context switching operating systems that require this
mechanism.
• ■ Interrupt controllers—support for different interrupt controllers.
Red Hat RedBoot
• RedBoot is a firmware tool developed by Red Hat. It is provided under
an open source license with no royalties or up front fees. RedBoot is
designed to execute on different CPUs (for instance, ARM, MIPS, SH,
and so on)
• The RedBoot software core is based on a HAL.
• Communication—configuration is over serial or Ethernet. For serial, X-
Modem protocol is used to communicate with the GNU Debugger
(GDB). For Ethernet, TCP is used to communicate with GDB. RedBoot
supports a range of network standards, such as bootp, telnet, and tftp.
• [The GNU Debugger (GDB) is a powerful, command-line debugger used
for debugging programs written in various languages, including C, C++,
and Fortran.]
• Flash ROM memory management—provides a set of filing system
routines that can download, update, and erase images in flash ROM.
In addition, the images can either be compressed or uncompressed.
• Full operating system support—supports the loading and booting of
Embedded Linux, Red Hat eCos, and many other popular operating
systems. For Embedded Linux,RedBoot supports the ability to define
parameters that are passed directly to the kernel upon booting.
• We have designed Sandstone to be a minimal system. It carries out
only the following tasks: set up target platform environment, load a
bootable image into memory, and relinquish control to an operating
system.
• The implementation is specific to the ARM Evaluator-7T platform,
which includes an ARM7TDMI processor. This example shows you
exactly how a simple platform can be set up and a software payload
can be loaded into memory and booted.
Sandstone Directory Layout
The object file produced by the assembler is placed under the build/obj
directory.
The object file is then linked, and the final Sandstone image is placed under
the sand/build/image directory.
This image includes both the Sandstone code and the pay_x0002_load. The
payload image, the image that is loaded and booted by Sandstone, is found
under
the sand/payload directory.
Sandstone Code Structure
• Sandstone consists of a single assembly file. The file structure is
broken down into a number of steps, where each step corresponds to
a stage in the execution flow of Sandstone.
• Step Description
• 1 Take the Reset exception
• 2 Start initializing the hardware
• 3 Remap memory
• 4 Initialize communication hardware
• 5 Bootloader—copy payload and relinquish control
• Take the Reset Exception:
• Execution begins with a Reset exception. Only the reset vector entry is
required in the default vector table. It is the very first instruction
executed.
Step 2: Start Initializing the
Hardware
• The primary phase in initializing hardware is setting up system
registers. These registers have to be set up before accessing the
hardware. For example, the ARM Evaluator-7T has a seven-segment
display, which we have chosen to be used as a feedback tool to
indicate that the firmware is active.
 Step 3: Remap Memory
• One of the major activities of hardware initialization is to set up the memory
environment.
• Sandstone is designed to initialize SRAM and remap memory. This process occurs
fairly early on in the initialization of the system.
• when the platform is powered up, only flash ROM is assigned a location in the
memory map. The two SRAM banks (0 and 1) have not been initialized and are not
available.
 Initialize Communication Hardware
• Communication initialization involves configuring a serial port and
outputting a standard banner. The banner is used to show that the
firmware is fully functional and memory has been successfully
remapped.
• The results of executing step 4 are the following:
• ■ Serial port initialized—9600 baud, no parity, one stop bit, and no
flow control.
• ■ Sandstone banner sent out through the serial port:
Step 5: Bootloader—Copy Payload and Relinquish Control