Exception Priority and Link Register Offset in ARM

📚 As per VTU Module 4 – Exception and Interrupt Handling

🔶 1️⃣ Exception Priority in ARM Processors

✅ Need for Priority:

 Multiple exceptions can occur simultaneously.

 ARM must decide which exception to handle first — that's why it uses a priority mechanism.

✅ How ARM Prioritizes Exceptions:

 Each exception has a fixed priority level.

 Table 9.3 (from the text) lists exceptions from highest to lowest priority.

🔽 Priority Order (from highest to lowest):

🔁 Exception 🔝 Priority 🔐 Disables

🔃 Reset 1 (Highest) IRQ + FIQ (I=1, F=1)

❌ Data Abort 2 IRQ (I=1)

⚡ Fast Interrupt (FIQ) 3 IRQ + FIQ (I=1, F=1)

🔔 Interrupt Request (IRQ) 4 IRQ (I=1)

🧠 Prefetch Abort 5 IRQ (I=1)

🧩 SWI & Undefined Instr. 6 (Lowest) None or I=1

🔷 2️⃣ Explanation of I-bit and F-bit

 CPSR contains two important bits:

o 🔸 I-bit = disables IRQs when set (I = 1)

o 🔹 F-bit = disables FIQs when set (F = 1)

📌 When an exception is taken, ARM automatically sets these bits to prevent further interrupts:

 FIQ sets both I=1 and F=1

 IRQ sets I=1

 Reset, Data Abort, Prefetch Abort set I=1

 SWI and Undefined do not disable interrupts.

📝 This ensures exceptions are handled safely and prevents re-entry.

🟩 3️⃣ Summary of Key Exception Behaviors

1. Reset (Highest priority)

o Initializes memory, cache, stack for all modes.

o Assumes no further exceptions occur during initial setup.

o ⚠ Must avoid instructions like SWI, aborts, undefined ops early on.

2. Data Abort

o Triggered when invalid memory is accessed (via MMU or access violation).

o ⚡ FIQ can still occur during a Data Abort.

3. FIQ (Fast Interrupt)

o Raised by nFIQ pin from high-speed peripherals.

o Both IRQ & FIQ are disabled on entry.

o 🕒 Must be handled quickly.

4. IRQ (Standard Interrupt)

o Triggered by nIRQ pin.

o IRQs disabled on entry.

o Occurs only if no higher exception is active.

5. Prefetch Abort

o Happens when an instruction fetch causes a fault (e.g., missing memory).

 o IRQs disabled, but FIQs may still occur.

6. SWI (Software Interrupt)

o Occurs when SWI instruction is executed.

o Used for system calls; enters Supervisor Mode.

o Must save LR and SPSR for nested calls.

7. Undefined Instruction

o Occurs if instruction is not in ARM/Thumb set.

o ARM checks if a coprocessor can handle it, else exception raised.

🔶 4️)Link Register Offsets in ARM Exception Handling

✅ What is LR in Exceptions?

 LR (r14) stores the return address when an exception is raised.

 It helps the processor resume execution after the exception is handled.

🔧 Each exception sets LR to a different offset from PC depending on when it's taken.

📌 Role of Link Register in ARM Exception Handling

✅ Purpose:
The Link Register (LR) is used to store the return address when an exception occurs. It allows the
processor to return to the instruction that was being executed before the exception interrupted the
normal flow.

🧩 What Happens During an Exception?

When an exception (like IRQ, FIQ, SWI, etc.) occurs:

1. 🔁 The current Program Counter (PC) value is stored in LR of the exception mode (e.g.,
r14_irq, r14_fiq, r14_svc, etc.).

2. 📥 The CPSR is saved into the SPSR_<mode>.

3. 📌 Control is transferred to the exception vector address.

4. Later, to return, the value in LR is used to restore PC, and the processor resumes normal
execution.

📊 Table of Offsets (from Table 9.4):

🧩 Exception 📍 LR Value 📝 Meaning

Reset — Not defined (reset starts fresh)

🧩 Exception 📍 LR Value 📝 Meaning

Data Abort lr = PC + 8 Must return to faulting instruction − 8

FIQ lr = PC + 4 Return using lr − 4

IRQ lr = PC + 4 Return using lr − 4

Prefetch Abort lr = PC + 4 Faulting instruction is at lr − 4

SWI lr = PC + 4 Resume from next instruction

Resume from next instruction

Undefined Instruction lr = PC + 4

Example: Returning from an IRQ/FIQ Handler using SUBS Instruction

