YT YouTube2Text

YouTube2Text → Transcripts → EECS 373 - Fall 2026 - Lecture 8 "NVIC"

EECS 373 - Fall 2026 - Lecture 8 "NVIC" — Transcript

by Interactive Sensing and Computing Lab · 11,915 words · 1,785 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Let's see. Today we're going to be
0:02finishing up uh interrupts in general.
0:05Hopefully, we'll get through it all
0:06today. So, homework four was released.
0:09It's due I think the fifth is correct.
0:12Monday next week, uh office hours today.
0:15And then we're aiming to release exams
0:18grades by Wednesday. Hopefully that will
0:20work out.
0:23And then just to recap where we are in
0:25the course. So, pretty soon we're going
0:27to be starting our uh project. So, we
0:29have a team formation event next week.
0:32We'll serve pizza. We'll uh there'll be
0:35some work to do beforehand where you'll
0:36submit ideation slides. We'll talk about
0:38them later. And then in that event,
0:41people will pitch ideas, things they
0:42want to have uh work on. They'll try and
0:44get other team members to join them. Um
0:48and then hopefully the goal is that
0:50you'll have a team in a general pro
0:52project direction by the time you leave
0:54that event.
0:56Any questions?
1:00Okay.
1:03>> And yes, uh, lab is normal this week.
1:06Okay. So, component of the day. It's I
1:09feel like the things I tell you for
1:10components of the day are either like
1:12are super basic, but they're always
1:14nuanced and horrible, right? So, there's
1:16lots of different types of switches and
1:18they all have been designed to do
1:20slightly different things. And if you
1:21don't know that, you're going to grab a
1:22switch and I I've done it myself and
1:25I've seen other students do it. You grab
1:26a switch and you say, "It doesn't work
1:27how I expect. Why is it?" Well, there's
1:29lots of different variations. And the
1:31biggest one that usually gets people is
1:32not realizing that there's a difference
1:34between momentary switches and maintain
1:36switches. Uh, and sometimes how you
1:38interact with them, you can't actually
1:39tell which one they are. And so a
1:41momentary switches only while it's being
1:43depressed is a connection made or not
1:45made versus a uh maintain switch. So
1:49maintain switch is better seen as like a
1:50slider or something. that one is has a
1:52definite state but you can certainly
1:53have switches that you would think would
1:55be maintained but are actually momentary
1:57or vice versa.
2:00The other painful one for uh uh
2:03different types of uh switches is the
2:06poles and the throws and the poles are
2:08the thing that you switch and you that
2:10pole lands on a throw. So I guess the
2:13best version to look at this would be uh
2:15and there's different variants. So like
2:16single pole means the switching part
2:18there's one of them and then double
2:21throw means that there's two locations
2:23where it can land. So up there you see
2:25single pole double throw and that means
2:27that the switch can make connection to
2:30two points. A single pole single throw
2:33would be it's either uh there's nothing
2:35for it to connect to or it's connecting.
2:37And then you have other ones like double
2:39pull double throw and you can have
2:40triple throw triple throw all that sort
2:42of stuff. And this is just one physical
2:44action will switch two circuits. So you
2:47could have two different voltages or two
2:48different signals. So all those little
2:51nuances make a big difference especially
2:54since sometimes manufacturers will have
2:55the same switch in different variations.
2:58So they'll still have like six legs but
3:00only two of them say are used versus all
3:02six of them. So you just kind of have to
3:04watch the data sheet.
3:07The other variations are what you would
3:08consider normally open or normally
3:10closed. So that one up there with off
3:12and on tells you. But like the switch
3:14over here, is that open right now or
3:16closed? You don't know. You can't tell.
3:19And so you have to the easiest way if
3:22you get a switch in the labs, just get a
3:23multimeter out, put a multimeter on it
3:25in uh continuity mode with a beep. And
3:27then you can tell pretty quickly if it's
3:28normally open or normally closed. But
3:30don't make assumptions when you just are
3:32given some random switch.
3:34And then uh important part is uh voltage
3:36ratings. In lab, almost everything that
3:39you get is going to be fine. Um, it's
3:41only when you get up to like hundreds
3:43volts, 50 volts or so, they have to
3:45start really worrying. But current
3:46handling is a big deal. Uh, you have to
3:49make sure your switch is rated for the
3:50amount of power you're going to push
3:51through it. A little switch like this
3:53thing here or even these little dip
3:55switches can't take amps. Uh, it becomes
3:58dangerous. And then an unsung hero that
4:00doesn't matter for us right now in
4:02school, but uh, when you get into
4:03industry is the number of cycles. Each
4:05switch is going to be rated for a number
4:07of cycles that the manufacturer
4:09guarantees it can be pushed which seems
4:11trivial but is sometimes it's easy to
4:14get to 100,000 in the life cycle of a
4:16device.
4:19Any boring switch basic switch
4:21questions?
4:23All right, we'll go on to more exciting
4:25things. So today we're going to be
4:27talking about uh interrupts really the
4:29control registers flow control interrupt
4:32priorities um
4:35current and overlapping interrupts. So a
4:38little bit from last week yeah uh two
4:39weeks or like a week ago we talked about
4:41basic interrupts polling versus
4:43non-polling types of interrupts and the
4:45vector table and then stacking and
4:47unstacking. So really what we're trying
4:49to do is understand this picture. This
4:51comes from the CortexM manuals um the
4:55authoritative
4:56uh manual on Cortex M4s. And there's a
4:59bunch of different parts you have to
5:00worry about for interrupt. So there's
5:02the peripherals. Remember the
5:03peripherals are the things that the
5:06device manufacturer makes this outside
5:08of ARM. Uh and they are the things that
5:11are generally creating the interrupts.
5:13So they're gonna create a interrupt
5:15request. So we call it IRQ.
5:18And ARM supports up to 124 uh interrupts
5:23uh as well as its own 16, but uh it
5:27doesn't have to. The manufacturer
5:28doesn't have to implement all of those.
5:30And those interrupts the manufacturer
5:31generates uh are either going to be
5:33pulsed or level set. And it depends on
5:36the peripheral. It depends on all the
5:38little details in the data sheet. So you
5:40can't assume a certain behavior. And of
5:43course like everything else those uh
5:46interrupts are configured in the
5:48peripherals registers.
5:51Uh yeah right and then they make they're
5:52making these IRQ. So those are the
5:55signals that go to the env
5:59which is this module here. This is part
6:02of ARM uh the ARM cortex you know
6:05platform that ARM sells as an IP stack
6:08to the different manufacturers and it
6:10handles the interrupt requests. So it's
6:12looking at these lines trying to figure
6:13out what to do. Uh it controls which
6:16interrupt gets run and when and then it
6:19initiates the process of running the uh
6:22interrupt service routine on the core.
6:25And then the other major thing so that
6:26and then of course there's registers in
6:28there that control that and configure
6:29that. And then we've already kind of
6:31went over the the core itself. So the
6:33core is where the interrupt service
6:36routine gets run. And there's two
6:38different modes, right? if you're in
6:39thread mode which is the normal uh
6:41processor mode and then you need to
6:43switch into thread handler mode and that
6:45needs to be done carefully and switching
6:47into or sorry in uh yeah the handler
6:49mode so interrupt handler mode the ISR
6:52that is done by the envict this makes
6:54that decision and then initiates that uh
6:57that change is there any questions so
7:00far
7:06>> I'm sorry you guys speak loud uh the
7:08difference between thread mode and
7:10handler mode.
7:11>> Thread mode is just a normal a name a
7:14label for normal operation and then
7:16handler mode is when you're in an ISR or
7:19you're you're doing this other thing
7:20which is the interrupt service routine.
7:22>> Is there any difference between
7:25>> not really uh I mean to be in those
7:28modes uh you can't go from like normal
7:31uh program execution to handler mode on
7:34your own. It's not like a branch that
7:35you just do. it has to be initiated by
7:37the envic.
7:41And so we'll just quickly review from
7:43last week what's going on on the cortex
7:46processor side before we dive into the
7:49rest. So we we had this diagram here.
7:51You're in some program execution. Some
7:54interrupt occurs and then you need to
7:56figure out where that IRQ came from. So
7:59the ENVIC goes through it sees these
8:02lines here. So it's got some IRQ lines
8:04coming into it and then it goes through
8:07and figures out what interrupt uh has
8:11gone figures out which interrupt goes on
8:12and then it figures out where is the
8:15address of the ISR that should be run.
8:17So basically for for what you're
8:19understanding right now is this is just
8:21a lookup table. The NVC is just
8:22basically line goes high I'll go over to
8:25this place in memory. What is this
8:27memory? It's the interrupt vector table.
8:28It lives at the lowest or second lowest
8:31address in memory and it basically holds
8:34the location of the ISRs. And what
8:36you're going to find out later though is
8:38that the envic isn't just just a lookup
8:41table is actually going to determine
8:43which interrupt should take uh
8:45precedence over other interrupt when
8:46they're uh overlapping or uh interrupts
8:49that occur at the same time.
8:53All right. And then you go through you
8:54do your interrupt service routine.
8:56you're going to do a bunch of tasks to
8:58get there. We remember we had to do this
8:59idea of stacking and unstacking. And the
9:01whole idea here was what we have to
9:03preserve the state of the program. So
9:06some interrupt signal comes in. We've
9:08decided we're going to act on it. We're
9:10going to stack. Stacking is we're going
9:12to take the state of the processor and
9:15we're going to put it on the stack. And
9:16the important again this is going to be
9:18an AI compliant function. So, we're
9:21going to store or save on the stack R0
9:24through R3, R12, the link register, the
9:27program counter, and the program status
9:29register, not the PSP that I got wrong
9:32last time. That's going to go up on the
9:34stack. Then the interrupt handler is
9:36going to go that you're in handler mode,
9:38and it's going to go and execute that
9:40ISR using uh the uh spaces that are
9:43allocated for it. So, it's not going to
9:45use R4 through R11.
9:49And if it needed to, it'd have to push
9:50that to the stack. Then when it's done,
9:52you exit. You're going to exit to that
9:54special address.
9:56And then you're going to unstack and go
9:58back to the program. And I said that
9:59these were in hardware last time. It's
10:01probably more accurate to say that
10:02they're hardcoded. There's not a whole
10:05another set of processor hardware that's
10:07making these loads in stores. It's still
10:09in the core. It's just that it's a
10:11hard-coded function that's causing these
10:13things to happen. You cannot change it.
10:17Okay. Okay. And then so now you're just
10:19going to exit this and then that's your
10:20return path back. So this is your mental
10:22model of like how does the processor uh
10:25get uh interrupted? How does it know
10:27what interrupt service routine to run?
10:30How does it retain the state? And how do
10:32we get back? So is there any questions
10:34on this so far?
10:38>> Yeah. Real loud though. Um, I think last
10:41time we talked about
10:43last time we talked about like
10:45unstacking where you go to specific
10:47address.
10:55Um, is there something for stacking as
10:58well that like also goes to like find
11:00address?
11:01>> So the the address is the is what goes
11:04in the link register and it's not the
11:06link back to where you were in code
11:08because if you just did that you'd
11:10branch back to your code and you
11:12wouldn't unstack anything. It wouldn't
11:13cause unstacking to happen. So instead
11:16you br you uh branch back to like fff99
11:19or something and that does the hardware
11:21part. That's the hard-coded unstacking
11:23procedure. But there's no like there's
11:26no I guess the what you're thinking is
11:30is there on the on the stacking side is
11:32there a special address to go to and
11:34that is in a sense what's in the vector
11:36table.
11:38So the special address you go to is
11:40here. So this is the address you go to
11:42which is the the uh location of this the
11:46um uh interrupt service routine and that
11:50also invokes the act the act of
11:52stacking. Does that answer your
11:53question?
11:54>> Yeah, I guess I was just like wondering
11:55if it was like a little bit wasteful to
11:57have each of the interrupts do their own
11:59stack
12:02or address.
12:08>> It's not that the interrupt does its own
12:10stacking. This is hardware feature,
12:12right? The the enving
12:15to occur in the decision to to jump to
12:18this location in code. So I don't think
12:20it would be it's not I wouldn't it's not
12:21correct to say the interrupt service
12:23routines are doing the stacking. They
12:25occur after stacking has happened. Is
12:28that
12:29>> okay? Yep.
12:31>> Yeah.
12:32>> How does the
12:37depending on
12:38>> I'm sorry you got to say it real loud.
12:39depending on the IRQ get the decide what
12:42class are.
12:44>> Um there's basically a lookup table in
12:46here and each one of these uh IRQs have
12:49a number and then they're related to the
12:51numbers here. So it's it's just a direct
12:53lookup table. The only trick here is
12:55system exceptions are defined by ARM and
12:58so whatever the IRQ's coming from the
13:00peripherals are it's plus 16. So all
13:02it's doing is adding 16 for right now.
13:04>> I see. So do we set those or are those
13:08>> um
13:10you set those so you don't set a zero
13:13through 15 that's from ARM but you can
13:16go through and set what those individual
13:19things do. Now your uh exfinion assumes
13:24that certain interrupts are at certain
13:26locations but you could rewrite those
13:27interrupts to do other tasks if you
13:29wanted to. So you have freedom, but
13:31generally just uh you know, you go with
13:34what they already have because it's kind
13:35of pre-built and then you're just
13:36modifying that interrupt code.
13:40But I guess you know in this particular
13:43example here, it's um an external
13:45interrupt handler up there in red. You
13:47could go and do something like if that
13:49fires, do something in flash or uh but
13:52it'd just be weird because the only
13:54thing that's going to cause it is the
13:55external interrupt signal here.
13:59All right. What other questions we have?
14:03Okay.
14:08All right. So, this may leave some open
14:09questions like how do you set up and
14:11control these interrupts? What happens
14:13if multiple interrupts happen at once or
14:15some are more important? Um, and then uh
14:18what what happens if you're in a
14:19critical code section? So, like how do
14:21we deal with these things? And that's
14:23really where the the power of the nested
14:25interrupt controller comes in. And so uh
14:29this I don't think this well anyways the
14:31interrupts are coming from here but I
14:33think there's probably a better way to
14:34think about it. And so we'll switch to
14:36this diagram. So we have the core and we
14:37have a peripheral. And most of the
14:39examples we can think about now are
14:40we're just going to focus on interrupts
14:42that come from the GPO port. So what
14:44would that be? You want to check to see
14:46if a pin is going high. That's a very
14:48common one. Somebody's pressing a button
14:50and you need to figure out that that's
14:52occurring. You don't want to spend your
14:54time polling and so then uh that will
14:56cause an interrupt and so some
14:58manufacturers will go and actually put
15:00the control registers for the interrupt
15:02in the peripheral itself. Totally fine.
15:05In fact, Infinine's done that for some
15:06of their peripherals. But there's a
15:08small wrinkle here that Infinine for all
15:11its GPO has invoked uh an own its own
15:14peripheral called the event request
15:16unit. That is just another peripheral on
15:19the APB. And what they've done is for
15:23every not everyone but many of the input
15:25lines it's just going to monitor all
15:28those input lines that you could
15:29possibly want to have an interrupt on.
15:31So here in our nomenclature here our
15:34design we had a port of n pins with n
15:38registers and here we're going to look
15:39at like potentially we'll see the
15:42details in a second that different lines
15:45are going into this unit. So now it can
15:47make decisions on it. So that's just a a
15:49choice that um Infinion made because
15:52we're in the manufacturer side. They get
15:55the freedom to control it whatever way
15:57they like. There's no inherent
15:59difference between this and another
16:00manufacturer. The other manufacturers
16:01may just have interrupt control pins.
16:04And what I mean by that is the pin or
16:06the registers that define if an IRQ
16:08should go off uh inside the GPO
16:11peripheral. So it's just a separate
16:13peripheral.
16:15Any questions? Yeah.
16:23>> Sure.
16:24>> If I press it, did the actual peripheral
16:27like register get that value or is it
16:30just automatically going to be
16:32>> um it it gets that value. So in
16:34infinion's way of doing things which is
16:35pretty standard the uh GPL port is still
16:38going to be an input and still something
16:40you can monitor. It's just also will
16:42trigger this thing called an interrupt
16:44in the IRQ. So it's not an alternate
16:46function per se. Um those lines always
16:49run there. It's just that only when you
16:52set the registers is the this unit going
16:55to um set an IRQ.
16:59>> Yeah.
17:02>> I'm sorry.
17:03>> Did you explain the request again? I'm
17:06going to explain uh a bunch in a second
17:09but the conceptual idea is that instead
17:11of making the act of enabling and
17:14disabling IRQs is not done in the GPO
17:18peripheral is going to be done in a
17:19separate peripheral which controls that
17:21and this peripheral has wires that go to
17:23N GPIO peripheral. So if you have port
17:26one port two it's going to go to all
17:28those.
17:36Oh, and then this unit itself is going
17:38to write this IRQ. So, this is a
17:40interrupt request uh line. All right.
17:43So, now we're going to talk about what's
17:45in there. So, this is the diagram, a
17:48little overly complicated diagram, but
17:50this is the diagram of the event request
17:53unit uh from Infinion. And we're going
17:55to simplify it a little bit for the
17:56these purposes. So, instead of saying
17:58that we're going to get events from
17:59every single device, we'll just make it
18:02events specifically from the GPIO.
18:04that's fine. And then uh instead of
18:07having uh events go so normally what
18:11they think about is that there's
18:12triggers or IQs that can go to all sorts
18:14of other things other than the invas
18:18or other timing peripherals. We'll talk
18:20about that later when we get to those.
18:22So for now we're going to simplify it
18:23that these triggers go to the env. Okay.
18:25So uh go things are going you know
18:28button presses are occurring. This thing
18:30is listening. We're gonna use it to
18:32configure it and then they're going to
18:33send the signals to the envic.
18:37So we'll dive in a little bit. So
18:40Infinine
18:41uh the way they look at this is they
18:43have um this in event input selector.
18:47And so this has four channels. Um so
18:49there's four input channels. Each
18:51channel can have two inputs uh paths A
18:54and B. And uh each path has uh four
18:57possible source signals. So you can look
18:59at 32 possible signals on every ERU and
19:02there's two ERUs on your device. So
19:04basically this is a big MX just looking
19:06at different peripheral uh GPIO pins and
19:09seeing which one's going high. You can't
19:11look at all of them at once in this
19:12particular architecture but you can look
19:14at many of them. So basically you look
19:17at 16 at once
19:19and then you have this combiner unit
19:21which has some combinational logic in
19:23it. So now you can say there's two
19:25paths. Say those paths went to two
19:27different GPO pins. And you can apply
19:29some combinational logic if you wanted
19:31to. You could say nots, ands, and ors.
19:34Or you could just look at just one pin.
19:35It doesn't have to be two pins at once.
19:37But basically, you can imagine,
19:39especially if you had some sort of
19:40encoder or something where you only
19:42wanted to look at events where both are
19:44high at the same time or maybe one is
19:46high and one is low. This is a unit that
19:48will allow you to do that. And only
19:49under those conditions uh does the GPO
19:52pin uh or would you want an IRQ to go
19:54off.
19:57uh let's see they have event triggering.
19:58So this allows uh so here we have four
20:01inputs from one of these four channels.
20:03You've decided some combinational logic
20:05and now you have four events and these
20:08events can be triggered high or falling
20:10edge, rising edge or both. And then the
20:13result is a trigger that will go to um
20:16the output stage or there's just a
20:19register set in there that you could go
20:21look at if you wanted to. So it doesn't
20:23have to make an IRQ. You could just
20:24store this event and then if you're
20:26polling, let's say, you could look in
20:27there and see what happens. This is also
20:29a good way that if an IRQ went off and
20:31you don't, it's hard to keep track of
20:33state, you could look in this uh
20:34register and see what happened.
20:38There's a cross connect layer. This is
20:41where it takes the four channels and
20:43mxes them to one of four outputs
20:46or some other peripherals that can come
20:48in there. And then finally, there's four
20:51output gates that can set up to four
20:52IRQs. So the big piece is you have four
20:56possible or uh four channels inputs with
20:59two paths that look at different GPO
21:01pins. You can do some combinational
21:03logic. You can set whether you want
21:05interrupts to be high to on positive
21:06edge, falling edge, and then you get to
21:08route them to IRQ channels that go to
21:12the core. I know that's a lot. You're
21:14going to learn a lot in a lab, but do
21:16you have any questions?
21:22Yeah.
21:26>> What is the
21:30>> All right. So, the output is going to
21:31send the IRQ to the ENVIC.
21:35So, it's a single line. So, one of four
21:37lines that go out.
21:39Okay. And then you get to configure what
21:42causes those lines to go high.
21:45the output data unit.
21:47>> Yeah. So the output data unit gating
21:49unit here the output is just there's
21:52four lines that go high. Those go back
21:54to the env. So those are your interrupt
21:56requests and you have your you can
21:59configure what causes those things to go
22:02high.
22:08>> Yeah.
22:14I'm just like confused how
22:17>> there's two.
22:18>> Yeah. So there's two on ship
22:20>> and now that's now that's a great I'm so
22:22you're so glad you asked that question.
22:26Set me up. Okay. So so far we have a
22:29very few IRQ. So we only discussed four
22:31and I alluded that there's another unit
22:33that could do eight. So like this device
22:37has 117 port pins on it. depends on
22:40which uh physical variant we get. And
22:42there's 112 IRQs that on this particular
22:45device, but it's only giving you eight
22:47eight possible things for GPIOs. Like
22:51that seems weird to me. Um
22:55so my question to you is why would a
22:57system architect, you know, they're
22:59smart people at Infinion who made this
23:01stuff. Why would they have all these
23:03possible IRQs, 112, in fact, you can get
23:06up to, I think, two 240 IRQ. They had
23:10enough IRQs to do more with the GPOS,
23:12but why did they choose to only allow
23:15eight different IRQs to go off of all
23:18those GPOs? So, why don't you take a
23:20second, brainstorm,
23:22come up with an answer?
24:14Why do we think? Why don't we take a
24:15guess? I gave you an extra hint here
24:18that a lot of the IRQs are handled by
24:21these communication buses as well as
24:22ADCs.
24:24So why has Infinion prioritized those
24:27things rather than GPO pins?
24:34I heard you guys talking though.
24:41>> Y
24:56It's true. There are a lot of other
24:57things I think is what you're saying.
24:58There's a lot of other things on this um
25:01device, but why so few? Why only eight,
25:04right? like they could have done like
25:06what is special about these things
25:08that's different from just general
25:11purpose inputs to a GPO pin.
25:17>> Yeah.
25:26>> Yeah. So different manufacturers will
25:29prioritize different things. So STM
25:31allowed more interrupts uh just from
25:34general purpose GPO pins. Now it's a
25:36little bit confusing because USB will
25:38pass through a GPO pin, right? It's in
25:40the alternate function mode. Say well
25:41EtherCAT or Ethernet or CAN or anything.
25:44Those go through the pins. It's true,
25:46but it's not. It's different than saying
25:47I get to decide if it's uh high or low
25:50or I'm looking at the behavior of a
25:51specific fan pin from a voltage level.
25:54And so infinion essentially saying like
25:56look this is a industrial automation
25:58chip. We want to prioritize interrupt
26:01activity from these things because these
26:02are going to happen way more often and
26:05humans pressing buttons is really slow
26:07and we'll figure out other ways to deal
26:09with that. So that was just a design
26:10choice. There's no inherent obvious
26:12reason why they would choose it. That's
26:13their market segment.
26:16Okay.
26:18Uh okay. So then we talked about this a
26:21little bit but uh there are two only two
26:24u on your device. One of them is very
26:27port uh focused. That's the ERU uh zero
26:31we just talked about. And this again is
26:33focused on looking at the external
26:36world. Then it has internal as well. And
26:39we're not it's not important that we
26:40know this specifically right now, but
26:41it's good that you just are aware of it.
26:43And what they are really looking at is
26:46how do I connect uh interrupts caused on
26:48peripherals to other peripherals. They
26:50want to automate tasks on device. So
26:53they want to say when my ADC is done go
26:57raise an IRQ to say DMA which is your
26:59direct memory access controller so that
27:01I take the value out of my ADC and put
27:03it into memory. I don't even need the
27:05core involved. So a lot of what Infinian
27:07is really trying to do is automate
27:09general basic tasks by having one
27:11peripheral signal another peripheral.
27:14And we'll talk more about that when
27:16we've gone through our vast list of
27:18peripherals you'll learn about in this
27:20class. So, for now, uh, we're just going
27:22to focus on IRQS that are generated from
27:25a GPU into the ERU and then onto the
27:28ENVIC.
27:33And so now any sorry any ERU questions
27:36yet?
27:39>> So you said the output unit allows you
27:41to choose when those signals go high.
27:44>> Yep.
27:44>> So then what is the event combination
27:46unit?
27:47>> That the event combination unit says I
27:49have inputs. I have more than I have
27:52four channels and I say I have eight
27:53inputs and I'm going to for each channel
27:55I have two paths and those paths are
27:57like signals coming from some GPO pin
28:00and then the combinational unit can say
28:01when this one is high and that one is
28:03low let's say so it allows you to do
28:05some combinational logic on those inputs
28:08before it's passed to the next layer.
28:11>> But doesn't the unit also then do some
28:14combination?
28:15>> No. All that does is basically mxing out
28:20um
28:21it's not really I wouldn't say it's
28:22combinational logic it's more routing.
28:25So here we're saying that something on
28:27channel zero could go to channel 3. It
28:30could also be that and I don't know why
28:32why do they want that? I don't know this
28:33they wanted the flexibility. It also
28:35could be other peripherals such as
28:38timers. It's not all the timers but some
28:40of the ch timers some of the other
28:41peripherals also get routed through
28:43here. So now you can decide which one
28:45goes where.
28:54All right. So we're going to move on to
28:55the ENVIC. And this is more the the star
28:58of the show. The assumption here is
28:59we've figured out how to set up these uh
29:02peripherals. And then these lines, these
29:04IRQs, which are just single data lines,
29:06they're not buses, are going to go high
29:08when some event should take place or
29:10when they want to tell the endic, hey, I
29:12need you to respond to something
29:14asynchronously to the uh code that's
29:16being run. And so we'll start off with
29:19three basic um
29:22registers. So we have an enable
29:23register. So this is a uh an an a
29:27register on the env that will uh enable
29:31if an um uh IRQ should go uh cause an
29:36interrupt. So not only does your
29:39peripheral have to be configured to
29:42raise high or low to cause an inter an
29:44IRQ, the envic has to be enabled to
29:48respond to such an IRQ.
29:51Oops. And then there's two registers for
29:53that. So there's a a set enable and then
29:56there's clear enable just so that
29:57there's clear functionality here between
30:00you don't you know uh do a make
30:02something make a mistake by writing or
30:04setting too many bits. So you have the
30:07functionality specifically to clear and
30:09specifically to set.
30:12So now um even even if a interrupt is in
30:16uh is disabled it can still set the
30:18pending flag. So the pending register is
30:20just a register that holds the state of
30:23what in IRQs have been fired, have gone
30:27off, and that the NVC has latched them
30:29in. So it's just a place that stores uh
30:32what uh IRQs are uh pending or have been
30:37detected. Uh and you're waiting here for
30:40them to go into the active state. You
30:42can also have software. So, it's not
30:45that common, but there's sometimes,
30:46especially in debugging, you're going to
30:48want software to go fire off an
30:50interrupt. So, software can also put set
30:52pending status. And then there's again,
30:55there's two registers for this. There's
30:57a dedicated set pending and a dedicated
31:00clear pending.
31:03And then the final register that we
31:04think about here is the active register.
31:06So, this one holds the state of which
31:09IRQ or sorry, ISRS are active.
31:14uh and there can be more than one
31:17uh and then so the active going from
31:19into active clears pending and then when
31:22you're inactive and you leave active
31:24then active gets uh cleared as well and
31:27there's a particular register for that.
31:29So the the big takeaway here is we have
31:31three registers to start thinking about
31:33what is enabled meaning what should go
31:36into active. We have a pending register
31:38which keeps track of which uh IRQs have
31:41gone off and then there's the active
31:43register which says this is the thing
31:45that is going on right now and later
31:47we'll find out you can have multiple uh
31:49interrupts occurring at once.
31:52>> Yeah.
31:55For the multiple interrupts does it mean
31:57that
32:00>> sorry for what one?
32:01>> For if there's multiple interrupts
32:03>> does that mean the ISRs are all running?
32:06>> Yes. We'll we'll see how that works
32:07later. You can only have one piece of
32:09code running on your processor at once.
32:11It's not multi-core or anything, but
32:12we'll see how these things can overlap.
32:22Okay. So, here's a basic flow. Oh, here
32:25we go. So, basic flow here. So, here in
32:28this example, there's a So, this is just
32:30one single bit in that register. It's
32:32not supposed to be the entire register.
32:35Um let's see we have uh interrupt
32:39request has come as a function time
32:40here. Can you hand these out to all that
32:42those people and can you pass this that
32:45way and then up and you can go.
32:50Thank you. You can pass over and up
32:54and then Okay. So at some point the
32:56interrupt request came and then the
32:59envic realized that. So, can you just
33:01pass these this way and up?
33:08Uh, the pending status flag got caught.
33:14Now it's pending. And then the processor
33:16goes from thread mode into handler mode.
33:20Okay. And the timing here doesn't really
33:23matter that much. This is more logical
33:25timing, not like there's no time axis on
33:27here. Okay.
33:30Now there's some tricks here in the
33:32sense that the peripheral generates the
33:35IRQs and that can either be pulsed or
33:37level set meaning that here the hardware
33:41cleared the interrupt. Doesn't mean it's
33:43not shouldn't be acted on. It just means
33:46that this was just a pulse. Okay. Now
33:48the peripheral or the thing that sent
33:51the IRQ could just hold it high as well.
33:53Both are valid.
33:56And then it's the envic in the program
33:59pending status register. It detects
34:01pulses at rising edge, but it also needs
34:04to be able to respond to level set ISRs
34:06or IRQs, sorry.
34:12All right.
34:15And so you could have a software uh you
34:19know in software clearending. Um so in
34:22that case you were just doing something
34:24else for whatever reason you never got
34:26to uh um activate that uh go into active
34:30mode. The most common case is that
34:32you've disabled that uh interrupt but
34:34your IRQ your peripheral kept on
34:37throwing a signal. Hey I want to please
34:40pay attention to me. It's just that you
34:42as a programmer said I'm not I don't
34:44care about that right now. Like in a
34:45program state that's not a thing I I
34:47want to respond to. But if you went into
34:50active uh enabled it, then the problem
34:52is that you would have all these backlog
34:54of pending interrupts and you would
34:56immediately go into it. So here's where
34:58the software clear is really important.
35:00Before you actually enable an interrupt
35:04uh in the NVIC, you should probably
35:05clear it first just to make sure it
35:07hasn't been pending for a while.
35:08Otherwise, you may mistakenly jump into
35:10that interrupt because of some old
35:12outdated information.
35:15>> Yeah.
35:17disable.
35:21>> Yeah. So you can you can enable and
35:23disable uh the IRQ requests in the
35:26peripherals but you have an enable
35:28register in the env.
35:34So it's got these two places that are
35:36holding this or have to both be enabling
35:39uh interrupts for it to actually work.
35:44All right. And then we can add in an
35:45active state here. So, no big surprise,
35:48we have an interrupt RQ that's gone off.
35:50The envic is looking at those 10und
35:53whatever 12 lines coming off of the uh
35:56peripherals and it says okay this one
35:57has gone to pending and then um it has
36:01decided in this case that you've gone
36:03from pending you go into active mode you
36:05start doing stacking. Now technically
36:07you don't under enter active mode until
36:10you fully stacked even though the active
36:13stacking means you're going into active
36:14mode. It's just that explicitly in the
36:17manual it argues that a handler mode or
36:20being in an active state only happens
36:22when you're in the ISR. But regardless
36:24of that, IRQ has come pending was
36:27asserted and then you went into active
36:28mode and then the processor went to
36:30stacking. Uh at the end of it, you um
36:34the interrupt returns uh pending is
36:37deasserted as you destack. And it's also
36:40good to point here that when you
36:41transferred from uh thread mode to
36:44handler mode, uh pending was deasserted
36:47as uh active status came in. So you're
36:50not going to have um a pending stay high
36:53while you're in that actual interrupt.
37:01Uh okay. Oh, that's right. It says
37:04interrupt request cleared by software.
37:06So what does that mean? So in this
37:08particular case, you'd have to look
37:09through how is the IRQs generated in the
37:12peripherals. Some of them are just
37:14pulses. Some of them are held high. So
37:17what you want here is that in your
37:20processor mode, right? And sorry, when
37:22you're in your handler mode, uh you're
37:25doing your interrupt service routine, if
37:27you as a programmer know that the thing
37:30that generated that IRQ is just holding
37:33it high, you don't want to immediately
37:34go back into it. that would cause an
37:36error. So what happens is you have to go
37:39in software go clear that interrupt in
37:41the peripheral so that line goes down
37:42and doesn't trip you again.
37:50All right. So we'll go through an
37:52example to see what would happen here if
37:54in fact the IRQ is left high. So you can
37:58fill out your sheets just go through
38:00what happens. You're going to start your
38:02handler starts going down, right? You've
38:05been deasserted, but this pending thing
38:07is still high. What do you think will
38:09happen?
38:17So, state another way, there's an IRQ
38:20that's valid, it's not in pending, and
38:23you're not actively in the IRQ or ISR.
38:28What happens next? Take a guess.
38:46Thank you.
38:49>> You get one.
38:51>> All right.
38:57>> No. Does anybody need a worksheet?
39:08What do you think? What's going to
39:09happen here?
39:25It's okay.
40:03We're going to see later.
40:38All right. So, this is uh some good
40:40clarification here.
40:42This is just for one IRQ. There could
40:44be. So this would be one IRQ with one
40:48pending bit in one register and one
40:50active bit in the register. But there
40:53could be well there are in your
40:54particular device 112 of these. So while
40:57this might feel overly complicated like
40:59why not just have an IRQ go directly to
41:01handler mode? Why do we need all these
41:03layers of obiscation? What's going to
41:05happen is you're going to see when you
41:05have 112 going off, you need some other
41:07ways to handle that. So now we're just
41:09setting ourselves up for understanding
41:10the flow of how things happen and then
41:12we'll see what happens when multiple
41:14things go off. We have to make decisions
41:16about what should uh go what should have
41:18higher priority.
41:20All right. So the question here is what
41:22happens this thing has been left high
41:25wasn't cleared and you uh it's no longer
41:28pending because why? because you were in
41:30pending you went when you went to active
41:31pending got deasserted and then you've
41:34exited your uh interrupt and so you're
41:37not active anymore. So what do you think
41:38will happen?
41:45Take a guess. Yeah.
41:50>> Yep. So here as you leave
41:54your invict is always looking at these
41:56lines. It's both edge triggered and
41:59level set level triggered. So here it
42:01goes through and says oh well I've
42:03deasserted everything is not pending
42:05anymore but that thing is still high. So
42:07now I'm going to go through and reassess
42:10that and now we're going to go right
42:12back into that interrupt. So the
42:13interrupt got re-entered.
42:19All right. We can look at another case
42:20here.
42:22Um, this assumes that these pulses come
42:24in very fast. So, whatever, who knows?
42:28It is. It's not going to be a button
42:29press, but maybe you have some. Yep.
42:34>> What was narrow?
42:39>> Well, I the question could be I don't
42:42know what it was doing over here, but
42:44here it just did it immediately went
42:46into it and then came back. So, I would
42:48not infer timing from these things. It's
42:50just stating that something else was
42:52keeping it from acting here. Who knows?
42:54It could have been a more important
42:55interrupt. But then because it would
42:57just ran, it just becomes pending and
43:00immediately goes back to to active.
43:02>> Yeah.
43:03>> So there's like no reason that the first
43:05stat.
43:06>> No, no, no. We can't infer. This is just
43:08logical flow. We can't infer timing from
43:10these basic diagrams.
43:16>> Does that mean it doesn't?
43:18>> Yes. Well, yes. You're very good. Very
43:20clever. We'll figure that out at the
43:21very end.
43:25Okay. Yes.
43:33>> Because by definition, there's no good
43:35reason other than by definition the act
43:38of going into active state deasserts
43:40pending. It can't be pending anymore if
43:42you're active.
43:48Okay. So, we'll jump ahead. Assume this
43:51is some sort of like CAN bus that has an
43:53emergency going on. It's hit it three
43:56times. Don't worry too much about
43:58length. Just assume that um you know,
44:01you know what's going to happen after
44:03pending, but you're going to go into
44:05active mode. So, figure out what's going
44:06to happen here. Just draw out what you
44:09think will happen because of these three
44:11uh pulses that came in.
44:40That's pretty much
44:54Amen.
45:05How
45:07do you
45:25do?
45:48Okay.
45:59>> All right. So here we have multiple
46:01inter interrupt requests occur. Pending
46:04was not able went into pending
46:06immediately. Pending is just one bit,
46:08right? And then for whatever reason, we
46:11don't know why the example doesn't tell
46:13you, but pending wasn't able to go into
46:16active until over here until after those
46:18uh pulses came through. So what do you
46:20think will happen next?
46:22How many Well, I can ask it this way.
46:24How many times will this interrupt
46:26service routine run?
46:29one. I see lots of ones. Okay,
46:32that's right. Um because the this
46:36pending interrupt bit does not have any
46:38information about how many times it was
46:40triggered. It's just a single bit. It
46:41just says it was requested. It has been
46:44requested for a while. It doesn't matter
46:46how long. And then it can go into active
46:49mode. It doesn't have state information
46:51about how many times. Okay.
46:58Yeah.
46:59>> So what do I do if I want?
47:04>> Well, then so I guess it's all about
47:06timing, right? So like um we're going to
47:09assume that these things are relatively
47:10short like in the hundred of cycles sort
47:12of time frames we're talking about. Um,
47:16but if you want an event to occur three
47:18times, like uh then you would have to
47:20have somewhere else on your device,
47:22maybe some memory location or some
47:24register that's saying, "Hey, I meant it
47:26to happen three times." And then in your
47:28ISR, you wake up and you go check that
47:31place to see how many times the action
47:34should be taken. This is not about
47:36communicating information to the core
47:38through the ENVIC. This is about just
47:40saying, "I need action to be taken."
47:43>> Yeah. the inter request is one. Will the
47:46interrupt pending status always become
47:47one?
47:51>> Nope.
47:52>> It'll always be if if there's a rising
47:55edge or it's level set. It's either high
47:57or rising edge then pending will go high
48:01>> always. Yep.
48:04There's no way for a a peripheral to
48:09clear a pending uh request.
48:13this doesn't happen.
48:16Now, it could be that you as a
48:17programmer know that in your ISR you
48:20need to double check if the action that
48:22needs to be taken is still relevant.
48:25It could just be a long time. I don't
48:26know. There's could be reasons why it
48:29may be stale. But this is just saying
48:32should I enter interrupt service
48:34routine?
48:37All right, we'll go back to our our last
48:39example.
48:40All right. So an interrupt uh request
48:43after pending has cleared. So here I am
48:46uh and I I have a interrupt request
48:49comes went to pending. Pending went to
48:52uh active. I'm in thread handler mode
48:54and now pending came again. What do you
48:56think will happen?
49:21What's going to happen here?
49:59city
50:11forever.
50:22Jesus.
50:51I wonder.
50:57All right. So, remember these you do not
50:59have all the possible bits of
51:01information. This is just more for you
51:02to think through something. That's it's
51:04not like you're it's not like exam where
51:06you're supposed to get it right just
51:07yet. You just learned about this. So,
51:09what do you think could happen? Uh,
51:11basically pending got deasserted because
51:14you went active and another pulse came
51:16from the IRQ requesting another event.
51:19Can pending go high when you're active?
51:22What What's your guess?
51:27No, I got a no over here.
51:31>> Yeah.
51:31>> Yes.
51:32>> Well, I I talked to them so they know
51:33the answer.
51:37Okay. So, in this particular case,
51:40pending can go high. Pending to get into
51:42pending state only matters on if it was
51:45already pending or not. Right? So, in
51:48the the example with the three pulses,
51:49it was already pending. It can't go more
51:52pending. here pending was deasserted. It
51:54gets an edge. It goes high. Now it's
51:56pending. Right? All this is is a
51:58register with this edge triggered uh or
52:03high. And every clock cycle it's going
52:04through. Well, if it's edge triggered,
52:06it goes high. If every clock cycle, it
52:08looks to see if the line's coming in. If
52:10it's high, it goes high. That's all
52:11pending is. Is an IRQ wanting to talk to
52:14me?
52:16Okay.
52:18Any questions?
52:21Oh yeah,
52:22>> sorry.
52:30>> We'll we'll talk about that later.
52:32There's something called late arrivals
52:34uh and tail chaining. If we get to the
52:36end of lecture today, we'll find about
52:37them. Don't worry about it right now.
52:39But to to give away the answer, if
52:41you're already stacked and you have to
52:43go into another interrupt, why unstack?
52:46Just leave that on the stack and go
52:47right ahead. saves you 12 cycles, six
52:49cycles.
52:59>> So I also like
53:09>> Are you saying that you made pending
53:12maybe? Sorry, I really can't hear stuff.
53:14I think it's the acoustics. Are you
53:15saying you put pending high here? I'm
53:17saying I put it high like right after
53:20low at the first time because request
53:23>> Oh. Ah, that's a good point. Uh, it
53:28probably should explain this detail. I
53:30guess it's not looking here. Um, when uh
53:33it's in active mode, it's not going to
53:35be level set level triggered. That is a
53:37I should make that caveat more clear.
53:40>> Yep.
53:41Okay. Good question. So the basic model
53:45was we have a set of registers that
53:47disables enables uh interrupts and it
53:50doesn't disable the IRQs. It just
53:52disables if the system if the NVIC is
53:54going to take those IRQs and put them
53:56into active mode. You can still get they
53:58can still get in pending. Uh you have a
54:00register for every IRQ that's holding
54:03the pending state and then you have a
54:05register that holds which interrupts are
54:08active.
54:10Uh so the next question is what happens
54:12when you have two or more interrupts
54:14that are pending? For example, you have
54:16um GPO1, GPO zero, a timer. Um one of
54:21the issues here is that pending does not
54:24uh know who what interrupt went off
54:26first. It doesn't hold any information
54:28other than it has occurred. There's no
54:30timing information in that bit. So the
54:32question for you is what would be a good
54:34strategy or how should the process
54:35determine which interrupt should go
54:38first if there's multiple pending
54:39interrupts. So take 60 seconds just come
54:42up with may what are some possible
54:44options that you could design
54:46to handle this situation.
55:07Look at
55:14All right.
55:42>> All right. We haven't
55:44We haven't explained how, but just
55:46assume that we're in a case where we
55:48have multiple pending bits are set. How
55:52do you determine or what's an elegant
55:54way or what do you have to consider uh
55:56when you have multiple pending bits? How
55:58do you decide which one should go first,
55:59second, third, whatever?
56:04>> Yeah.
56:06>> So, we have to have assign some way to
56:08to assign them priority.
56:12just start by timing first and then
56:17the number of the
56:19>> that's pretty good. So the one problem
56:20with timing there's no state there's no
56:22timing information recorded remember
56:24pending is just a this thing has wanted
56:27to talk to me there's no timing
56:28information but your default of hey
56:30these things are numbered right that's a
56:33great way to decide but it's not very
56:35flexible so the answer is that's the the
56:38the last resort when we when you that's
56:40the last tiebreaker is the IRQ number
56:43but we're going to assign some other
56:44methods for doing that so uh what it's
56:47called is interrupt priority so we're
56:49going to be able to set the priority how
56:51important certain interrupts are and so
56:54there's mechanisms for that. So we have
56:56um an interrupt priority register. So
56:59this is a 8bit value um that determines
57:02the priority of an interrupt. So you get
57:05to assign in a register in the envic and
57:08says this thing is more important than
57:10other interrupts and therefore if two
57:12have collided or both are pending this
57:15one should go before the other one. And
57:18you might think that in a a small
57:20project might feel even rare that that
57:23could happen. But in especially uh you
57:26know automated things, communication
57:28buses uh there are lots of uh or control
57:31systems there are a lot of uh interrupts
57:34going off and you really do want to
57:35control which one can uh interrupt
57:38another one.
57:40Then along those ideas, there's the uh
57:43group priority or priority group
57:45register which allows you to set a
57:47preeemption and sub uh priority uh
57:50categories. And we'll talk about this
57:52more, but basically there's bits that
57:54define if this interrupt can be
57:56interrupted. If not, if it if there are
57:59penny interrupts uh that of equal
58:01interrupt priority, which one should go
58:03first? So it's the idea of what's
58:05interruptible and then what has
58:06priority. Go over that in a bit.
58:09And then we have a bunch of ways to
58:11control what interrupts go off and which
58:14ones don't. So you have like base
58:15priority, fault mask, and prior mask.
58:18Basically, these are three registers
58:19that control that eliminate or turn off
58:23low urgency interrupts so that uh the
58:25core can focus on certain tasks. And why
58:27this is important, you could imagine
58:28that you have multiple interrupts or
58:31multiple tasks that have to interact
58:33with a piece of memory. And you don't
58:34want to be doing some mathematical
58:36operations or moving things around. some
58:38interrupt occurs and rewrites parts of
58:41memory and you as a core aren't aware of
58:43that. So in this particular case you
58:45could say well this should needs to be
58:46an atomic option and I will stop all
58:49interrupts of a certain value urgency or
58:52whatever they are um so that I'm never
58:54interrupted while I'm doing this memory
58:56operation. So that's why as a one way to
58:58make them atomic. You could go through
58:59and disable individual interrupts, but
59:03that can be um tedious, especially if
59:06you didn't program everything uh on your
59:08device. So, this is a way to say
59:10everything is lower than this particular
59:12level of importance, just turn it off
59:14for this moment. So, I'm going to go
59:16through each one of these, but is there
59:18any questions so far?
59:21Okay.
59:23Um so interrupt priorities. So the envic
59:25hat allows configurable uh priorities
59:28for almost every interrupt. Uh here
59:30higher importance uh can in uh interrupt
59:34lower important items. But to make it
59:36confusing we're going to use uh lower
59:40priority numbers have higher importance.
59:42So in this example, you know, priority
59:44uh A of five and B of two are both in
59:48pending, but B has higher importance
59:50because uh than A because B is smaller.
59:54So this is always confusing when we talk
59:57about uh higher importance or higher
59:59priority, but it's important to remember
1:00:01this is all golf scores. You want the
1:00:02lowest possible score, that means it's
1:00:04the most important thing.
1:00:07And one maybe architectural way to think
1:00:10about this is um
1:00:13ARM doesn't know how many IRQs there are
1:00:17in the system. It knows it could be up
1:00:19to 240, but different manufacturers can
1:00:22control different values. So you don't
1:00:24want to say like 240 is the top or 256
1:00:27is the most important thing because you
1:00:28just don't know if there's enough IRQs
1:00:30for that. So that's why it's all
1:00:32starting from zero. In fact, we'll even
1:00:34see this starting from negative -3. But
1:00:37um all starting from basically higher
1:00:40importance means lower uh priority
1:00:42number.
1:00:44And then there are three fixed
1:00:46priorities and these are from ARM.
1:00:48They're system exceptions. So reset
1:00:50handler uh IRQ mask or sorry nonmaskable
1:00:54interrupts and then hard defaults. And
1:00:56basically they're just saying that these
1:00:57are negative -2gative1g3.
1:01:00Not because we're doing you know signed
1:01:02math here just because you cannot set
1:01:05anything lower than zero. These always
1:01:07have the priority over anything that you
1:01:10as a programmer can set or that infinion
1:01:13can design because these are core
1:01:16priority levels to uh the device.
1:01:19Basically, if you're power on resetting,
1:01:21you know, you you you're in the middle
1:01:22of reset, nothing should be able to
1:01:24interrupt you while you're in the middle
1:01:26of reset because your whole thing could
1:01:28easily get bricked.
1:01:30Any question? Yeah.
1:01:37>> Yeah. Yep. And then what we'll see is
1:01:40you have two interrupts at the same
1:01:41priority. They're both in pending. Well,
1:01:43which one should go first? Well, that's
1:01:45where the sub priority comes in. That's
1:01:46the ordering afterwards.
1:01:50And so the mental model is that you have
1:01:53uh your interrupt priority registers and
1:01:55there's eight bits and for this is for
1:01:57each one of those uh interrupts and
1:02:00you're going to go and set some 8-bit
1:02:01value in there that indicates its
1:02:03priority.
1:02:06Now I said it's eight bits but then we
1:02:08come to the next caveat.
1:02:10So, oh well, first of all, there's two
1:02:12different ways. Before I get to that,
1:02:14there's two different ways to interpret
1:02:15the data that's in those eight bits. So,
1:02:18one is the preeemption priority, which
1:02:20means uh the value that can preempt or
1:02:23interrupt an interrupt, and then the sub
1:02:26priority, which is if you have multiple
1:02:29uh pending interrupts, which one should
1:02:31go first? Which one's more important?
1:02:37And then uh ARM defines that there's
1:02:39eight bits but Infinine only uses six.
1:02:42Now this is because having lots of bits
1:02:46just makes things much more complicated.
1:02:48And because Infinion only has 112 of its
1:02:51own IRQs, it doesn't need all those bits
1:02:53to be that expressive. And it makes the
1:02:56Envvic more complicated and other parts
1:02:58more complicated. So uh STM only used
1:03:01five. So it just depends on a
1:03:03manufacturer side of how many bits uh do
1:03:05you want to be used for preemption
1:03:08priority and uh subpriority
1:03:12and then to make it even slightly more
1:03:14complicated
1:03:16the allocation of those bits. So you
1:03:19have eight bits. We're going to say that
1:03:21the last two aren't used on Infinine.
1:03:23You can decide the allocation. Do you
1:03:26want them all to be preeemption
1:03:28priority? So six bits for that. Do you
1:03:30want them all to have sub priority? Do
1:03:32you the same uh do you want all the bits
1:03:34allocated for sub priority or do you
1:03:36want some sort of mix of them so that
1:03:37you have say in this case three bits for
1:03:40preeemption priority and three bits for
1:03:41sub priority. So this gives you
1:03:43flexibility about controlling what can
1:03:45go what can turn on what can turn off or
1:03:48what can uh sorry what can interrupt
1:03:50another interrupt but it also adds this
1:03:52extra layer of complication because now
1:03:53you have to decide which is which.
1:03:59And then these are all live in the I
1:04:01forgot what this interrupts. Oh no,
1:04:02application interrupt and reset control
1:04:05register. There is a register. The
1:04:06reason why I bring this up is uh here is
1:04:09where you would set the allocation of
1:04:11the priority group. You would go in uh
1:04:14this little threebit thing here and you
1:04:17would go through oops come back. You'd
1:04:20go through this table and figure out
1:04:22what it is that you need uh what
1:04:24allocation you want to define
1:04:27and then to able to edit this interrupt
1:04:30uh table or the that priority group.
1:04:33There's actually a key because it's so
1:04:34critical that you don't screw this up,
1:04:36you have to go look in the
1:04:38manufacturer's data sheet. You have to
1:04:39write the right key to that register up
1:04:42top before you can go and modify the
1:04:44priority group allocation because if you
1:04:47mess it up, then nothing's going to
1:04:48work. So a lot of times this generally
1:04:50means is you figure out what your uh
1:04:52group priority schema is going to be at
1:04:55the beginning and you don't change it
1:04:56otherwise it becomes painful to back
1:04:58edit everything else.
1:05:00But the big thing I'm trying to take
1:05:02away is the allocations of how many bits
1:05:04are for preemption priority and how many
1:05:06bits for sub priority is definable by
1:05:09you.
1:05:11Any questions? Oh you guys are good.
1:05:14Okay.
1:05:18So preeemption priority is whichever one
1:05:21is lower that can interrupt a lower
1:05:24interrupt, right? So sorry, a less
1:05:26important interrupt. So if I'm at
1:05:28interrupt one, uh priority one and
1:05:31something of six comes in, uh it cannot
1:05:33interrupt me. But the vice versa, if I'm
1:05:35at six and one comes in, it can
1:05:37interrupt. But sub priority says it
1:05:40doesn't matter if six comes in uh sorry
1:05:43if um two things of the same priority
1:05:46come up then it looks at the sub
1:05:48priority to figure out which one should
1:05:50go first.
1:05:53>> Yep.
1:05:54>> Yep.
1:05:56>> Yeah.
1:06:02>> Um it helps you better categorize what's
1:06:06going on. So now you can say everything
1:06:08of a certain like here you in that
1:06:10previous example we had eight preemption
1:06:11priorities and then it allows you to to
1:06:13define everything of those same
1:06:15priorities. Uh it just gives you more
1:06:17flexibility when you're programming
1:06:18things. So it's just like
1:06:24>> the priority number like3 was that the
1:06:27preemptive?
1:06:28>> Yes.
1:06:29>> Okay. the tiebreers
1:06:32>> uh and for those there's no tie breakers
1:06:34for those negative 3G12 because those
1:06:37from ARM you don't get to control those
1:06:39but say you had uh preemption priority
1:06:41of zero then those sub priorities would
1:06:43be the tiebreakers and then if you have
1:06:45the same uh sub priority and same two
1:06:49interrupts with same sub priority and
1:06:50same uh pri preemption priority then you
1:06:53would use the interrupt number as the
1:06:55tiebreaker
1:06:58and Um yeah.
1:07:02Okay. And then lastly, um I'm just
1:07:06putting this so you have reference of
1:07:08it, but there are these three registers
1:07:10that allow you to control and disable
1:07:13certain interrupts. And this is
1:07:15important. Like I said before, just like
1:07:17the base priority says nothing below the
1:07:19certain amount can interrupt me. And
1:07:21oftentimes you can see you can imagine
1:07:23that a processor can get bogged down
1:07:25because it's spending so much time uh
1:07:28operating on certain tasks uh that it
1:07:30can't make forward process in main. Um
1:07:33you can also think about like you have a
1:07:35real-time system and you have mission
1:07:37critical things. So say you know you're
1:07:40the difference between uh you know
1:07:42keeping your drone stable versus taking
1:07:44camera footage. Well, if you find that
1:07:46you're uh running out of memory or uh
1:07:50your stack space or that you're not able
1:07:52to meet your real-time deadlines, then
1:07:54you can start disabling some of your uh
1:07:56lower priority interrupts to free up
1:07:59resources to go after the tasks that are
1:08:01most important.
1:08:04Um let's see, where are we on time?
1:08:06Okay. Um I'll go through these quickly.
1:08:10It's not that important, but there's two
1:08:11ways to interrupt to interact with the
1:08:13interrupts. Um basically there's the
1:08:16registers which I just described but
1:08:18then uh ARM as part of their CM uh SIS
1:08:22this protocol that they've made uh
1:08:24defines that there must be certain C
1:08:26abstractions and I bring this up is
1:08:29because if you understand these C
1:08:30abstractions they work across almost all
1:08:32ARM devices. So uh if you're working on
1:08:35STM or Nordic or Infinion these
1:08:38abstractions will always be there. Um,
1:08:41and it I don't know which one they're
1:08:42using in lab this year, but there's the
1:08:44the C functions here which look at those
1:08:46things or there's the actual memory
1:08:48addresses and the memory locations that
1:08:50you can write to. So, it's it's either
1:08:52one uh whichever one you want. All
1:08:55right, but now I want to get to the more
1:08:56interesting parts.
1:08:59What happens when we have overlapping
1:09:02interrupts? So, preemption, tail
1:09:04chaining, and late arrivals. So, here
1:09:06we'll start with a base case. I'm in a
1:09:09program. I have a stack. I have a vector
1:09:13table. Essentially, it's kind of
1:09:14inverted. I have pending, enabled, and
1:09:17active. And I'm in a program. And then
1:09:19an interrupt occurs. So, this is the
1:09:21base case. Um, yeah. Uh, okay. And so
1:09:26now the pending came in. It went to
1:09:29pending. Oh, these were all enabled. And
1:09:31because that's there's nothing else
1:09:32active, I'm going to go into stacking.
1:09:35Enter my RSQ.
1:09:37uh pending got deasserted when I went to
1:09:39active. The base priority or the uh the
1:09:43priority of the thing that's that's uh
1:09:45going on right now is six because that
1:09:47was through RQ4. So IRQ4 there on that
1:09:50table has a priority of six.
1:09:55And then uh when you're done, you're
1:09:57going to branch. Where do you branch
1:09:58back to? That special location. And then
1:10:02that causes the unstacking to occur and
1:10:04active gets um deasserted. So this is
1:10:07the base case before we add in extra
1:10:10overlapping interrupts. Any questions so
1:10:12far?
1:10:14>> Yeah.
1:10:20>> Yeah. So you don't branch back to main
1:10:23because that would not cause you to
1:10:25unstack. So you go to this I forgot what
1:10:28it is like fff9 and that's basically a
1:10:31hard-coded uh return routine which does
1:10:35the unstacking.
1:10:41Okay. So nested interrupts. So here
1:10:44we're going to talk about higher higher
1:10:46interrupts or higher priority interrupt
1:10:48occurs which interrupts a lower priority
1:10:51interrupt. So we're going to see what
1:10:52happens.
1:10:54All right. So here we're kind of back
1:10:56where we were. We're uh we're in RQ4.
1:10:59You stacked. You're in the middle of it.
1:11:00We're not saying we're at the end. We're
1:11:01in the middle. And what do we see?
1:11:03Nothing's pending. Everything's active.
1:11:05And there's or any everything's enabled.
1:11:07And only one is inactive. Number four is
1:11:09inactive.
1:11:10And so now IRQ3 comes in and this has a
1:11:15lower uh priority number
1:11:18and so it goes to pending and now the
1:11:21device is figuring out what it's
1:11:23supposed to do. It's going to go to
1:11:24active. Well, it can't just switch. It
1:11:27can't just all of a sudden just start
1:11:29doing uh IRQ3.
1:11:32Uh yeah, IRQ3 because IRQ4 is going. So
1:11:36the trick here is it's just going to act
1:11:39like it was in main. It's going to do
1:11:41stacking again. We're going to go stack.
1:11:44And now you look here. I already have my
1:11:46program. I stacked IRQ the the context
1:11:49of IR of the main program on the stack
1:11:51for IRQ4. And then IRQ3 came in. It
1:11:55preempted it because it had a it was
1:11:57more important but a lower priority
1:11:59number. And now I went and stacked all
1:12:01of IRQ4's
1:12:03information onto the stack. And so now
1:12:06the core has no doesn't even know how
1:12:09many IRQs deep it is. It just keeps
1:12:12going, right? Putting stuff on the
1:12:13stack. Uh and so you could spend a lot
1:12:16of time here and never actually get back
1:12:17to main.
1:12:19So then any questions so far?
1:12:23Yeah.
1:12:27>> Yeah. Yeah. This example doesn't have
1:12:29sub priority yet. Um okay. So now we're
1:12:32going to go we've stacked. Now we're
1:12:34going to go enter IRQ3.
1:12:36I don't there's no other interrupts
1:12:38occurring. Uh we're going to branch.
1:12:40It's going to unstack. But what what's
1:12:42the information it unstacks? Well, it
1:12:44unstacks all this stuff. It unstacks the
1:12:47state of IRQ4 when it puts the PC back
1:12:51into uh from the stack into the core.
1:12:54Well, then it's just going to be
1:12:56operating IRQ4, right? So now it just
1:12:59goes back. unstacking causes IRQ4 to
1:13:02resume. Now, the core never had to keep
1:13:05track of how many uh interrupts am I
1:13:08deep in, how many service routines was I
1:13:10doing. It doesn't know. It just says
1:13:12this was more important. I let it run
1:13:14just like it said with the program. This
1:13:15is more important. I'm going to run this
1:13:17other thing. And then you unstack.
1:13:22What questions do you have? Yeah.
1:13:29>> It should have, did it not?
1:13:32Let's see. It did. Did. So, wait. It
1:13:36did.
1:13:37Uh, let's see. Yeah, because it was Oh,
1:13:39we because we jumped right into it. We
1:13:41jumped halfway into the example. So, uh,
1:13:43interrupt four's priority was six from
1:13:45the previous thing. And then, uh, it
1:13:48stacks and then the base priority
1:13:50changed to three because three was here.
1:13:53How's it go back to four?
1:13:54>> Oh, how's it go back to four?
1:13:57Um, how does it go back to four?
1:14:01>> Well, it should
1:14:03that is in the program status register
1:14:06is your is that uh information uh well
1:14:10the information of what's active is in
1:14:13there and then it should be a lookup
1:14:15table actually that kind of looks and
1:14:16see which is the interrupt uh what's the
1:14:18priority of the current interrupt.
1:14:20That's a good question. I had to think
1:14:21through exactly what that mechanism is.
1:14:24>> Yeah.
1:14:33>> Well, it never stops halfway through an
1:14:35instruction. So, we'll complete an
1:14:37entire instruction, then it will go. So,
1:14:39at least it does it on a clock edge.
1:14:42>> Yeah.
1:14:43>> What happens if
1:14:47>> you're you're screwed. That's this bad
1:14:50bad handling of your stack space. But
1:14:52yeah, it could it could happen. It's
1:14:54just you should be keeping track of it
1:14:56somehow.
1:14:58>> Yeah, it would break it. Yeah,
1:15:00>> we had a like right before we unstack
1:15:02number three, we had like another
1:15:07go.
1:15:08>> Yeah, we got example for that one. See
1:15:10if we can get through it. Um,
1:15:13so the person asked what happens when
1:15:15you go through your stack. There's an
1:15:17error for that, right? when you go past
1:15:18your stack buffer and uh so you could
1:15:20have an interrupt service routine or
1:15:22your stack frame that goes and handles
1:15:23that situation. That seems pretty dire.
1:15:26All right. And then we unstack we go
1:15:28back. Okay. So let's talk about tail
1:15:30chaining. So that's the exact question
1:15:31that was just asked. So we're in four.
1:15:34Uh interrupt one comes in. Interrupt one
1:15:37has a lower priority. Sorry, a higher
1:15:40priority number of lower importance. Now
1:15:42it stays pending. Okay. It went
1:15:45independent, but we're going to continue
1:15:47execution in our IRQ4 because that is of
1:15:50higher priority. So, we don't preempt.
1:15:53Uh we don't have to unstack. We don't
1:15:55have to do anything because we're just
1:15:56going to keep continuing
1:15:58what we're doing. And then we're going
1:16:01to do um we're not going to unstack.
1:16:03We're just going to take a little
1:16:04basically you just waste six cycles. Um
1:16:07so tail chaining is you don't want to
1:16:09unstack all the way down because if you
1:16:11unstack then you just stack uh unstack
1:16:14everything and then have to restack
1:16:16right so you don't want to unstack you
1:16:18just take six cycles uh basically to do
1:16:21your uh uh to find out where your IRQ
1:16:25are and load that into memory or where
1:16:27the address is you enter IRQ1 and so
1:16:30this is tail chaining where one happens
1:16:32after the other one something of a lower
1:16:34priority sorry a lower importance but
1:16:37higher priority number uh is not able to
1:16:39interrupt. So then you do that after uh
1:16:41your state is done. Then you're going to
1:16:44go through after that clears there's
1:16:46nothing else pending and then you are uh
1:16:49go unstack and go to your normal
1:16:50program.
1:16:59So anyways, the whole idea of this one
1:17:00is uh if another interrupt comes that is
1:17:04not as important as this interrupt, it
1:17:05just waits to the end.
1:17:08>> Yeah.
1:17:13>> Is the pause necessary there? You have
1:17:15to do an instruction fetch to actually
1:17:17figure out where the next uh interrupt
1:17:19service uh routine is located in memory.
1:17:22So it's usually uh I think it's 12
1:17:25cycles to get in and 12 cycles to get
1:17:26out and shorten shortens it to six.
1:17:31How do you like I guess how do you make
1:17:34sure
1:17:38>> because it looks in pending it's going
1:17:40to go and says do I have more pending
1:17:42things
1:17:47>> uh if so if pending if there's anything
1:17:50unpending then it's what it's going to
1:17:53do is it's going to go through here oops
1:17:56no no no back.
1:17:59Uh, so here it's pending. It ends, but
1:18:03say it still looks at pending. It's
1:18:05like, okay, great. Right, I still have
1:18:07things pending. I don't need to unstack.
1:18:09I just need to go to the next thing. So,
1:18:10this is what tail chaining is. It's just
1:18:12looking at the pending register and
1:18:14saying, well, let's not waste time
1:18:15unstacking.
1:18:18All right, let's try and get through the
1:18:19last one. So, these are late arrivals.
1:18:22So, here's the idea. I was in four,
1:18:25right? four's um priority six and then
1:18:29while I'm in the action of stacking
1:18:31right I'm doing that I get another
1:18:33interrupt now I could um what you don't
1:18:37want to do is go stack again and then
1:18:41you're wasting time so instead what you
1:18:43do is you just do one last little check
1:18:45before you you've stacked you do one
1:18:47last little check to see is there
1:18:49anything else in pending that happens to
1:18:51be more important a lower priority
1:18:53number than the thing I'm doing right
1:18:55Now if there is you just switch to that
1:18:56one.
1:18:58So now even though IRQ4
1:19:01is what caused stacking to occur because
1:19:05IRQ3 was of higher priority and came in
1:19:07while stacking it diverts to IRQ3 and
1:19:10then when IRQ3 is done it goes back to
1:19:12four. There's no reason to unstack and
1:19:14then finally here there's nothing left
1:19:16pending and so then you unstack all the
1:19:18way back to the program. So, it's just
1:19:20this last little catch
1:19:22uh to see if you are actually doing the
1:19:24most important thing.
1:19:31One question. Somebody's got questions.
1:19:33I can't be that good a teacher. You must
1:19:35be confused.
1:19:39>> Yes.
1:19:43Say we got interrupt

About this transcript

This page contains the full transcript of EECS 373 - Fall 2026 - Lecture 8 "NVIC" by Interactive Sensing and Computing Lab , generated from the public captions YouTube serves with the video. The transcript has 11,915 words across 1,785 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.