I use semaphore technology in uart (rs485) packet parser in stm32l151 mc project. xSemaphoreGiveFromISR from uart '"recieve line idle" interrupt starts parser. After forming an answer packet task waits for "transmit end" interrupt with xSemaphoreGiveFromISR that gives the same (!) semaphore. After that task returns in recieve mode and waits for recieve semaphore. Problem: after few hours of work I detect semaphore fail. The task just freezes. I see xSemaphoreGiveFromISR execution, but xSemaphoreTake doesn't execute. Besides uart parser task there're another tasks working (they have mutex hold inside). I've tested programm work without them - no semaphore fail. What problem can it be? I've checked unallocated memory for FreeRTOS - about 600 words (or bytes). No stackoverflow, no mallocfail. May be there some memory leak? May I should separate semaphores for recieve and trancieve? Help me detect an error.

When you say, maybe there is a memory leak, where are you allocating and freeing memory? FreeRTOS will not be allocating and freeing unless you are creating and deleting objects (dynamically, rather than statically) at run time.

Normally problems such as your are due to invalid interrupt priorities. Do you have configASSERT() defined - best to use a recent version of FreeRTOS too as recent versions perform more assert checks.

Thanks for answer! What do you mean by "invalid interrupt priorities"? For uart and dma (didn't mention that I use dma transfer) I have priority 3. How configASSERT will help to find reason why semaphores stop to work?

http://www.freertos.org/FAQHelp.html http://www.freertos.org/RTOS-Cortex-M3-M4.html

Thanks, it were wrong priority settings. UART works stable now. But another problem appeared: now low priority tasks (lower than uart parser task) freeze after some time. There are no more interrupts beside dma and uart.

The biggest reason I have seen for low priority tasks not running is that a higher priority task starves them by not blocking. EVERY task (except the Idle task, and possible other Idle Priority tasks) should block on sometthing if not actively doing useful work. Polling loops and the like do not belong in an application running under a RTOS. If you need such a loop, it really must be in an Idle priority task, and either enable time-slicing or put a Yield in the loop.

Does the uart parser task block on a queue/semaphore waiting for more characters? or is it in a busy loop checking for data.

Remember, unlike some general purpose OSes, lower priority doesn't mean give a lower share of CPU time, but they are put at the back of the line to get the CPU, and higher priority tasks get to 'cut' the line. The running task is always of the highest priority that has a ready task.

No, I block all tasks with vTaskDelay or Semaphore/Mutex take.

A semaphore or muutex won't block if the resource is available, so you could still starve a lower priority task, if your loop is just taking semaphores/mutexes.