ARM Exception Handling CS2253 Owen Kaser, UNBSJ

Overview ● Warning: hardest parts of CS2253.

● Back to Chapter 1: Processor Modes & Vector Table

● Concept of Exceptions – Interrupt Handlers – Priority Levels ● Software Interrupts

● Memory-Mapped Input/Output

● See Textbook Chapter 14, 16

Exceptions

● Sometimes, the normal flow of control needs to be unexpectedly modified – A character is received on the keyboard – An access is made to a memory location with no memory/device there – The processor is asked to execute a bit pattern that is not a valid machine code ● Two main cases: interrupts and errors

Interrupts

● An interrupt can occur because a hardware device wants service...now.

● Device: “I have just received a character from the keyboard, and my buffer is only 1 character deep. Please stop whatever you are doing and remove/process this character ASAP, so that I will be able to accept the next character the keyboard sends”.

● CPU: “ok, I see your interrupt request. I am interrupting my normal execution to switch to handler code for you. When I finish, I will return to my normal execution, where I left off.”

Why Interrupts?

● There can be a lot of asynchronous things happening in a computer system. Having one program keeping track of them would be hard.

● (Eg, every loop that ran more than a few microseconds would have to contain code to check for input/output)

● System running one dedicated program can use this approach. Maybe it even waits, looping, while I/O happens.

● This is called polling I/O. It is generally viewed as unweildy.

● Better to just have the I/O device interrupt.

IRQ and FIQ interrupts

● The ARM ISA defines regular (IRQ) interrupts and fast (FIQ) interrupts.

● Stay tuned.

Software Interrupts

● Some ISAs, including ARMv4, have a special SWI instruction that, when executed, causes the system to act like a hardware device requested an interrupt.

● A hardware interrupt is like an unscheduled subroutine call that also puts the processor into an more privileged mode. Handler code is trusted and part of the operating system.

● So an SWI instruction is often used to invoke an operating system service subroutine.

● Book refers to the SWI instruction under its new name, SVC, but Crossware still uses SWI.

Error Exceptions

● Undefined instruction – Can be intentional (emulate a “missing” instruction) ● Prefetch abort – An attempt to fetch instruction fails (eg, PC is not a valid memory location) ● Data abort – A LD or ST with an illegal address – A store to a read-only address ● Sometimes, the response should be to die gracefully. But other times, we may be able to recover and continue.

Overall Approach

● For an exception, we need to – save the current state (including CPSR) – Reset the PC to the handler code [ & change mode] – Execute the handler – Restore the saved state, including the PC & mode ● State saving and PC resetting are done by hardware. Handler and restoring done by software.

Modes

● See textbook Sections 2.3.1, 2.3.2.

● Normal code executes in User mode. In processing exceptions, modes are System, Undef, Abort, IRQ, FIQ, Supervisor.

● In some of these modes, some of the registers are banked out. The User version of R11 is hidden from use, replaced by another R11 when in FIQ mode. (So the User version of R11 is safe from modifications.)

Processor Modes (Book Fig 2.1)

Registers in Different Modes

Recognizing Your Mood Mode

● The CPSR stores more than your status flags. A 5-bit field M4:M0 stores a flag indicating mode (Table 2.1) – eg 10000 for User, 11011 for Undefined, etc.

● I bit enables or disables IRQ interrupts

● F bit enables or disables FIQ (fast) interrupts

● T is status: are you in Thumb mode?

Details Invoking Exception

● See textbook 14.4.

● First, CPSR copied to SPSR_

● Adjust CPSR (mode bits, disable IRQ, maybe disable FIQ)

● Store return address to LR_

● Set PC to start of relevant handler

Finding the Right Handler ● For the different kinds of exceptions, there are different handlers. When an exception occurs, the hardware determines the source of the exception as a 3-bit number, which it uses to index the vector table (which starts in memory at address 0).

Textbook Figure 14.3

Returning After Exception

● When the handler has finished its task, it returns to the caller (in software)

● The mode needs to be put back to its pre-interrupt value. And the PC needs to be put back to the correct instruction. – Either to the instruction that had the exception (and did not successfully finish) or to the next instruction. Case depends on the kind of exception ● SUBS PC, LR, #4 or SUBS PC, LR, #8 ← magic CPSR restore when PC is the destination and the S flag set

● Or on entry to handler – adjust LR (eg subtract 4) – STMDB sp!,{some regs, lr} ● then use a LDMIA sp!, {some regs, pc}^ to return.

● ^ means to restore CPSR also.

Multiple Stacks