asm

CopyEdit

<handler code>

...

SUBS pc, r14, #4 ; pc = r14 - 4

📝 Explanation:

 SUBS subtracts 4 from the Link Register (r14) and stores the result in pc (Program Counter).

 Since the destination is pc and the instruction ends with S, it also causes the processor to:

o 🔄 Restore CPSR from SPSR

o 🔚 Return to the previous mode/state (User/System/etc.)

 This is the standard method used to return from IRQ or FIQ exceptions in ARM processors.

✅ This ensures both program flow and status flags are restored properly after handling the
exception.
⚙️ARM Firmware Suite (AFS), Firmware Execution Flow, and Red
Hat RedBoot
📘 As per VTU syllabus – Module 5: Firmware and Bootloader

🔶 1️)Features of ARM Firmware Suite (AFS)

ARM has developed a firmware package called the ARM Firmware Suite (AFS).
AFS is specially designed for ARM-based embedded systems and supports many ARM processors
such as Intel XScale and StrongARM.

AFS contains two major technologies:

 μHAL (micro-Hardware Abstraction Layer)

 Angel (debug monitor)

✅ μHAL – micro Hardware Abstraction Layer

μHAL provides a low-level device driver framework for embedded systems.

It allows operation over different communication devices such as USB, Ethernet, or Serial ports.

It offers a standard API, which makes it easier to port firmware to new platforms because only the
hardware-specific parts need to follow the API functions.

μHAL supports the following features:

1. System Initialization
 When any embedded system like an ARM processor is powered on, the first thing it does is prepare
itself to work properly. This preparation step is called system initialization.

o This sets up the target platform and processor core when the system starts.

 On simple boards (like small microcontrollers):

 It’s easy: just a few steps like turning on memory or enabling a timer.

 On complex boards (like smartphones or Linux-based systems):

 It’s harder: it might need to set up many parts such as:

o Memory regions (RAM, Flash)

o Communication ports (USB, UART)

o Displays, input devices, etc.

2. Polled Serial Driver

This part talks about how the board (target) and the computer or host communicate with each
other during early stages of booting.

💬 What is it?

 It means the board can send or receive messages (like logs or commands) to/from a
connected computer (host).

🔄 What is “Polled”?

 The board keeps checking again and again ("polling") if any data has arrived.

 It's like a person looking at their phone screen every few seconds to see if they got a
message 📱.

✅ When is it used?

 In the early stages of system startup (before full setup is done).

 When interrupts are not yet enabled, because using interrupts needs more setup.

🎯 Why it matters:

This kind of communication helps us:

 See what’s going on inside the board during startup.

 Debug any problems if the board is not starting properly.

 3. LED Support

What is μHAL?

 μHAL (Micro Hardware Abstraction Layer) is a small piece of software that helps your code
talk to the hardware.

 It hides the hardware complexity and gives easy functions to control things like LEDs.

💡 What does it do?

 It lets your program turn ON, OFF, or blink LEDs on the board.

 These LEDs are used to show important signals, like:

o ✅ Success (e.g., green LED blinks)

o ⚠️Activity or status (e.g., yellow LED flashes during loading)

o ❌ Errors (e.g., red LED stays ON)

🧠 Why is it useful?

 Even if there's no screen, you can still know what's happening by looking at LED behavior.

 It's a quick way to debug and track progress during startup.

4. Timer Support

Why is this important?

 Preemptive operating systems (like real-time OS) use these timer interrupts to:

o Give each task a time slice to run.

o Then pause it and switch to another task.

o This is called real-time multitasking 🧠.

✅ Result

 Thanks to timers, multiple things can run smoothly on the processor, like a clock, sensor
reading, or LED blinking—all at the right time.

5. Interrupt Controllers

 Devices like UART, timers, or sensors send interrupts (signals) to the processor when they
need attention.
  The interrupt controller makes sure these signals are:

o Received correctly

o Handled in order of priority

o Sent to the right part of the code (Interrupt Service Routine).

📌 Why is μHAL useful here?

 μHAL simplifies the process of:

o Enabling or disabling interrupts

o Connecting the interrupt source (like UART) to the handler

o Maintaining system stability

✅ Result

 With μHAL, interrupts work smoothly, and the processor knows what to respond to and
when 🧠.

6. Boot Monitor with Command Line Interface (CLI)

o μHAL includes a CLI-based boot monitor, which provides a user interface to interact
with the board during boot.

o This allows developers to run commands, check system status, and control startup
behavior.

