# What is config KERNEL INTERRUPT PRIORITY?

**URL:** <https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501>\
**Category:** Kernel\
**Created:** [January 10, 2021, 10:59am UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501 "2021-01-10T10:59:19Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 10, 2021, 10:59am UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/1 "2021-01-10T10:59:20Z")

</div>

The explanation on freeRTOS web is:  
_“configKERNEL\_INTERRUPT\_PRIORITY sets the interrupt priority used by the RTOS kernel itself. Interrupts that call API functions must also execute at this priority. Interrupts that do not call API functions can execute at higher priorities and therefore never have their execution delayed by the RTOS kernel activity (within the limits of the hardware itself)”_

I don’t understand what is meant by “interrupt priority used by the RTOS kernel”. Does kernel use or generate any interrupt?

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [January 10, 2021, 12:53pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/2 "2021-01-10T12:53:54Z")

</div>

The Kernel often will use a software generated interrupt to do the task switch operation (This code will be in port specific section of code. It also uses a Timer Interrupt to provide basic timing services.

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 10, 2021, 4:41pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/3 "2021-01-10T16:41:07Z")

</div>

Dear Richard-Damon,

Thanks for reply

1. AFAIK, the software interrupt which is used to trigger context switching, should be of the lowest priority. This is because task should only run when there is no other ISR running, and it is not good to perform context switching while another ISR is still running  
Is this correct?

2. If configKERNEL\_INTERRUPT\_PRIORITY is set to, for example, 0, does that mean all kernel interrupts which you mentioned (software interrupt, timer interrupt) will be at 0?

3. If the answer to 2. is yes, then next question is: If 0 is the lowest priority, setting software interrupt to priority 0 makes sense (as my understanding in 1.). But making Timer Interrupt (Tick Interrupt) at priority 0 seems not logically to me; because the counter of the time base has to increment by 1 when it needs to - any delay will render the timer tick inaccurate  
Is this correct?

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [January 10, 2021, 5:35pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/4 "2021-01-10T17:35:05Z")

</div>

Which port are you using? My answers assume a Cortex-M, but the answers will be different if that is not the case.

> [@leesp](#):
>
> configKERNEL\_INTERRUPT\_PRIORITY sets the interrupt priority used by the RTOS kernel itself. Interrupts that call API functions must also execute at this priority. Interrupts that do not call API functions can execute at higher priorities and therefore never have their execution delayed by the RTOS kernel activity (within the limits of the hardware itself)

Where did this text come from as I think it is subtly wrong for the general case, which may be because it is out of date or it may be because you are not using a Cortex-M but something like a PIC24. In the Cortex-M case interrupts that cause a context switch have to run **at or below** configMAX\_SYSCALL\_INTERRUPT priority, nothing to do with configKERNEL\_INTERRUPT\_PRIORITY.

> [@leesp](#):
>
> AFAIK, the software interrupt which is used to trigger context switching, should be of the lowest priority. This is because task should only run when there is no other ISR running, and it is not good to perform context switching while another ISR is still running  
> Is this correct?

Tasks can only run when there is no ISR running - that is a hardware thing, FreeRTOS, as software, can’t change that.

Again, specific to the Cortex-M, configKERNEL\_INTERRUPT\_PRIORITY should be the lowest priority because it sets the priority of the interrupt that performs the context switch. In a system in which interrupts nest you want the entire nesting of interrupts to unwind before performing a context switch - rather than allowing each interrupt in the potentially nested stack of interrupts perform context switches.

> [@leesp](#):
>
> If configKERNEL\_INTERRUPT\_PRIORITY is set to, for example, 0, does that mean all kernel interrupts which you mentioned (software interrupt, timer interrupt) will be at 0?

In the Cortex-M there are only two interrupts used by the kernel - SysTick and PendSV - and both are set to configKERNEL\_INTERRUPT\_PRIORITY. However, again you answer makes me suspicious you are not using a Cortex-M as if you were 0 would be the highest priority, not the lowest, and you cannot set configKERNEL\_INTERRUPT\_PRIORITY to 0.

> [@leesp](#):
>
> But making Timer Interrupt (Tick Interrupt) at priority 0 seems not logically to me; because the counter of the time base has to increment by 1 when it needs to - any delay will render the timer tick inaccurate  
> Is this correct?

It is not such a strict requirement to make the tick interrupt the lowest priority, but it is best to do so so the tick count changing doesn’t change the logic path half way through an ISR, and to ensure interrupts that may be higher priority are not delayed (the RTOS doesn’t know what the application is doing, so application interrupts may be more important). It would only start to become an issue with timing if interrupts were disabled for more than one entire tick period - so two ticks were missed as the processor can only hold one pending. If interrupts are disabled for that length of time then I suspect there will other issues in the application design anyway.

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 12, 2021, 2:51pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/5 "2021-01-12T14:51:21Z")

</div>

> [@leesp](#):
>
> configKERNEL\_INTERRUPT\_PRIORITY

Dear Richard,

> > Which port are you using?

I am using RX600 port. Interrupt priority 0 is of lowest priority

> > Where did this text come from as I think it is subtly wrong for the general case, which may be because it is out of date or it may be because you are not using a Cortex-M but something like a PIC24.

I apologise for taking information out of context. The complete explanation on [freertos.org](http://freertos.org) is:  
_"For ports that only implement configKERNEL\_INTERRUPT\_PRIORITY_  
_configKERNEL\_INTERRUPT\_PRIORITY sets the interrupt priority used by the RTOS kernel itself. Interrupts that call API functions must also execute at this priority. Interrupts that do not call API functions can execute at higher priorities and therefore never have their execution delayed by the RTOS kernel activity (within the limits of the hardware itself)._

_For ports that implement both configKERNEL\_INTERRUPT\_PRIORITY and configMAX\_SYSCALL\_INTERRUPT\_PRIORITY:_  
_configKERNEL\_INTERRUPT\_PRIORITY sets the interrupt priority used by the RTOS kernel itself. configMAX\_SYSCALL\_INTERRUPT\_PRIORITY sets the highest interrupt priority from which interrupt safe FreeRTOS API functions can be called."_

And I understand your explanation. Thank you

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 19, 2021, 4:43pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/6 "2021-01-19T16:43:45Z")

</div>

Still a bit unclear about the statement below in italic. I understand that:  
i) If a port implements only configKERNEL\_INTERRUPT\_PRIORITY, then in a critical section, all interrupts will be blocked  
ii) If a port implements both configMAX\_SYSCALL\_INTERRUPT\_PRIORITY and configKERNEL\_INTERRUPT\_PRIORITY, then in a critical section, only interrupts which has the priority in between these two priorities, will be blocked

But in:  
_"For ports that only implement configKERNEL\_INTERRUPT\_PRIORITY_  
_configKERNEL\_INTERRUPT\_PRIORITY sets the interrupt priority used by the RTOS kernel itself. Interrupts that **call API functions** must also execute at this priority. Interrupts that **do not call API functions** can execute at higher priorities and therefore never have their execution delayed by the RTOS kernel activity (within the limits of the hardware itself)."_

- Why is it that “Interrupts that call API functions must also execute at this priority”? Is there an example? What is the treatment different between interrupts which **call** , and **don’t call**  
, API functions?

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [January 19, 2021, 5:00pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/7 "2021-01-19T17:00:32Z")

</div>

I think this is because ports that only implement one of those constants tend to be on much simpler processors that don’t have many priority levels. It is not relevant to the RX port you are using though.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [January 19, 2021, 9:10pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/8 "2021-01-19T21:10:36Z")

</div>

> Why is it that “Interrupts that call API functions must also execute at this priority”? Is there an example? What is the treatment different between interrupts which **call** , and **don’t call** , API functions?

For the discussion below, lets make the following assumptions:

1. Numerically higher priority interrupts have logically higher priority (i.e. priority 2 interrupt can preempt priority 1 interrupt handler).
2. The port implements `configKERNEL_INTERRUPT_PRIORITY` and `configMAX_SYSCALL_INTERRUPT_PRIORITY`.

FreeRTOS critical sections disable interrupts up to `configMAX_SYSCALL_INTERRUPT_PRIORITY`. Critical sections are the sections of code which manipulate FreeRTOS internal data structures and therefore, any other FreeRTOS API **must not** be called when the code is in a critical section (otherwise FreeRTOS internal data structures may get corrupted).

Lets say you have 5 interrupts and `configMAX_SYSCALL_INTERRUPT_PRIORITY` is 3.

```auto
                                         ^ +------------+
                                         | | IRQ1 |
                                         | | |
                                         | +------------+
        Blocked during critical section | | IRQ2 |
                                         | | |
                                         | +------------+
                                         | | IRQ3 |<------- configMAX_SYSCALL_INTERRUPT_PRIORITY
                                         v | |
                                        ---+------------+
                                         ^ | IRQ4 |
                                         | | |
    Not blocked during critical section | +------------+
                                         | | IRQ5 |
                                         | | |
                                         v +------------+

```

When FreeRTOS kernel is in a critical section, IRQ1, IRQ2 and IRQ3 are blocked but IRQ4 and IRQ5 are not. So when the code is in a critical section:

- If IRQ1, IRQ2 or IRQ3 happens, the corresponding ISR will not be executed until the code exits the critical section.
- If IRQ4, or IRQ5 happens, the corresponding ISR will be executed immediately and the critical section will be interrupted.

```auto
           Critical Critical
            Section IRQ3 Section ISR3
             Starts active Ends starts
                  ^ ^ ^ ^
                  | | | |
                  | | | |
                  | | | |
          --------+--------------+------------+-+----------------------
                            ---- Increasing time ---->

                            IRQ4 ISR4 ISR4
                           active starts ends
                                ^ ^ ^
           Critical | | | Critical
            Section | | | Section
             Starts | | | Resumes
                  ^ | | | ^
                  | | | | |
                  | | | | |
                  | | | | |
          --------+-------------+-+-------+-+-----------------------
                            ---- Increasing time ---->

```

If ISR for IRQ1, IRQ2 or IRQ3 calls a FreeRTOS API, it will be okay as it will not interrupt a critical section. But if ISR for IRQ4 or IRQ5 calls a FreeRTOS API, that API may be called at a time when the code is in a critical section which will lead to data corruption.

Hope it helps.

Thanks.

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 20, 2021, 4:02am UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/9 "2021-01-20T04:02:50Z")

</div>

Dear Gaurav,

“_FreeRTOS critical sections disable interrupts up to configKERNEL\_INTERRUPT\_PRIORITY_”  
I thought if only configKERNEL\_INTERRUPT\_PRIORITY is used, then in critical section, **all** interrupts are disabled? And when configMAX\_SYSCALL\_INTERRUPT\_PRIORITY is used, then critical sections disable interrupts up to configMAX\_SYSCALL\_INTERRUPT\_PRIORITY itself?

“_Critical sections are the sections of code which manipulate FreeRTOS internal data structures…_”  
I thought in taskEnterCritical(), the only thing happening in there is that the interrupts got disabled? I cannot find anywhere in taskEnterCritical() that manipulates FreeRTOS internal data structure

Please correct me if I am wrong: I think it should be like below:

```auto
                                         ^ +------------+
                                         | | IRQ1 |
                                         | | |
                                         | +------------+
        Blocked during critical section | | IRQ2 |
                                         | | |
                                         | +------------+
                                         | | IRQ3 |<------- **configMAX_SYSCALL_INTERRUPT_PRIORITY**
                                         v | |
                                        ---+------------+
                                         ^ | IRQ4 |
                                         | | |
    Not blocked during critical section | +------------+
                                         | | IRQ5 |
                                         | | |
                                         v +------------+

```

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [January 20, 2021, 4:46am UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/10 "2021-01-20T04:46:30Z")

</div>

> I thought in taskEnterCritical(), the only thing happening in there is that the interrupts got disabled? I cannot find anywhere in taskEnterCritical() that manipulates FreeRTOS internal data structure

Critical section is the code that executes after a call to `taskEnterCritical()` and before a call to `taskExitCritical()`. It is that code which manipulates FreeRTOS data structures. An example is this function which updates FreeRTOS tasks ready list after calling `taskEnterCritical()` (i.e. after entering critical section): [https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L1068](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L1068)

And yes, you are right and I updated my answer (for others reference).

Thanks.

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 20, 2021, 3:41pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/11 "2021-01-20T15:41:17Z")

</div>

Hi Gaurav/Richard,

I think I understand now. Let me summarize, and correct me if I am wrong:

1. While Kernel is running, it should not be interrupted by interrupt which calls FreeRTOS API function. It can be, however, be interrupted by interrupt which does not call API functions. This is because Kernel has critical sections, and interrupting Kernel’s critical sections with an interrupt which calls FreeRTOS API will potentially cause data corruption

2. In a port which implements both configKERNEL \_INTERRUPT\_PRIORITY and configMAX\_SYSCALL\_INTERRUPT\_PRIORITY: when Kernel is running, IPL (in case of RX port) is set (by the Kernel code) to configMAX\_SYSCALL\_INTERRUPT\_PRIORITY, such that only interrupts having priority high than this, are able to interrupt the Kernel

3. Therefore, when assigning priority level to a interrupt, user should check whether it calls API function or not. If it does not, then it can be assigned priority higher than configMAX\_SYSCALL\_INTERRUPT\_PRIORITY. If the interrupt does call API function, than its assigned priority cannot be higher than configMAX\_SYSCALL\_INTERRUPT\_PRIORITY; because if otherwise, this interrupt (which calls API function) is able to interrupt the Kernel (which violates 1. above)

---

<div class="post-metadata">

**Author:** ![leesp](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@leesp](https://forums.freertos.org/u/leesp)\
**Post date:** [January 20, 2021, 3:53pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/12 "2021-01-20T15:53:15Z")

</div>

Question:  
Application can also have critical sections. Is it safe to interrupt application’s critical section with an interrupt which calls FreeRTOS API function?

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [January 20, 2021, 4:02pm UTC](https://forums.freertos.org/t/what-is-config-kernel-interrupt-priority/11501/13 "2021-01-20T16:02:56Z")

</div>

> [@leesp](#):
>
> I think I understand now. Let me summarize, and correct me if I am wrong:

That is correct.

> [@leesp](#):
>
> Application can also have critical sections. Is it safe to interrupt application’s critical section with an interrupt which calls FreeRTOS API function?

If critical sections in the application mask interrupts up to the priority set by configMAX\_INTERRUPT\_PRIORITY, and interrupts that use API functions can only run at priorities configMAX\_INTERRUPT\_PRIORITY and below, then an interrupt calling an API function cannot interrupt a critical section in the application because it would be masked. That is the whole point.