xSemaphoreTake in FreeRTOS V4.7.2

spyhabs wrote on Friday, June 27, 2008:

Hello,

My project is dedicated for the Cortex M3 CPU.  I’m cycling our board in order to test the firmware. I created several tasks,  Some tasks wait for a binary semaphore.  Each of them, I defined a block time to wait for the semaphore.  One of them is 20 ms and the other one is 10 ms.  The cycling test is to capture a signal from an input (using a timer capture).  So I can get ~200 interrupts in 100 ms @ each 8 seconds.  (signal — wait 8 sec — signal —).

The problem is the following one.  Sometimes, the os freezes in vListInsert() called from a xSemaphoreTake()… 

It loops for ever in a for loop()

for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )
{
   /* There is nothing to do here, we are just iterating to the
      wanted insertion position. */
}

We have 10 boards in cycling test, 9/10 boards got this problem < 15 minutes. 

I’m using IAR to compile and debug the project.

I hope to get an answer from you soon.

Regards

Christian

edwards3 wrote on Friday, June 27, 2008:

I would say you have most likely corrupted your data somewhere. Have you checked how much stack is left free in your tasks?

spyhabs wrote on Friday, June 27, 2008:

Yeah each task has enough space in the stack.  Is it a way to see how many space left in the stack?  I verified in the memory window, I can count how many 0xA5 is present in each stack.

daworm wrote on Thursday, August 14, 2008:

Look at vTaskList to get a list of tasks and their min stack remaining (it shows the lowest free bytes, not the most used bytes).

I’m having the same problem, only with serial interrupts causing the problem.  In my ISR, I read a queue to send data, write a queue with received data (just like the demos).  Another task reading a queue will hang exactly the way you describe almost immediately if I have more than one serial port active, or after a few hours if only one is active.  My stacks look fine (well over 100 bytes extra in each).