Module 4: Exception and Interrupt Handling

Introduction

 Embedded systems rely heavily on exception handlers.

 Exception handlers manage errors, interrupts, and other events from external sources.
 Well-designed handlers can significantly boost system performance.
 Choosing the right handling method can be complex, but also interesting and rewarding.
 This chapter focuses on exception handling and specifically interrupt handling on ARM
processors.
 ARM processors have seven types of exceptions that can disrupt normal execution:

 Data Abort
 Fast Interrupt Request
 Interrupt Request
 Prefetch Abort
 Software Interrupt
 Reset
 Undefined Instruction

 The chapter is structured into three main parts:

 Exception handling: Details how the ARM processor manages exceptions.

 Interrupts: Explains interrupts as a special type of exception and introduces terms and
mechanisms related to handling them.
 Interrupt handling schemes: Presents various methods for handling interrupts, each
accompanied by an example implementation.
9.1 Exception Handling
 ARM processor mode and exceptions
 Vector table
 Exception priorities
 Link register offsets

9.1.1.ARM Processor Exceptions and Modes

(Explain the role of exceptions and modes in ARM processors)

 Table 9.1 shows the exceptions for the ARM processor.
 Each exception switches the core into a specific mode.
 Modes like User and System can only be entered by manually changing the cpsr.
 When an exception changes the mode, the core switches automatical.
9.1.2 Vector Table
(Discuss the role and structure of the Vector Table in ARM microcontrollers. )
Vector Table in ARM Microcontrollers:

 Purpose: Stores addresses of interrupt service routines (ISRs).

 Location: Typically resides at a fixed memory location, often at the start of the program
memory.
 Contents: Contains entries for different interrupt sources (IRQs, FIQs, etc.).
 Structure: Each entry holds the address where the processor jumps when an interrupt
occurs.
 Initialization: Programmed during system initialization to handle specific interrupts
efficiently.
 Customization: Can be customized for different application needs, allowing
prioritization and management of interrupts.
9.1.3 Exception Priorities

(Explain the concept of exception priorities in ARM processors, as detailed in handling exceptions.
Describe the priority mechanism employed by ARM processors for managing simultaneous exceptions )
Handling Exceptions in ARM Processors:

 Priority Mechanism: Due to possible simultaneous exceptions, ARM processors employ

a priority system.
 Table 9.3 Overview: Lists exceptions and their priority levels on the ARM processor.
 Example: Reset Exception: Highest priority, triggers during power-up, initializes the
system.
 Data Abort Exception: Occurs for invalid memory accesses or permission issues, high
priority after Reset.
 Interrupt Setup: External interrupts should be initialized before enabling IRQ or FIQ
interrupts to prevent spurious interrupts.
 Nested Exceptions: FIQ exceptions can occur within Data Abort handlers, as FIQs aren't
disabled during Data Aborts.
 IRQ and FIQ handlers disable corresponding exceptions upon entry to prevent external
interruptions.
 FIQ, abort, SWI, and IRQ handlers are designed for efficient exception handling.
 IRQ exception triggered by external peripheral signaling.
 Prefetch Abort caused by memory faults during instruction fetch.
 SWI switches processor to supervisor mode upon execution.
 Undefined Instruction exception occurs for unrecognized instructions in ARM or Thumb
sets.
9.1.4 Link Register Offsets
(Explain the significance of the link register (lr) in ARM microcontrollers, particularly in the context of
exception handling such as IRQs.)

 Link Register (lr):

 In ARM microcontrollers, the link register (lr) is a special register that holds the return
address for function calls and exceptions.
 When an exception (like an IRQ - Interrupt Request) occurs, the processor saves the
address of the instruction that was being executed into the link register (lr).
 For example, if the exception happened at instruction address 0x1000, lr would typically
hold 0x1008 (current instruction address + 8 bytes).

 Avoiding Corruption:

 It's critical not to overwrite or corrupt the link register (lr) when handling exceptions
because it's needed to return to where the main program execution should continue after
handling the exception.

 IRQ Exception Handling:

 When an IRQ exception is handled, the processor ensures that after the exception handler
finishes, it returns to the instruction immediately following the one that was interrupted.
 Therefore, lr should be set to (current lr value - 4) to ensure it points to the correct return
address.

 Table 9.4:

 This table (which would be provided in ARM documentation or reference manuals) lists
important addresses and offsets related to different types of exceptions. It helps
developers understand how to manage return addresses correctly during exception
handling.

 Returning from Exception Handlers:

 After an exception handler (like an IRQ handler) finishes its job, it must set lr to the
