Seeing assert in taskSELECT_HIGHEST_PRIORITY_TASK()

Kernel
1

bsder wrote on Thursday, November 05, 2015:

I’m trying to hunt down a really pernicious bug, and could use a little advice.

I’m running on a PIC32MX on FreeRTOS 8.2.3 (problem exists in 8.0.1 which is what I was originally using but I upgraded just in case), and I’m seeing an assert fire when I plug in my USB–but only in release mode. If I’m in debug mode, everything works just dandy. I had to rig up special code to shove debug info out a port that I could actually probe while in full release mode.

This is really infuriating. Now, that kind of behavior screams “smasher” (stack/heap/runaway variable init). I am hitting a configASSERT( uxTopReadyPriority );

My questions:

  1. What is that ASSERT checking?
  2. What does failing that ASSERT mean?
  3. What in the world could cause that ASSERT to fire?

Any advice is appreciated.

Thanks,
-a

The code that is tripping is this from tasks.c:

	#define taskSELECT_HIGHEST_PRIORITY_TASK()															\
	{																									\
		/* Find the highest priority queue that contains ready tasks. */								\
		while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )						\
		{																								\
			configASSERT( uxTopReadyPriority );															\
			--uxTopReadyPriority;																		\
		}																								\
																										\
		/* listGET_OWNER_OF_NEXT_ENTRY indexes through the list, so the tasks of						\
		the	same priority get an equal share of the processor time. */									\
		listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );		\
	} /* taskSELECT_HIGHEST_PRIORITY_TASK */
2

rtel wrote on Thursday, November 05, 2015:

  1. What is that ASSERT checking?
  2. What does failing that ASSERT mean?
  3. What in the world could cause that ASSERT to fire?

There should always be one task that is able to run. Normally this is the RTOS idle task. If that assert is being hit then, as far as the RTOS is concerned, there are no tasks it can select to enter the Running state as even the list containing idle priority tasks is empty.

This can happen because of a simple data corruption somewhere in the RTOS’s internal data structures.

Normally I would suggest reading through the following list FreeRTOS - Open Source RTOS Kernel for small embedded systems to see if you are complying with all the recommendations, ensuring the interrupt priorities are set correctly (an incorrect interrupt priority is a classic cause for this type of symptom), etc. In this case it is more interesting that the debug build works though, so in addition you would have to consider whether there is anything in the application or driver/usb code that might cause a problem with faster execution, or missing ‘volatile’ qualifiers, etc.