The Nested Vectored Interrupt Controller (NVIC) is an integrated part of the Cortex-M0 processor. It is closely linked to the processor core logic and provides the functions of interrupt control and system exception support.

Apart from the NVIC, there is also a System Control Block (SCB), which shares the same System Control Space (SCS) memory address range. The SCB contains features for operating system support, like an internal timer for the SysTick exception. The OS-related features will be covered in Chapter 10.

The NVIC features were explored in Chapter 3. Those features include the following:

The NVIC in the Cortex-M0 processor supports up to 32 external interrupts and one nonmaskable interrupt (NMI). The interrupt input requests can be level triggered, or they can be pulsed with a minimum of one clock cycle. Each external interrupt can be enabled or disabled independently, and its pending status can also be set or clear manually.

The NVIC control registers are memory mapped and can be easily accessed in C language. The location of the NVIC registers starts from address 0xE000E100. For the Cortex-M0 processor, the accesses to the NVIC register must be in word size. (Note that in the Cortex-M3 processor, access to the NVIC can be in the form of word, half-word, or byte transfers.)

Similar to the NVIC registers, the SCB registers are also word accessible, and the address starts from 0xE000E010. The SCB registers handle features like the SysTick timer operations, system exception management and priority control, and sleep mode control.

The Interrupt Enable control register is a programmable register that is used to control the enable/disable of the interrupt requests (exception 16 and above). The width of this register depends on how many interrupts are supported; the maximum size is 32 bit and the minimum size is 1 bit. This register is programmed via two separate addresses. To enable an interrupt, the SETENA address is used, and to disable an interrupt, the CLRENA address is used (Table 9.1).

Separating the set and clear operations in two different addresses has various advantages. First, it reduces the steps needed for enabling an interrupt, thus getting small code and shorter execution time. For example, to enable interrupt #2, we only need to program the NVIC with one access:

or in assembly,