appropriate value to resume execution correctly.
 Typically, for IRQs, lr is set to (current lr value - 4) to point to the next instruction after
the interrupted one.
ARM microcontrollers (MCUs) often use interrupts to handle events asynchronously. When
an interrupt occurs, the processor stops its current execution, saves its current state, and
jumps to an Interrupt Service Routine (ISR) to handle the interrupt. After handling the
interrupt, it needs to return to the interrupted task. This example illustrates how that return
process typically works in ARM assembly language.

Example 9.2 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

Interrupt Handling: When an interrupt occurs, the microcontroller saves where it was
interrupted (in the lr register) and starts running the ISR code.

Returning from ISR: To go back to the interrupted task, the ISR uses SUBS pc, lr, #4. This
instruction subtracts 4 from the lr register and sets the Program Counter (pc) to this new value.

Automatic Restoration: The SUBS instruction also restores important flags that tell the
microcontroller's processor about its current state (CPSR), ensuring everything continues
smoothly.
Example 9.3 This example shows another method that subtracts the offset from the link register
r14 at the beginning of the handler.

9.2 Interrupts
Types of Interrupts on ARM Processors

1. External Peripheral Interrupts (IRQ and FIQ):

o These interrupts are triggered by external devices connected to the ARM
processor, such as sensors or communication modules.
o IRQ (Interrupt Request): Used for general-purpose interrupts.
o FIQ (Fast Interrupt Request): Used for urgent or high-priority interrupts that
need faster processing.
2. Software Interrupt (SWI):
o This is a specific instruction (SWI) that a program can execute to request a service
from the operating system or supervisor mode.
o It's used for controlled software-based exceptions.

Interrupt Effects

 Interrupts Suspend Normal Program Flow: When an interrupt occurs, the ARM
processor temporarily stops executing its current task and jumps to handle the interrupt.
This is to quickly respond to external events or software requests.

In this section we will focus mainly on IRQ and FIQ interrupts. We will cover these topics:

■ Assigning interrupts

■ Interrupt latency

■ IRQ and FIQ exceptions

■ Basic interrupt stack design and implementation

Assigning interrupts

(Discuss the process of assigning interrupts in embedded systems.)

 System Design Choice: Designers choose which hardware devices can trigger which types of
interrupts, using either hardware, software, or a combination. This decision depends on the
specific embedded system requirements.

 Interrupt Controller: This hardware component connects external devices to ARM

processors and can be configured to direct interrupts to either IRQ or FIQ exceptions. Advanced
controllers allow flexibility in assigning interrupt sources.

 Standard Practice:

 Software Interrupts (SWI): Reserved for calling privileged operating system routines,
like switching program modes.
 Interrupt Requests (IRQ): Typically used for general-purpose interrupts, such as
periodic timers. IRQs have lower priority and slightly longer latency compared to FIQs.
 Fast Interrupt Requests (FIQ): Dedicated to urgent tasks needing immediate
processing, like memory block transfers. FIQs are used for specific applications, freeing
IRQs for broader system operations in embedded designs.

Interrupt Latency

(Explain the concept of interrupt latency in embedded systems. Describe factors that contribute to
interrupt latency and techniques to minimize it.)

 Definition: Interrupt latency is the time from when an external interrupt signal is raised
to when the processor starts executing the specific Interrupt Service Routine (ISR) code.

 Factors Affecting Interrupt Latency:

o Hardware and Software Combination: It depends on both the hardware setup
(like interrupt controllers) and the software implementation (ISR handling).
o System Design: Architects must balance the system to manage multiple interrupt
sources efficiently and minimize latency.

 Importance: Minimizing interrupt latency is crucial because delays can lead to slower
system response times, impacting overall system performance.

 Methods to Minimize Interrupt Latency:

 o Nested Interrupt Handlers: Allows handling of new interrupts while already
servicing an ongoing interrupt. This is done by re-enabling interrupts as soon as
the current interrupt source is serviced, before completing the handling of the
current interrupt.
o Ensuring Timely Handling: Promptly servicing interrupts ensures that the
system responds quickly to external events, maintaining efficiency and
responsiveness.

9.2.3 IRQ and FIQ Exceptions

(Describe IRQ (Interrupt Request) and FIQ (Fast Interrupt Request) exceptions in ARM microcontrollers. )

IRQ and FIQ Exceptions

 Triggering Conditions: IRQ and FIQ exceptions occur when their respective interrupt