✅ Angel Debug Monitor

Angel is a debugging tool that allows communication between the host debugger and the target
ARM board.

Angel must be integrated with SWI, IRQ, or FIQ vectors, which are the special memory locations for
exceptions.

Angel supports the following:

 Inspecting and modifying memory on the target board.

 Downloading and executing programs remotely.

 Setting breakpoints for debugging.

 Viewing the contents of processor registers.

 Reading and writing files on the host using SWI (Software Interrupts).

For communication, Angel may also use IRQ or FIQ interrupts, depending on configuration.
🔷 2️⃣ Firmware Execution Flow

The firmware execution flow describes the steps followed by the ARM processor from reset to
handing over control to the operating system.

The flow is as follows:

1. Reset Occurs

o When power is applied, the processor enters the Reset state and starts executing the
firmware.

2. System Initialization by μHAL

o The firmware initializes the processor core and board peripherals.

o It sets up memory, cache, and stack pointers for each processor mode (User,
Supervisor, IRQ, etc.).

3. Device Driver Setup

o μHAL configures basic device drivers for components like timers, serial ports, LEDs,
and communication interfaces.

4. Interrupt Controller Initialization

o The firmware initializes interrupt controllers and configures interrupt sources.

 o This is important to avoid spurious interrupts during system setup.

5. Boot Monitor or Debug Interface Activated

o The firmware activates a command-line interface (CLI) or Angel debug monitor.

o Angel connects to a host debugger, allowing developers to control the target.

6. Transfer to Operating System Bootloader

o Once initialization is complete, control is passed to the bootloader or directly to the

OS kernel.

o This allows the main operating system to start running.

🟥 3️)Red Hat RedBoot – Features

RedBoot is an open-source firmware developed by Red Hat for embedded systems.

It supports various processor architectures including ARM, MIPS, and SuperH (SH).

RedBoot provides both bootloader and debugging capabilities.

Its core is based on a Hardware Abstraction Layer (HAL) like μHAL.

✅ RedBoot Supports These Main Features:

1. Communication Support

RedBoot can connect to a host system (like your PC) using two main methods:

🔸 A. Serial Port Communication

 RedBoot uses X-Modem protocol over a serial cable.

 ✅ This protocol makes sure files (like firmware) are transferred reliably without errors.

🔸 B. Ethernet Communication

 RedBoot can also talk to the host using Ethernet (network cable).

 It uses the TCP/IP protocol, just like the internet.

🌐 What Services RedBoot Supports over Ethernet:

 bootp – Automatically gets an IP address from the network.

 telnet – Lets you remotely connect and run commands on RedBoot from your PC.

 tftp – Helps you download firmware/images from the host system to the target device.
 2. Flash ROM Memory Management

RedBoot helps you manage the flash memory (the permanent storage area) on your development
board:

✅ A. Download Images to Flash

 RedBoot can receive firmware or OS images (via serial or network) and store them in flash
memory.

✅ B. Update or Erase Images

 You can use RedBoot to overwrite old images or completely erase flash before writing new
data.

✅ C. File System for Flash

 RedBoot includes routines (functions) that help organize and manage the flash storage
efficiently, so you don’t overwrite or corrupt anything

✅ D. Handles Compressed or Uncompressed Images

 The downloaded image can be either:

o Compressed (to save space)

o Uncompressed (for faster access)

RedBoot knows how to deal with both.

3. Full Operating System Support

o RedBoot can load and boot operating systems like:

 Embedded Linux

 Red Hat eCos

 And many other embedded operating systems.

o RedBoot can also define and pass parameters to the OS kernel when booting.
This is useful to configure the OS at startup based on hardware or user settings.

3) ⚙️IRQ and FIQ Exceptions & Steps to Enable/Disable Interrupts

in ARM
🔶 1️⃣ IRQ and FIQ Exceptions in ARM

The ARM processor handles two types of hardware interrupts:

 IRQ (Interrupt Request) – Standard priority interrupt

 FIQ (Fast Interrupt Request) – High priority, faster processing

📌 IRQ and FIQ exceptions are only recognized when their respective interrupt mask bits in the
CPSR are cleared (i.e., not masked).
🟡 Standard Procedure Followed on IRQ or FIQ Exception

When either IRQ or FIQ is triggered, and the corresponding mask is cleared, ARM performs a
standard set of steps:

🔄 Steps:

1. Processor switches to the specific interrupt mode

o Changes the mode to IRQ mode or FIQ mode depending on the interrupt.

