Using FreeRtos on board atmel D51, I don’t manage to set IRQ priority such that I can call few “xxxFromISR()” function from interrupt handler. I keep being stuck on the assert configASSERT(ucCurrentPriority >= ucMaxSysCallPriority); (ucCurrentPriority is 0, ucMaxSysCallPriority is 128) I know that this is kind of classical problem, however despite various reading both on FreeRTOS and ATMEL side discussing trouble around this, I don’t manage to fix this. My FreeRTOS config looks correct (can share some part if required). I’m setting the priority of my IRQ (41) to configLIBRARYMAXSYSCALLINTERRUPTPRIORITY (128) and from what I can check with the debugger, it works. (uisng CMSIS NVIC_SetPriority() function) My interrupt handler is called when interrupt is triggered; however, when calling some FreeRTOS FromISR routine from there, the interrupt priority seen is not the one set (still 0). NVIC prio table is still correct; That’s why I’m missing something: the IRQ prio set seems not to be the one expected by FreeRTOS. Can anyone advise on what I’m missing ? Thanks

I presume this is the page you are referring to? https://www.freertos.org/RTOS-Cortex-M3-M4.html

I’m setting the priority of my IRQ (41) to configLIBRARYMAXSYSCALLINTERRUPTPRIORITY (128)

Which is hex 0x80, or binary 1000 0000, so basically a value that has already been shifted to the most significant bits (see link above). I would need to know the value of __NVICPRIOBITS to know what logical priority that represented.

(uisng CMSIS NVIC_SetPriority() function)

Not a function I use myself, but if I recall correctly, this function requires the logical interrupt priority BEFORE it is shifted up to the most significant bits. Hence – your code is not going to work – but you knew that already ;o) Basically you are mixing the way the priority registers want the priority to be specified (priority value in the most significant bits) with the way the function being used to set the priority wants the value to be specified (priority value in the least significant bits).

I presume this is the page you are referring to? https://www.freertos.org/RTOS-Cortex-M3-M4.html

Yes, one of them indeed.

I would need to know the value of __NVICPRIOBITS to know what logical priority that represented.

It is set to 3 (which match the datasheet)

Not a function I use myself, but if I recall correctly, this function requires the logical interrupt priority BEFORE it is shifted up to the most significant bits. Hence – your code is not going to work – but you knew that already ;o) Basically you are mixing the way the priority registers want the priority to be specified (priority value in the most significant bits) with the way the function being used to set the priority wants the value to be specified (priority value in the least significant bits).

Indeed, I’m more or less aware of this without knowing which one is correct as none of my trials works: my understanding is that I should set a priority >= 4 (which is 100 in 3-bits binary). But whatever the value I used when calling NVIC_SetPriority() (128, 3, 5, 7, …), I always fall into the assert with ucCurrentPriority == 0 . Also, I noticed that even if in the callstack, I can see that I’m in my interrupt handler (of interrupt number 41), in FreeRTOS level, the prority that is looked up here (when the assert failed): ucCurrentPriority = pcInterruptPriorityRegisters[ulCurrentInterrupt]; is number 37 (ulCurrentInterrupt == 37) and priority is 0 Here, I’m missing the point about how IRQ 41 becomes 37 when coming here ? Second point is that if I look at the other entries in the table pcInterruptPriorityRegisters, I don’t see any that seems to be the one I set with NVIC_SetPriority() ? Thanks,

I don’t think you mentioned which version of FreeRTOS you are using. Can you ensure you are using the very latest official release as that contains the most configASSERT() calls to check nearly everything, maybe even everything, that can be mismatched between your configuration and the hardware. That might catch something at initialisation time.

I found my mistake: I’m using an external interrupt controller and 41 is the IRQ number in the EIC, but not the one seen by NVIC. Using 41 in NVIC routine was my mistake. My bad, thanks anyway !

Appreciate you taking the time to report back.