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


Nesting of critical regions

Posted by Marcel van Lieshout on February 4, 2005
I'm working on a port for the pic18 using wizC as development environment.
It looks like "enter_critical"/"exit_critical" should be able to be nested. The current MCC18 port for the pic18 uses the softwarestack to do this.
Because wizC does not use a framepointer, I cannot use this technique. I looked through some other ports and found an alternative in the "GCC\MSP430F449"-port. But I was wondering: Can the pic's hardwarestack be used for this? This stack is used by wizC as call/return-stack but is modifiable from software. I think it can be done IF all combinations of enter/exit are at the same level. What I mean is: An enter_critical and it's counterpart should always be in the same functioncall-depth. Can anyone tell me if this is guaranteed the case? Now and in the future?

RE: Nesting of critical regions

Posted by Marcel van Lieshout on February 5, 2005
Because my first tests run succefully, I think the answer to the above question is 'yes', but confirmation is still appreciated.

RE: Nesting of critical regions

Posted by Richard on February 5, 2005
I'm not sure I quite follow this one.

The msp430 port uses the method for systems that cannot modify the stack without crashing the program - typically systems that don't use a frame pointer as you say.

It works by simply maintaining a count of the depth of critical section nesting. Each task must have it's own count, so the count is saved and restored as part of the tasks context.

As far as I can remember the hardware stack on the PIC is used by the processor itself when jumps are made. It might be that you can use values on the stack yourself, provided no function calls are made while the stack has been modified. The bit width of the stack may be odd. I suggest that this has potential to be a dangerous approach ... but I'm always willing to be proved wrong.

RE: Nesting of critical regions

Posted by Marcel van Lieshout on February 5, 2005
Indeed, I don't have a framepointer and therefore cannot modify the software-stack.

The pic hardwarestack is mostly used as a implicit call/return-stack, but it's use is not limited to that. It can also be used as a datastack by using the push/pop instructions.

Functioncalling between the push/pop combinations is no problem as long as the pop is done after returning from these functions (stack must be the same before the pop as it was just after the push).

Basically what I am asking is: Are the enter_critical and the exit_critical always in the same function?

So, this is no problem:
call func
return from func

But this is a problem:
call func
return from func

Perhaps it's easier to simply use the msp430 way.

It's part of my personality: when I dive into something, I want to get to the bottom... :-)

RE: Nesting of critical regions

Posted by Richard on February 5, 2005
Things are a little complicated.

The enter/exit routines are always in the same function (function calls can exist between them however) ... BUT ...

It is possible for a context switch to occur within a critical region. This sounds odd but there are places where a portYIELD is called within a critical section. This is ok as each task maintains it's own interrupt flags so the next task will start with interrupt enabled. When the task that called yield from within the critical section starts again it will start with interrupts disabled.

I'm not sure how this affects your idea. When a yield is performed the hardware stack is swapped out (presumably) so any modifications may just get saved as part of the task context and then not affect any other tasks. I think the only way to get confidence in this is to step through a few switches in the simulator. You could try adding:


within a simple task and see what happens!

RE: Nesting of critical regions

Posted by Marcel van Lieshout on February 5, 2005
Tested it with no problems! Even with multiple tasks sharing their code using different values for pvParameters.

But I have decided to go the MSP430-way because I don't see (m)any advantages in my approach. Besides, adding a new concept could possibly interfere with future modifications/additions of FreeRtos.

Thanks anyway, I'm really learning a lot!

[ 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