2. CPSR is saved into SPSR of the new mode

o The current status register (CPSR) of the previous mode is copied into SPSR_irq or
SPSR_fiq.

3. PC is saved into LR of the new mode

o The current program counter (PC) is stored in Link Register (r14_irq or r14_fiq) of
the new mode.

4. Interrupts are disabled

o For IRQ: Only IRQ is disabled (I = 1 in CPSR)

o For FIQ: Both IRQ and FIQ are disabled (I = 1, F = 1)

5. Processor branches to the exception vector address

o For IRQ: Branches to address 0x18

o For FIQ: Branches to address 0x1C

➡️The processor is now ready to execute the Interrupt Service Routine (ISR).

🧪 2️⃣ Example of IRQ Exception Handling

Let’s understand what happens during an IRQ exception using a simplified stepwise flow:

🧭 Processor Initial State:

 Mode: User

 Interrupts: Both IRQ and FIQ enabled

💥 IRQ Occurs:

1. The processor:

o Changes to IRQ mode

o Sets I bit = 1 to disable further IRQs

o Leaves F bit = 0 (FIQ remains enabled)

2. CPSR is copied to SPSR_irq

3. PC is copied to LR_irq (r14_irq)

4. Branches to vector address 0x18

5. The IRQ handler executes the required routine.

6. After the interrupt is serviced, the processor returns to User mode, restoring CPSR from
SPSR_irq.
🧪 3️⃣ Example of FIQ Exception Handling

🧭 Processor Initial State:

 Mode: User

 Interrupts: IRQ and FIQ enabled

💥 FIQ Occurs:

1. The processor:

o Changes to FIQ mode

o Sets both I and F bits = 1 (disabling IRQ and FIQ)

2. CPSR is copied to SPSR_fiq

3. PC is copied to LR_fiq (r14_fiq)

4. Branches to vector address 0x1C

5. FIQ handler runs with banked registers (r8–r12) which need not be saved, improving speed.

6. After servicing, returns back to User mode.

🟩 4️)Steps to Enable and Disable IRQ and FIQ Interrupts

The ARM core allows interrupts to be manually enabled or disabled by changing the CPSR bits when
in privileged mode (e.g., Supervisor mode).

🔹 To Enable IRQ (Clear I bit):

asm

CopyEdit

MRS r1, cpsr ; Move CPSR to r1

BIC r1, r1, #0x80 ; Clear bit 7 (I bit)

MSR cpsr_c, r1 ; Write updated value back to CPSR

➡️CPSR before: nzcvqjIFt

➡️CPSR after: nzcvqjiFt (IRQ enabled)

🔹 To Enable FIQ (Clear F bit):

asm

CopyEdit

MRS r1, cpsr ; Move CPSR to r1

BIC r1, r1, #0x40 ; Clear bit 6 (F bit)

MSR cpsr_c, r1 ; Write updated value back to CPSR

➡️CPSR before: nzcvqjIFt

➡️CPSR after: nzcvqjIft (FIQ enabled)
🔻 To Disable IRQ (Set I bit):

asm

CopyEdit

MRS r1, cpsr

ORR r1, r1, #0x80 ; Set bit 7 (I = 1)

MSR cpsr_c, r1

➡️IRQ now masked/disabled

🔻 To Disable FIQ (Set F bit):

asm

CopyEdit

MRS r1, cpsr

ORR r1, r1, #0x40 ; Set bit 6 (F = 1)

MSR cpsr_c, r1

➡️FIQ now masked/disabled

4) 🧠 Firmware and Bootloader in ARM

📚 Textbook: Embedded Systems with ARM, Module 4 – VTU 4th Semester

🔹 1️⃣ What is Firmware?

The firmware is deeply embedded low-level software that provides an interface between the
hardware and the application or operating system-level software.

 📌 It resides in ROM and starts executing when power is applied to the embedded system.

 Firmware may remain active even after system initialization to support basic operations.

💡 Purpose:

 To provide a stable mechanism to load and boot an operating system.

 The specific firmware implementation depends on the application:

o A complex system may boot Embedded Linux.

o A minimal system may only need basic microkernel support.

🔹 2️)What is a Bootloader?

The bootloader is a small, temporary program that:

 📥 Loads the operating system or application onto the hardware.

 🔁 Exists only until the OS or application starts executing.

 ✅ Is often incorporated within the firmware itself.

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

🔹 3️)Firmware Execution Flow

To understand how firmware functions, we look at its execution flow, divided into four stages.
📊 (Table 10.1 in textbook)

