Quality RTOS & Embedded Software

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


STM32L1xx -- uxPendedTasks value in tasks.c underflow

Posted by kagnewkid on January 8, 2014

Greetings, Discovered a situation where the value, uxPendedTicks in tasks.c, can underflow and hang the task switching.

In tasks.c, I added a check for underflow at around line 1413 (following the decrement of uxPendedTicks) as follows:

if (0 != (uxPendedTicks & 0x10000000)) { uxPendedTicks = 0; // MAD: THIS SHOULD NOT HAVE HAPPENED!!!!! }

I am not entirely sure WHY this situation occurred.

Am running version 7.6.0 and using the STM M3 core port and the IAR development chain. My project consists of about 6 tasks of equal priority and very low functionality. The interrupt processing that I am doing does not invoke any FreeRTOS facilities so the ISRs are not using the FreeRTOS stack framing macros. Due to critical timing (bit pacing for one-wire communications) kernel interrupt priority is set lower (less responsive) than the priorities of my one-wire interrupts.

I initially submitted a ticket on this but was encouraged to submit this as a forum topic for discussion to determine whether this should truly be considered a bug or if I have misapplied something that led to this behavior.

Thanks in advance for any advice in this situation.

Cheers, KagnewKid.

STM32L1xx -- uxPendedTasks value in tasks.c underflow

Posted by rtel on January 8, 2014

That is not an issue that has been reported before, so I will have to take a look through the code as to where the variable is used to see which scenarios could lead to this happening. It sounds like your application is very simple, especially as you are not using FreeRTOS calls from interrupts.

I note you are using an STM32. Is your application code calling NVICPriorityGroupConfig( NVICPriorityGroup_4 ); before it starts the scheduler? That is essential on STM32 chips only - as unlike any other Cortex-M system I'm aware of, they default to having some priority bits assigned as sub-priority rather than preemption priority. If that is the case then, depending on other configurations, it is possible that the tick interrupt is interrupting a critical section - and that in turn could lead to a context switch in a critical section - which could in turn lead to the uxPendedTicks variable being corrupted in the way you describe (because the variable assumes context switches are not going to happen in critical sections).

Also, as you are using V7.6.0, do you have configASSERT() defined? V7.6.0 includes additional assert statements to check against just the sort of scenario I describe above.


STM32L1xx -- uxPendedTasks value in tasks.c underflow

Posted by kagnewkid on January 8, 2014

The NVICPriorityGroupConfig( NVICPriorityGroup_4 ); call was NOT being made.

The configASSERT() is defined.

I have added the NVICPriorityGroupConfig( NVICPriorityGroup_4 ); per your requirement and it appears to have solved the problem.

I think in retargeting your sample application, I overlooked and then omitted the call. Not wise. Thanks for your assistance. KagnewKid.

STM32L1xx -- uxPendedTasks value in tasks.c underflow

Posted by kagnewkid on January 10, 2014

Greetings again. Well, my hopes were dashed. I left the trap that I described originally "just in case..." and my code hit the break point I set in the trap. This means that the underflow occurred despite my implementing the NVIC_PriorityGroupConfig() call. So this is still open for discussion. Cheers. KagnewKid.

STM32L1xx -- uxPendedTasks value in tasks.c underflow

Posted by rtel on January 10, 2014

I'm struggling with this one. Looking at V7.6.0 the uxPendedTicks variable is only decremented in one place, and it is within a loop that tests to ensure uxPendedTicks is greater than 0, and within a critical section (so assuming interrupt priorities are set correctly, should be safe code).

    while( uxPendedTicks > ( unsigned portBASE_TYPE ) 0U )
        if( xTaskIncrementTick() != pdFALSE )
            xYieldPending = pdTRUE;

The only thing called while the pended ticks are being unwound is xTaskIncrementTick(), so other than xTaskIncrementTick doing something that corrupts uxPendedTicks() it would seem the decrements were safe.

xTaskIncrementTick() manipulates some ready lists, and a couple of file scope variables, but does not attempt to perform any context switching - it is just a C function.

Have you made any edits to the FreeRTOS code anywhere, even if you think they are trivial and could not cause an issue? That is any code in the FreeRTOS/Source directory or sub-directory thereof. The line number you quote above is a return statement that is 18 lines away from the code I posted above.

Did you also define configASSERT()?

Are you able to cut your project down to its bare bones, just enough to still exhibit this behaviour, then send it to me? You can send it to the business contact on http://www.freertos.org/contact I would need the project supplied buildable, so with no absolute file paths, etc.


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

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

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

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

Xilinx Microblaze and Zynq partner