Task Priorities Limitations

[hs2 (Hartmut Schaefer)]

Don’t mix up (logical) FreeRTOS task priorities and HW specific interrupt priorities. These are different and independent things.
However, when using FreeRTOS calls in ISRs (the API tagged with FromISR) some constraints come into play due to so called critical sections in the FreeRTOS code and also in application code.
Critical sections are implemented in FreeRTOS by disabling interrupts.
For CPUs like Cortex-M3/4 etc. supporting interrupt priorities only the relevant part of the interrupt priorities are disabled allowing to use interrupts/ISRs at higher priority but without any FreeRTOS API call. These interrupts are never disabled and the corresponding ISRs would provide even harder real-time behavior. In other words there is no jitter invoking the ISR on interrupt caused by (very short) critical sections. Except there are some more of those interrupts with even higher interrupt priority, of course.
Hope it helps a bit

Since Renesas RA family also have a Cortex-M CPU see this related documentation:

RTOS for ARM Cortex-M

and this very good forum posts:

What is config KERNEL INTERRUPT PRIORITY?

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: Numerically higher priority interrupts have logically higher priority (i.e. priority 2 interrupt can preempt priority 1 interrupt handler). The port implements configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIO…

Understanding priority levels of ISR and FreeRTOS APIs

A pictorial representation, if that helps: Logical Numerical Priorities Priorities +--------+ +-------+ ^ | | | | | | | | | | | | | | | Not masked by FreeRTOS kernel | Higher | | Lower | | ( FreeRTOS APIs can not be | | | | | called from these ISRs. ) …