Hi,

I create an mutex, works. I give that mutex, works. I try to take that mutex, but now the xSemaphoreTake( ..) function hangs. And yes I would check the returned value, I used a time out and no time out, it just hangs. And yes, the sheduler is running and the system works (some tasks running, serial console ... everything works until I try to use this mutex.

Any ideas how I can find something about a reason?

With best regards

Gerhard

What 'hangs'? You mean the function doesnt return or the system crashes. Maybe it hit an assert. Do you have a debugger?

Hi,

more infos yet. Try to Give/take a mutex within the loop of another task, works fine. When I step into the take function it turns out, that the program hungs on entering the critical section. Any ideas?

.. the system crashes. Yes I have a debugger, see my later post to get infos where it hungs ...

Do you mean, in the screen shot, you can step into the taskENTER_CRITICAL() macro, but not out again? Which port are you using?

Hi,

this must be the last statements before crashing ...

yes correct, I use the port provided by Atmel together with the Atmel Studio 6.2.1563 SP2. I can step into but not out

I also add some stack space for the task running that code. 4096 original, +512 but no changes.

Any idea in which direction to search?

With best regards

Gerhard

That function is doing very little that could make the system crash. Possibilities are:

• the error actually occurred before this function started to execute, for example, maybe the mutex object has been corrupted by something.
• The CPU privilege state has somehow changed, denying access to the registers being access by that macro (extremely unlikely, unheard of).
• The return address in the bx lr function has been corrupted.

The CPU won't just crash and freeze, so you need to see what happens when it crashes. Most likely the processor will go into a fault handler, in which case you have the opportunity of debugging how it got there.

Do you have configASSERT() defined, and are you using a recent version of FreeRTOS so configASSERT() will help trap a wider range of configuration errors?

Have you set the priority of all the interrupts that are being used? You must not leave any at their default if they use FreeRTOS function.

Thanks, will check everything carefully this evening/night, hope my coffe machine (and the processor within) wouldn't crash too ...

Hi,

hmm, implemented the HardFault_Handler, but never gets there. Is there any trick to execute a line of asm code which definitely brings me there? Just for checking the handler ((Searching a problem with a not working tool is a never ending strory))

With best regards

Gerhard

~~~~

TaskHookFunction_t myNullFunc = NULL; myNullFun(); /* boom, calling null function */ ~~~~

thanks, seems I have to refill coffee now ... sorry about that silly question.

Ok, the HardFault_Handler is working, calling the null function immediately ends there .. But taking the semaphore just hungs the system without calling that handler ...

Once the system is hung, pause the debugger, what is being executed? If you cannot see C code being executed, look at the value of the program counter (either in the register, or bringing up a disassembly window to see the address) then see which function it is in. You can get the function from the program counter value either by looking at the map file, or doing an objdump of the binary to an assembly file.

.. fine, works it hungs in the generic receive function ...

ahhh ( pvBuffer == NULL) ==> True

So it has just hit an assert(). They are there to allow you to find the cause of a potential crash quickly by simply stopping the debugger and seeing which line it is on, or defining assert to print out the line number and file name (LINE, FILE).

Hmmmm,

configASSERT( !( ( pvBuffer == NULL ) && ( pxQueue->uxItemSize != ( unsigned portBASE_TYPE ) 0U ) ) );

This line fails, cause ( pxQueue->uxItemSize != ( unsigned portBASE_TYPE ) 0U ) ) evaluates to false .... How can I do that in application code???

I put guard variables around the semaphors, but this doesnt change anything ...

With bes regards

Gerhard

Mutexes are built on top of queues and both use the function in question. Queues store data, so for a queue uxItemSize is not zero, and pvBuffer must not be null. Mutexes and semaphores on the other hand do not store data, so for any kind of semaphore uxItemSize is expected to be zero, and it is also expected that pvBuffer is NULL as no data is copied into the buffer.

If you are passing a mutex into the function then uxItemSize should be zero. If its not then the mutex is somehow corrupt, or what you are passing into the function is not the mutex.

Regards.

Thanks a lot, this was it. I missed a '*' for dereferncing and so I take some memory intead of the semaphore.

With best regards

Gerhard