EventGroupsDemo is failing

I am using FreeRTOS v10.1.1, IAR Embedded Workbench 8.42.1, and running on a Nordic NRF52833. EventGroupsDemo.c has been converted to use static allocation to match our project configuration.

Function prvSyncTask() attempts 3 calls of xEventGroupSync() with block times of 0, 1, and 0xffffffff. All bits of ebALL_SYNC_BITS are unexpectedly set after call of xEventGroupSync with block time of 1 tick.

All bits of ebALL_SYNC_BITS are unexpectedly set after call of xEventGroupSync with block time of 1 tick.

ebALL_SYNC_BITS is just a define. Do you mean that this assert failing for you: https://github.com/FreeRTOS/FreeRTOS/blob/master/FreeRTOS/Demo/Common/Minimal/EventGroupsDemo.c#L314?

Also, would you please share the changes you have made?

Thanks.

Correct, that assert is failing. As a new user I am blocked from upload.

NEW:

static StaticTask_t xTCBBufferSlave, xTCBBufferMaster;
static StaticTask_t xTCBBufferSync1, xTCBBufferSync2;
static StackType_t uxStackSlave[ configMINIMAL_STACK_SIZE ];
static StackType_t uxStackMaster[ configMINIMAL_STACK_SIZE ];
static StackType_t uxStackSync1[ configMINIMAL_STACK_SIZE ];
static StackType_t uxStackSync2[ configMINIMAL_STACK_SIZE ];

static StaticEventGroup_t xISREventGroupBuffer;
static StaticEventGroup_t xEventGroupBuffer;

CHANGED:

	 * Create the test tasks as described at the top of this file.
	 */
	xTestSlaveTaskHandle = xTaskCreateStatic( prvTestSlaveTask, "WaitO", configMINIMAL_STACK_SIZE, NULL, ebWAIT_BIT_TASK_PRIORITY, &( uxStackSlave[ 0 ] ), &xTCBBufferSlave );

	xTaskCreateStatic( prvTestMasterTask, "SetB", configMINIMAL_STACK_SIZE, ( void * ) xTestSlaveTaskHandle, ebSET_BIT_TASK_PRIORITY, &( uxStackMaster[ 0 ] ), &xTCBBufferMaster);

	xSyncTask1 = xTaskCreateStatic( prvSyncTask, "Rndv", configMINIMAL_STACK_SIZE, ( void * ) ebRENDESVOUS_TASK_1_SYNC_BIT, ebWAIT_BIT_TASK_PRIORITY, &( uxStackSync1[ 0 ] ), &xTCBBufferSync1 );

	xSyncTask2 = xTaskCreateStatic( prvSyncTask, "Rndv", configMINIMAL_STACK_SIZE, ( void * ) ebRENDESVOUS_TASK_2_SYNC_BIT, ebWAIT_BIT_TASK_PRIORITY, &( uxStackSync2[ 0 ] ), &xTCBBufferSync2 );

CHANGED:

	/* Create the event group used by the ISR tests.  The event group used by
	the tasks is created by the tasks themselves. */
	xISREventGroup = xEventGroupCreateStatic( &xISREventGroupBuffer );

CHANGED:

	/* Create the event group used by the tasks ready for the initial tests. */
	xEventGroup = xEventGroupCreateStatic( &xEventGroupBuffer );

CHANGED:

		/* Recreate the event group ready for the next cycle. */
		xEventGroup = xEventGroupCreateStatic( &xEventGroupBuffer );

You are creating two tasks with the same StaticTask_t, thus the first one task got clobbered by the second.

(Never mind, miss read the code)

Does it work without your changes? Do you have configASSERT and stack overflow check enabled as mentioned here: https://www.freertos.org/FAQHelp.html

Thanks.

Yes I have configASSERT and stack overflow check enabled.
After enabling dynamic memory allocation, I found the unmodified EventGroupsDemo code also fails in the same spot (configAssert after xEventGroupSync with block time of 1 tick).

Would you please put a breakpoint at the following two places to see if the other 2 tasks are setting these bits or is there any memory corruption:

Is this a project you created or is it one of our demo project?

Thanks.

My line #'s are slightly different since I am using v10.1.1 but the same code is available.
Having the #L594 break point enabled prevents the test failure from occurring no matter how many times #L594 is reached. Having the #L445 break point enabled does not impact the test result either way. Both break points are hit if enabled.
I created my own project since there were no Nordic based examples for v10.1.1.

I don’t know in this case - but the tests make some assumptions about timings and the tick rate at which they are executed. They should run without problems in demos we provide, but changing anything anything about the system, or swapping tests in and out can make them appear to fail whereas in fact the test would pass were it running by itself - but when run in certain combinations or with different timing it things it is not working properly other tasks are using processing time too.

Per the symptoms, when the sync task blocks for 0 ticks, bits are not set but when it blocks for 1 tick, these bits are set. What I am trying to find by setting these breakpoints is who is setting these bits:

  • Are the bits getting set by respective tasks?
  • Or is this a memory corruption?

Thanks.

Sorry for the delay. I finally have time to investigate this further.

With a break point enabled at L#594, the call of xEventGroupSync with 0 tick delay returns 0x06 and the subsequent call of xEventGroupSync with 1 tick delay returns 0x0E.
With no break point enabled at L#594, the call of xEventGroupSync with 0 tick delay returns 0x06 and the subsequent call of xEventGroupSync with 1 tick delay returns 0x0F.

So seemingly the delay of 1 tick is enough for the rendezvous to complete. Would you please comment out this failing assert and see if everything else passes?

I need to get a trace of events to confirm - I do not have NRF52833 but I will give it a try on some other hardware and will let you know my findings.

Thanks.

Scenario 1)
Comment out failing assert and call of xEventGroupSync with delay of 1 tick,
then all remaining test code passes.
Scenario 2)
Change call of xEventGroupSync with delay of 1 tick to use delay of 0 ticks,
then all test code passes.
Scenario 3)
Comment out only failing assert,
then assert at the end of prvTestMasterTask fails.

Any news on getting a trace of events to confirm the behavior?
Thanks.

Any news on capturing a trace of events to confirm the behavior?
Thanks.

I am able to repro the assert failure you are seeing and trying to determine the cause of it. Will update about my findings.

Thanks.

This has been fixed in this PR: https://github.com/FreeRTOS/FreeRTOS/pull/294

Thank you for reporting this issue.

Just wondering about how the file is versioned. This fix is not in the 10.4.1 release from the FreeRTOS website. However the fixed file on github also has the 10.4.1 version?

Luckily this thread was here so I found the solution quickly.

If a PR is merged into main line it will be in the next release. The version number is updated as part of the release process, not as part of the PR process. Therefore if you take the head revision from github you will see what will be in the next release, but you will also see the version number of the prior release.

1 Like