Task not running after vTaskNotifyGiveFromISR

Hi there FreeRTOS team!

I’m having a problem with a task not running after an interrupt.

This is a FreeRTOS project running on ESP32 microcontroller which has 2 CPUs. I have an interrupt to trigger a GPIO input.

static void IRAM_ATTR encoderIntCallBack()
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    vTaskNotifyGiveFromISR(rotatory_reader_task_handle, &xHigherPriorityTaskWoken);
    if (xHigherPriorityTaskWoken)
    {
        portYIELD_FROM_ISR();
    }
}

I added a counter++ in this interrupt and can confirm the number of times I trigger the GPIO equals the counter.
The problem is that the task that should be triggered after this interrupt doesn’t trigger every time.
I’ve about 10 tasks split into core 0 and core 1. All these tasks are using ulTaskNotifyTake(pdTRUE, portMAX_DELAY); to wait for notifications, so I’m pretty sure no other tasks are running at the same time the GPIO task should run.

Any idea on how can I debug this?

Thanks a lot in advance

@juanpgg

All these tasks are using ulTaskNotifyTake(pdTRUE, portMAX_DELAY); to wait for notifications, so I’m pretty sure no other tasks are running at the same time the GPIO task should run.

You are calling ulTaskNotifyTake with xClearCountOnExit as pdTRUE.

[refer - ulTaskNotifyTake]

If an RTOS task notification is received and xClearCountOnExit is set to
pdTRUE then the RTOS task’s notification value is reset to 0 before ulTaskNotifyTake()
exits. This is equivalent to the value of a binary semaphore being left at zero (or empty, or ‘not available’) after a successful call to xSemaphoreTake().

The ISR handler encoderIntCallBack might be calling the vTaskNotifyGiveFromISR multiple times, causing the notification value to be incremented, but the notification value instead of being decremented is reset as xClearCountOnExit is set when ulTaskNotifyTake is called.

How did you verify that? Also, please share your findings after changing ulTaskNotifyTake call to ulTaskNotifyTake(pdFALSE, portMAX_DELAY); as @tony-josi-aws suggested.