xEventGroupWaitBits returns 0x00ffffff

I have 2 tasks running, task A sets task B last bit to 1. xEventGroupSetBits is used. This works and xEventGroupWaitBits exits with 1 as the value of bits. The second time, xEventGroupSetBits is used again to set the last bit to 1. This time, xEventGroupWaitBits on the other side returns 0x00ffffff. I notice a pattern where the first time always the second time is incorrect. Please help.

Please post the code used to create the event group, as well as the code where the event group is written to (set bits) and read from (wait bits).

This is the wait in task B

*pEvent = xEventGroupWaitBits(
This is the set in task A
		uxBits = xEventGroupSetBits(

*pEvent is alternately valid, and invalid. When invalid, it is 0x00ffffff. When valid it is 1.

NOTE: event_ptr is stored in a global table with enum index for each task to find the other’s event group. This global table access is locked with a semaphore

Please also show how the event group is created (how event_ptr is set - as it is a handle).

Sorry - one more thing, what is configUSE_16_BIT_TICKS set to?

configUSE_16_BIT_TICKS = 0 in freeRTOSConfig.h

In case you didn’t see this one above.

xCreatedEventGroup = xEventGroupCreate();
uxBits = xEventGroupSetBits(
xCreatedEventGroup, /* The event group being updated. /
The bits being set. */
evthandle = (LX_OS_Evt_Handle_t *) lx_malloc_clean(sizeof(LX_OS_Evt_Handle_t));
evthandle->event_ptr = xCreatedEventGroup;

NOTE: evthandle is stored in global mutex locked table. When retreived using an enum, the event ptr is used to set the bits.

Yes pardon the delay I appreciate your help. Our project is depending on this feature to work

On further debugging, I found that the 0x00ffffff is obtained whenever there is a timeout. So the set is just not awaking the other end, it just eventually times out.

This is very strange - is there any further information you can provide, for example, is this a C or C++ application?

Have you followed all the tips here https://www.freertos.org/FAQHelp.html , including having configASSERT() defined?

Hi there. It is a C application. The events are being set, but the wait is not receiving the set. It’s a show stopper for us. I have configASSERT as this
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

MORE info: I notice that the first 2 event sets/wait succeed, then the third one gets a 0x00ffffff. Then the next 2 sets/wait succeed and the next one receives a 0x00ffffff. So there is a pattern.

I can’t see anything in the code that could set all the bits to 1 (to create the 0x00ffffff value, the top byte being control bits rather than event bits).

So it’s a mystery :=( I forgot to mention that the task setting the bits is timer task. The task waiting for the bits is a normal task. Should I be using the “ISR” version of GroupWaitBits ?

So far., I narrowed it down to just these 2 tasks one setting the bit, the other waiting on the bit. Task 1 is setting value to 2. Task 2 is waiting for any bit to be set. (as already mentioned)
timer task (task 1) breakpoint keeps breaking on the set logic in the timer code, which runs every 250ms. It does not hit the code that is waiting until it hits the set logic 40 times.

  1. timer task set group bits = breaks here 40 times
  2. task waiting on wait group bits = breaks 1 time after the #1 occurs 40 times (1 second, and it’s all 0x00ffffff)

GOOD NEWS! I think I found the problem!!
This call

I changed to
and it works!!!

Great - thanks for reporting back. Do you have configASSERT() defined, I would have thought it would have caught that.

Hi! Yes configASSERT was defined like so
define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
This was a huge mystery because instead of asserting, the call hung and occasionally came back with 0x00ffffff

If I might piggy back another question - Can the xGroupSetBits be called from a timer task? Does it need to be an ISR?

Yes it can be called from the timer task. It definitely should NOT be called from an ISR - if that was what you were doing then it might explain the erratic behaviour. This is the version to call from an ISR: https://www.freertos.org/xEventGroupSetBitsFromISR.html