Understanding priority levels of ISR and FreeRTOS APIs

As clarified by Richard Damon, that page is not Cortex-M specific and therefore, you should read those numbers as logical priorities (lesser the number, lower the priority).

As mentioned before too, this pages talks about Cortex-M priorities in detail: https://www.freertos.org/RTOS-Cortex-M3-M4.html

Getting the priority configuration right on Cortex-M is not straight forward - therefore, there are many asserts to catch incorrect configurations.


so the higher level interrupt will be masked off for the duration of the critical section

do you mean higher priority interrupts are masked off while the lower priority interrupt is executing critical section?

Yes, to give a concrete example, on a Cortex-M with the MAX_SYSCALL of 5 and 4 bits (priorities 0-Highest to 15-Lowest).
If a Priority level 14 ISR enters a critical section, the Interrupt Mask Level gets set to 5, so if a Interrupt level 8 interrupt get raised, it will be held off. When the critical section end, and the mask level restored, the interrupt will occur then.

On the other hand, if a priority level 2 interrupt comes, it will interrupt immediately.

Priority 2 will preempt immediately cause it’s got a higher priority and is not masked, but i’m not sure if this relates to your previous point about high priority interrupts getting disabled while lower priority interrupt is executing critical section.

And by high priority, I mean the ones that are not masked by the kernel (higher priority than configMAX_SYSCALL_INTERRUPT_PRIORITY