I’m using Atmel Studio 7.0 and AtmelStart to create a project on a ATSAMV71-XULT board.
I’ve created a project with FreeRTOS 10.0 and in a UART ISR when I try:
This would be ok and give the UART0_IRQn the highest possible interrupt priority covered by FreeRTOS.
NVIC or numerical interrupt priorities 4…7 can be used for interrupts calling FreeRTOS API (note the FromISR versions of the API) in their corresponding ISRs with numerical prio 7 being the logically lowest priority.
Interrupts with priorities 0…3 are outside the scope of FreeRTOS (they are not disabled/enabled by FreeRTOS critical sections) and could also be used but in their corresponding ISRs FreeRTOS API calls are NOT allowed.
The only thing to add to Hartmut’s very concise explanation is that there is a reason for the counter intuitive “backward” priority numbering in the Cortex M kernel: The highest configurable prio is 0 because there are three higher priority, non maskable ISRs - the Reset Interrupt (-3), NMI (-2) and Hard Fault (-1). Since Cortex PODs are allowed to support differing counts of ISR priorites, it would be very cumbersome to have to renumber those three on top of a PODs implemented count if priorites were numbered 0 (low) to x (high) which would be more intuitive.
One small comment, priorities 0 to 3 are not reserved for use by FreeRTOS, as FreeRTOS will not use those priorities. They are reserved for use by user interrupts that will not directly interact with FreeRTOS and will not be blocked by FreeRTOS critical sections.