MODULE 4

EXCEPTION , INTERUPT HANDLING

& FIRMWARE

​

​

​

BY: GURURAJ S CSE DEPT

GURURAJ S CSE DEPT

EXCEPTION HANDLING

​

This will Cover

■ ARM processor mode and exceptions

■ Vector table

■ Exception priorities

■ Link register offsets

​

An exception is any condition that needs to halt the normal sequential execution of instructions

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.

When an exception causes a mode change, the core automatically

■ saves the cpsr to the spsr of the exception mode

■ saves the pc to the lr of the exception mode

​

ArM processor Exceptions and Modes

Shows a simplified view of exceptions and associated modes. Note that when an exception occurs the ARM processor always switches to ARM state

vector Table

​

You can also have other types of instructions in the vector table. For example, the FIQ handler might start at address offset +0x1c

Exception priorities

​

Exceptions can occur simultaneously, so the processor has to adopt a priority mechanism

The Reset exception is the highest priority exception and is always taken whenever it is signaled. The reset handler initializes the system, including setting up memory and caches. External interrupt sources should be initialized before enabling IRQ or FIQ interrupts to avoid the possibility of spurious interrupts occurring before the appropriate handler has been set up. The reset handler must also set up the stack pointers for all processor modes.

During the first few instructions of the handler, it is assumed that no exceptions or interrupts will occur. The code should be designed to avoid SWIs, undefined instructions, and memory accesses that may abort, that is, the handler is carefully implemented to avoid further triggering of an exception.

Data Abort exceptions occur when the memory controller or MMU indicates that an invalid memory address has been accessed (for example, if there is no physical memory for an address) or when the current code attempts to read or write to memory without the correct access permissions. 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.

– An Interrupt Request (IRQ) exception occurs when an external peripheral sets the IRQ pin to nIRQ. An IRQ exception is the second-highest priority interrupt. The IRQ handler will be entered if neither an FIQ exception nor Data Abort exception occurs. On entry to the IRQ handler, the IRQ exceptions are disabled and should remain disabled until the current interrupt source has been cleared.

– A Prefetch Abort exception occurs when an attempt to fetch an instruction results in a memory fault. This exception is raised when the instruction is in the execute stage of the pipeline and if none of the higher exceptions have been raised. On entry to the handler, IRQ exceptions will be disabled, but the FIQ exceptions will remain unchanged. If FIQ is enabled and an FIQ exception occurs, it can be taken while servicing the Prefetch Abort.

– A Software Interrupt (SWI) exception occurs when the SWI instruction is executed and none of the other higher-priority exceptions have been flagged. On entry to the handler, the cpsr will be set to supervisor mode.

If the system uses nested SWI calls, the link register r14 and spsr must be stored away before branching to the nested SWI to avoid possible corruption of the link register and the spsr.

Link register Offsets

​

When an exception occurs, the link register is set to a specific address based on the current pc.

Useful link-register-based addresses

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

Because there is an S at the end of the SUB instruction and the pc is the destination register, the cpsr is automatically restored from the spsr register.

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.

​

The final example uses the interrupt stack to store the link register. This method first subtracts an offset from the link register and then stores it onto the interrupt stack.

handler

SUB r14, r14, #4 ; r14-=4

STMFD r13!,{r0-r3, r14} ; store context

...

<handler code>

...

LDMFD r13!,{r0-r3, pc}ˆ ; return

To return to normal execution, the LDM instruction is used to load the pc. The ˆ symbol in the instruction forces the cpsr to be restored from the spsr.

IntErrupts

​

There are two types of interrupts available on the ARM processor. 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

These topics will be covered:

■ 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

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. The IRQ exception has a lower priority and higher interrupt latency (to be discussed in the next section) than the FIQ 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. Thus, in an embedded operating system design, the FIQ exception is used for a specific application, leaving the IRQ exception for more general operating system activities.

​

INTERRUPT LATENCY

– Interrupt-driven embedded systems have to fight a battle with interrupt latency—the interval of time from an external interrupt request signal being raised to the first fetch of an instruction of a specific interrupt service routine (ISR).

– Interrupt latency depends on a combination of hardware and software

– 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

​

The processor spends time in the lower-priority interrupts until a higher-priority inter- rupt 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. The ARM processor will continue executing the current instruction in the execution stage of the pipeline before handling the interrupt—an important factor in designing a deterministic interrupt handler since some instructions require more cycles to complete the execution stage.

An IRQ or FIQ exception causes the processor hardware to go through a standard procedure (provided the interrupts are not masked):

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.

Figure shows what happens when an IRQ exception is raised when the processor is in user mode. The processor starts in state 1. In this example both the IRQ and FIQ exception bits in the cpsr are enabled.

When an IRQ occurs the processor moves into state 2. This transition automatically sets the IRQ bit to one, disabling any further IRQ exceptions. The FIQ exception, however, remains enabled because FIQ has a higher priority and therefore does not get disabled when a low-priority IRQ exception is raised. The cpsr processor mode changes to IRQ mode. The user mode cpsr is automatically copied into spsr_irq.