🚀 Stage 1: Set Up Target Platform

This step prepares the hardware environment for the OS to run.

 The OS expects certain system registers, memory layout, and peripherals to be in place.

 Firmware initializes hardware like memory controllers, timers, or system control registers.

 If the same executable runs on different platforms, the firmware identifies:

o The core: via coprocessor 15, register 0 (contains processor ID and manufacturer).

o The platform: by detecting peripherals or using a preprogrammed chip.

💡 Why is this important?

Because the OS requires a specific environment to function properly. This step ensures compatibility.

🔍 Stage 2: Platform Identification, Diagnostics, Debugging

 Diagnostics Software is used to check for hardware errors specific to the platform.

 Debug Monitor allows:

o Setting breakpoints in RAM

o Viewing/modifying memory (peek/poke)

o Inspecting register values

o Disassembling memory into ARM/Thumb instructions

 These actions are done via:

o A command line interpreter (CLI), or

 o A host debugger connected to the device.

The CLI is especially useful in advanced firmware, letting you:

 Change OS boot options

 Control via serial/network connection (e.g., from a PC terminal)

⚙️Stage 3: Hardware Abstraction Layer (HAL)

After platform setup, the firmware abstracts hardware using a software layer called HAL.

 HAL hides hardware details and offers standard programming interfaces (APIs).

 This allows the same higher-level code to run on different platforms with different hardware.

🔧 Device Drivers:

 Part of HAL, they handle communication with specific hardware (like timers, serial ports).

 Drivers give a standard interface to read/write to peripherals, even if hardware is different.

💾 Stage 4: Load a Bootable Image

Now the firmware loads an OS or application image:

 From where?

o Flash ROM (common in embedded systems)

o Hard drives, SD cards, or even over the network

 How?

o Use a filing system (like Flash Filing System) to store/retrieve images

o Images might be:

 Binary (plain)

 ELF format (Executable and Linking Format – includes headers, debug info)

🧩 If the image is:

 Compressed or encrypted, the firmware must first decompress/decrypt it.

 Network-loaded, firmware must handle Ethernet + network protocols (e.g., TFTP).

🔚 Final Stage: Relinquish Control

After loading, the firmware:

 Transfers control to the OS by:

o Updating the vector table (interrupts & exceptions now handled by OS handlers)
 o Changing the Program Counter (PC) to point to the OS entry point

🧠 For more complex OS like Linux, firmware also passes a standard data structure to the kernel:

 Contains platform details like:

o Available RAM

o MMU type

o Hardware settings

📌 In some systems, firmware remains active as a background HAL layer (exposed via SWI interface),
but in others, it becomes inactive once the OS takes over.

✅ Summary Table – Firmware Execution Flow (as per textbook)

Stage Description

Setup Target Platform Initialize hardware, configure memory, detect platform/core

Diagnostics & Debug Run diagnostic checks, provide debug access via CLI or host

Use HAL and device drivers to abstract hardware and create a standard
Hardware Abstraction
interface

Load Bootable Image Load OS/app image from ROM, storage, or network (supports binary or ELF)

Relinquish Control Update PC and vector table to transfer control to OS

5)🪨 Sandstone Execution Flow – Explained Step-by-Step

✅ Purpose:
Sandstone is a small firmware system designed to initialize ARM hardware and boot a payload. It
helps set up the environment so the system can run an operating system or application smoothly.
🔁 Step-by-Step Sandstone Execution Flow:

🔹Step 1: Take the Reset Exception

 What Happens:
The processor begins execution from the reset vector, which is the very first instruction at
address 0x00000000.
Only the reset vector has real functionality — others branch to dummy handlers (infinite
loops) to avoid unhandled exceptions.

 Code Snippet:

AREA start, CODE, READONLY

ENTRY

sandstone_start B sandstone_init1 ; reset vector

ex_und B ex_und ; undefined instruction

ex_swi B ex_swi ; software interrupt

ex_dabt B ex_dabt ; data abort

ex_pabt B ex_pabt ; prefetch abort

int_irq B int_irq ; IRQ

int_fiq B int_fiq ; FIQ

ex_und B ex_und ; dummy handlers

ex_swi B ex_swi

ex_dabt B ex_dabt

ex_pabt B ex_pabt

int_irq B int_irq

int_fiq B int_fiq

 Result:
✔ Dummy handlers setup
✔ Control moves to hardware initialization (sandstone_init1)

🔹Step 2: Start Initializing the Hardware

 Goal:
