xygblarbin wrote on Monday, July 25, 2016:
Hi all,
I have an application I’m writing for a Atmel sam4sd32a, with FreeRTOS. I modified an existing FreeRTOS sample project for the Sam4s to get up and running.
As my code got more complex, I started noticing some of the threads freezing, and tracked them down on the call stack.
Any time a thread freezes, it is because the variable uxCriticalNesting is already 0 when vPortExitCritical is called.
My code has binary semaphores, mutexes, and queue messaging implemented in it.
The thread that freezes most often is an LCD thread that uses the USART in SPI mode to write to the screen. The thread actually freezes when attempting to return the mutex that it has checked out. It freezes in vPortExitCritical because uxCriticalNesting is already zero. Here is some psuedo-code:
LcdSendBuffer(void)
{
while(xSemaphoreTake(m_LcdMutex, 1000) != pdTrue)
{
vTaskDelay(1);
}
WriteData();
xSemaphoreGive(m_LcdMutex);
}
I cannot see why uxCriticalNesting would already be zero here. It’s pretty obvious this code SHOULD have the mutex.
The other thread that freezes up is a comm thread that sends messages out the ACTUAL SPI peripheral. However, every time it is frozen is when it is attempting to check for a new Queue message. When checking for the new queue message, the thread freezes up in vPortExitCritical as well, also because uxCriticalNesting is already 0.
I’ve looked at my code extensively, and cannot see a reason why this would be happening. I can’t post the actual code, since it is for a commercial product, but I will answer any questions that will help uncover a solution.
Thanks,
- Mike