Quality RTOS & Embedded Software

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


Use of FreeRTOS API before call of vTaskStartScheduler

Posted by hpc64 on June 19, 2018


We are using FreeRTOS with C++. Our main application is globally defined and so it's contructor gets called in the run init array. Afterwards main is called which finally calls vTaskStartScheduler.

Queues and mutexes are created in the constructors. Also some mutexes get locked and unlocked at that state. Even so this would not be necessary as nothing is running concurrently we do it anyway because we don't want to have duplicated code, one that locks the mutex and other that doesn't.

I now observed that all interrupts we disabled in this phase until the scheduler was started what caused for instance the USB not be ready until the scheduler was started. This caused to fail the enumeration process with some hosts.

I tracked the problem down to the vPortExitCritical which is called from xQueueGenericCreate -> pvPortMalloc -> xTaskResumeAll. As uxCriticalNesting is initialized to 0xaaaaaaaa the condition uxCriticalNesting == 0 is not true and thus portENABLE_INTERRUPTS() is not called and the interrupts remain disabled.

The same problem was already discussed here: https://www.freertos.org/FreeRTOSSupportForumArchive/December2013/freertosCortex-M3allocatingmemorybeforeschedulerstartlocksinterrupts_bee040c1j.html

A proposed solution was to initialize uxCriticalNesting to 0. Is this safe? What are the drawbacks?

There are also threads related to the question what of the API can be used before the call of vTaskStartScheduler:

https://www.freertos.org/FreeRTOSSupportForumArchive/May2011/freertosPostingtoqueuesbeforeschedulerstarts4527847.html https://www.freertos.org/FreeRTOSSupportForumArchive/July2017/freertosUsingMutexbeforeschedulerstarts_34ad0b10j.html

It would very helpful to know which API calls can be used before the call of vTaskStartScheduler.

In my opinion as many as API functions as possible should be usable before vTaskStartScheduler, even a e.g. xSemaphoreTake with a non-zero timeout because there is no other task that could have taken it. If so, an assertion should be triggered

Thanks a lot for any comment on this.

Use of FreeRTOS API before call of vTaskStartScheduler

Posted by rtel on June 19, 2018

The initialisation of the critical nesting count to a non-zero value is, as you have observed, quite deliberate and therefore not considered an 'issue'. It is done to ensure interrupts remain masked (up to a user definable value) between FreeRTOS objects being created and the scheduler being started - at which point they are unmasked. Historically, going back many years, a very common source of support requests originated from interrupts attempting to use kernel services before the scheduler had been started - so this mechanism was introduced to prevent that. You asked if changing the initialisation value to 0 would be dangerous - it would only be dangerous in the situation above - where an RTOS object was created and something such as an interrupt attempted to use it before the kernel was ready.

[ 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.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo & Nuvoton Cortex-M23 demo.

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