What is config KERNEL INTERRUPT PRIORITY?

Kernel
8

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.

                                         ^ +------------+
                                         | |  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.
           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.

3 Likes