FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [November 2015 Threads]
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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.