anonymous wrote on Monday, March 12, 2012:
Hello. I am using GCC STM32F103VE.
I came across some odd behaviour of my firmware after calling portEND_SWITCHING_ISR - there are two tasks, one for processing data, low priority, and another for delayed interrupt handling, high priority.
So, high priority task is waiting for counting semaphore, xSemaphoreTake(IRQSemph, portMAX_DELAY);
ISR text is provided below:
void EXTI15_10_IRQHandler() //IRQ
When entering ISR first time both tasks are blocked, awaiting different events. So, It works great, context is switched to High Priority task, which is unblocked by IRQSemph counting semaphore. But while processing this task, I suppose, this interrupt is being called once more.
Here is my question: due to mistype, I always passed TRUE to portEND_SWITCHING_ISR, causing context switch even when I shouldn’t.
But this caused odd effect - high priority task never unblocked.
This seems wrong to me - even after unexpected context switch - there are no more candidates for running, low priority task is blocked all the time, then why sheduler does not return to High Priority task, why is High Priority task still awaiting semaphore, when semaphore is already being given?
I checked return value of xSemaphoreGiveFromISR, it retrurns success.
When I fixed code and started passing *real* xHigherPriorityTaskWoken value instead of 1, it began to work.