Mutex hang

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

davedoors wrote on Thursday, December 03, 2015:

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

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?

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

rtel wrote on Thursday, December 03, 2015:

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

Hi,

this must be the last statements before crashing …

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

rtel wrote on Thursday, December 03, 2015:

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.

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

woops_ wrote on Thursday, December 03, 2015:

#include "freertos.h"
#include "task.h"

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

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 …

rtel wrote on Thursday, December 03, 2015:

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.

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

gerhardkreuzer wrote on Thursday, December 03, 2015:

ahhh ( pvBuffer == NULL) ==> True

rtel wrote on Thursday, December 03, 2015:

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).

gerhardkreuzer wrote on Thursday, December 03, 2015:

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

rtel wrote on Friday, December 04, 2015:

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.

gerhardkreuzer wrote on Friday, December 04, 2015:

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