Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Seeing assert in taskSELECT_HIGHEST_PRIORITY_TASK()

Posted by bsder on November 5, 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 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 */

~~~~


Seeing assert in taskSELECT_HIGHEST_PRIORITY_TASK()

Posted by rtel on November 5, 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 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS