xEventGroupWaitBits() and xEventGroupSetBitsFromISR() APIs

I am using xEventGroupWaitBits() and xEventGroupSetBitsFromISR() APIs in project, In ISR: xResult = xEventGroupSetBitsFromISR(xI2CEventGroupHandle, I2CEVENTISR, &xHigherPriorityTaskWokeni2c ); if( xResult != pdFAIL ) { portENDSWITCHINGISR(xHigherPriorityTaskWokeni2c); } in Task process: uxBitsI2C = xEventGroupWaitBits(xI2CEventGroupHandle, 0xF, pdTRUE, pdFALSE, pdMSTOTICKS(5)); if (uxBitsI2C & I2CEVENTISR) { // process: } results are not expected occasionally, mostly, this pair works, but sometimes, 1: xEventGroupSetBitsFromISR() is called in ISR, but xEventGroupWaitBits() never gets bit set in uxBitsI2C occasionally, so task process is missed; 2: since 5ms waiting in max (pdMSTOTICKS(5)), but uxBitsI2C gets set after 25ms occasionally, delay too long to process;

xEventGroupWaitBits() and xEventGroupSetBitsFromISR() APIs

Setting a bit in an event group is not a deterministic operation because you don’t know in advance how many tasks will get unblocked. Therefore the operation is actually deferred to the RTOS daemon task (also known as the timer task). That means the daemon task must execute before the bits get set. The priority of the daemon task is set by the configTIMERTASKPRIORITY setting in FreeRTOSConfig.h. What is its priority compared to the other tasks in your system? What happens if you set configTIMERTASKPRIORITY to (configMAX_PRIORITIES – 1), which is the highest possible priority, and all your other tasks have a lower priority? Doing that would ensure the timer task was always the task returned to from the interrupt if posting to the event group caused a task to unblock.