xSemaphoreTake() got stuck

Kernel
#1

zohargolan365 wrote on Tuesday, March 22, 2016:

HI all,

I have a problem with xSemaphoreTake() in FreeRTOS 8.2.0 (and 8.2.3) port for Freescale Kinetis (using Mcu on Eclipse component).
The problem is that I have an interrupt with priority 8 which is giving a binary semaphore

/*
** ===================================================================
** Event : EInt1_OnInterrupt (module Events)
**
** Component : EInt1 [ExtInt_LDD]
/
/!
** @brief
** This event is called when an active signal edge/level has
** occurred.
** @param
** UserDataPtr - Pointer to RTOS device
** data structure pointer.
/
/ ===================================================================*/
void EInt1_OnInterrupt(LDD_TUserData UserDataPtr)
{
/ Write your code here … */
uint32_t error;

portBASE_TYPE higherPriorityTaskWoken = pdFALSE;

// Set semaphore
error = xSemaphoreGiveFromISR(MySemaphore, &higherPriorityTaskWoken);

// Activate the task immediately if priority is higher
portEND_SWITCHING_ISR(higherPriorityTaskWoken);

}

Then I have a task with priority 8 which is taking the semaphore

for (;:wink:
{

	if(xSemaphoreTake(MySemaphore, (TickType_t) 20) != pdTRUE)
	{
		ThreadSafePrintf("Missed an interrupt.\n");
	}
 	else
	{
 			function();
            vTaskDelay(5);
	}
}

The configMAX_SYSCALL_INTERRUPT_PRIORITY is set to (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY<<(8-configPRIO_BITS)) where configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYis set to 5

This mechanism is working fine for long time (anywhere from 10 minutes to several hours) and then the function stops executing.

if I am printing the tasks state (using vTaskList), I see that the task is in running stste. The external interrupt is keep running correctly and when the semaphore is given, the result of the xSemaphoreGiveFromIsr is false.

The RTOS will get from this weird state only if I will run a higher priority task (priority 9) which has a vTaskDelay(1) in it. Once the vTaskDelay(1) is executed, the scheduler is switching back to the stuck task and execution proceed as normally.

Please advise as I am desperate
Best regards,
Z

#2

rtel wrote on Tuesday, March 22, 2016:

Is this using the port layer files from the FreeRTOS distribution which has the vPortValidateInterruptPriority() function? (see https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c). If so, then defining configASSERT() will help catch interrupt priority issues. Do you have configASSERT() defined?

#3

zohargolan365 wrote on Tuesday, March 22, 2016:

Thank you for your response

Looks like this portion of the code in port.c is commented out


#if 0 /* NYI */ && configCPU_FAMILY_IS_ARM_M4(configCPU_FAMILY) /* ARM M4(F) core */
#if( configASSERT_DEFINED == 1 )

/*
 * Used by the portASSERT_IF_INTERRUPT_PRIORITY_INVALID() macro to ensure
 * FreeRTOS API functions are not called from interrupts that have been assigned
 * a priority above configMAX_SYSCALL_INTERRUPT_PRIORITY.
 */
#if ( configASSERT_DEFINED == 1 )
     static uint8_t ucMaxSysCallPriority = 0;
     static uint32_t ulMaxPRIGROUPValue = 0;
     static const volatile uint8_t * const pcInterruptPriorityRegisters = ( const volatile uint8_t * const ) portNVIC_IP_REGISTERS_OFFSET_16;
#endif /* configASSERT_DEFINED */

    void vPortValidateInterruptPriority( void )
    {
    uint32_t ulCurrentInterrupt;
    uint8_t ucCurrentPriority;

        /* Obtain the number of the curre

configAssert() is defined in FreeRTOSConfig.h

/* Normal assert() semantics without relying on the provision of an assert.h header file. */
#define configASSERT(x) if((x)==0) { taskDISABLE_INTERRUPTS(); for( ;; ); }

What else can I try?

Thanks
Z

#4

rtel wrote on Tuesday, March 22, 2016:

So the whole thing is taken out by a

#if 0

?

What happens if you put it back in, or try using the file I linked to in
my previous post? Failing that perhaps you could ask the vendor why it
is taken out?

#5

zohargolan365 wrote on Tuesday, March 22, 2016:

I guess there is a reason why it is taken out. I will try to put it back and clean the bad connections. Do you have other suggestion of how to debug the semaphore problem?
I must get this thing resolved ASAP

#6

zohargolan365 wrote on Tuesday, March 22, 2016:

Hi,

OK, so I went back to the project with the FreeRTOS 8.2.3. In this project the vPortValidateInterruptPriority is defined and the configAssert is also defined.
What do I need to do to get the information on the interrupts? the program is not getting stuck in the configAssert macro, so I guess it is not an interrupt issue. Am I correct?

Thank you,
Z

#7

zohargolan365 wrote on Wednesday, March 23, 2016:

All,

Here is what I have to do in order to fix this problem. It sounds like a bug in the FreeRTOS to me.
I had to create a bogus task with high priority. This task looks like

void TaskBogusIdle(void* pdata)
{
	while(1)
	{
		vTaskDelay(5000);
	}
}

Essentailly it does not do anything, but it makes sure the RTOS is not loosing the semaphore.
I really would like to get some help from real time engineering on this issue, as I dont think this is the right way to go

Best regards
Z

#8

rtel wrote on Wednesday, March 23, 2016:

No, this is definitely not the right way to do it. What’s more, this is almost certainly just disguising the problem, as the problem should not exist in the first place.

First, to make sure we are talking about the same thing here and are actually able to support you - is the code you are using now the official 8.2.3 code, unmodified? If you think this is the case, please diff all the code in the FreeRTOS/Source directory between your project and the main V8.2.3 release to be sure.

Once verified that the code is indeed the same, please cut your application down to the absolute minimum that exhibits this behaviour so we can try and find out what is going on. Basically, just the skeleton of the tasks and interrupts that are needed to reproduce the issue. Then attached the skeleton code to your next post in a zip file.

Many years of experience of this type of support request shows it is normally (nearly always) a configuration error, but in V8.2.3 the asserts() would normally catch those, so if the asserts are not catching the problem then it is more interesting.

Please also attach your FreeRTOSConfig.h.

#9

davedoors wrote on Wednesday, March 23, 2016:

before doing that look at the first post again.

if I am printing the tasks state (using vTaskList), I see that the task is in running stste. The external interrupt is keep running correctly and when the semaphore is given, the result of the xSemaphoreGiveFromIsr is false.

Only the task that called vTaskList should show as running. No other task can be running otherwise vTaskList can not be called.

If the task is running but not taking the semaphore then it can only be in the function() function (referring to the code in your first post).

You call vTaskDelay(5) so will miss interrupts if they come in faster than every 5 ticks.

#10

zohargolan365 wrote on Wednesday, March 23, 2016:

Hi Dave,

Thank you for your post.
First the vTaskDeleay(5) is a non problem as the interupt is longer (20ms). Second, I spent a wee to test and retest and tripple test. The function is finishing the execution. The RTOS still thinks its in running state, but the function exited already.
Well, I will try the real time engineering suggestion
Thanks,
Z

#11

zohargolan365 wrote on Wednesday, March 23, 2016:

The code is a port for kinetis devices from MCUonEclipse component. Released on february 2016. I will try the diff to the source and see if I can find anything. I dont think I will have enough time to do that, as I have 2 projects that needs to be finished this month. I will update the post when I will have time.

Best regards,
Z