Quality RTOS & Embedded Software

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


Problem in switch context

Posted by Naomi Hochberg on March 20, 2011
I use FreeRTOS with PIC24F15KA102. My application includes only one task (except the idle task) and I work with non nested interrupts and total disable interrupts for portDISABLE_INTERRUPTS(). In ISRs messages are entered to Q. Messages are received and handled by the task. Sometimes I reach the point where msg Q is full,but the task is not running although it is ready.

Problem is caused by the fact that in vTaksSwitchContext scanning the ready lists and decrementing the global variable uxTopReadyPriority is not protected from interrupts. It may be changed by ISR that enters the message to Q during the following loop and than be overwritten in the loop.

/* Find the highest priority queue that contains ready tasks. */
while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )

When I put the scanning loop under disable interrupts problem is solved.

RE: Problem in switch context

Posted by Dave on March 20, 2011
It sounds like you are doing something very wrong. Are you calling API functions that do not end in FromISR from inside an ISR? Are you enabling interrupts in the ISR in the wrong way, etc, etc. If it is being used correctly, the problem you describe will not happen.

RE: Problem in switch context

Posted by Naomi Hochberg on March 24, 2011
I call xQueueSendToBackFromISR() that calls xTaskRemoveFromEventList() that calls prvAddTaskToReadyQueue()
that modifies uxTopReadyPriority (in ISR).

vTaskSwitchContext() is call by portYIELD() called by the Idle task.

RE: Problem in switch context

Posted by Richard on March 24, 2011
In that port, portYIELD() disables interrupts up to the priority set by configKERNEL_INTERRUPT_PRIORITY, and there is a documented restriction that interrupts that call ISR safe API functions cannot use a priority above configKERNEL_INTERRUPT_PRIORITY - therefore, if the usage instructions are being followed, it should not be possible for the two code sections you highlight (one inside an interrupt, and one outside of the interrupt) to interfere with each other.

That is the intention anyway - I'm always happy to be proven wrong.


RE: Problem in switch context

Posted by Naomi Hochberg on March 27, 2011
In PIC24F15KA102 none nested interrupt mode it is impossible to write to IPL bits of SR register. ISR will always run in higher priority than none ISR routines.
Does that mean that it is impossible to use FreeRTOS in none nested interrupts mode ?

RE: Problem in switch context

Posted by Naomi Hochberg on March 31, 2011
I use nested interrupts and configure all interrupts to configKERNEL_INTERRUPT_PRIORITY. It is actually the same as working in none nested interrupts mode. This way portYIELD() disable interrupts before vTaskSwitchContext() is called
and my application is working OK.

Thanks to richarfbarry for the explanation.

RE: Problem in switch context

Posted by Roman on April 12, 2011
Hello naomihochberg,
I had the same problem on my LPC2468 (ARM7TDMI-S) and FreeRTOS 6.1.1. I have implemented nested interrupts by re-enabling all IRQs on entrance in a wrapper ISR. I mask out from configKERNEL_INTERRUPT_PRIORITY to configMAX_SYSCALL_INTERRUPT_PRIORITY and I have to mask out before calling vTaksSwitchContext.

Your denoted loop in vTaksSwitchContext isn't safe using xFromISR functions if the CSW can be preempted by that syscall-level IRQs with xfromISR calls. If using any other traps that cannot interrupt IRQs everything is safe again .

I think this behavior should be considered in one of the next releases or should be mentioned correctly in the documentation as it only denotes
“To utilize this scheme your application design must adhere to the following rule: Any interrupt that uses the FreeRTOS API must be set to the same priority as the kernel (as configured by the configKERNEL_INTERRUPT_PRIORITY macro), or at or below configMAX_SYSCALL_INTERRUPT_PRIORITY for ports that include this functionality”


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

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

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

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