anonymous wrote on Tuesday, March 13, 2012:
Yesterday I asked a question about eternal lock after context switch (here https://sourceforge.net/projects/freertos/forums/forum/382005/topic/5111217)
But unfortunately, even right procedure of serving interrupt still causes eternal lock!
It looks like this:
static portBASE_TYPE xHigherPriorityTaskWoken; xHigherPriorityTaskWoken=pdFALSE; EXTI_ClearITPendingBit(EXTI_Line10); irq++; //for debug purposes if(irq==2) __asm("NOP"); //here I can place a break, after that all tasks remain blocked forever xSemaphoreGiveFromISR(IRQSemph, &xHigherPriorityTaskWoken); portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);
There are two tasks, one for actual serving this interrupt, high-priority, which starts with xSemaphoreTake(IRQSemph, portMAX_DELAY);
and another, with lower priority, which is blocked, waiting signal form high-priority task.
I suppose, that when breakpoint is reached (irq count == 2), ISR interrupts this high priority task, while it is processing last ISR (irq == 1). But I don’t understand, why this is causing this lock!
When I am entering xSemaphoreGiveFromISR, I can see that it’s pxQueue->xTxLock is 0, so no actions with even list is taken, just data copy, inctement of xTxLock and return of FALSE;
Also pxQueue->xTasksWaitingToReceive->uxNumberOfItems = 2.
What does this mean, why there is two tasks, waiting for receive? The only one task, that uses this semaphore is my high-priority routine…