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.
Thanks.
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
This is how I understand it.
If we now have 2 tasks and 6 interrupts, among which, and when interrupts 4, 5, 6 are running, they will call the safe freertos api.
Just like (1) in the picture.
So now if we are executing task 1 or task 2, interrupt 5 is triggered, and it will do what it needs to do in the callback, including calling the safe freertos api, and during the execution, it will enter the critical section to block all interrupts and tasks with a lower priority than it (for now, let’s not consider the MAX_SYSCALL_INTERRPUT_PRIORITY mechanism in FreeRTOS, that is, it will not block interrupts 1~4).
Just like (2) in the picture.
Moving forward, when interrupt 5 calls the safe freertos api and is in the process of execution, interrupt 4 is triggered at this time, it will preempt interrupt 5 execution, and further call the safe freertos api. At this time, I guess that interrupt 5 involves the operation of the freertos kernel (because of preemption, only half of it is executed) will lose protection, causing serious irreversible effects (there may be problems with context scheduling and task management).
Just like (3) in the picture.
So now let’s go back to the beginning. If there is MAX_SYSCALL_INTERRPUT_PRIORITY in FreeRTOS The mechanism exists. During the execution of interrupt 5, all interrupts below MAX_SYSCALL_INTERRPUT_PRIORITY will be blocked, so the accident caused by the interrupt 4 preemption execution mentioned above will not happen.
Just like (4) in the picture.
Then, you will definitely ask, what about interrupts 1~3, will they be blocked? The answer is: No. Then will they call the safe freertos api and the above mentioned accident will not happen? This is the problem I encountered recently, and now I know the answer. There is a MAX_SYSCALL_INTERRPUT_PRIORITY mechanism in FreeRTOS. Interrupts above MAX_SYSCALL_INTERRPUT_PRIORITY will not allow you to call the safe freertos api (if you call it, the code will not pass the compilation due to the existence of the reertos assertion), so there will be no accident.
This is my own understanding. If you find any errors, please leave a message to reply.
Thank you writing in detail. Your understanding is mostly correct, just a minor correction:
The above is true when the FreeRTOS API explicitly enters a critical section by calling taskENTER_CRITICAL_FROM_ISR:
void FreeRTOS_API_FromISR( void )
{
/* Priority 4 interrupt is NOT blocked here. */
taskENTER_CRITICAL_FROM_ISR();
{
/* Priority 4 interrupt is blocked here because all the interrupts upto
* configMAX_SYSCALL_INTERRPUT_PRIORITY are blocked here. */
}
taskEXIT_CRITICAL_FROM_ISR();
/* Priority 4 interrupt is NOT blocked here. */
}
That’s right, I overlooked this detail in my discussion, thank you for your reply.