CS452 - Real-Time Programming - Winter 2017

Lecture 11 - Hardware Interrupts

Public Service Annoucements

  1. Due date for kernel3: Monday, 6 February, 2017.

Hardware Interrupts

What is a Hardware Interrupt?

In the CPU

A hardware interrupt is an input signal to the CPU from the outside world, usually signifying that a device needs attention. Here is the sequence of events when it occurs.

A chart of the pipeline: eleven (11) cycles
920T pipeline
PC for fetch\Cycle -2 -1 0 1 2 3 4 5 6 7 8
-8 Execute Data Write back
-4 Decode Execute Data Write back
0 (PC at IRQ Assert) Fetch Decode Execute Link Adjust
+4 Fetch Decode
+8 No Fetch
0x18 Fetch Decode Execute Data Write back
kernel entry Fetch Decode Execute

In the Interrupt Control Unit (ICU)

The input signal (IRQ pin) is created by the ICU, a component separate from the CPU, but located on the same chip as the CPU. In the Cirrus EP9302 the ICU is an ARM part, the PL190.

In the Peripheral Hardware

When two interrupts are present

There may be several interrupts present when interrupt processing starts.

How does the transition from handling the first interrupt to processing the second occur?

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

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict where they occur

Assymmetry between User Task and Kernel

Scratch registers of the user task must be saved.

Scratch registers of the kernel need not be saved.

Four link registers must be put in the correct places.

  1. One to return from interrupt
  2. One allowing the interrupting task to return from the function that was executing when it was interrupted.
  3. One allowing IRQ mode code to return from whatever function it is executing when the interrupt occurs.
  4. One allowing code executing in svc mode to return from whatever function called it.

Helpful Features of the ICU

Because the ICU was designed by programmers it has a few features that are helpful to programmers

  1. Several places where you can read state
  2. Several places where you can block interrupt flow
  3. Trigger hardware interrupt from software

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

The four registers of the timer.
Offset Function R/W Bits Comments
0x0 Timer3Load R/W 32: <Load/Reload Value>
0x4 Timer3Value R 32:<Current value> Set when Load is written,
even when counting
0x8 Timer3Control R/W 32:the lowest order bits are <CLKSEL>xx<MODE><ENABLE> <CLKSEL>: 0, 2KHz clock; 1, 508KHz
<MODE>: 1, count continuously; 0, count once
<ENABLE>: Clock turned on
No bit for turning interrupts off and on
0xc Timer3Clear W 32: Writing anything clears the interrupt

Interrupt Control Unit (ICU)

The actual device is the ARM PL190, and there are two of them in the SoC. In the Cirrus documentation they are called VIC1 and VIC2.

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

All input signals are

Base addresses

Basic Operation

VIC powers up with

Most likely you will change only the last of them.



  1. leave protection off, unless you are in doubt about your partner's ethics or competence.
  2. enable in VICxIntEnable only when you are ready to handle the interrupt

On an interrupt, the kernel

  1. reads the VICxIRQStatus register,
  2. chooses which interrupt to handle and
  3. clears the interrupt source in the device.

For debugging

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

Hardware Definitions

Registers for Basic Operation
Register Name Offset R/W Description
VICxIRQStatus 0x00 RO One bit for each interrupt source

1 if interrupt is asserted and enabled

VICxFIQStatus 0x04 RO As above for FIQ
VICxRawIntr 0x08 RO As above but not masked
VICxIntSelect 0x0c R/W 0: IRQ, 1: FIQ
VICxIntEnable 0x10 R/W 0: Masked, 1: Enabled
VICxIntEnClear 0x14 WO Clears bits in VICxIntEnable
VICxSoftInt 0x18 R/W Asserts interrupt from software
VICxSoftIntClear 0x1c WO Clears interrupt from software
VICxProtection 0x20 R/W Bit 0 enables protection from user mode access
VICxVectAddr 0x30 R/W Enables priority hardware

See documentation.

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


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

Normal operation

When a hardware interrupt occurs you find yourself in IRQ mode. How do you you are in IRQ mode?

Next, you
  1. Remember that you started in IRQ mode.
  2. Switch to svc mode.
  3. Do the context switch.
  4. Look at the active interrupt sources; decide which one you will service; turn it off.
  5. Find which task is blocked waiting for the interrupt.
  6. Set up its return value, and make it ready.
Tasks waiting on interrupts are normally high priority, and usually run right away.

If a second interrupt occurs immediately

  1. The CPU checks AND( IRQ, NOT( IRQ disabled bit set in CPSR ) ) before each instruction fetch.
  2. If it is asserted an IRQ exception is taken in place of next instruction fetch.
  3. Context switch into kernel
  4. Turn off interrupt in device

Return to: