xTaskGenericNotifyFromISR() is not working if called twice in ISR before unblocking happens

I have encountered following scenario in which tasks notification from ISR stops working :

  1. I Have 2 interrupts
    a) EXTI: First one is external interrupts which enables a immediate timer(TIM) interrupt.
    b) TIM: second one is an immediate timer interrupt enabled by EXTI interrupts.

  2. I am calling xTaskNotifyFromISR() from timer interrupt (TIM)

  3. which is unblocking one of my task using ulTaskNotifyTake();

Now what’s happening is : my EXTI interrupt is quite fast and before the execution of ulTaskNotifyTake() unblocking, Timer interrupt is executing xTaskNotifyFromISR() again.
This changes ucOriginalNotifyState to taskNOTIFICATION_RECEIVED in function xTaskGenericNotifyFromISR of tasks.c
and somehow unblocking of ulTaskNotifyTake() doesnt happen.

any clue ?

xTaskResumeAll lockup - Kernel - FreeRTOS Community Forums

1 Like

From your description it seems that when two notifications are received in quick succession from the interrupts, the second notification is missed before the task acting upon it unblocks itself. If so did you try using xTaskNotifyFromISR() with action eIncrement and on the receiving task use ulTaskNotifyTake() with xClearCountOnExit parameter to pdFALSE ? This will essentially use task notification as a counting semaphore and ulTaskNotifyTake() will block only when count reaches 0.

This page provides details and examples for the technique that Ravi described - FreeRTOS task notifications, fast Real Time Operating System (RTOS) event mechanism

1 Like

Hi ,
Thanks!!
Issue is because RTOS taskENTER_CRITICAL(); is not able to disable the interrupt in role.
Thing is i am using a trustzone enabled code.
My RTOS scheduler is running in non-secure section and interrupts are configured in secure section.
Now taskENTER_CRITICAL(); writes BASEPRI_NS registers with configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY .

# define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 8
my interrupt priority is 10.

if i am configuring my interrupt priority as 12 , taskENTER_CRITICAL(); disables this interrupt.

I am guessing since my interrupt is secure one it is using BASEPRI_S during IRQ triggering.
If so , how can i mask BASEPRI_S with configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ??

using ARM cortexM33

That assumption does not seem correct. Which Cortex-M33 part are you using? How many priority bit your hardware implements? Can you share your complete FreeRTOSConfig.h?

FreeRTOSConfig.h (8.7 KB)
I am working on STM32U575 device ARM Cortex-M33.
__NVIC_PRIO_BITS is 4 for this .
And i am using priority grouping NVIC_PRIORITYGROUP_4

Also i found this forum
https://community.arm.com/support-forums/f/architectures-and-processors-forum/8764/correct-way-to-mask-interrupts-in-secure-world-armv8m-m33

which says : “If BASEPRI_NS is set to 0x80, and if PRIS is set to 1, it blocks Secure interrupts with priority levels 0xC0 to 0xFF
this is what happening with me , i am able to disable interrupts having priority >= 0xC0
now what i require is how can i disable secure interrupts from 0x01 to 0xFF !!!

Why do you need to disable secure interrupts? Since you are calling FreeRTOS functions from ISR, you need to configure this EXTI interrupt as non-secure.

Because my application requires this interrupt to be in secure side.
But as i am able to disable this interrupt when its priority is >= 12 ,why is not working for lesser priority.

Basically, the hardware doesn’t allow non-secure code to disable certain interrupts priorities so that the secure side can make sure it isn’t interfeared with by using those interrupt priorites

If that is the case, you cannot call any FreeRTOS API from this ISR and then you do not need to disable this interrupt. May I please ask you to elaborate on why your application needs this interrupt to be secure and still need to interact with FreeRTOS running on the non-secure side.

Let me try to explain this. When Secure Exception Priority Boosting is enabled (i.e. PRIS is set, which is the case for FreeRTOS), non-secure interrupt priorities are mapped to the bottom half of the priority range. As a result, you can only mask the bottom -half priority interrupts from the non-secure side.

1 Like