/ listGET_OWNER_OF_NEXT_ENTRY indexes through the list, so the tasks of
* the same priority get an equal share of the processor time. /
listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopPriority ] ) );
uxTopReadyPriority = uxTopPriority;
} / taskSELECT_HIGHEST_PRIORITY_TASK */
A higher priority IRQ occurs, tick IRQ is switched out. The higher priority IRQ adds a ready task into the ready list and sets uxTopReadyPriority to this task’s priority, let’s assume it is 6.
The higher priority IRQ finished and tick IRQ contine it’s code. uxTopReadyPriority will be set to a value <= 5.
The task scheduler cannot call priority 6 task on next tick IRQ. That would cause some issues.
Thanks, Gaurav, Richard.
My product is with ARM® Cortex®-M33 core. After set configUSE_PORT_OPTIMISED_TASK_SELECTION to 1 and defined corresponding taskSELECT_HIGHEST_PRIORITY_TASK(), a lot of system issues are fixed.
My MCU vendor might implement an incorrect tick ISR, which caused an impossible bug happened. They are working on it. However, this generic way that taskSELECT_HIGHEST_PRIORITY_TASK() changes uxTopReadyPriority isn’t a good idea.
In my humble opinion, searching the highest priority task in the whole pxReadyTasksLists everytime only sacrifices a little bit performance. If a MCU vendor cares about the performance, they should implement their own optimised task selection.
We cannot assume all MCU vendor can port everything in a perfect shape. Just like my case, we spent a lot of time to figure out our MCU vendor didn’t follow the FreeRTOS reference design.
Would you like to share your ideas about this? I am long for them.
of course I don’t know about the history of the code, but I believe the issue you raise is similar to that one here:
I tend to believe that the reasoning may be similar here: uxTopReadyPriority is only ever written to in the task selector, but read from in several other places. Without having looked at the code explicitly, it seems as if keeping it as a module level static global helps avoiding overuse of the critical section at pxReadyTasksLists access time.
The other issue, of course, is that optimized task selection is about as close to the heart of the OS as one can get, so at least I would assume that whoever tackles that issue should know (or, at the very least, very thoroughly test) what he/she is doing. Programming errors at this level tend to manifest themselves fairly soon (a profiler would probaly testify that the task selection is among the most heavily used code section in FreeRTOS). If there really have been bugs in a vendor’s adaption that you had to pinpoint, it doesn’t shed a bright light on the adaptor’s quality system (my humble opinion).
Whatever, I’m curiously waiting for Richard Barry’s answer to your query as he probably is the one who coded the selection algorithm (and as far as I can tell, he codes very deliberate and meticuluous, so there probably is a good reasons why it is as it is).
So how to explain your unexpected observation? One explanation is that you might have configured interrupt priorities incorrectly. What version of FreeRTOS are you using? More recent versions of FreeRTOS catch these configuration errors via configASSERT(). Can you share your definition of configASSERT()?
That definition of assertEFM() isn’t ideal for FreeRTOS. Better to mask interrupts prior to entering the forever loop. That way FreeRTOS can’t continue operating, and your tasks won’t attempt to continue operating. For example, use taskDISABLE_INTERRUPTS();.
However, even with your current definition of assertEFM(), you probably would have noticed hitting it. Especially if it were called from an interrupt at a priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY, a common error caught by configASSERT().
So, back to explaining your observation that problems go away when you use port-optimized task selection. Did you say that your tick ISR is provided by the MCU vendor? And that the tick ISR doesn’t mask interrupts for the call to xTaskIncrementTick()? Maybe that’s still the problem. Has that been resolved yet?
Did you say that your tick ISR is provided by the MCU vendor? And that the tick ISR doesn’t mask interrupts for the call to xTaskIncrementTick() ? Maybe that’s still the problem. Has that been resolved yet?
Yes, it is from our MCU vendor. We didn’t find this failure sympton untill MCU vendor replaced portDISABLE_INTERRUPTS() with portSET_INTERRUPT_MASK_FROM_ISR() for the call to xTaskIncrementTick().
In that case, you might be better off with the official freertos port, as @aggarg suggested. This forum and the freertos maintainers can be more helpful that way too. Hard to tell what other mistakes the MCU vendor may have made.