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 taskSELECTHIGHESTPRIORITYTASK() { /* Find the highest priority queue that contains ready tasks. */ while( listLISTISEMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) ) { configASSERT( uxTopReadyPriority ); --uxTopReadyPriority; } /* listGETOWNEROFNEXTENTRY indexes through the list, so the tasks of the same priority get an equal share of the processor time. */ listGETOWNEROFNEXTENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) ); } /* taskSELECTHIGHESTPRIORITYTASK */

~~~~

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 http://www.freertos.org/FAQHelp.html 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.