EECS 373
Design of Microprocessor-Based Systems
Prabal Dutta
University of Michigan
Lecture 7: Interrupts (2)
January 29, 2015
Some slides prepared by Mark Brehob
1
High-level review of interrupts
• Why do we need them? Why are the alternatives
unacceptable?
– Convince me!
• What sources of interrupts are there?
– Hardware and software!
• What makes them difficult to deal with?
– Interrupt controllers are complex: there is a lot to do!
• Enable/disable, prioritize, allow premption (nested
interrupts), etc.
– Software issues are non-trivial
• Can’t trash work of task you interrupted
• Need to be able to restore state
• Shared data issues are a real pain
2
3
4
5
6
Pending interrupts
The normal case. Once Interrupt request is seen, processor puts it in
“pending” state even if hardware drops the request.
IPS is cleared by the hardware once we jump to the ISR.
This figure and those following are from The Definitive Guide to the ARM Cortex-M3, Section 7.4
7
8
9
10
11
12
Masking
13
Interrupt Service Routines
• Automatic saving of registers upon exception
–
–
PC, PSR, R0-R3, R12, LR
This occurs over data buss
• While data bus busy, fetch exception vector
–
–
•
•
•
•
•
•
i.e. target address of exception handler
This occurs over instruction bus
Update SP to new location
Update IPSR (low part of xPSR) with exception new #
Set PC to vector handler
Update LR to special value EXC_RETURN
Several other NVIC registers gets updated
Latency can be as short as 12 cycles (w/o mem delays)
14
The xPSR register layout
15
ARM interrupt summary
1. We’ve got a bunch of memory-mapped registers
that control things (NVIC)
– Enable/disable individual interrupts
– Set/clear pending
– Interrupt priority and preemption
2. We’ve got to understand how the hardware
interrupt lines interact with the NVIC
3. And how we figure out where to set the PC to
point to for a given interrupt source.
16
1. NVIC registers (example)
17
1. More registers (example)
18
1. Yet another part of the NVIC registers!
19
2. How external lines interact with the NVIC
The normal case. Once Interrupt request is seen, processor puts it in
“pending” state even if hardware drops the request.
IPS is cleared by the hardware once we jump to the ISR.
This figure and those following are from The Definitive Guide to the ARM Cortex-M3, Section 7.4
20
3. How the hardware figures out what to set the PC to
g_pfnVectors:
.word _estack
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
.word MemManage_Handler
.word BusFault_Handler
.word UsageFault_Handler
.word 0
.word 0
.word 0
.word 0
.word SVC_Handler
.word DebugMon_Handler
.word 0
.word PendSV_Handler
.word SysTick_Handler
.word WdogWakeup_IRQHandler
.word BrownOut_1_5V_IRQHandler
.word BrownOut_3_3V_IRQHandler
.............. (they continue)
21
Discussion: So let’s say a GPIO pin goes high
- When will we get an interrupt?
- What happens if the interrupt is allowed to proceed?
22
What happens when we return from an ISR?
• Interrupt exiting process
–
–
System restoration needed (different from branch)
Special LR value could be stored (0xFFFFFFFx)
• Tail chaining
–
–
–
–
–
–
When new exception occurs
But CPU handling another exception of same/higher priority
New exception will enter pending state
But will be executed before register unstacking
Saving unnecessary unstacking/stacking operations
Can reenter hander in as little as 6 cycles
• Late arrivals (ok, so this is actually on entry)
–
–
–
–
When one exception occurs and stacking commences
Then another exception occurs before stacking completes
And second exception of higher preempt priority arrives
The later exception will be processed first
23
Other stuff: The xPSR register layout
24
Example of Complexity: The Reset Interrupt
1) No power
2) System is held in RESET as long as VCC15 < 0.8V
a) In reset: registers forced to default
b) RC-Osc begins to oscillate
c) MSS_CCC drives RC-Osc/4 into FCLK
d) PORESET_N is held low
3) Once VCC15GOOD, PORESET_N goes high
a) MSS reads from eNVM address 0x0 and 0x4
25
Interrupt types
• Two main types
– Level-triggered
– Edge-triggered
26
Level-triggered interrupts
• Signaled by asserting a line low or high
• Interrupting device drives line low or high and holds it
there until it is serviced
• Device deasserts when directed to or after serviced
• Can share the line among multiple devices (w/ OD+PU)
• Active devices assert the line
• Inactive devices let the line float
• Easy to share line w/o losing interrupts
• But servicing increases CPU load  example
• And requires CPU to keep cycling through to check
• Different ISR costs suggests careful ordering of ISR checks
• Can’t detect a new interrupt when one is already asserted
27
Edge-triggered interrupts
•
•
•
•
•
•
•
•
•
•
•
•
Signaled by a level *transition* (e.g. rising/falling edge)
Interrupting device drive a pulse (train) onto INT line
What if the pulse is too short? Need a pulse extender!
Sharing *is* possible...under some circumstances
INT line has a pull up and all devices are OC/OD.
Devices *pulse* lines
Could we miss an interrupt? Maybe...if close in time
What happens if interrupts merge? Need one more ISR
pass
Must check trailing edge of interrupt
Easy to detect "new interrupts”
Benefits: more immune to unserviceable interrupts
Pitfalls: spurious edges, missed edges
28