Program stuck at "configASSERT" whilst calling "vTaskNotifyGiveFromISR", might be caused by interrupt nesting

System:STM32WB55CE, 256KB RAM, 512KB Flash, M4F core clock @ 32Mhz

Hello, I’m kind of new to FreeRTOS and couldn’t find solutions which will tackle this specific problem.

I used to call “vTaskNotifyGiveFromISR” from an EXTI ISR, everything was fine even though I had no idea whether the EXTI ISR’s priority is lower than configMAX_SYSCALL_INTERRUPT_PRIORITY or not.

Now I’m calling it from another ISR, and I don’t think there is ISR nesting involved but I could be wrong, so here’s my description:

2 ISRs. One EXTI (key stroke), another being a timer (TIM2). The EXTI ISR basically changes the timer’s counter register and then exits (which is why I believe no isr nesting is involved), and then the timer2 fires, and that’s where “vTaskNotifyGiveFromISR” is called.

There is a catch, when EXTI interrupt is triggered, the EXTI is masked, and will be unmasked in the timer2 ISR, or in other words, the masking and unmasking are done in different ISRs, which is why I suspect there might be a tiny bit of “nesting” involved… anyway please don’t let this tiny detail influence you more than it should.

When calling “vTaskNotifyGiveFromISR” from the timer ISR, the program failed the assertion “configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );”.

There’s a nice comment above this assertion that basically says:

The following assertion will fail if a service routine (ISR) for
an interrupt that has been assigned a priority above
function. ISR safe FreeRTOS API functions must only be called
from interrupts that have been assigned a priority at or below

My questions are:

  1. How do I solve this?
  2. Is it a good idea to simply change the priority of my timer ISR? I’m concerned that straightforward solutions aren’t always the best, and I’m prepared and willing to not call the “vTaskNotifyGiveFromISR” from my timer ISR at all

Please feel free to provide any insight but please don’t give me an overly simplified solution (unless there is nothing more to it) which may cause future setbacks!

You’ve to take care and set interrupt priorities correctly i.e. logically less than or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY if your ISRs make use of the FreeRTOS - API. That’s all about it.
You don’t really need to take care about nesting at least regarding FreeRTOS.
To get interrupt prios right e.g. on Cortex-M3/4/7 please see

Your comment that “I had no idea whether the EXTI ISR’s priority is lower than configMAX_SYSCALL_INTERRUPT_PRIORITY or not.” make me think you haven’t set it priority, which likely means It is at priority 0 which is logically too high, so you hit the assert. On Cortex-M machines, you basically MUST setup the priority of every interrupt you will be using.

1 Like

Problem a-solved! Thank you!