Quality RTOS & Embedded Software

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


C++ class initialisation lockup

Posted by terrybarnaby on May 27, 2014

We are using an in house C++ class library that sits on top of FreeRTOS for use on the STM32F4 platform (Tasks, IO devices etc). This works well, but there is an issue if you try and use something like pvPortMalloc() before the FreeRTOS scheduler is started (probably from a object creation constructor (creating semaphores etc etc)). Code like this eventually calls: vPortEnterCritical() then vPortExitCritical(). The GCC/ARM_CM4F port uses a variable uxCriticalNesting to determine if interrupts should be re-enabled in vPortExitCritical(). However before the scheduler is started uxCriticalNesting is set to 0xaaaaaaaa. Thus when the C++ initialises things before the scheduler is started, interrupts end up by being disabled. Unfortunately we are using interrupts at that time for certain functionality (debugging printf's through USB for example). Now we can set uxCriticalNesting to 0 in port.c and this works, but are there implications of doing this and generally in calling FreeRTOS functions (apart from the obvious ones !) before the scheduler is started ?

C++ class initialisation lockup

Posted by rtel on May 27, 2014

What you are seeing is intentional and not related to C++. You will have the same effect calling any FreeRTOS API functions that use critical sections, not just pvPortMalloc().

A context switch cannot be performed prior to the scheduler being started. Interrupts are intentionally left disabled (in fact, just masked in this case) during the initialisation phase to ensure any interrupts that use the FreeRTOS API that are pre-installed or installed during the initialisation phase cannot execute while the scheduler is in an inconsistent state. Interrupts are enabled again automatically when the first task starts to run.

On STM32 platforms interrupts are not actually globally disabled, only masked upto configMAXSYSCALLINTERRUPTPRIORITY, so if you set your UART interrupt to a priority above that (which means a lower numeric value on Cortex-M parts) then the interrupt will remain enabled - however the interrupt must not attempt to use the FreeRTOS API and its priority must be lowered again to be equal to or below configMAXSYSCALLINTERRUPTPRIORITY if it is going to use the FreeRTOS API after the scheduler has been started.


C++ class initialisation lockup

Posted by terrybarnaby on May 27, 2014

Many thanks for the reply. That makes sense, shame I have to change interrupt priorities during the initialisation phase, but I can see the sense of this to save odd issues in some usage cases. Cheers.

C++ class initialisation lockup

Posted by dumarjo on May 27, 2014


One thing that we have done here to protect against the malloc, is we test how many task exist. If at least 1 task exist, we presume that the sheduler is started. This don't prevent the problem with the interrupt, but At least this correct the problem of global object creation.


C++ class initialisation lockup

Posted by rtel on May 27, 2014

This might be helpful as an alternative to checking the number of tasks: http://www.freertos.org/a00021.html#xTaskGetSchedulerState

Regards, Richard Barry.

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

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists