Real Time Operating Systems with KA and nKA Interrupts

This article is written by Jean J. Labrosse, RTOS Expert.

Interrupts are events generated by peripherals when they require attention; for example, an Ethernet packet was received. Interrupting devices force the CPU to jump to interrupt service routines (ISRs). If the interrupt is the event that a task is waiting for, the ISR will signal the task that will be responsible for doing most of the work needed to service the event. In other words, if the interrupt signals the availability of a packet from an Ethernet controller, then a task will service the received packet, not the ISR. This type of ISR is called a kernel aware (KA) ISR, because the ISR uses a service provided by the RTOS (a.k.a. Kernel) to signal the task about the event. The RTOS then decides whether a context switch is necessary based on the importance of the task that services the ISR.

RTOSs disable interrupts when manipulating internal data structures such as linked lists to ensure these operations are handled atomically. This means that ISRs are not triggered immediately upon receipt of the interrupt signal from the peripheral device. This delay is called interrupt latency. The amount of time it takes for the task to service the device is called interrupt response, and is also based on the priority of the task that handles the device. This delay might be acceptable if the servicing task is a low-priority task, because the RTOS always favors higher-priority tasks.

If an interrupt requires very little servicing, such as reloading a pulse width modulation (PWM) register with a new value then, the ISR can simply perform the work and not even involve the RTOS. These types of interrupts are always higher in priority than KA interrupts and are called non-kernel aware (nKA). The RTOS cannot disable these interrupts, making them highly responsive.

The difference between nKA and KA ISRs is shown below. The latency to an nKA ISR is very short (typically just a few CPU clock cycles) because the RTOS cannot disable nKA interrupts. The latency to a KA ISRs depends on how long interrupts are disabled and whether the CPU is responding to nKA interrupts or other higher-priority interrupts.

So how do you determine whether an ISR is KA or nKA? Well, that’s for the system designer to decide. Most CPUs allow interrupting devices to be assigned a priority. For instance, many of the Cortex-M MCUs (ARMv7M) use 3 bits in the Nested Vectored Interrupt Controller (NVIC) to define the priority level for an interrupting device. In other words, you can choose between 8 priority levels with priority level 0 being the highest and 7 the lowest.

Since the RTOS needs to (temporarily) ignore interrupts to access critical sections of code, it can disable interrupts from any priority by changing the BASEPRI register of the Cortex-M. This makes it easy to determine the boundary of nKA vs KA interrupts. For example, the table below shows you how you could set the nKA/KA boundary to 3. So, when accessing critical sections, the RTOS will set BASEPRI to 3 thus preventing interrupts from devices that have their interrupt priority set to 3, 4, 5, 6 or 7.

With this setup, the RTOS can be interrupted by devices that are configured to interrupt at levels 0, 1 and 2!  Again, these ISRs must not make any RTOS API calls because, by definition, they are non-kernel aware.

The KA/nKA concept is not supported by all RTOSs so you might want to consult the documentation of the RTOS you are using or, consult the manufacturer if it’s a commercial product.