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


FreeRTOS-MPU CM3. User task cannot call ENTER_CRITICAL?

Posted by mc4924 on February 7, 2016

I am currently experimenting with FreeRTOS with MPU for Cortex M3.

It seems to me that given the settings in FreeRTOSConfig.h, an unprivileged task will never be able to use taskENTER_CRITICAL.

For instance, this is from the CORTEXMPULM3Sxxxx_Rowley port:

FreeRTOSConfig.h ~~~~ ...

define configKERNELINTERRUPTPRIORITY (( unsigned char ) 7 << configUNUSEDPRIOBITS)


define configMAXSYSCALLINTERRUPTPRIORITY (( unsigned char ) 5 << configUNUSEDPRIO_BITS)

... ~~~~

'KERNELINTERRUPTPRIORITY' is the priority that is assigned to SysTick, SVC and pendSV Handlers

'MAXSYSCALLINTERRUPTPRIORITY' is the priority that is used in ENTERCRITICAL. Any exception/interrupt with same or below priority will be masked out between ENTERCRITICAL and EXITCRITICAL.

But if KERNELINTERRUPTPRIORITY is lower or same as MAXSYSCALLINTERRUPTPRIORITY, as it is here (bigger or equal numerical value), after ENTERCRITICAL is called, the task will not be able to execute another SVC (which will have too low a priority now), including calling EXITCRITICAL! (because EXITCRITICAL calls prvRaisePrivilege, which uses SVC 2).

So I could do one of two things: 1. give KERNELINTERRUPTPRIORITY a higher priority than MAXSYSCALLINTERRUPTPRIORITY 2. give just the SVC handler a higher priority than MAXSYSCALLINTERRUPTPRIORITY

In both cases a small test application seems to work ok (i.e. a non privileged call can use ENTER_CRITICAL/EXIT CRITICAL) but I am not sure of the ramifications of this.

The priorities seem to be set this way (KERNELINTERRUPTPRIORITY lower than MAXSYSCALLINTERRUPT_PRIORITY) for most if not all M3/M4 ports, so I guess there must be a good reason for this.

FreeRTOS-MPU CM3. User task cannot call ENTER_CRITICAL?

Posted by rtel on February 7, 2016

I think it is deliberate that an unprivileged task cannot call enter/exit critical directly as doing so disables a subset of interrupt priorities - which only tasks running with full privileges can do.

The maximum system call priority is normally above the kernel interrupt priority to allow for a full interrupt nesting model where API calls can be made from interrupts that have a priority above the kernel interrupt priority (the kernel must always be the lowest interrupt priority).

FreeRTOS-MPU CM3. User task cannot call ENTER_CRITICAL?

Posted by mc4924 on February 7, 2016

Thank you for the prompt answer to my question. Thinking about it,I guess it makes sense wanting to avoid unprivileged task blocking exceptions.

However if I was stubborn and still wanting to be able to ENTER/EXIT_CRITICAL from unprivileged tasks (maybe because I have just a very short critical section) I guess it would be better to adopt my solution n. 2 (give just the SVC a higher priority). After all the SVC itself is quite short in itself so putting in at high priority will have a limited impact on interrupt latency.

FreeRTOS-MPU CM3. User task cannot call ENTER_CRITICAL?

Posted by hengblom on July 30, 2016

Waking up this old thread since I ran into exactly the same problem when experimenting with MPU on Coretx-M3.

You say that it is a deliberate design that an unprivileged task shall not be able to enter a critical section. I can understand that, sort of, but if so, why does this code:

void vPortEnterCritical( void ) { BaseType_t xRunningPrivileged = xPortRaisePrivilege();


vPortResetPrivilege( xRunningPrivileged );


check if we are unprivileged, and if so, raise the privilege level ? If an unprivileged task should not be allowed to enter a critical section, it would have been better just to assume that the task is privileged, and if it isn't, let it crash when trying to disable interrupts. It will, as the Claudio says, crash anyway when doing EXIT-CRITICAL.

FreeRTOS-MPU CM3. User task cannot call ENTER_CRITICAL?

Posted by rtel on July 30, 2016

Perhaps this is something that was changed, I would have to look through the change logs.

[ 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