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.
Problem in switch context
Problem in switch context
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.
Problem in switch context
I call xQueueSendToBackFromISR() that calls xTaskRemoveFromEventList() that calls prvAddTaskToReadyQueue()
that modifies uxTopReadyPriority (in ISR). vTaskSwitchContext() is call by portYIELD() called by the Idle task.
that modifies uxTopReadyPriority (in ISR). vTaskSwitchContext() is call by portYIELD() called by the Idle task.
Problem in switch context
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.
Regards
Problem in switch context
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 ?
Does that mean that it is impossible to use FreeRTOS in none nested interrupts mode ?
Problem in switch context
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.
and my application is working OK. Thanks to richarfbarry for the explanation.
Problem in switch context
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
Roman
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 functionalityRegards,
Roman