Register r14_irq is assigned the value of the pc when the interrupt was raised. The pc is then set to the IRQ entry +0x18 in the vector table.

In state 3 the software handler takes over and calls the appropriate interrupt service routine to service the source of the interrupt. Upon completion, the processor mode reverts back to the original user mode code in state 1.

Figure shows an example of an FIQ exception. The processor goes through a similar procedure as with the IRQ exception, but instead of just masking further IRQ exceptions from occurring, the processor also masks out further FIQ exceptions. This means that both interrupts are disabled when entering the software handler in state 3.

Changing to FIQ mode means there is no requirement to save registers r8 to r12 since these registers are banked in FIQ mode. These registers can be used to hold temporary data, such as buffer pointers or counters. This makes FIQ ideal for servicing a single-source, high-priority, low-latency interrupt.

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

To enable and disable both the IRQ and FIQ exceptions requires a slight modification to the second instruction. The immediate value on the data processing BIC or ORR instruction has to be changed to 0xc0 to enable or disable both interrupts.

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:

■ Operating system requirements—Each operating system has its own requirements for stack design.

■ 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

The IRQ mode stack has to be set up before interrupts are enabled—normally in the initialization code for the system

Figure shows two typical memory layouts in a linear address space. 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.

For each processor mode a stack has to be set up. This is carried out every time the processor is reset. Figure shows an implementation using layout A. To help set up the memory layout, a set of defines are declared that map the memory region names with an absolute address.

For instance, the User stack is given the label USR_Stack and is set to address 0x20000.

The Supervisor stack is set to an address that is 128 bytes below the IRQ stack.

FIRMWARE

Firmware is an impor- tant part of any embedded system since it is frequently the first code to be ported and executed on a new platform. Firmware can vary from being a complete software embedded system to just a simple initialization and bootloader routine.

ARM Firmware Suite and Red Hat’s RedBoot. These firmware packages are general purpose and can be ported to different ARM platforms relatively easily and quickly.

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.

​

For example, a small system may require just minimal firmware support to boot a small operating system. One of the main purposes of firmware is to provide a stable mechanism to load and boot an operating system

​

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

​

​

To help understand the features of different firmware implementations, we have a common execution flow

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 pack- age 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- ferent communication devices (for example, USB, Ethernet, or serial). It also provides a standard API. Consequently, when a port takes place, the various hardware-specific parts must be implemented in accordance with the various μHAL API functions

μ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

The boot monitor in μHAL contains a CLI.

The second technology, Angel, allows communication between a host debugger and a target platform. It allows you 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

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. 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 proto- col 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.

​

ExAMPLE: SANDSTONE

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.

​

Note that Sandstone is written entirely in ARM assembler and is a working piece of code that can be used to intialize target hardware and boot any piece of software, within reason, on the ARM Evaluator-7T.

SANDSTONE DIRECTORY LAYOUT

SANDSTONE CODE STRUCTURE

The initial goal of Sandstone is to set up the target platform environment so that it can provide some form of feedback to indicate that the firmware is running and has control of the platform.

Step 1: 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. You can see from the code here that all the vectors, apart from the reset vector, branch to a unique dummy handler—a branch instruction that causes an infinite loop. It is assumed that no exception or interrupt will occur during the operation of Sandstone. The reset vector is used to move the execution flow to the second stage.

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

The results of executing step 2 are the following:

​

■ The system registers are set from a known base address—0x03ff0000.

■ The segment display is configured, so that it can be used to display progress.

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.

The results of executing step 3 are the following:

​

■ Memory has been remapped as shown in Table

■ pc now points to the next step. This address is located in the newly remapped flash ROM.

Step 4: 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. Again, because the code for initializing the serial port on the ARM Evaluator-7T is hardware specific.

​

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

The final stage involves copying a payload and relinquishing control of the pc over to the copied payload. This is achieved using the code shown here. The first part of the code sets up the registers r12, r13, and r14 used in the block copy. The bootloader code assumes that the payload is a plain binary image that requires no deciphering or uncompressing.

The results of executing step 5 are the following:

​

■ Payload copied into SRAM, address 0x00000000.

■ Control of the pc is relinquished to the payload; pc = 0x00000000.

■ The system is completely booted. The following output is shown on the serial port:

Sandstone initializes the hardware and then loads and boots an image following this procedure:

​

■ Takes the Reset exception.

■ Starts initializing the hardware; sets the system register’s base address and initializes segment display hardware.

■ Remaps memory; ROM address = high addr and SRAM addr = 0x00000000.

■ Initializes the communication hardware output on the serial port.

■ Bootloader—loads an image into SRAM and relinquishes control of the pc to the image (pc = 0x00000000).

We now have a fully initialized ARM7TDMI embedded system.

MODULE 4 ENDS