/
1 EECS 373 1 EECS 373

1 EECS 373 - PowerPoint Presentation

faustina-dinatale
faustina-dinatale . @faustina-dinatale
Follow
390 views
Uploaded On 2016-05-15

1 EECS 373 - PPT Presentation

Design of MicroprocessorBased Systems Mark Brehob University of Michigan Lecture 6 Interrupts January 30 th Slides developed in part by Prof Dutta Announcements Behind due to snow ID: 321327

word interrupt handler interrupts interrupt word interrupts handler data program code processor state reset register external branch ignore device

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "1 EECS 373" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

1

EECS 373Design of Microprocessor-Based SystemsMark BrehobUniversity of MichiganLecture 6: InterruptsJanuary 30th

Slides developed in part by

Prof. DuttaSlide2

Announcements

Behind due to snow…2Slide3

3

OutlineAPB reviewInterruptsBackgroundOur processor (Cortex M3 and the SmartFusion implementation)Slide4

So what’s happening here? Read? Write? Wait states?Slide5

And here?

5The key thing here is that each slave device has its own read data (PRDATA) bus!Slide6

6

And this?Setup phase beginswith this rising edgeSetupPhaseAccessPhaseWait

State

Wait

StateSlide7

Verilog!

7Slide8

8

APB state machineIDLEDefault APB stateSETUPWhen transfer requiredPSELx is assertedOnly one cycleACCESSPENABLE is assertedAddr, write, select, and write data remain stableStay if PREADY = LGoto IDLE if PREADY = H and no more dataGoto SETUP is PREADY = H and more data pendingWe’ll spend a bit more time on this next week…Slide9

Interrupts

Merriam-Webster: “to break the uniformity or continuity of”Informs a program of some external eventsBreaks execution flowKey questions:Where do interrupts come from?How do we save state for later continuation?How can we ignore interrupts?How can we prioritize interrupts?How can we share interrupts?9Slide10

I/O Data Transfer

Two key questions to determine how data is transferred to/from a non-trivial I/O device:How does the CPU know when data is available?PollingInterruptsHow is data transferred into and out of the device?Programmed I/ODirect Memory Access (DMA)Slide11

Interrupts

Interrupt (a.k.a. exception or trap): An event that causes the CPU to stop executing the current program and begin executing a special piece of code called an interrupt handler or interrupt service routine (ISR). Typically, the ISR does some work and then resumes the interrupted program.Interrupts are really glorified procedure calls, except that they:can occur between any two instructionsare transparent to the running program (usually)are not explicitly requested by the program (typically)call a procedure at an address determined by the type of interrupt, not the programSlide12

Two basic types of interrupts(1/2)

Those caused by an instructionExamples:TLB missIllegal/unimplemented instructiondiv by 0Trap instructionNames:Trap, exception, software interruptSlide13

Two basic types of interrupts(2/2)

Those caused by events external to the core.External deviceReset buttonTimer expiresPower failureSystem errorNames:interrupt, external interrupt, hardware interruptSlide14

How it works

Something tells the processor core there is an interruptCore transfers control to code that needs to be executedSaid code “returns” to old programMuch harder then it looks.Why?Slide15

… is in the details

How do you figure out where to branch to?How to you ensure that you can get back to where you started?Don’t we have a pipeline? What about partially executed instructions?What if we get an interrupt while we are processing our interrupt?What if we are in a “critical section?”Slide16

Where

If you know what caused the interrupt then you want to jump to the code that handles that interrupt.If you number the possible interrupt cases, and an interrupt comes in, you can just branch to a location, using that number as an offset (this is a branch table)If you don’t have the number, you need to poll all possible sources of the interrupt to see who caused it.Then you branch to the right codeSlide17

Get back to where you once belonged

Need to store the return address somewhere.Stack might be a scary place. That would involve a load/store and might cause an interrupt (page fault)!So a dedicated register seems like a good choiceBut that might cause problems later…Slide18

Snazzy architectures

Be aware that processors sometimes “cheat”Execute instructions out-of-order.Can happen even in a (mostly) “in-order” processor due to variable execution latencies.So when an interrupt occurs, need to get things in order.Could be a delay. Slide19

Nested interrupts

If we get one interrupt while handling another what to do?Just handle itBut what about that dedicated register?What if I’m doing something that can’t be stopped?Ignore itBut what if it is important?PrioritizeTake those interrupts you care about. Ignore the restStill have dedicated register problems.Slide20

Critical section

We probably need to ignore some interrupts but take others.Probably should be sure our code can’t cause an exception.Use same prioritization as before.Slide21

21

OutlineInterruptsBackgroundOur processor (Cortex M3 and the SmartFusion implementation)Slide22

22Slide23

SmartFusion interrupt sources

23Slide24

And the interrupt vectors (in startup_a2fxxxm3.s found in CMSIS, startup_gcc)

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)

24Slide25

Interrupt handlers

25Slide26

Pending interrupts

26The 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.4Slide27

27

In this case, the processor never took the interrupt because we cleared the IPS by hand (via a memory-mapped I/O register)Slide28

28Slide29

29Slide30

Answer

30Slide31

Interrupt pulses before entering ISR

31Slide32

Answer

32Slide33

33Slide34

34Slide35

35Slide36

36Slide37

37Slide38

38Slide39

39Slide40

40Slide41

Masking

41Slide42

42Slide43

Example of Complexity: The Reset Interrupt

No powerSystem is held in RESET as long as VCC15 < 0.8VIn reset: registers forced to default RC-Osc begins to oscillateMSS_CCC drives RC-Osc/4 into FCLKPORESET_N is held lowOnce VCC15GOOD, PORESET_N goes highMSS reads from eNVM address 0x0 and 0x443Slide44

The xPSR register layout

44