Set system registers and prepare display for user feedback.

 Code Snippet:

sandstone_init1

LDR r3, =SYSCFG ; SYSCFG = 0x03ff0000

LDR r4, =0x03ffffa0 ; New settings: top 16 bits = address, bottom = attributes

STR r4, [r3] ; Set the base of system register

 What It Means:
r3 is used to point to the system config register. r4 has new configuration data.
This sets the system registers and enables the 7-segment display to show firmware status.

 Result:
✔ System registers set
✔ Display initialized for visual feedback

🔹Step 3: Remap Memory

 Goal:
Move Flash ROM to a higher address and make SRAM available.

 Initial Memory Map:

Flash ROM : 0x00000000 – 0x00080000 (512KB)

SRAM Bank 0 : Not yet available

SRAM Bank 1 : Not yet available

 Code Snippet:

LDR r14, =sandstone_init2

LDR r4, =0x01800000 ; New Flash ROM location

ADD r14, r14, r4

ADRL r0, memorymaptable_str

LDMIA r0, {r1-r12}

LDR r0, =EXTDBWTH ; = (SYSCFG + 0x3010)

STMIA r0, {r1-r12}

MOV pc, r14 ; Jump to remapped address

 What It Does:

o Calculates new address for next routine sandstone_init2

o Loads memory map data into registers

o Applies remap via memory controller

o Jumps to new code location using MOV pc, r14

 New Memory Map:

Flash ROM : 0x01800000 – 0x01880000

SRAM Bank 0 : 0x00000000 – 0x00040000

SRAM Bank 1 : 0x00040000 – 0x00080000

 Result:
✔ Memory remapped
✔ pc updated to continue from new memory

🔹Step 4: Initialize Communication Hardware

 Goal:
Setup serial communication (UART) and send a startup message.

 Serial Settings:
9600 baud, No parity, 1 stop bit, No flow control

 Output Message:

 Sandstone Firmware (0.01)

 platform ......... e7t

 status ........... alive

 memory ........... remapped

 + booting payload ...

  Result:
✔ Serial port initialized
✔ Banner message sent for confirmation

🔹Step 5: Bootloader – Copy Payload & Relinquish Control

 Goal:
Load payload (main program or OS) into SRAM and hand over control.

 Code Snippet:

sandstone_load_and_boot

MOV r13, #0 ; Destination (SRAM)

LDR r12, payload_start_address ; Source Start

LDR r14, payload_end_address ; Source End

_copy

LDMIA r12!, {r0-r11}

STMIA r13!, {r0-r11}

CMP r12, r14

BLT _copy

MOV pc, #0 ; Hand control to payload

payload_start_address DCD startAddress

payload_end_address DCD endAddress

 How It Works:

o Copies payload (binary image) from source to destination

o After copy is complete, sets pc = 0x00000000, giving control to payload

 Final Output:

 Sandstone Firmware (0.01)

 + booting payload ...

 Simple Little OS (0.09)

 initialized ...... ok

 running on ....... e7t

  Result:
✔ Payload loaded into SRAM
✔ Firmware control ends
✔ System is now fully booted

7) 🔐 Enabling and Disabling IRQ and FIQ Interrupts in ARM

✅ Purpose:
To manually enable or disable IRQ and FIQ interrupts, we modify the CPSR register (Current Program
Status Register) in privileged modes using ARM assembly instructions.

🔹⚙️Instructions Used:

 MRS: Move CPSR to a general-purpose register (read CPSR)

 BIC: Bit Clear (used to clear bits to enable interrupt)

 ORR: Logical OR (used to set bits to disable interrupt)

 MSR: Move register back to CPSR (write CPSR)

🟢 Enabling IRQ and FIQ Interrupts

💡 Code to Enable IRQ:

assembly

CopyEdit

MRS r1, cpsr ; Read CPSR into r1

BIC r1, r1, #0x80 ; Clear IRQ disable bit (bit 7)

MSR cpsr_c, r1 ; Write back to CPSR

➡️Explanation:

 0x80 corresponds to bit 7 — the IRQ disable bit.

 Clearing this bit enables IRQs.

💡 Code to Enable FIQ:

assembly

CopyEdit

MRS r1, cpsr ; Read CPSR into r1

BIC r1, r1, #0x40 ; Clear FIQ disable bit (bit 6)

MSR cpsr_c, r1 ; Write back to CPSR

➡️Explanation:

 0x40 corresponds to bit 6 — the FIQ disable bit.

 Clearing this bit enables FIQs.

