Quality RTOS & Embedded Software

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




Loading

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.

Regards.


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

Hi,

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.

Jonathan


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) 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