masks are cleared in the Current Program Status Register (CPSR), allowing interrupts of
that type to be processed.
 Execution Stage Consideration: Before handling the interrupt, the ARM processor
completes the current instruction in its execution stage. This ensures determinism in
interrupt handling, especially for instructions that require multiple cycles to complete.
 Standard Procedure for IRQ and FIQ Exceptions:
1. Mode Change: The processor switches to a specific interrupt request mode
corresponding to the type of interrupt raised (IRQ or FIQ).
2. Saving State:
 The CPSR of the previous mode is saved into the Saved Program Status
Register (SPSR) of the new interrupt request mode.
 The Program Counter (PC) value is saved into the Link Register (LR) of
the new mode.
 3. Disabling Interrupts: IRQ or both IRQ and FIQ exceptions are disabled in the
CPSR. This prevents another interrupt of the same type from interrupting the
current handler.
4. Branch to Vector Table: The processor jumps to a specific entry in the vector
table, which contains addresses of interrupt service routines corresponding to
different interrupt types.
 Variations in Procedure: The exact handling varies slightly between IRQ and FIQ
exceptions due to their different characteristics and priorities.

9.2.3.1 Enabling and Disabling FIQ and IRQ Exceptions

(Explain the process of enabling and disabling FIQ (Fast Interrupt Request) and IRQ (Interrupt Request)
exceptions on ARM microcontrollers.)

 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.

 Table 9.5 shows how IRQ and FIQ interrupts are enabled. 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 registerr1 back into the cpsr, enabling the interrupt request.
Disabling or Masking IRQ and FIQ Exceptions

 Procedure: Similarly in privileged mode, modify CPSR using:

1. MRS Instruction: Copy CPSR to register r1.
2. Setting IRQ/FIQ Mask Bit: Update r1 to set the specific IRQ or FIQ mask bit.
3. MSR Instruction: Copy r1 back to CPSR to disable or mask the interrupt
request.

9.2.4 Basic Interrupt Stack Design and Implementation

(Explain the fundamental considerations in designing and implementing interrupt stacks for ARM
microcontrollers.)

 Interrupt Stack Basics: Interrupts and exceptions in ARM microcontrollers use dedicated
stacks. Each mode (like IRQ) has its own stack pointer register for efficient context switching.

 Factors Influencing Stack Design: Stack design depends on:

 Operating System Requirements: Different operating systems have specific needs for
how stacks are organized and managed.
 Target Hardware: Physical memory limits dictate where stacks can be located and their
maximum size.

 Design Decisions:

 Location: Typically, stacks grow downwards in memory. This ensures efficient use of
memory and clear boundaries between different memory regions.
 Size: The stack size depends on whether the system needs to handle nested interrupts
(where interrupts can occur while another interrupt is being processed). More complex
interrupt handling requires larger stacks.
 Avoiding Stack Overflow: Stack overflow occurs when the stack extends beyond its
allocated memory, leading to system instability. Techniques to prevent this include:

 Memory Protection: Setting boundaries to prevent stack overflow.

 Stack Check Functions: These functions monitor stack usage and can take corrective
actions if overflow is imminent.

 IRQ Mode Stack Setup: Before enabling interrupts, the IRQ mode stack must be properly
configured. During system initialization, the maximum stack size should be determined to ensure
sufficient memory allocation.

 Memory Layout Considerations (Figure 9.6):

 Layout A: Traditional stack layout places the interrupt stack below the code segment.
This can risk overwriting critical data if the stack overflows.
 Layout B: In this layout, the interrupt stack is positioned at the top of memory, above the
user stack. This design prevents critical system data corruption in case of a stack
overflow and allows the system to recover more effectively.
Firmware
Firmware is crucial for embedded systems as it's often the first code to run on a
new platform. It can range from a full software system to basic startup and
bootloader functions.

10.1 Firmware and Bootloader

 Firmware is essential low-level software that connects hardware with higher-level
applications or operating systems.
 It's stored in ROM and runs when the device is powered on. Firmware supports basic
system functions even after startup.
 Choosing the right firmware for an ARM-based system depends on the specific needs,
from running a complex OS to just basic operations.
 For instance, a small system may only need minimal firmware to boot a small OS. The
main role of firmware is to reliably load and start an OS.
 A bootloader is a small program within firmware that installs the OS or application onto
the hardware. Once the OS or app starts running, the bootloader's job is done.
 It's typically part of the firmware.
 To compare different firmware types, we use a common execution flow (see Table 10.1).