🔴 Disabling IRQ and FIQ Interrupts

💡 Code to Disable IRQ:

assembly

CopyEdit

MRS r1, cpsr ; Read CPSR into r1

ORR r1, r1, #0x80 ; Set IRQ disable bit (bit 7)

MSR cpsr_c, r1 ; Write back to CPSR

💡 Code to Disable FIQ:

assembly

CopyEdit

MRS r1, cpsr ; Read CPSR into r1

ORR r1, r1, #0x40 ; Set FIQ disable bit (bit 6)

MSR cpsr_c, r1 ; Write back to CPSR

⚠️Note:

 Both IRQ and FIQ can be disabled/enabled together by changing the bitmask to 0xC0 (0x80 |
0x40).

 Changes take effect only after the final MSR instruction completes the execution stage of
the pipeline.

8) Difference between bootloader and firmware

Feature Firmware Bootloader

Low-level software that interfaces A small application that loads the OS or

Definition between hardware and application onto the target, incoperated within
OS/application firmware itself

Location Resides permanently in ROM Exists temporarily during system start-up

Feature Firmware Bootloader

Execution Starts at power-on and can remain

Active only until OS or application starts
Time active

Provides a stable mechanism to load Loads the OS/application into memory and then
Purpose
and support OS hands over control

Can be complex, supports

Simple and minimal, often a single task like
Complexity diagnostics, HAL, drivers, debug, CLI
copying and jumping
etc.

Initializes hardware, runs

Simply copies payload (e.g., binary image) and
Functionality diagnostics, configures system,
updates pc
debug support

May stay active even after OS starts

Lifespan Inactive after handing over control to OS
(e.g., HAL parts)

Shows status messages, diagnostics, Usually just displays boot progress or message
Output
CLI, hardware abstraction like “booting...”

📌 In summary:

 Firmware = full controller + interface layer for OS

 Bootloader = minimal code to load and start the OS

9) ⚡ What are Interrupts?

✅ Definition:
Interrupts are signals that temporarily halt the normal execution of a program so the processor can
respond to an urgent task or event, such as I/O, timer, or external hardware request.

✅ Purpose:

 To provide asynchronous event handling

 To improve system efficiency and responsiveness

🧩 Types of Interrupts in ARM Processor

Type Description

IRQ (Interrupt Request) General-purpose, lower-priority interrupt

FIQ (Fast Interrupt

High-priority, faster response interrupt (used for real-time requirements)
Request)

SWI (Software Interrupt) Triggered by executing the SWI instruction—used for system calls
Type Description

Undefined Instruction Triggered when CPU encounters an invalid or undefined instruction

Prefetch Abort Triggered on error in instruction fetch (e.g., from protected memory)

Triggered when an instruction attempts invalid memory access (data

Data Abort
stage)

Occurs on system reset; resets the CPU and starts execution from
Reset
address 0x00

📥 Interrupt Vector Table (ARM)

✅ Definition:
The Vector Table is a set of memory locations starting at address 0x00000000 (or 0xFFFF0000 in high
vectors) where the processor branches when an exception/interrupt occurs.

Each entry in this table corresponds to a specific type of exception.

📊 Vector Table Layout

Exception Mode Entered Vector Offset Handler Example

Reset Supervisor (SVC) 0x00 B reset_handler

Undefined Instruction Undefined (UND) 0x04 B und_handler

Software Interrupt (SWI) Supervisor (SVC) 0x08 B swi_handler

Prefetch Abort Abort (ABT) 0x0C B prefetch_abort_handler

Data Abort Abort (ABT) 0x10 B data_abort_handler

Reserved — 0x14 —

IRQ IRQ 0x18 B irq_handler

FIQ FIQ 0x1C B fiq_handler

🧭 ARM Vector Table Implementation Methods