● Interrupt code typically uses stacks. And there is a separate R13 for each mode (except one). So there is a separate stack per mode...and at machine startup, it needs to be initialized.

● Initialization via a MSR (move into status register) instruction to change mode.

● Then store a value to (that) SP.

● Then use a MSR to put mode back

Mrs. MRS

● MSR moves to a status register. – Status registers are CPSR, SPSR – Underscores after (eg CPSR_cf) indicate which sub-parts of the status register are affected. Used in book code but not described… _cxsf is all of it?. ● MRS moves a status register into a regular register.

Implementing ADDSHIFT

● See Example 14.1 for the hairiest program of CS2253.

Priorities

● In order of decreasing priority, we have – Reset – Data abort – FIQ – IRQ – Prefetch abort – SVC and Undefined Instruction ● A higher priority exception can interrupt the handling of a lower priority exception, but usually not the other way.

Priorities in IRQ

● Even within a given exception (eg IRQ), some hardware units (eg disk) are more urgent than others (eg keyboard).

● To prioritize, could OR together all interrupt request inputs. Then software can check each possible device to see who’s knocking...starting with the most urgent.

● Or a special priority device, a VIC, can take care of this. – Devices' IRQ lines go to VIC – Only VIC actually interrupts CPU – CPU can ask VIC for the handler address of the highest priority active interrupt request. [talking to devices: stay tuned!]

Vectoring IRQ Interrupts Textbook Figure 14.5

Software Interrupts

● Software can generate an exception. Use SWI to request an operating-system service.

● SWI handler has to use the value in R14 to find the actual instruction, in order to extract the “SVC number” field and thus know which OS service was requested.

● Assembler example: SWI 234

Talking to Devices (Ch 16)

● Not dealing with co-processors in CS2253.

● Instead, we are dealing with attached devices such as – UART (“serial port”) – Timer – Analogue to Digital (A-D) and Digital to Analogue converters – Disk controllers – General Purpose I/O (GPIO) connections that can control electronic devices (LEDs, motors, ...)

Special I/O Instructions

● Some ISAs (not ARM) have special instructions to access devices

● Intel x86: IN and OUT instructions.

● Devices are assigned 1+ numeric “port addresses”.

● CPU does an OUT instruction to the port address of the UART to give it a command

● CPU does an IN instruction to the port address to get a byte of data from the UART, or check its status.

● Frequently, a device has several (usually consecutive) port addresses: – 1+ status port, 1+ control port, 1+ data output port, 1+ data input port.

Memory-Mapped I/O

● Alternative: memory-mapped I/O, where certain “memory” addresses have no RAM.

● Instead, they are assigned to devices. No distinction between “port addresses” and “memory addresses”

● Now, ordinary LD and ST instructions (to the right “memory” addresses) can talk to devices.

● No IN or OUT instructions: RISC-ish.

Book Example

● LPC2104 System-on-Chip has an ARM processor core and a bunch of memory-mapped devices (peripherals)

● Some are internally connected via an “AHB” bus and some via an “VPB” bus.

● All VPB bus peripherals are in one range of addresses (0xE000000 to 0xEFFFFFF)

● UART0 device occupies 0xE000C000 to 0xE000C01C

● Every 4 addresses, we have 8 bits of data. Use LDRB or STRB to access, avoid endian-ness issue.

SoC's Memory Map

Zoom Into 0xE000C000 area

UARTs are Fiddley

● Serial communication is quite hairy. Lots of communications parameters to be set. You're lucky this era is largely past us.

● After setup, sending characters is pretty easy.

● Bit 5 of the Line Status Register (memory mapped to 0xE000C014) tells us if the transmitter buffer can accept another character now. (0 means “yes”)

● Transmit Holding Register (0xE000C000) is where we can put the next character.

Polling I/O Example (p 347, mod)

; ASCII code to send is in R0 LDR R5, =0xE000C000 wait LDRB R6, [R5, #0x14] ; Line Status Reg CMP R6, #0x20 ; Risky check of Bit 5 BEQ wait ; spin until ready ; if we get here, bit 5 = 0 STRB R0,[R5] ; write to transmitter buff.

Polling vs Interrupt Driven I/O

● Note how the “wait” loop repeated asks (polls) the device to see if it is ready.

● If not, it just tries again...and again...and....

● No other work in the system can be done...tight polling loops waste system resources.

● Better to flip some bits in 0xE000C004 and get the transmitter to give us an interrupt when its buffer gets some space. In the meantime, we can be doing other things (eg, getting input, doing calculations).

● This “Interrupt-driven I/O” is generally better, though more complicated.