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


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 ]    [ 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