YT YouTube2Text

YouTube2Text → Transcripts → EECS 373 - Fall 2026 - Lecture 6: “Interrupts”

EECS 373 - Fall 2026 - Lecture 6: “Interrupts” — Transcript

by Interactive Sensing and Computing Lab · 9,273 words · 1,556 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:02All right, we can begin. Let's see here.
0:09All right, sorry for technical delays.
0:11We're just getting slides downloaded.
0:15So, today we're going to be talking
0:16about interrupts.
0:17Um we'll go actually go through the uh
0:20the data sheet as well. But, homework is
0:23due today. There's office hours after
0:25class. And then uh next week or next on
0:29Wednesday we'll talk through logistics
0:31of the exam. We'll talk about that a
0:32little bit today, but uh I'll also go
0:34through the data sheet. So, before we
0:36get started, are there any questions?
0:39Yeah.
0:40>> How many lectures uh are there that are
0:42going to be covered on the exam?
0:43>> How many lectures?
0:44>> Yes. I figured what lectures is the
0:46content coming from?
0:48>> Um we'll talk So, we're not going to be
0:50able to get into deep into um
0:52interrupts, and you won't have a lab on
0:54interrupts. So, I would say the
0:55nitty-gritty of getting into interrupts
0:57is probably not going to be on the exam,
0:58but maybe a conceptual question would
1:01probably be really reasonable after
1:02today's lecture.
1:05And we'll do Wednesday we'll do a full
1:06review of what's going to be on the
1:08exam.
1:09Give you guys a chance to ask questions.
1:11What other questions you have?
1:13Yeah.
1:14>> Do we need labs?
1:16>> Yes, you have lab this week. Go to lab.
1:19So, we're not going to make the labs due
1:21this week. It's a little bit longer lab,
1:23but it also takes your pressure off,
1:24right? So, you should go to lab. They're
1:26going to be staffed. They're going to be
1:27giving you the presentations on how to
1:29do the lab, but because we have an exam
1:31this week, we're not making labs due
1:34this week. So, it kind of takes some of
1:35the pressure off you. So, you do have an
1:36extra week. So, if you wanted to skip
1:38lab, that's fine, I suppose, but then
1:41nobody's going to be there to
1:42necessarily tell you how to do the lab
1:44next week. If that makes sense. They'll
1:46still be staffed, but they're not going
1:47to be giving the presentation.
1:50What other questions you have?
1:55Okay.
1:59So, let's see.
2:01So, let's off with the component of the
2:02day.
2:03How many people have used servos before?
2:07Oh, most of you. Is that a question?
2:10No, that was no question. Okay, just
2:12telling me you're excited. All right.
2:14How servos servos work servos are just a
2:17a DC motor, but they have one special
2:19trick. The special trick
2:23is that Oh, I don't want that. The
2:25special trick is that they have a little
2:27piece of feedback in there. There's a
2:28little piece of hardware
2:30in there, which is basically a
2:31comparator.
2:32And that comparator is working to look
2:35at the pulse train coming in and go to a
2:38particular location. So, most more
2:40normally a motor just rotates. You put
2:42DC power and goes clockwise or
2:44counterclockwise. This one has a special
2:46feature of it will go to a particular
2:47location. How is that defined? Well,
2:50there's these three uh pins or wires
2:52that are put there. So, power and
2:54ground, that makes sense, and also
2:55signal. And then signal has a little
2:57pulse train.
2:58So, the width of that pulse encodes the
3:02angle that it should be at at some
3:04mapping that will be defined in the data
3:05sheet. And so, you have some that will
3:07go plus or minus 90°, and you'll have
3:09others that will go plus or minus 180,
3:12and some of that will also spin if you
3:14go all the way to the extent. So,
3:16there's different types of servos, and
3:19they come in different weight categories
3:20and torque categories.
3:22But, that allows you to do things like
3:23this. So, here person has an IMU and the
3:26controller, and then the servo is trying
3:28to mimic
3:29those uh
3:31um
3:32motions.
3:33What questions you have?
3:38Okay.
3:41All right. Actually, we got ahead, so
3:44we're not going to do a quick review of
3:45memory map IO, but let's go through the
3:47data sheet just to save that we did it.
3:51Um
3:52Okay, so on the assignment page
3:56is
3:57uh the data sheet.
3:59And so, the reason we give you I should
4:01have explained this earlier. I think
4:03we'll have to write up a formal syllabus
4:04for this class cuz we get lots of edge
4:06condition questions. But, the idea of a
4:08data sheet is that uh we want to ask
4:12more interesting questions of you about
4:14how embedded systems can be put
4:15together.
4:16But, it's not really fair. And so, what
4:19we used to do is give you like, here's a
4:21data sheet. In 473, they'll give you
4:22like, here's a real data sheet.
4:24The challenge is that that puts a lot of
4:26pressure on you in a 2-hour exam to read
4:29like 11-page data sheet and come up with
4:31an answer, right? That's And that's also
4:33not how engineering works. I've never
4:34been in a situation where my boss is
4:36like, you know, read this data sheet and
4:38program this thing in 2 hours or you're
4:40fired. Like, that that never happens.
4:42So, we're going to give you the data
4:44sheet beforehand and it outlines, for
4:46instance, this mythical processor that
4:48we've made and you've you've seen it
4:49from your other ones. Uh so, you get
4:51this mythical processor. Uh formatting
4:54already got screwed up. Cool.
4:57Uh that's unscrewed up. Uh it has This
5:00is kind of like what you would normally
5:01see in a data sheet. Has architecture,
5:02has pin assignments. And then it has
5:04some registers.
5:06And some of those registers have
5:07particular functions and mappings. And
5:09so, it's your job to be able to review
5:11all this information beforehand and
5:13figure out like how to use the thing,
5:16basically.
5:17And then we also give a data sheet for
5:19this mythical microphone.
5:21And a data sheet for this LCD screen,
5:23which is different than last
5:25uh F25's
5:28uh LCD screen cuz it has a different
5:29interface.
5:31And so, you should be go through these
5:33data sheets and read through and make
5:34sure you understand what's in there. And
5:36if there's you have questions, you can
5:38raise them, put them in Piazza, come to
5:39office hours. And sometimes students
5:41will find errors. They'll be like, "Hey,
5:42look, your addressing scheme is crazy.
5:44Right? Is this supposed, you know, okay,
5:45we'll we'll fix those errors." And uh if
5:47there are any issues, we'll update them
5:50on Piazza so everybody uh is aware of
5:52those. But, you could also, as a study
5:55uh method, you could probably figure out
5:57what the exam problem is.
6:00Right? Like, you could just write it
6:01down.
6:02And just guess what the exam problem is.
6:04We're not too creative. So, you could
6:06say, well, like, okay.
6:08Let's see. You're probably going to have
6:10a microcontroller.
6:12It probably has a GPIO interface.
6:15It has some weird audio interface.
6:19>> [snorts]
6:19>> There's a microphone.
6:22And there's an LCD screen.
6:24So, pretty much, you could probably
6:25figure out what's on the exam.
6:30What do you think?
6:32What questions you have?
6:38Yeah.
6:39>> Do we get a data sheet in
6:41>> No.
6:43I mean, we're going to give We're going
6:44to give you a copy of this data sheet on
6:46the exam. And then, if you look at the
6:48very bottom of the data sheet, they have
6:51here are like some There's an appendix,
6:54right? So, here's what a timing diagram
6:55looks like for an APB. Here are some
6:57symbols that you could use. So, you
6:58don't have to remember that. Here a
7:00whole bunch of instructions.
7:02Like, your ability to remember
7:03instructions is probably not that
7:05important as an engineer. Your ability
7:06to to know how to use them when you look
7:08at a reference sheet is really
7:09important.
7:17So, does this feel overwhelming or does
7:19this seem like, okay, I just got to do
7:21some more studying?
7:24All right. Over Well, okay. I saw some
7:26people going like that. You will see
7:28we'll go through There's two practice
7:30exams on the on the website. The
7:33assignment page one is I didn't make
7:35that. It was from last year's winter and
7:36one I made
7:38uh last year
7:40uh fall. But, I'll I'll answer questions
7:43on all of them. And you can kind of see
7:45what What is the challenge that you're
7:47up against? Um I would say that the
7:49trick is really how to kind of like lab
7:52is how do you architect these things?
7:54And specifically, also remembering that
7:56this data sheet like
7:59you could imagine that if you read the
8:02the data sheet here, this tells you what
8:04the architecture of a peripheral is.
8:07Just by reading it. you could guess. You
8:09can look through the datasheet and
8:10imagine what that peripheral is made of,
8:13>> [clears throat]
8:13>> how it functions on the inside. This
8:14defines how it's going to operate. It's
8:17an important thing to remember.
8:19All right. Well, we'll do a a more
8:21detailed review
8:22uh tomorrow.
8:25But for now, we're going to start uh
8:29Oops. Slides got a little out of
8:30control.
8:31We'll start doing uh interrupts.
8:36All right.
8:37So,
8:38up until now, you've been living in this
8:40a world where you're you're basically
8:42like in a while one loop and everything
8:43is happening um synchronously. Um
8:48but there's a problem where the external
8:50world is not a synchronous event. It
8:51doesn't happen
8:53uh as on a function call. It doesn't
8:55happen on a clock schedule. So, um
8:57you have events like people pressing
8:59buttons or sensors going off and you
9:01need some methodology to allow that that
9:05information to go and interrupt your
9:07system process so you can respond. So,
9:09this is really about being responsive.
9:11And it's being responsive to things that
9:12are internal and external to your
9:14microcontroller.
9:16Um
9:17So, applications make system calls.
9:19Software
9:20uh does instructions, but what about
9:23these external events? How do you know?
9:25So, probably to term, there's two
9:27versions.
9:29Uh there is two ways to figure out an
9:30external event works. So, one would be
9:32you could just pull and that's probably
9:34mostly what you've done so far. You can
9:35just go check the GPIO pin, measure a
9:38thing. Yes.
9:41>> Your mic is not working.
9:42>> My mic is not working.
9:44Thank you for telling me. Let's see.
9:46This is
9:50How about now?
9:52Okay.
9:53Thank you.
9:55Um so, there's basically two ways to
9:58check for uh external events. One would
10:00be polling. And so, that is where you
10:02could go and you could just like do a
10:05load, right? And you could just load the
10:08value of some GPIO uh
10:10register, like the input for a GPIO pin
10:13and to see if that
10:18and then an interrupt lets the processor
10:22get notified through some other method
10:24that this polling event has occurred.
10:26>> [clears throat]
10:27>> So,
10:28I don't know who made these slides, but
10:31so the the example of polling is trying
10:33like texting with notifications turned
10:36off. Basically, the only way you get to
10:38know if anything happens is your
10:39response from the other person is if
10:41you're actually looking at your screen.
10:42So, that just takes your attention away.
10:44Nothing is going to alert you that this
10:46event has occurred.
10:48So, like the conceptual problem with the
10:50polling is from the
10:52minimal case if you have a very small
10:54program, it's not that big a deal. So,
10:56here we're going to go and look
10:58at a push button
10:59here and then you're going to go turn
11:01that LED on or off if that button
11:04[snorts] has been pressed.
11:06And so, if the software is just looping
11:08through this thing continuously,
11:09[clears throat]
11:11and it's very fast. It only takes three
11:12cycles to respond to. However, it
11:15doesn't do anything else and that's the
11:16fundamental process problem. So, your
11:18processor utilization is like zero
11:20because you can't do any other tasks.
11:22And it gets worse
11:24because if you start adding other tasks
11:26like let's spend 100 cycles doing
11:27something else,
11:29now you're less responsive to the LED
11:33events. And now 100 cycles might not be
11:36a big issue, but as you keep going with
11:38more and more tasks on your
11:39microcontroller, you'll find that you
11:40become far less responsive to the
11:42external world or external events
11:45without
11:47while doing polling. So, we need another
11:49mechanism to to take care of this.
11:52So, the external method is interrupts.
11:55And so, you know, textbook definition
11:58informs the program that some event has
12:00taken and breaks flow execution. So,
12:02let's take a look at what that looks
12:03like.
12:04So,
12:06this idea of
12:07an interrupt is an interrupt service
12:09routine. So, it begins with a
12:13um
12:14uh some piece of hardware triggering off
12:17an event that will cause an interrupt
12:19service routine. And that will pull up a
12:21piece of code that does a particular
12:23task.
12:25Uh then you would enter in that service
12:27routine and then you would resume your
12:29regularly scheduled program. And as
12:31we'll see, the
12:33I don't know if it's the goal, but the
12:34function is that the program that was
12:36originally running is transparent. It's
12:38not even aware that this uh interrupt
12:40occurred.
12:42So, uh interrupts are just nothing more
12:45than uh glorified procedure calls.
12:48Um
12:48they should generally be transparent to
12:50the program running, like I just said.
12:53All right. So, some examples. So, table
12:55misses, illegal divide by zeros,
12:58um supervisor calls. These would be
13:00examples of like this system faults or
13:02instruction faults.
13:04Um when we think about So, we use names
13:07like system exceptions. Uh typically
13:09think about interrupts. Uh
13:11>> [clears throat]
13:11>> this class is usually something from the
13:13outside world causing an interrupt or
13:15like a peripheral causing an interrupt.
13:17We'll talk about timers. For timers will
13:19go off and alert the core to some sort
13:22of event. But, they do have a a number
13:23of different um
13:25names that you'll see throughout the
13:27literature.
13:29Um [snorts] so, yeah, some examples.
13:31Power failures, push buttons. All of
13:33these things can cause uh an interrupt
13:36to [clears throat] occur. One thing
13:37that's maybe not obvious is when you
13:39power on reset effectively. So, when you
13:42first boot up your thing, it goes into a
13:45um
13:46an interrupt uh that will uh load your
13:49device uh state and then return
13:52uh you and put you into main.
13:55Okay.
13:58Oh, and again, the word external here,
14:00we're going to use the word external
14:01interrupts. External is reference to the
14:04core, not to the chip necessarily. So,
14:07an external interrupt could be uh a
14:09peripheral.
14:12All right. So, let's go fast. We'll fill
14:13in the details later. So,
14:15uh how does interrupt work? A hardware
14:17or sometimes firmware, I mean there's a
14:19special construction you could use, but
14:21generally hardware generates an
14:22interrupt signal. It determines which
14:26interrupt fired. So, just because code
14:28got stopped doesn't mean you know what
14:30caused that code uh to get stopped and
14:33what you should your response should be.
14:35So, you have to determine what code
14:37should be executed in response to that
14:39interrupt firing.
14:40Uh
14:40>> [clears throat]
14:41>> so, the main program is halted. You
14:43change your processor mode. You go into
14:45this thing called interrupt service
14:46routine.
14:47Uh
14:48you do your task and then return the
14:49process to its original state so that
14:51you can continue your program. So, a lot
14:53of what we're going to be doing is
14:55trying to hold the state of the
14:56processor so you don't and you store it
14:58somewhere so you're not going to get
14:59lost. Basically, the same as when you do
15:02a branch
15:04uh or when you do a subroutine call, you
15:06have to keep track of your link
15:07register.
15:08All right. So, the question for you
15:11is how do we get interrupt from
15:13peripherals to the core? So, why don't
15:14you take, you know, 60 seconds,
15:16brainstorm with your neighbor. How do
15:18you actually [clears throat] get these
15:19signals
15:20uh from a
15:22peripheral like a timer to the core?
15:39>> [laughter]
16:18>> All All what do we think? How do we
16:19actually get the signals?
16:20To the core.
16:22Okay.
16:31You have any ideas? Anybody?
16:33What's the method?
16:34Yeah.
16:35>> Through the bus.
16:36>> You could do it through the bus.
16:38Now, remember there's a there's a
16:39problem with that.
16:41That the peripherals
16:43cannot cause any bus transactions. Only
16:47the requestor, or the bridge in this
16:49case, can denote that this thing should
16:52talk. So, there's no way for the
16:53peripheral to say, "Hey, I need to have
16:55an important message. I need to do
16:56something."
16:59What's another way we can do it?
17:03You have to you have to invent
17:04something. This is a trick question.
17:06Yeah.
17:09You have I am hard of hearing.
17:12>> [clears throat]
17:15>> I'll just write that just That's
17:17perfect. Maybe you looked ahead on the
17:19slides. That's fantastic. There you go.
17:21That's exactly what you did.
17:23Oh, this is the old uh
17:25I know this is the old block diagram on
17:28your particular device on the GPIOs in
17:30the advanced peripheral block, but
17:32regardless, you're really going to add
17:33this extra wire. In fact, for every
17:36interrupt, there is going to be an extra
17:39wire that goes from wherever it's
17:40located, so usually GPIOs or uh UARTs or
17:44wherever it is, there are going to be
17:45these extra lines that go back to the
17:48core. And it's just a single bit. It's
17:50not like a bus. It's just saying, "Hey,
17:52this interrupt occurred, and now it's
17:55time to do some task."
17:58So, if you go look at some of the
18:00you know, ARM literature, here's what
18:02essentially what it looks like. It's a
18:03brief block diagram of everything. So,
18:05you have your processor core, then you
18:07have your NVE. So, the uh this is nested
18:10vector interrupt uh controller. And this
18:13is the the kind of second You can call
18:16it processor, but the combinational
18:17logic here
18:18>> [clears throat]
18:18>> is going to interpret the IRQs that are
18:20interrupt uh requests from the
18:23peripherals and then change the
18:25execution mode of the core. So, here you
18:28have a peripheral just like we saw
18:30there's a wire coming in. This is
18:31different than the bus system. It pulls
18:33high and then the NVIC's job is to
18:35figure out, "Hey, what am I supposed to
18:38do with that particular line going
18:40high?" Cuz that is just one bit. And
18:42then it will change the execution of the
18:45core.
18:46Yeah.
18:55>> [clears throat and snorts]
18:59[sighs]
19:00>> I Essentially, yes. Now, you have to
19:03read through the data sheet. It's not a
19:05guarantee that every GPIO pin will be
19:08interruptible in the sense that it has
19:10that capability. Although, I think for
19:12the processor you're using that is true.
19:15But, you would look through and say,
19:16"Okay, does this have that
19:17functionality?" And if the data sheet
19:19says it does, then probably means
19:20there's a wire that goes back.
19:28What do you mean by outside peripheral?
19:35Yeah.
19:37Ah, okay. So, you have to have
19:39specialized logic. So, uh when you say
19:41plug in, you probably mean like on a
19:43PCB, right? Okay. So, that PCB you're
19:46going to have to route the signal into
19:48your device. Like it has to be wired in.
19:50And let's just say it's digital, let's
19:51make it easy, and it's a GPIO pin. And
19:53let's just make it even easier say that
19:55GPIO that temperature sensor goes high
19:57when it's over a threshold. And you have
19:59to configure your GPIO pin to say,
20:01"Okay, on this event, then trigger this
20:04IRQ." And how do you do that? Oh, well,
20:07just like we do everything. You go read
20:08through the data sheet and you're like,
20:09"Okay, this register defines that I'm
20:12going to turn on an interrupt."
20:14And then I'm going to be positive edge
20:16or negative edge.
20:18It's a good question.
20:19Other questions you got?
20:22Yeah.
20:23>> Um so, you said it's the interrupt
20:25>> procedure for the hardware.
20:27Um from the way you described it, it
20:29sounds to me like the processor is
20:30executing the instructions and then it
20:31clears the mask and then it works again.
20:33I don't see how it would prevent it from
20:35working anymore.
20:37>> Uh so there are there's a manual way to
20:40trigger an interrupt in firmware with a
20:42special instruction.
20:43>> [cough]
20:43>> It's [clears throat] not used often,
20:45like I don't know why you would do it,
20:46but it's good for testing. So that's why
20:48sometimes we use it in the lab. So you
20:49can like
20:50force this interrupt to occur. But
20:53generally, you software to configure the
20:55interrupt so that the hardware will
20:57automatically make that
20:59decision for you.
21:00>> [clears throat and cough]
21:01>> Does that make sense?
21:05All right.
21:10All right, so let's see.
21:12Yeah.
21:14And so let's go through a quick example
21:16here. We're going to be in
21:17main,
21:19right? You're We're going around. You're
21:20going through executing, independent of
21:22anything you're doing, some interrupt
21:25has been fired. And so the NVIC's job
21:28is to go through and look in what's
21:30called the interrupt vector table.
21:32>> [cough and clears throat]
21:33>> And so one of those lines goes high, and
21:35then it has to say, "Okay,
21:37that line is associated with a
21:39particular
21:40location in the table, and then it says,
21:43'Okay, that means I have to go run
21:46a piece of code.' Well, what code is
21:47that? Well, that code lives at this
21:49address.
21:51And so now it breaks the processor's
21:53normal execution. It basically does a
21:56fancy branch, and there's a special
21:57extra conditions there, but it does a
21:59fancy branch over to this section of
22:01code. You run that code, and then when
22:04you're done, you reset the state of the
22:06processor, and you go back, and then
22:09the processor continues. So what you
22:11have to do is make sure that you don't
22:13interrupt or corrupt the processor by
22:16executing this code. So this is a lot
22:18like how we had to be ABI compliant when
22:21we were dealing with
22:23function calls. We have to make sure
22:24that we're not clobbering all the
22:26registers in the in the main program
22:29when we're executing this interrupt
22:30routine.
22:35Uh so, here we talk about the vector
22:37table is where that information stored.
22:39So,
22:40uh remember from our diagram, we have uh
22:42the space here. Uh in the code space,
22:45the very bottom, the very smallest entry
22:48here
22:49uh well, first that is set to your
22:51Sorry, the the very zero zero defines
22:54your stack pointer. Then the vector
22:56table is on top of that. And that is by
22:58ARM's um
23:00instructions in the sense uh that that's
23:02where the vector table has to live. But
23:03it is just a location in memory. That's
23:05all it is. And it's just a uh uh
23:08um a set of addresses of where functions
23:10are going to be.
23:12Um and then often times, this usually
23:14comes up in lab, uh
23:16you actually store your code up here in
23:18flash and then on boot it is uh put into
23:21SRAM.
23:24So, here's a more detailed uh diagram of
23:27what the vector table could look like.
23:29Your processor might be slightly
23:31different, but the the concepts are all
23:32the same.
23:34So, here um
23:36the vector table is just a functional
23:37like an address book. Uh interrupt
23:39service uh routine is called when um
23:43uh
23:44Yeah, I just basically said this, but
23:45interrupt service routine call is called
23:47and then you have to look up in here.
23:49So, uh
23:50>> [clears throat]
23:50>> the stack Oops.
23:55And so, the the PC is always initialized
23:57to
23:58uh instruction or address four, not
24:00address zero. Address zero is uh stack
24:04pointer. And then this is the interrupt
24:06routine that happens on startup, which
24:07is the reset handler. So, when you brown
24:10out, or sorry, when power is
24:11disconnected, uh when it comes back on,
24:14it has to know what to do. It just
24:15doesn't just go and start executing
24:19uh the first instruction in memory or
24:20main. It does a special task, which is
24:23the boot sequence. And the reason they
24:24just they
24:26they changed that from just like
24:27whatever code you put in it. The boot up
24:29sequence uh often times is very
24:32processor
24:33specific. Things happen to happen in a
24:35certain order. All this is obfuscated
24:38from you in your IDE cuz this is for
24:40you. Now, you certainly could go and
24:42change that boot up sequence and I had a
24:43project where you were harvesting
24:46RF energy and [clears throat] the power
24:49source had high source resistance, which
24:51means it was easy if you pulled a lot of
24:53current you would brown yourself out.
24:55You'd get in this weird state where you
24:56had almost enough power and voltage to
24:58do something, but then you sip a little
25:00of that power and then you would brown
25:02out. And so, what we had to do is
25:04actually tell it don't copy any of that
25:06information over
25:08when you go from flash into SRAM or even
25:12build any of that stuff. The immediate
25:13instruction was go to sleep for end
25:16period of time so we can
25:18save more power. So, not that that's
25:20really important for your labs, but just
25:22remember that there is this extra piece
25:24of code that's going to run before you
25:26jump into main and you could edit it if
25:28you ever had to.
25:32Okay.
25:34Uh so, say we're going to look up some
25:35IRQs. So,
25:37a request comes in. Uh it says STM32,
25:40but it's exactly the same for your
25:43devices as well.
25:45Um
25:46So, what happens is an interrupt routine
25:49service call comes in and it has some
25:51index to it. So, all those lines we saw
25:54go from zero to something.
25:56Right? And
25:58the bottom set of
26:01interrupts or system
26:04exceptions are all defined by
26:07ARM. So, ARM says these ones have to
26:10happen and they're far more important
26:12than any of the other ones, any of the
26:13vendor specific ones. You can imagine
26:15you don't want a vendor specific
26:17interrupt like a watchdog timer or
26:19something being more important than the
26:21reset handler. That has to happen for
26:23your
26:24chip to function. So, ARM says that
26:26these 16 have to exist even though
26:29many of them are reserved, they're just
26:31saying these must exist. And so these
26:34are system exceptions and what else we
26:35have here? I can't really see, but
26:39you know, hard faults, memory management
26:41faults, bus faults, all of those are
26:43about the inner workings of the
26:46core, not necessarily about the
26:48peripherals.
26:50>> [snorts]
26:53>> Uh
26:54and so the inner So these numbers here
26:57have to be remapped. It's more I'm
26:59pointing this out is because ARM says
27:01that these are negative 1 through -14.
27:04Um
27:06and that's just to denote that those are
27:07system exceptions rather than the normal
27:09exceptions. So when you're looking
27:09through your documentation, you might be
27:11like, "How am I supposed to do a
27:13calculation on negative numbers? You
27:15know, these should just be whole ints."
27:17Well, that's just because there's an
27:18offset applied and you have to go and
27:20add it. Um 16 to your IRQ number to know
27:24where it belongs.
27:28All right, so now, you know, so again,
27:31what's happening here is that your NVIC
27:33is getting the number on some index. It
27:35says, "Okay, the the lower or the maybe
27:37the 12th
27:38indexed wire goes off. I need to add 16
27:41to that or subtract 16 and then that
27:43tells me where in this
27:46table I need to go and find which
27:49interrupt just got fired." And I call
27:51that
27:52put the PC to that a memory location and
27:54go forward.
27:57So the program status register
28:00holds a lot of information in this. We
28:02previously just talked about the
28:04basically the ALU flags that come out
28:06the end.
28:07There's other things in here as well.
28:09TI's This basically if then take
28:12bits and some other process generation
28:15flags. But then here the bottom eight
28:18are the exception number and this tells
28:20processor what is the exception that is
28:21running at this moment.
28:25Uh yep.
28:28All right.
28:30So if you got a external IRQ, so this
28:32would be like an external interrupt is
28:34going off a GPIO pin. You'd go, you'd
28:38figure out do the offset here to figure
28:39out what memory address you need to go
28:42to. So, here you're getting the seventh
28:44law. Let's see this sorry, this is the
28:4664th. And then you come up here and you
28:48would look and say, "Okay, this this
28:49memory address needs to go and then I
28:51need to go to this location." So, all
28:54the NVIC is really a fancy look up table
28:56mechanism. [clears throat]
28:57We'll see later that you can set up
28:59priorities on the interrupts.
29:01There's another example.
29:04Okay.
29:06That's the the general idea here that is
29:08the the NVIC is that it's really
29:11combinatorial logic. It's not running
29:13arbitrary code, but you'll see that it
29:14has to make decisions about which
29:16interrupts get fired when.
29:19Uh so, let's go through um another
29:21example here.
29:25All right. So, here
29:26a GPIO pin is been configured to go
29:30high, so pin
29:32you know, A3. It gets raised. That means
29:35that the GPIO module itself is going to
29:37raise a line and that is the ninth line,
29:40let's say. The NVIC needs to go through
29:43and decide, "Okay, calculate the offset,
29:45go through here and look in the NVIC
29:47table for the correct memory
29:51location." Then it gets that address and
29:53puts that into the core.
29:55Now the core is going to be executing
29:57this new piece of code
29:59um
30:00uh and uh
30:03we have to make sure that the rest of
30:04the processor isn't corrupted.
30:07All right. So, question.
30:12Okay. So, what are the what are the
30:14things if we know the IRS must be
30:16ABI compliant,
30:18what state information do you think that
30:21we have to store or save in the core?
30:24Let me take 30 sec or a minute, talk
30:27to yourselves and try and identify all
30:28the pieces of information that would
30:30have to be saved in order to do this
30:33function.
30:43>> [clears throat]
30:46[groaning]
32:01>> All right, so these interrupt services
32:03need to be ABI compliant.
32:05So, what what signals would we have to
32:07save?
32:17That's a good idea. I don't So, we could
32:19just store that
32:22from just a data point of view, we could
32:24just store just the first four if our
32:27function was aware that that was
32:30supposed to do. So, we could still keep
32:31that little
32:33carrier for some ABI compliance, but
32:35there are other registers that we
32:37normally wouldn't consider for ABI
32:38compliance. And you were talking about
32:39some of them. What were the other ones?
32:42Yep.
32:45PC link register, right? Because what's
32:47going to happen is you're going to do
32:48some completely other piece of code.
32:51And if you go and come back, there is no
32:56there's not the built-in kind of
32:59main does not know where that was and
33:01doesn't All right, you don't want to
33:02interrupt your main function. So we need
33:04PC
33:05link register. What else do we need?
33:09Yeah.
33:23>> [snorts]
33:27>> Well,
33:30Ah.
33:33That's a great question. Okay, so hold
33:35on. You get two unboxed things. It's not
33:37a requirement that we save every
33:39register if we know our
33:41function isn't going to clobber that. So
33:43we can tell the function you only you
33:45can have the first four scratch space.
33:47Let's just do that.
33:48But the function will go and manipulate
33:51things like your
33:53program counter, right? And so if you
33:56don't save your program counter when you
33:57go back to your main, you get lost. So
33:59we know we have to save that.
34:01Um and we'll talk about the details of
34:03who does what in a second.
34:05Uh we talked about the program counter
34:07and link register. What else do we need
34:08to save?
34:09Yeah.
34:11Yeah, we need a new stack pointer as
34:12well.
34:13Anything else we can think of?
34:16Running out of registers.
34:19Yeah, that's great. So the program
34:21status register cuz remember if you just
34:23did some instruction
34:25and you were counting on So you did some
34:26add as let's say and that updated it
34:29the status bit and then the next thing
34:31was like a comparison. Well, if your
34:34interrupt service routine goes and
34:35messes that up, then you're lost, right?
34:37So you need to save that piece of
34:39information as well. Yes?
34:48It replaces the polling issue. So, the
34:50problem with polling is that you make a
34:53trade-off. You poll, either can be very
34:55responsive,
34:57but you can't get any work done cuz all
34:59you're doing is spending all your time
35:01looking to see if someone pushed the
35:02button. But, if you have most, you know,
35:04processors or program going to have a
35:07couple of hundred, maybe a thousand
35:08lines of code or more, right? Well, then
35:10you have to just go through all that
35:12code before you can go look at that
35:13thing. So, you become unresponsive.
35:15So, an interrupt allows you to do this
35:17asynchronous thing. You just run your
35:19code, you calculate pi, you do whatever
35:20you're doing, and then when somebody
35:22presses the button, it's interrupts you.
35:26It's a good question.
35:28Yeah.
35:32Sorry, what?
35:35Yes.
35:40We just We just dump it. We assume we're
35:42just going to start losing our pipeline.
35:44Uh that's just built into the penalty
35:47that you'll see as uh going in and out
35:49of service routines.
35:51It's a good pipeline hit.
35:52>> [clears throat]
35:54>> All right, another question. Craig?
36:01>> [snorts]
36:09>> Uh yes, and the hardware is going to
36:11take care of that for you. You don't
36:13have to keep track of that.
36:18I think I have microphones. I'm going to
36:19have to give you guys microphones or
36:20something
36:21to uh
36:22get get hard of hearing.
36:24All right, what other questions we have?
36:27Guys are thinking ahead. It's great.
36:29>> [clears throat]
36:30>> All right, so let's go through a little
36:31bit more about how the stacking
36:33unstacking process happens. So, this is
36:35done in hardware.
36:37So, here are your your at your user
36:39program, you've written this program,
36:41and then some event occurs. So,
36:43uh this is time and then an interrupt
36:45signal happens, okay? And then what we
36:48do is we call it stacking. This is a
36:50hardware driven event or hardware
36:52initiated event where
36:56you need to go through and you take
36:58your active point and stack pointer and
37:00you go and you push all this information
37:02onto the stack.
37:04So, you're going to put your program
37:05status register, your PC, your link
37:07register. Wait.
37:09Oh, wait. We don't have to do stack
37:10pointer because stack pointer will as we
37:12leave will get returned back to its
37:13previous location. So, I was wrong about
37:15stack pointer.
37:16Um
37:17R12 R12 is because it's the inner
37:20procedural
37:21um
37:23uh register scratch space, so it's
37:24another scratch space that is available.
37:27So, we have to save that and then you
37:28have R0 through R
37:30uh three.
37:32So, then you go enter your handler.
37:36You at some point you're going to exit,
37:38right? This normal exit of your
37:39interrupt.
37:40>> [snorts]
37:40>> And then hardware is going to unstack
37:42this.
37:43Um or at least an automated process. You
37:45don't have to write the code. The and
37:47the
37:48uh action of branching
37:50uh will un
37:52uh stack everything.
37:54And then you will return the uh program
37:57to its original state because all those
37:59things will go back where they were. And
38:01the part that I forgot is that the stack
38:03pointer will also
38:04uh go back to its original location
38:06pointing at the original location. So,
38:08that is uh preserved as well.
38:13And so, this part uh is done
38:15automatically. You don't actually have
38:16to push or pop anything. That's done for
38:19you.
38:20And as you'll find out, this is actually
38:22done in an interrupt service routine
38:24itself. It's kind of this extra thing
38:27that happens before and after uh your
38:30code execution.
38:33Yeah.
38:33>> So, what's PSP
38:36>> PSP. Oh, program stack.
38:39Um
38:39>> No, no. PC and PS.
38:41>> Oh,
38:42this is this is state of your uh
38:44processor. It's the
38:46I'm I'm
38:46blanking on the the phrase. It is
38:49Help me out somebody. Yeah, the process
38:50stack pointer. No. No.
38:55I don't know. What's it called? Help me
38:57out. Help the old guy out.
39:00>> [clears throat]
39:00>> No, it's not program counter.
39:02>> [snorts]
39:02>> PSR
39:03>> Yeah.
39:04Program status register, thank you. So,
39:06it's the basically the state of your ALU
39:08flags and all those other things, right?
39:10So, like that has to exist. It's
39:12actually uh 32-bits and it holds some
39:15other uh states that we don't talk
39:17about. Uh your IT flags, your DE flags,
39:20and then uh which interrupt you're in.
39:22And we'll talk about That's important
39:23cuz later on we're going to be doing
39:24nested interrupts when an interrupt
39:26interrupts an interrupt.
39:27>> So, is that the
39:29PSR or the
39:32>> Oh, I see.
39:34>> There's different versions of how to
39:36write it. I will uh make sure the slides
39:38are
39:39>> So, it's the PSR. [snorts]
39:45>> Sorry, what did you say
39:46R0 was?
39:48>> Ah, same reason that we uh had to
39:51we the
39:52calling function needs some scratch
39:54space.
39:55Right? And so, we're going to the
39:58hardware's going to
39:59preserve that those uh instruction those
40:02registers because if main could not do
40:04it. Main normally if you call a function
40:06it's main's job to pass variables there,
40:09and if you they want to keep it they're
40:11going to save that put it on stack. But
40:13main never called this. Something else
40:14called it. This interrupt called it. So,
40:16the interrupt itself is going to
40:18uh or the the action of that is going to
40:20save those registers so they don't get
40:22corrupted by the interrupt service
40:23routine.
40:26No.
40:26But if the just like with a normal ABI
40:29compliant function, uh if the the
40:32called function goes and
40:34manipulates those registers, right? It's
40:36responsible and it's responsibility is
40:38to put them back. So, it's they're
40:40caller safe.
40:43Does that make sense?
40:46What?
40:47>> Wait, what is the ISR doing?
40:49>> The ISR
40:51So, there's two things. There's The ISR
40:53is a function, but how you get to that
40:55function is done through hardware.
40:56>> Oh, okay. Okay.
40:57>> Right? So, the hardware is doing this
40:59task for you.
41:01But, because the main engine know they
41:04was about to get called, the main can't
41:05go and save R0 through R3 for itself.
41:09So, something else has to do that task.
41:17What other questions you have? Clearly,
41:18I Yeah.
41:19>> I'm looking at the documentation for the
41:22PSP.
41:22>> Yeah.
41:23>> It says like it's used for like when the
41:26architecture is running in privileged
41:27mode.
41:29So, it's like a stack pointer for
41:30>> [cough and clears throat]
41:30>> processes.
41:31>> That's true.
41:32>> Running in privileged mode.
41:33>> Uh
41:35I'll have to go look at the look at
41:37exactly what's on what's being slide,
41:39but
41:40uh you're right.
41:41The PSP is uh for different process
41:43mode. We don't really cover that in this
41:45class though.
41:48I mean, other than I mean, just to point
41:50out to students that these other There's
41:53shadow registers that you'll see in your
41:54documentation for your program uh your
41:57PSP, but uh that is not
42:00I think maybe the other slide has an
42:02error then. So, I'll go look that up and
42:03report back next week.
42:06Okay.
42:09Uh what else?
42:12Yep.
42:13Uh there's different uh your program
42:14stack pointer and your main stack
42:15register have slightly different uh
42:18connotations. Uh let me see if I can
42:20find that slide. Well, that'll come up
42:21in a second, but basically, they're
42:23holding your state of your mode. Uh you
42:25don't really doesn't really matter if
42:27you're in for this class if you're in
42:28handler mode or thread mode.
42:30Um
42:31we just I'm just putting this here for
42:33for your reference.
42:34Okay, great. And we're going to do that.
42:36Um
42:37okay.
42:39So, depending on what mode you are in,
42:42your return [snorts]
42:43address is one of these uh different if
42:46you're
42:47floating point versus non-floating point
42:49versus handler mode versus thread mode,
42:51you have a different link register
42:53address. This is when you're leaving
42:55your ISR, where should you go?
42:58So, in this class, we're going to go
43:00Almost all the examples are going to go
43:02to We're going to be in thread mode.
43:03We're going to go back to this uh
43:05address. And so, you notice that that's
43:07really high up in the memory. So,
43:09basically, that is the key to tell the
43:12hardware, "Okay, now you're supposed to
43:14unstack." The hardware is not keeping
43:16track inherently if you are in an ISR or
43:20not. Um but, the link register says,
43:24"Okay, if you go back to that location,
43:27if you put that into your PC, then you
43:29are supposed to do the unstacking event,
43:32right? Then you go and return the state
43:34of the processor, and go back." That's
43:36the That's the trick of where you're
43:38supposed to essentially branch back
43:40from.
43:41So, let's go through an example here.
43:44So, say we're stacking,
43:46or sorry, we're uh we're in a normal
43:48function.
43:50Then, all of a sudden,
43:51uh say your SysTick timer goes off. And
43:54now, the program counter says that you
43:56need to jump to a different um location.
44:02So, here, we're going to assume that
44:03we're in this mode.
44:05And then, we're going to go and stack.
44:07So, here, we're going to go and take So,
44:10there I've corrected it.
44:12Uh here it is the program status
44:14register. That was a mistake on the
44:15other slide. Uh so, here, we have to
44:17save the program status register, uh the
44:20PC, the link register, R12, and R0 R3.
44:24Those get pushed up on the stack, so
44:26that uh now the function that runs can
44:29use those bottom uh four registers
44:31however it wants. If it wanted to use
44:33R4, then it would have to push that to
44:35the stack. And the function would
44:37Um and then, we start doing your
44:39execution of your interrupt.
44:43Uh when we're
44:44uh done, uh we're going to You notice
44:46here that the link register is that
44:48specific value. And that's to know to
44:50what should happen when it returns
44:53uh back. So, here, we're going to go
44:55through, we're going to do some tasks.
44:57Oh, here we're going to use our uh we're
44:59going to use our full uh oh Oh, I'm
45:02showing the problem. Yeah, so here's R5
45:04gets four gets updated. We're going to
45:06branch back, and we're going to branch
45:08back to that special address which
45:09causes unstacking. And here is the
45:11showing the error function. This is not
45:14what's supposed to happen.
45:15Didn't show on my shows on my screen.
45:19How can you not see
45:20How is it possible you see different
45:21things than I do?
45:30Oh, you missed all those good things I
45:32was telling you then.
45:33Uh
45:41Okay.
45:49Okay.
45:51So, this is the screen's not updating.
45:54>> [clears throat]
46:40All right, we're back to a wired
46:42scenario. All right, no more airplay.
46:45Where were we? Okay. So, here we've
46:47entered our instruction, our ISR
46:50hardware did the stacking. Don't know
46:52which guy it's last in the C. The
46:55program stack
46:57uh program encounter, or sorry, the
46:58stack pointer gets updated that
47:00location.
47:01Uh, the link register gets updated with
47:03that special,
47:05uh, return address, which signals that
47:07unstacking should occur. And then your
47:09program, your PC points to the address
47:13of this new,
47:14uh, of the interrupt service routine.
47:16And it's a routine because this is what,
47:19uh, is going to run. And so, an
47:20interrupt request causes the NVIC to
47:24look up the location of the interrupt
47:26service routine, and then the NVIC will
47:28cause all of this to happen. It will
47:30initiate all this. It will enter your
47:32interrupt service routine, which we are
47:34just about to do, and then we'll do this
47:35task. And we'll see that R4 is going to,
47:38uh, identify the error that's going to
47:40occur.
47:43Any questions on the setup so far?
47:48Yeah.
47:50>> Uh,
47:51what are the two modes?
47:52I don't know.
47:53>> Sorry.
47:53>> What are the two modes again?
47:56>> It's less important.
47:57It doesn't really matter for how we're
47:59using this class. It's more like, uh,
48:01smart students at this university who,
48:04uh, know more than I do. I was looking
48:06at the documentation more recently. Um,
48:08it'll trip you up. So, you can look
48:09through the slides and be like, "Okay,
48:10why is there this freaking normal and
48:12this normal mode? And what is the
48:13difference?" And it's not really that
48:15important.
48:15>> [snorts]
48:16>> Um, it really is The reason it comes up
48:18is because you have to know which mode
48:19you are in to know what your, uh, link
48:22register return path is.
48:24It's a good question. Wait, I saw some
48:26other hands.
48:31Yeah. You have to be very loud though.
48:34>> How come you didn't see the
48:36R0 and R1?
48:38>> Why How come we didn't see that?
48:40Uh, arbitrary reasons. It's completely
48:42arbitrary reasons. But, it's just like
48:45with the ABI from times, uh, thing. So,
48:47the
48:48ABI decided
48:50that R0 through R3 are just ones that
48:52are going to be saved for, um,
48:54ABI call and return for this. So, this
48:56is just trying to mirror what the ABI
48:58normally does.
49:00Does that make sense?
49:04So, you could save everything,
49:06but then that would be wasteful. You
49:08have to actually function You have to do
49:09extra slots and storage for R
49:13uh the other the other things, right? R4
49:15through R11. So, we're just not going to
49:17This is from a hardware standpoint here.
49:18I'm just going to show that the error
49:20that occurs We're just showing you some
49:21of this stuff. They're not loading up
49:23the hardware.
49:25>> Is it guaranteed that the rest of the
49:27registers uh R4 through R11 say are
49:31going to be preserved in the interrupt
49:33call or is it just like
49:34>> The programmer of that interrupt call is
49:37responsible for saving those registers.
49:39Just as a uh pro as the function
49:42programmer or sorry, person who writes
49:44the function would be responsible for
49:45saving those. So, the same rules apply
49:48when you're writing interrupts as you
49:49would in main functions.
50:00Ah, that's a good question.
50:03So, normally what happens, right? You
50:04put that link register and then it tells
50:06you how to get back.
50:07But, we don't just want to get back to
50:10the where we were in the program.
50:12That's not enough because
50:15that would mean that say that program
50:17status register too could be corrupted.
50:19It could be changed. So, we need some
50:21way to say, "Hey,
50:23take the program status register that's
50:25on the stack and put it back."
50:27I need some way to say, "Hey, R0 through
50:29R3 need to go back and R12 needs to go
50:32back." And so, rather than burdening you
50:35and making you as the person who has to
50:36write the interrupt service routine do
50:38that every single time, right? you don't
50:40want to have to write that every time.
50:43What happens is this piece of that If
50:45you branch back to that particular
50:48location, it causes the hardware to
50:50unstack. So, now the [clears throat]
50:52hardware's going to do all that stuff
50:54for you. And really, it's not
50:56hardware or is it? It's just another
50:58little
50:59uh piece of code that says, "Do this
51:01task." But, it's automatically done for
51:03you. That much.
51:22Which slide, Emma?
51:29Sorry, I really can't hear anything.
51:43This slide?
51:44No.
51:4639. Thank you. Thank you.
51:58Yeah.
52:06But, she's showing that this is the
52:07normal factor of the heater.
52:09The red is the stack pointer area, so
52:10it's loaded down.
52:11And, this is showing you all the steps.
52:13There's nothing new here. It's nothing.
52:19Correct.
52:20Because it's it's just an automated
52:21process. When I say hardware is doing
52:23it, it means that it's a set it's a set
52:26function. It always stacks the same
52:28things. It always unstacks the same
52:31things. It always does it in the same
52:32order. That just makes it so that you as
52:35a programmer
52:37of the interrupt service routine don't
52:38have to unstack anything, and there's
52:41nothing that has to happen when you
52:42start. You don't have to program
52:43anything when you
52:45get an interrupt. It's done for you.
53:01All right. So, now we're going to go
53:03through, and in this example, we are you
53:06know the the you have a misbehaving
53:09interrupt service routine. So, sure it
53:12can use R3, no problem. R3 has already
53:15been preserved on the stack. So, it is
53:19scratch space
53:20for the interrupt service routine. But,
53:23R4 is not and that should have been. If
53:25you needed to use that space, it should
53:26have been put up on the stack. So, do
53:28nothing in here. Typically, you want to
53:30keep your IRQs short. You don't want to
53:32have a thousand lines in your IRQ just
53:35because you are blocking the progress of
53:38main. So, typically a strategy would be
53:42if there's a small task [clears throat]
53:43to do like take data from one location
53:45and put it in somewhere else, do that.
53:47Or maybe you're just going to set a flag
53:49that says, "Hey,
53:51this event occurred. Next time I go and
53:53through main, go and process that flag."
53:56So, normally you don't want to do a lot
53:57here, but certainly there's enough time
53:59to go and
54:00push something to the stack if you
54:02needed the extra space card board. But,
54:04this example did not do that.
54:09Okay?
54:10And so now we're going to branch. Where
54:12are we going to branch to? We're going
54:13to branch to special location.
54:15That special location is going to cause
54:17the unstacking event to occur. So, now
54:19[snorts] we're going to unstack all
54:21those things. Essentially, we're going
54:23to place them. Oops.
54:26Come back.
54:28We're going to take all those things and
54:29put them back onto your registers here
54:32including the program status register
54:34going to be updated to this value.
54:36So, here we go. All those things get
54:38updated and because
54:41it's just a normal pop or yeah, pop
54:44operation, your stack pointer goes back
54:46to where it was. So, stack pointer is
54:48not apparently needed to be saved on the
54:50stack. It just will go back to where it
54:52was. And then the problem here is
54:54because this is a misbehaving function,
54:56now R4 has been updated and it should
54:58not have been updated.
55:03What questions do we have?
55:06Yeah.
55:06>> Okay, so the stacking process is
55:09always saved
55:10>> people are better than
55:11hacking auto violence and they are
55:13better than hacking.
55:14>> [snorts]
55:14>> Right. And you don't
55:15If you don't
55:16>> [clears throat]
55:16>> I just like um
55:18If you're running a a normal function,
55:21you are uh not allowed to manipulate our
55:24core for a while.
55:26And so,
55:27uh without
55:28uh returning back how it's supposed to
55:29be, just as the same thing in our
55:32service return to the client.
55:33>> I see. So, this type of challenge is to
55:35save my core.
55:37>> Yep.
55:37>> All right. Yes.
55:48>> Okay. So,
55:52I actually went through that way faster
55:54than normal. Okay. So, uh so, recap. So,
55:57uh we talked a lot about polling versus
55:59uh interrupts. So, remember polling is
56:02has the time trade-off penalty. Where
56:06how much work you can do do in main, uh
56:09the more work you do there, the less uh
56:11reactive you will come to external
56:13events.
56:14Uh interrupt [clears throat] is just a
56:15method for allowing those signals to get
56:17into the core.
56:19Uh your peripherals
56:20will be configured to uh initiate
56:24interrupt uh service requests. And that
56:27is not a lot of data. It's not like it
56:29tells you tells the Nvic what happened.
56:32It's just a line, literally a wire that
56:34goes high. It gets interpreted by the
56:36Nvic, and the Nvic has to make a
56:37decision about what to do. And so, uh
56:41I think on your device you have about 96
56:44different interrupts that could occur.
56:46And so, that means there's 96 wires.
56:49Your Nvic could handle up to 256. It's
56:51just a lot of overhead. And so, there's
56:52a trade-off your the the vendor has to
56:55make saying the arm could do 256.
56:58However, that's a lot of overhead, so
57:00we'll just do the the more than minimum
57:02necessary for the job. And so, there's
57:05about 96 different interrupts
57:07uh that are available on your device.
57:10Um so when that interrupt gets called
57:13or that line gets raised, it's the
57:15NVIC's job to go look up, okay, so the
57:18nth
57:19uh interrupt line went high, it needs to
57:21go do the subtraction off of 16 and
57:23figure out where in the lookup table the
57:27address is for the service routine.
57:30And the and the
57:32uh
57:33uh lookup table is just the bottom bits
57:36of memory is starting at location two in
57:38memory and then moving up. So it's not
57:41like a special table, it's just memory.
57:44Uh yeah, there we go. Um so then then
57:47when that occurs, you have stacking so
57:48that the um
57:51uh
57:51the points of the table points to where
57:54the program counter needs to go for the
57:57inner service routine and that's
57:59somewhere in memory.
58:01And then hardware takes over. Hardware
58:03does the stacking.
58:05Um it uh will save the state of the
58:07register. It will then go and allow uh
58:10the inner service request to go. Uh
58:13you'll process that and then you'll
58:14branch back that special address. That
58:16special linkback address simply states,
58:19do unstacking for me. So if you did, you
58:22could do bad things. You could do a bad
58:23thing like just um manually branch back
58:27to that address from like a normal
58:29function call or just in main and your
58:32processor will go wild, right? You'll
58:33take whatever is in the stack and you'll
58:35dump it into your processor and see what
58:36happens. Shouldn't do that, but it's no
58:39more magical than just um
58:42uh branching to a particular location.
58:46All right.
58:47Uh and then when you on yeah, when you
58:49unstack the processor just goes back to
58:50its normal operation. And so next week
58:53we'll talk about So tomorrow or
58:55Wednesday's class will be exam review
58:57and then next week we'll talk about the
58:59details of the
59:00>> [clears throat]
59:00>> uh nested vector interrupt controller.
59:02And really what we're going to be
59:03talking about is what happens we have
59:06multiple interrupts occurring cuz and in
59:09real embedded systems you'll have, you
59:11know, 20 interrupts going off or
59:13configured. And sometimes interrupts
59:15will interrupt interrupts. And you have
59:18to figure out which one is the important
59:19interrupt, which one is will keep the
59:20plane from crashing, and which one is
59:22just trying to figure out what the
59:23volume button has been pressed up and
59:24down.
59:26All right.
59:28Yeah. And so that will end class early
59:31and we'll have start office hours early
59:33as well.

About this transcript

This page contains the full transcript of EECS 373 - Fall 2026 - Lecture 6: “Interrupts” by Interactive Sensing and Computing Lab , generated from the public captions YouTube serves with the video. The transcript has 9,273 words across 1,556 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.