The second advantage is that this arrangement prevents race conditions between multiple application processes that can result in the loss of programmed control information. For example, if the enable control is implemented using a simple read/write register, a read-modify-write process is required for enabling an interrupt (e.g., interrupt #2 in this case), and if between the read operation and write operation, an interrupt occurred and the ISR changed another bit in the interrupt-enabled register, the change done by the ISR could be overwritten when the interrupted program resumed.

An interrupt enable can be cleared with the use of similar code, only the address is different. For example, to disable interrupt #2, we use the following code:

Or in assembly

In normal application development, it is best to use the NVIC control functions provided in the CMSIS-compliant device driver library to enable or disable interrupts. This gives your application code the best software portability. CMSIS is part of the device driver library from your microcontroller vendor and is covered in Chapter 4. To enable or disable interrupt using CMSIS, the functions provided are as follows:

If an interrupt takes place but cannot be processed immediately—for example, if the processor is serving a higher-priority interrupt—the interrupt request will be pended. The pending status is held in a register and will remain valid until the current priority of the processor is lowered so that the pending request is accepted or until the application clears the pending status manually.

The interrupt pending status can be accessed or modified, through the Interrupt Set Pending (SETPEND) and Interrupt Clear Pending (CLRPEND) register addresses (Table 9.2). Similar to the Interrupt Enable control register, the Interrupt Pending status register is physically one register, but it uses two addresses to handle the set and clear the bits. This allows each bit to be modified independently, without the risk of losing information because of race conditions between two application processes.

The Interrupt Pending status register allows an interrupt to be triggered by software. If the interrupt is already enabled, no higher-priority exception handler is running, and no interrupt masking is set, then the interrupt service routine will be carried out almost immediately. For example, if we want to trigger interrupt #2, we can use the following code:

or in assembly,

In some cases we might need to clear the pending status of an interrupt. For example, when an interrupt-generating peripheral is being reprogrammed, we can disable the interrupt for this peripheral, reprogram its control registers, and clear the interrupt pending status before re-enabling the peripheral (in case unwanted interrupt requests might be generated during reprogramming). For example, to clear the pending status of interrupt 2, we can use the following code:

or in assembly,

In the CMSIS-compliant device driver libraries, three functions are provided for accessing the pending status registers:

Each external interrupt has an associated priority-level register. Each of them is 2 bits wide, occupying the two MSBs of the Interrupt Priority Level Registers. Each Interrupt Priority Level Register occupies 1 byte (8 bits). NVIC registers in the Cortex-M0 processor can only be accessed using word-size transfers, so for each access, four Interrupt Priority Level Registers are accessed at the same time (Figure 9.1).

The unimplemented bits are read as zero. Write values to those unimplemented bits are ignored, and read values of the unimplemented bits return zeros (Table 9.3).

Because each access to the priority level register will access four of them in one go, if we only want to change one of them, we need to read back the whole word, change 1 byte, and then write back the whole value. For example, if we want to set the priority level of interrupt #2 to 0xC0, we can do it by using the following code:

Or in assembly, we use this code:

Alternatively, if the mask value and new value are fixed in the application code, we can set the mask value and new priority level values using LDR instructions to shorten the code:

With CMSIS-compliant device driver libraries, the interrupt priority level can be accessed by two functions:

Note that these two functions automatically shift the priority level values to the implemented bits of the priority level registers. Therefore, when we want to set the priority value of interrupt #2 to 0xC0, we should use this code:

The Interrupt Priority Level Registers should be programmed before the interrupt is enabled. Usually this is done at the beginning of the program. Changing of interrupt priority when the interrupt is already enabled should be avoided, as this is architecturally unpredictable in the ARMv6-M architecture and is not supported in Cortex-M0 processor. The case is different for the Cortex-M3/M4 processor. The Cortex-M3/M4 processor supports the dynamic switching of interrupt priority levels. Another difference between the Cortex-M3 processor and Cortex-M0 processor is that the interrupt priority registers can be accessed using byte or half word transfers in the Cortex-M3, so that you can access an individual priority level setting with byte-size accesses. More details of the differences between various Cortex-M processors are covered in Chapter 21.

For users who are programming the Cortex-M0 processor using assembly language, it could be handy to have a set of generic functions for handling interrupt control in the NVIC. For C language users, a function library is already provided in the Cortex Microcontroller Software Interface Standard (CMSIS). The CMSIS is included in the device driver libraries from all major microcontroller vendors and is openly accessible. More about the CMSIS is covered in Chapter 4.

In some applications, it is necessary to disable all interrupts for a short period of time for time-critical processes. Instead of disabling all interrupts and restoring them using the interrupt enable/disable control register, the Cortex-M0 processor provides a separate feature for this usage. One of the special registers, called PRIMASK (introduced in Chapter 3), can be used to mask all interrupts and system exceptions, apart from the NMI and hard fault exceptions.

The PRIMASK is a single bit register and is set to 0 at reset. When set to 0, interrupts and system exceptions are allowed. When set to 1, only NMI and hard fault exceptions are allowed. Effectively, when it is set to 1, it changes the current priority level to 0 (the highest programmable level).

There are various ways to program the PRIMASK register. In assembly language, you can set or clear the PRIMASK register using the MSR instruction. For example, you can use the following code to set PRIMASK (disable interrupt):

You can enable the interrupt in the same way, by just changing the R0 value to 0.

Alternatively, you can use the CPS instructions to set or clear PRIMASK:

In C language, users of CMSIS device drivers can use the following function to set and clear PRIMASK. Even if CMSIS is not used, most C compilers for ARM processors handle these two functions automatically as intrinsic functions:

These two functions get compiled into the CPS instructions.

It is important to clear the PRIMASK after the time-critical routine is finished. Otherwise the processor will stop accepting new interrupt requests. This applies even if the __disable_irq() function (or setting of PRIMASK) is used inside an interrupt handler. This behavior differs from that of the ARM7TDMI; in the ARM7TDMI processor, the I-bit can be reset (to enable interrupts) at exception return because of the restoration of the CPSR. When in the Cortex-M processors, PRIMASK and xPSR are separated and therefore the interrupt masking is not affected by exception return.

The Cortex-M0 processor supports interrupt requests in the form of a level trigger as well as pulse input. This feature involves a number of pending status registers associated with interrupt inputs, including the NMI input. For each interrupt input, there is a 1-bit register called the pending status register that holds the interrupt request even if the interrupt request is de-asserted (e.g., an interrupt pulse generated from external hardware connected via the I/O port). When the exception starts to be served by the processor, the hardware clears the pending status automatically.

In the case of NMI it is almost the same, apart from the fact that the NMI request is usually served almost immediately because it is the highest priority interrupt type. Otherwise it is quite similar to the IRQs: the pending status register for NMI allows software to trigger NMI and allows new NMI to be held in pending state if the processor is still serving the previous NMI request.

Under normal situations, the interrupt latency of the Cortex-M0 processor is 16 cycles. The interrupt latency is defined as from the processor clock cycle the interrupt is asserted, to the start of the execution of the interrupt handler. This interrupt latency assumes the following:

There are some situations that can result in different interrupt latency:

These two behaviors allow interrupt latency to be reduced to a minimum. However, in some embedded applications, zero jitter interrupt response is required. Fortunately, the Cortex-M0 processor is equipped with a zero jitter feature.

On the interface of the Cortex-M0 processor, there is an 8-bit signal called IRQLATENCY, which is connected to the NVIC. This signal can be used to control the interrupt latency behavior. If this signal is connected to a 0, then the Cortex-M0 processor will start to process the interrupt request as soon as possible. If the signal is set to a specific value depending on the timing of the memory system, then it can enable the zero jitter behavior to force the interrupt latency to a higher number of cycles, but it is guaranteed to have zero jitter. The IRQLATENCY signal is normally controlled by configurable registers developed by microcontroller vendors and is not visible on the microcontroller interface.

Besides the external interrupts, some of the system exceptions can also have programmable priority levels and pending status registers. First, we will look at the priority level registers for system exceptions. On the Cortex-M0 processor, only the three OS-related system exceptions have programmable priority levels. These include SVC, PendSV, and SysTick. Other system exceptions, like NMI and hard fault, have fixed priority levels (Figure 9.9).

The unimplemented bits are read as zero. Write to those unimplemented bits are ignored. On the Cortex-M0 processor, only the System Handler Priority Register 2 (SHPR2) and SHPR3 are implemented (Table 9.4). SHPR1 is not available on the Cortex-M0 processor (it is available on the ARMv7-M architecture—for example, the Cortex-M3 processor).

Users of CMSIS-compliant device drivers can access to the SHPR2 and SHPR3 registers using the register names shown in Table 9.5.

Another NVIC register useful for system exception handling is the Interrupt Control State Register (ISCR) (Table 9.6). This register allows the NMI exception to be pended by software, and it accesses the pending status of PendSV and SysTick exceptions. This register also provides information useful for the debugger, such as the current active exception number and whether or not any exception is currently pended. Because the SysTick implementation is optional, the SysTick exception pending set/clear bits are only available when the SysTick option is presented. As a result, bits 26 and 25 of this register might not be available.

Users of the CMSIS-compliant device driver library can access ICSR using the register name “SCB->ICSR.”

Some of the fields (e.g., the ISRPREEMPT and ISRPENDING fields) in the ICSR are used by the debug system only. In most cases, application code only uses the ICSR to control or check the system exception pending status.

The NVIC address range (from 0xE000E000 to 0xE000EFFF) also covers a number of system control registers. Therefore, the whole memory range for NVIC is referred to as the System Control Space (SCS). A few of these registers are for the SysTick timer; they will be introduced in the next chapter, where the OS supporting features will be covered. Here the rest of the system control registers are introduced.