Each stage prepares the environment for booting an OS by setting up the hardware
platform correctly.
 This involves tasks like initializing control registers or adjusting memory layout to match
OS requirements.
 The first stage is to set up the target platform—in other words, prepare the environment
to boot an operating system since an operating system expects a particular type of
environment before it can operate.
 This step involves making sure that the platform is correctly initialized (for example,
making sure that the control registers of a particular microcontroller are placed at a
known address or changing the memory map to an expected layout).
 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.
 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
programming interfaces.
 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.
 The third stage is to load a bootable image. The ability of firmware to carry out this
activity depends upon the type of media used to store the image. Note that not all
operating system images or application images need to be copied into RAM.
 Relinquishing control on an ARM system means updating the vector table and modifying
the pc.
10.1.1 ARM Firmware Suite

 ARM Firmware Suite (AFS):

 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 different
communication devices (for example, USB, Ethernet, or serial).

The speed of this activity depends upon whether the OS takes advantage of the ported μHAL
API call to access the hardware. μHAL supports these main features:

o System initialization for target platform and processor core.

o Polled serial driver for basic communication.
o LED control for user feedback.
o Timer support for preemptive context switching OS.
o Interrupt controllers for managing interrupts.

Angel Debug Monitor:

 The second technology, Angel, allows communication between a host debugger and a
target platform.
 It allows to inspect and modify memory, download and execute images, set breakpoints,
and display processor register contents.
 All this control is through the host debugger.
 The Angel debug monitor must have access to the SWI and IRQ or FIQ vectors.
 Angel uses SWI instructions to provides a set of APIs that allow a program to open, read,
and write to a host filing system.
 IRQ/FIQ interrupts are used for communication purposes with the host debugger.

10.1.2 Red Hat RedBoot

RedBoot is a firmware tool developed by Red Hat. It is provided under an open source license
with no royalties or upfront fees. RedBoot is designed to execute on different CPUs (for
instance, ARM, MIPS, SH, and so on). It provides both debug capability through GNU
Debugger (GDB), as well as a bootloader. The RedBoot software core is based on a HAL.
RedBoot supports these main features:
 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.
 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.
10.2 Example: Sandstone

 Sandstone is a basic system designed for the ARM Evaluator-7T platform, which uses an
ARM7TDMI processor. Its main tasks are setting up the platform environment, loading a
bootable image into memory, and starting the operating system.
 It demonstrates how to initialize a simple platform and boot software like applications or
operating system images.
 Sandstone is fixed after it's built and uses ARM assembler for its code. It provides a
structured directory layout for source code and build files and focuses on initializing and
booting processes.

10.2.1 Sandstone Directory Layout

Table 10.2 Summary of Sandstone" provides a concise overview of Sandstone's key

characteristics:

 Feature Configuration: Sandstone only supports ARM instructions for its code. This means it
is written exclusively using instructions that the ARM processor can execute.

 Tool chain: Sandstone is built using the ARM Developer Suite 1.2. This tool chain includes
the necessary software tools (like compilers, assemblers, linkers, etc.) needed to develop
software for ARM processors.

 Image size: The size of the bootable image generated by Sandstone is 700 bytes. This
indicates how much space the initial program that Sandstone loads into memory occupies.

 Source: The total size of the source code for Sandstone is 17 KB (Kilobytes). This includes all
the files and lines of code that make up the system.
 Memory remapped: This likely refers to the process within Sandstone where it reconfigures
memory mappings. Memory remapping can involve changing how physical memory addresses
are mapped to virtual addresses, which can be crucial for efficiently utilizing memory resources
or handling specific hardware configurations.

Figure 10.1 Standstone directory layout.

 Sandstone Source File (sand.s):

 Location: sand/build/src/sand.s
 Description: This file contains the source code of Sandstone written in ARM assembler.

 Object File Produced by the Assembler:

 Location: sand/build/obj/
 Description: After compiling the sand.s source file, the assembler produces an object
file which is stored in this directory.

 Final Sandstone Image:

 Location: sand/build/image/
 Description: This directory houses the final executable or image file of Sandstone. It
includes both the compiled Sandstone code and the payload.

 Payload Image:
  Location: sand/payload/
 Description: The payload image, which is the software loaded and executed by
Sandstone, is stored in this directory.

 Build Procedure Information:

 Reference: sand/readme.txt
 Description: The readme.txt file located in the sand directory provides detailed
instructions on how to build the example binary image for the ARM Evaluator-7T using
Sandstone. It includes information on compiling, linking, and configuring the build
environment.