Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Mutex hang

Posted by gerhardkreuzer on December 3, 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


Mutex hang

Posted by davedoors on December 3, 2015

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


Mutex hang

Posted by gerhardkreuzer on December 3, 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?

Attachments

Mutex%20Hung.PNG (27025 bytes)

Mutex hang

Posted by gerhardkreuzer on December 3, 2015

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


Mutex hang

Posted by rtel on December 3, 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?


Mutex hang

Posted by gerhardkreuzer on December 3, 2015

Hi,

this must be the last statements before crashing ...

Attachments


Mutex hang

Posted by gerhardkreuzer on December 3, 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


Mutex hang

Posted by rtel on December 3, 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.


Mutex hang

Posted by gerhardkreuzer on December 3, 2015

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


Mutex hang

Posted by gerhardkreuzer on December 3, 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


Mutex hang

Posted by woops_ on December 3, 2015

~~~~

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

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


Mutex hang

Posted by gerhardkreuzer on December 3, 2015

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


Mutex hang

Posted by gerhardkreuzer on December 3, 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 ...


Mutex hang

Posted by rtel on December 3, 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.


Mutex hang

Posted by gerhardkreuzer on December 3, 2015

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

Attachments

here%20it%20hungs.PNG (33413 bytes)

Mutex hang

Posted by gerhardkreuzer on December 3, 2015

ahhh ( pvBuffer == NULL) ==> True


Mutex hang

Posted by rtel on December 3, 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).


Mutex hang

Posted by gerhardkreuzer on December 3, 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


Mutex hang

Posted by rtel on December 4, 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.


Mutex hang

Posted by gerhardkreuzer on December 4, 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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS