CS452 - Real-Time Programming - Winter 2013

Lecture 11 - Hardware Interrupts

Pubilc Service Annoucements

1. Due date for assignment 3

Hardware Interrupts

What is a Hardware Interrupt?

In the CPU

1. Test interrupt signal before fetching the next instruction
   • actually AND of INT and the IRQ bit in the CPSR
2. If asserted, follow interrupt procedure

       LR_irq = address of next instruction to be executed + 4
       SPSR_irq = CPSR
       CPSR[4:0] = 0b10010    ; IRQ mode
       CPSR[5] = 0            ; ARM instructions
       CPSR[7] = 1            ; disable interrupts
       PC = 0x018

3. Execute instruction at 0x18, which results in a jump to a kernel entry sooner or later.

In the Interrupt Control Unit (ICU)

• Several interrupts may be present when an interrupt occurs
  • One is chosen, by a priority mechanism
  • A software priority mechanism is easiest to implement
    • Read register in ICU
    • Determine which interrupt is most important to you
    • Leave the other(s) until later
  • Hardware is faster, but is error prone and only a little faster

In the Peripheral Hardware

• Several interrupts may be present
  • ORed in peripheral hardware
  • ORed in glue hardware
  • Software determines priority
    • Read register in peripheral
    • Determine which interrupt is most important
    • Leave the other(s) to later
• Clearing one interrupt can expose another one

When two interrupts are present

Clearing one interrupt can mean you take another immediately

1. Kernel executes with interrupts disabled
2. Context switch into user task turns on interrupts
3. Before fetching the first user task instruction test interrupt signal
4. If asserted, re-initiate interrupt processing

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict where they occur

• You may have made some assumptions about when they occur

Assymmetry between User Task and Kernel

Scratch Registers must be saved

• including the IP

Two Link Registers

1. One to return from interrupt
   • In the registers of the interrupt handling code
   • To return to the interrupted task in the right place
2. One to unwind the caller's stack frame
   • In the registers of the interrupted task
   • To return to whatever started in interrupted task

The SWI link register is off by 4 compared to the IRQ link register.

Everything above is extra compared to the software context switch.

One entry point or two

It's up to you, but it's probably a good idea to have a single exit, which is easier if there's one entry.

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from software
   • What makes interrupts hard is that you are doing two semi-hard things at once
     1. Making the hardware produce the interrupt
     2. Responding to the interrupt
   • This allows you to separate them in developing/debugging

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

Three registers:

Interrupt Control Unit (ICU)

The actual device is the ARM PL190, Vectored Interrupt Controller (VIC), Interrupt Control Unit (ICU)

The logic in this design is completely asynchronous, so it functions when the CPU clock is turned off.

• Important (= essential) for low power operation.

All input signals are

• active high
• level sensitive

Base addresses

• VIC1: 0x800B0000
• VIC2: 0x800C0000

Basic Operation

VIC powers up with

• all vectored interrupts disabled.
• all interrupts masked
• all interrupts activating IRQ

It's a bad idea to assume that it's in this state when your kernel starts running.

Procedure

Initialization

1. leave protection off
2. enable in VICxIntEnable when you are ready to handle the interrupt

On an interrupt

1. Read VICxIRQStatus
2. Choose which interrupt you wish to handle
3. Clear the interrupt source in the device

For debugging

1. Use VICxSoftInt and VICxSoftIntClear to turn interrupt sources off and on in software

Hardware Definitions

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from softwareonce
   1. What makes interrupts hard is that you are doing two semi-hard things at once
      • Making the hardware produce the interrupt
      • Responding to the interrupt
   2. Software interrupt generation allows you to separate them in developing/debugging

Non-vectored Operation

Initialization

1. Enable interrupt in device
2. Enable interrupt in ICU
3. Enable interrupt in CPU, usually by MOVS or SUBS

Interrupt occurs

1. AND of IRQ and NOT( IRQ disabled bit in CPSR ) is checked before each instruction fetch.
2. If set IRQ exception is taken in place of next instruction fetch.
   • Possibly zero instructions of active task are executed.
   • Make sure that this case works
3. Context switch into kernel

   ---

   Context switch novelties

   Difference from Software Interrupts

   • It is impossible to predict where they occur
   • You may inadvertently have made some assumptions about when they occur
   • Scratch Registers must be saved
     • r0-3
     • IP -- used only very occasionally by gcc
   • Two Link Registers
     • One to return from interrupt
     • One to return from the interrupted task to whatever called it
     • Trashing the second link register in the kernel is a bug that doesn't occur with a software interrupt.

   ---

4. Turn off interrupt in device
   • Should turn off interrupt in ICU
   • What about IRQ?

You are now ready to process the interrupt in the kernel

Return to:

• Bill Cowan's lecture notes for CS452 in w13
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page