Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Issue in xSemaphoreGiveFromISR

Posted by sareenakp on December 20, 2013

Hi,

I am facing an issue with xSemaphoreGiveFromISR . It is not unblocking the task that is waiting on a xSemaphoreTake. I am working on ARM Cortex™-M3 core. I use the xSemaphoreGiveFromISR in the ISR, and this interrupt is fired fast.

I have ensured that the interrupt is fired with an LED, as well as the call to xSemaphoreGiveFromISR is executed. The firmware is blocked at this instance. Please provide your inputs.

The priority of the interrupt is 7. configMAXSYSCALLINTERRUPT_PRIORITY is kept as 4.

gxSem_CntlessIntAvl is a binary semaphore.

The code is as below

ISR -->

void EXTI95IRQHandler (void) {

#if (configUSE_TRACE_FACILITY == 1)
	portENTER_CRITICAL(); // Required if nested ISRs are allowed
    vTraceStoreISRBegin(ID_CLESS);
    portEXIT_CRITICAL();
#endif


static portBASE_TYPE xTaskWoken = pdFALSE;
portBASE_TYPE xStatus = pdFALSE;


if(EXTI_GetFlagStatus(EXTI_Line5) == SET)
{

	EXTI_ClearFlag(EXTI_Line5);

	if (NULL != gxSem_CntlessIntAvl)
	{
		if (xQueueIsQueueFullFromISR(gxSem_CntlessIntAvl))
		{
                        // Queue is full
		}
		else
		{

    			xStatus = xSemaphoreGiveFromISR (gxSem_CntlessIntAvl,        
                                    &xTaskWoken );


                            if (xTaskWoken == pdTRUE)
                            {
                                //Force a context switch here not at all necessary
                                portYIELD_FROM_ISR (xTaskWoken );
                            }


		}
	}
}


#if (configUSE_TRACE_FACILITY == 1)
    portENTER_CRITICAL(); // Required if nested ISRs are allowed
    vTraceStoreISREnd();
    portEXIT_CRITICAL();
#endif

}

TASK --> .... while (TRUE) {

if (pdFALSE == xSemaphoreTake (gxSem_CntlessIntAvl, gwStmTimeout/portTICK_RATE_MS))
{
	PC_CL ('+');
	byRetVal = ERROR_TIMEOUT;
	break;
}
... 

//Continue to process the interrupt.

}


Issue in xSemaphoreGiveFromISR

Posted by edwards3 on December 20, 2013

portENTER_CRITICAL();

You can't call that from an interrupt because it does not end in FromISR. Step into xSemaphoreGiveFromISR() to see how it creates a critical section from an interrupt. There is nothing else obviously wrong in your code assuming the trace function calls are ok.

Are you using the latest FreeRTOS version 7.6.0 with configASSERT() defined? That helps trap quite a lot more config errors than older versions.


Issue in xSemaphoreGiveFromISR

Posted by sareenakp on December 23, 2013

I am using FreeRTOS V7.5.2.

Even RTOS API's uses the portENTERCRITICAL function internally. There are no portENTERCRITICALFromIsr functions defined in this RTOS version.

I feel the issue is in xSemaphoreTake, as the semaphore is given successfully from ISR ( confirmed with LED toggling.) The xSemaphoreTake should have atleast timed out.

The issue is seen when the xSemaphoreTake has entered its waiting loop and then the ISR gives the semaphore.

Its all fine , when the ISR has given the semaphore before the xSemaphoreTake enters its waiting loop in the RTOS.

Another issue I am facing is that , the FreeRTOS+ TRace is not able to capture any log past the xSemaphoreGiveFromISR call. It always stops at the first call to xSemaphoreGiveFromISR . Can anything be done about this?


Issue in xSemaphoreGiveFromISR

Posted by rtel on December 23, 2013

Even RTOS API's uses the portENTER_CRITICAL function internally.

No they don't.

There are no portENTER_CRITICALFromIsr functions defined in this RTOS version.

Yes there are.

Look at the implementation of xQueueGenericSendFromISR() in queue.c to see how it uses the portSETINTERRUPTMASKFROMISR() macro, and also read the FAQ "My application does not run what could be wrong" to ensure you understand which functions can be called from interrupts. http://www.freertos.org/FAQHelp.html

Can anything be done about this?

Please also use V7.6.0 and define configASSERT() as already suggested then report back if the asserts have trapped the problem or not as you are describing a situation that will occur if the configuration is not correct - and the asserts are there to trap that for you. If not we can look into the issue further.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS