Priorities assert in vPortValidateInterruptPriority


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:

	BaseType_t xHigherPriorityTaskWoken;
	xSemaphoreGiveFromISR ( Tx_mutex,&xHigherPriorityTaskWoken );
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );

the call to xSemaphoreGiveFromISR fails in port.c on vPortValidateInterruptPriority():

	configASSERT(ucCurrentPriority >= ucMaxSysCallPriority);

where ucCurrentPriority is 0, and ucMaxSysCallPriority is 128.

Any help, please?

See RTOS for ARM Cortex-M and e.g. this post Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg (there are more here in the forum) for the necessary details to setup interrupt priorities (on Cortex-M) right.
INT prio 0 is definitely wrong to be used with FreeRTOS API calls in the corresponding ISR.

And a priority of 0 likely means that it was never set, or was set with the priority bits in the wrong part of the number.

Additional info

Thanks for the answers.

Should I call NVIC_SetPriority() like this?


In my FreeRTOSConfig.h configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY is defined as 4.

#define configPRIO_BITS 3

then the priority of an interrupt routine could be between 4 and 7 (both inclusive).
Between 0 and 3 (both inclusive) will be reserved for FreeRTOS.

Did I get it right? :slightly_smiling_face:

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.