ARM provides multiple ways to define vector handlers:

 B <address>

 This is a branch instruction.

 It jumps to a location that is relative to the current program counter (pc).

  ✅ Simple and fast.

 LDR pc, [pc, #offset]

 This loads a full 32-bit address into pc from memory.

 Useful when the handler is far away in memory.

 ❗ Slight delay because it needs an extra memory access.

 LDR pc, [pc, #-0xFF0]

 Used with VIC (Vector Interrupt Controller PL190).

 Loads the interrupt service routine (ISR) address from memory location like 0xFFFFF030.

 MOV pc, #immediate

 Directly moves a specific address into the program counter.

 Can jump to any memory location.

 When you write:

 asm

 CopyEdit

 MOV pc, #some_address

 ARM does not allow any random number as #some_address. Instead, the number must
follow a special rule:

 ✅ It should be:

 An 8-bit number (like 0xF0, 0x33, etc.)

 Rotated right by 0, 2, 4, ..., up to 30 bits

 ❗ So this means:

 You cannot write any 32-bit address (like 0x12345678) directly.

 Only those addresses that can be created by rotating a small 8-bit value are allowed.

 📌 Example:

 Let's say you try:

 asm

 CopyEdit

 MOV pc, #0x12345678

 ⛔ This will NOT work because 0x12345678 can't be formed from an 8-bit number with right
rotation.
  But this:

 asm

 CopyEdit

 MOV pc, #0x80000000

 ✅ This will work because 0x80 (8-bit) rotated right by 24 gives 0x80000000.

 So, the limitation is:

 You can only use addresses that fit ARM's "8-bit rotate" rule. You can’t move just any
address into pc.

 .

📉 Vector Table Diagram for ARM

css

CopyEdit

Address Exception Instruction at Vector

---------------------------------------------------------------

0x00000000 → Reset → B reset_handler

0x00000004 → Undefined Instruction→ B und_handler

0x00000008 → SWI → B swi_handler

0x0000000C → Prefetch Abort → B prefetch_abort_handler

0x00000010 → Data Abort → B data_abort_handler

0x00000014 → Reserved → ---

0x00000018 → IRQ → B irq_handler

0x0000001C → FIQ → B fiq_handler

✍️Summary

 Interrupts allow the processor to respond to important events.

 ARM uses a vector table starting from 0x00000000 to branch to appropriate handlers.

 Multiple types of interrupts (IRQ, FIQ, SWI, etc.) each have dedicated vector entries.

 Different branching techniques (B, LDR, MOV) are supported based on speed and address
range.
10) 📦 Interrupt Stack Design and Implementation in ARM-Based Systems
✅ Definition:
An interrupt stack is a portion of memory used to temporarily store register values and data when
an exception or interrupt occurs, allowing the processor to resume normal execution after handling
the event.
In ARM, each processor mode (like IRQ, FIQ, SVC, etc.) has its own dedicated stack pointer register
(SP). This helps in isolating stacks and prevents data corruption between different modes.

🔧 Factors Influencing Stack Design

1. Operating System Requirements

o Each OS (e.g., Embedded Linux, RTOS) defines how much stack is required and how
it should be managed.

2. Target Hardware Limitations

o Hardware defines the available memory, which places limits on the stack size and
placement.

🔩 Design Decisions in Stack Implementation

There are two important design decisions:

1️⃣ Stack Location

 ARM stacks are usually descending, meaning they grow downward in memory.

 Stack starts from a high memory address and expands towards lower addresses.

 Must be placed in a safe memory area to avoid conflict with code/data.

2️⃣ Stack Size

 Depends on the type of interrupt handler:

o Nonnested interrupt → needs less stack space.

o Nested interrupt → needs more stack to store multiple return addresses and register
values.

💣 Avoiding Stack Overflow

Stack overflow leads to memory corruption and unpredictable behavior. To detect or prevent this:

✔️Two Key Methods:

 Memory Protection: Use MMU/MPU to guard memory areas.

 Stack Check Functions: Call a function at the start of each routine to check available stack
space.

Implementation Steps

✅ Step 1: Allocate Separate Stack for Each Mode

 ARM has banked stack pointer (SP) for modes like IRQ, FIQ, SVC.
  During system boot-up, set stack pointers for each mode.

✅ Step 2: Set Stack Size During Initialization

 Decide maximum size based on expected interrupt nesting.

 Set using:

assembly

CopyEdit

MOV r13_irq, #<IRQ_stack_top>

✅ Step 3: Enable Interrupts After Stack Is Ready

 Stack must be configured before enabling IRQ or FIQ.

 Otherwise, data will be lost or misdirected.

🧱 Memory Layout Options

📐 Layout A: Stack Below Code Segment

less

CopyEdit

High Address

| Vector Table |

| IRQ Stack |

| Code |

| Data |

| Heap |

| User Stack |

Low Address

 Disadvantage: If IRQ stack overflows, it may corrupt the code segment or vector table.

📐 Layout B: Stack at Top of Memory

less

CopyEdit

High Address

| IRQ Stack | ← Preferred

| User Stack |

| Heap |
| Data |

| Code |

| Vector Table |

Low Address

 Advantage: Safer as overflow is away from critical data/code, and system can still recover.