CS452 - Real-Time Programming - Winter 2015
Lecture 11 - Hardware Interrupts
Public Service Annoucements
- Due date for kernel3: 9 June, 2015
- Updated k3.pdf
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.
- Test interrupt signal before fetching the next instruction
- actually AND of INT and the IRQ bit in the CPSR
- If asserted, change mode to IRQ
- Disable interrupt in CPSR
- Execute instruction at 0x18
A chart of the pipeline: eleven (11) cycles
920T pipeline
Address |
-2 |
-1 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
|
IRQ Assert |
|
IRQ Ack |
|
|
|
|
|
|
PC before IRQ |
Fetch |
Dec |
Exec |
Link |
Adjust |
|
|
|
|
+4 |
|
Fetch |
Dec |
|
|
|
|
|
|
+8 |
|
|
Fetch |
|
|
|
|
|
|
0x18 |
|
|
|
Fetch |
Dec |
Exec |
Data |
Wrbk |
|
kernel entry |
|
|
|
|
Fetch |
Dec |
Exec |
Data |
Wrbk |
In the Interrupt Control Unit (ICU)
The input signal 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.
-
The ICU has many inputs, each hard-wired to a specific device.
The EP9302 ICU consists of two PL190s for a total of 64 inputs.
Most of them are used talking to devices on the EP9302.
-
Several interrupts may be present when an interrupt occurs
-
One is chosen, by a priority mechanism
-
software: the kernel knows priorities, chooses the
highest priority one using software
-
hardware: the kernel programs its priorities into the
ICU.
-
Software can override priority mechanism in ICU (not
recommended)
-
The time of an interrupt is not correlated with the time
of any other interrupt.
-
Clearing one interrupt may expose another one.
-
When and why does the next interrupt occur?
In the Peripheral Hardware
- Several interrupts may be present
- ORed in peripheral hardware
- ORed in glue hardware
- Rare that there is a priority mechanism
- Clearing one interrupt can expose another one
When two interrupts are present
There may have been two interrupts present when interrupt
processing started.
-
The second interrupt to be processed is lower in (interrupt)
priority than the first.
There may have a single interrupt present when interrupt processing
started.
-
The second interrupt occurred while the kernel was processing
the first.
-
Then the second interrupt processed may have higher (interrupt)
priority than the first.
How does the transition from handling the first interrupt to processing the
second occur?
-
Kernel executes with interrupts disabled
-
Context switch into user task turns on interrupts
-
Before fetching the first user task instruction the instruction fetch
procedure is followed
-
If IRQ 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 can 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.
- assuming that you do not let the optimizer loose on your context
switch.
Two Link Registers
- One to return from interrupt
-
In the IRQ mode link registers
-
where the interrupt handling code starts,
-
The other on the caller's stack in USR mode.
-
so the interrupted task can provide the
pc
when it returns from the function it was executing when the
interrupt occurred.
-
In the registers of the interrupted task
-
To return to whatever function that was being executed in
interrupted task
Helpful Features of the ICU
- Several places where you can read state
- Several places where you can block interrupt flow
- Trigger hardware interrupt from software
- 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
- This allows you to separate them in developing/debugging
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
|
0xc |
Timer3Clear |
W |
32: |
Writing anything clears the interrupt |
Interrupt Control Unit (ICU)
The actual device is the ARM PL190
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:
0
x800C0000
Basic Operation
VIC powers up with
- all vectored interrupts disabled.
- all interrupts masked
- all interrupts giving IRQ
Procedure
Initialization
- leave protection off
- enable in VICxIntEnable when you are ready to handle the interrupt
On an interrupt, the kernel
- reads the VICxIRQStatus register,
- chooses which interrupt to handle and
- clears the interrupt source in the device.
For debugging
- 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
- Several places where you can read state
- Several places where you can block interrupt flow
- Trigger hardware interrupt from softwareonce
- 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
- Software interrupt generation allows you to separate them in
developing/debugging
Non-vectored Operation
Initialization
- Enable interrupt in device
- Enable interrupt in ICU
- Enable interrupt in CPU, usually by MOVS
If a second interrupt occurs immediately
- The CPU checks AND( IRQ, NOT( IRQ disabled bit set in CPSR ) ) before each
instruction fetch.
- If it is aserted IRQ exception is taken in place of next instruction fetch.
- Possibly zero instructions of active task are executed.
- Make sure that this case works
- Context switch into kernel
- Turn off interrupt in device
- Should turn off interrupt in ICU
- What about IRQ?
Context switch novelties
Differences of hardware interrupts from software interrupts
- It is impossible to predict where they occur
- In k1 you may have inadvertently made some assumptions about when
interrupts can 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
You are now ready to process the interrupt in the kernel
Return to: