Dear FreeRTOS community,

I have a problem with FreeRTOS, which drives me mad for the last days/weeks. My simplified situation is now: I have a custom board which works fine with multiple STM32 (please exclude the custom board from the reasons of my problem). Two are communicating via USART. So the faulting STM32 usually just receives USART messages and writes an event into a queue. A handler task (Prio 4) then processes the event. configMAX_PRIORITIES set to 5. I disabled all the other processing stuff on that uC. This concept runs fine and smooth, most of the time.

After some random time, between 5-30mins, the handler task is no longer executed. Debugging shows that: uxTopReadyPriority = 0 and pxReadyTasksLists[4]->uxNumberOfItems = 1 pxIndex shows that this is my handler task, ready and waiting to be executed.

As there is no other task running at prio 4 my handler task is never executed.

I tried this with FreeRTOS v7.2.0 and v8.0.0, configASSERT defined (not hit though).

Is this a bug in FreeRTOS? How can uxTopReadyPriority become 0 when there is a ready task? I can futher investigate this issue if somebody can tell me what I should be looking for. I am currently not very much into the FreeRTOS source code.

My config is as follows: ~~~~~

/* Co-routine definitions. */

/* Set the following definitions to 1 to include the API function, or zero to exclude the API function. */

/* This is the raw value as per the Cortex-M3 NVIC. Values can be 255 (lowest) to 0 (1?) (highest). */

/* This is the value being used as per the ST library which permits 16 priority values, 0 to 15. This must correspond to the configKERNELINTERRUPTPRIORITY setting. Here 15 corresponds to the lowest NVIC value of 255. */

// Software Timers

~~~~~

This is almost always a problem with interrupts, an interrupt handler calling a non-FromISR routine, or an interrupt of wrong priority using the FromISR routine.

I am not sure how much of that is actually caught by configASSERT()

The other possible problem could be a stack overflow (configCHECKFORSTACK_OVERFLOW is good, but not perfect)

I was expecting this answer to come. I triple checked my code, it is rather minimal now with all unneeded stuff commented out, but the problem persists. Highest IRQ is on level 12, FreeRTOS is safe up to 4 in my configuration. I even checked the NVIC in debug after the task stopped, no priority above 12. From all IRQs I use xQueueSendFromISR. Strange thing is, my program runs for quite some time until one task stops. I have a xHeap size of 60k and also increased stack size to 2048 (resulting in 8kB), which is quite a lot. The problem persists.

If you say "almost always", what are the other reasons I might encounter?

BTW: I use GCC version 4.8-2014q1-update from linaro.

I would agree your symptom is of an interrupt priority configuration error. It would seem that if your ISR is genuinely running at priority 12, then you should be ok with the FreeRTOSConfig.h settings you already posted. However, have you called:

NVICPriorityGroupConfig( NVICPriorityGroup_4 );

Anywhere in your code? If not, then you will not really be running at priority 12.

If you are calling the above function then please post your UART interrupt handler code.

Regards.

Yes I have the NVICPriorityGroupConfig(NVICPriorityGroup_4) call directly in my main(), after I setup clocks and before I use any RTOS function.

My IRQ code is:

<!-- HTML generated using hilite.me -->

void USARTIRQ(USART* pUSART)
{
	uint16t sr = pUSART->pRegister->SR;
	uint16t event = 0;
	int32t yield = pdFALSE;
	if((sr & USARTSRTC) && USARTGetTCIE(pUSART->pRegister))	// transfer complete
	{
		USARTClearTCIE(pUSART->pRegister);	// prevent IRQ refiring due to TC
		event = EVENTTXDONE;
		if(xQueueSendFromISR(pUSART->hEventQueue, &event, &yield) != pdTRUE)
			Log(0x6000);
	}
	if((sr & (USARTSRORE | USARTSRFE | USARTSRNE)) && USARTGetEIE(pUSART->pRegister))
	{
		// clear interrupt enable
		USARTClearEIE(pUSART->pRegister);
		if(sr & USARTSRORE)
			event |= EVENTRXERRORORE;
		if(sr & USARTSRFE)
			event |= EVENTRXFE;
		if(sr & USARTSRNE)
			event |= EVENTRXERRORNE;
		if(xQueueSendFromISR(pUSART->hEventQueue, &event, &yield) != pdTRUE)
			Log(0x7000);
	}
	portENDSWITCHING_ISR(yield);
}

Could you strip down your project so it contains the least amount of code and functionality required to demonstrate the problem, make sure it builds without any absolute paths, zip it up, then send it to the "business contact" email found on http://www.freertos.org/contact

Regards.

Hi is there any updates on this issue? I think I might have the same problem.

Thanks!