FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2014 Threads] Issue using the xSemaphoreGiveFromISR() functionPosted by chris-itk on October 29, 2014 Hi to all,
I've got a problem regarding the use of the xSemaphoreGiveFromISR() function.
I'm using it out of a callback function which is called within an ISR.
I use a binary semaphore as a signal for a completed spi reception.
It has to be taken again immediately after it was given by the callback.
The problem is, that the binary semaphore is still "taken" after calling xSemaphoreGiveFromISR(), so my task blocks again.
Do you have any ideas how to fix my problem?
Here's the callback function:
static void SPIHandlerCallback(void)
{
static signed short xHigherPriorityTaskWoken;
if((0U != u8_SPI_Handler_Is_Initialized))
{
xSemaphoreGiveFromISR(SPI_Handler_SPI_Signal, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
return;
}
Issue using the xSemaphoreGiveFromISR() functionPosted by rtel on October 29, 2014 What does the call to xSemaphoreGiveFromISR() return?
Do you have configASSERT() defined?
Regards.
Issue using the xSemaphoreGiveFromISR() functionPosted by chris-itk on October 29, 2014 Thanks for your answer.
No, I have not defined the configAssert().
The return value of xSemaphoreGiveFromISR() is pdPASS.
I debugged inside this routine and it reaches the line:
/* Increment the lock count so the task that unlocks the queue
knows that data was posted while it was locked. */
++( pxQueue->xTxLock );
I'm not absolutely sure, but I think the semaphore is succesfully incremented after this line, isn't it?
But when that's true, why am I blocking the next time I try to take the same semaphore?
Issue using the xSemaphoreGiveFromISR() functionPosted by rtel on October 29, 2014 Could you please post the code where you are receiving/taking the mutex.
Issue using the xSemaphoreGiveFromISR() functionPosted by chris-itk on October 30, 2014 Here I'm doing a take just immediately after starting the spi transfere:
if(pdFALSE == xSemaphoreTake(SPIHandlerSPISignal, (SPIHANDLERSYNCTIMEOUTWAITMS/portTICKRATEMS)))
{
ret = MDERROR;
SPIHandlerSwitchChipselect(SPIDeviceInfo, CS_DISABLE);
}
The Semaphore is then given again within my callback routine (Interrupt context):
static void SPIHandlerCallback(void)
{
signed short xHigherPriorityTaskWoken = pdFALSE;
if((0U != u8_SPI_Handler_Is_Initialized))
{
xSemaphoreGiveFromISR(SPI_Handler_SPI_Signal, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
return;
}
I found out, that if I don't request a Taskswitch within the Callback, the task comes up again at the next systick, which is after 1ms. But by using portYIELDFROMISR() the task never comes up again. It seems to be a timing problem. If I do it step by step in debugger everything works fine. Maybe there is some kind of race condition (If I wait little, approx. 20µs, after starting the spi-transfere and before trying to take the semaphore, the problem also doesn't occur?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|