compile error after enabling configUSE_RECURSIVE_MUTEXES

rgqsch wrote on Thursday, May 09, 2019:

I get following error while compiling FreeRTOS. This error occured after enabling configUSE_RECURSIVE_MUTEXES:

Error[Pe223]: function “xSemaphoreTake” declared implicitly …\FreeRTOS\Source\queue.c 670

After adding #include “semphr.h” in queue.c (on line 40) the error disappears, however we want to use ‘stock’ code, so altering this code in our implementation is not an option.

Is there some other way to get this working, or is a code change required?

Configuration:
FreeRTOS V10.2.0
STM32H7

rtel wrote on Thursday, May 09, 2019:

When using FreeRTOS API functions you need to first include FreeRTOS.h
at the top of the file, then include the header file for the API
function being called. In your case you are using recursive mutexes, so
you need to include semphr.h. (the abbreviated name dates back to when
file names had to be in 8.3 format). Here is an example at the top of
the source file that demonstrates/tests recursive mutexes:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Demo/Common/Minimal/recmutex.c#l66

rgqsch wrote on Friday, May 10, 2019:

Dear Richard,

Thanks for the swift reply, however I cannot follow your post. I understand I need to include FreeRTOS.h before all other includes.
I have done this in my application, and it compiles and run. Now I need to change one mutex to a recursive mutex.

So configUSE_RECURSIVE_MUTEXES is enabled in my config, but without changing my application code I get a compilation error at queue.c:670. When manually adding #include “semphr.h” in queue.c the code is compiling again.

rtel wrote on Friday, May 10, 2019:

Do you include both FreeRTOS.h and semphr.h at the top of every C source
file in which you use semaphores (including mutexes and recursive mutexes)?

rgqsch wrote on Monday, May 13, 2019:

Yes,
I have a working application with regular mutexes (so FreeRTOS.h and semphr.h are included)

Now I need to add a recursiveMutex so I enabled configUSE_RECURSIVE_MUTEXES, this will cause
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l649
to unlock the call to xSemaphoreTake in line:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l670

However, this function is defined at
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/include/semphr.h#l289

Since queue.c doesn’t include semphr.h
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l36

The function cannot be found, and throws a compilation error, in my opinion there can be 2 solutions to this:

  1. Add semphr.h to the queue.c includes
  2. Change the functioncall in queue.c to xQueueSemaphoreTake

rtel wrote on Monday, May 13, 2019:

Sorry, I’m still not able to understand yet. Thank you for your
patients. I have added some comments inline below:

Now I need to add a recursiveMutex so I enabled
configUSE_RECURSIVE_MUTEXES, this will cause
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l649
to unlock the call to xSemaphoreTake in line:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l670

Line 670 calls xQueueSemaphoreTake(). Note the ‘Queue’ in the name,
because the function is defined is also defined in queue.c.

The prototype for xQueueSemaphoreTake() is in queue.h, not semphr.h:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/include/queue.h#l1418

As you are including semphr.h in your C source file, and semphr.h
includes queue.h, then the prototype and implementation of
xQueueSemaphoreTake() seem to be in scope, hence my confusion here:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/include/semphr.h#l35

However, this function is defined at
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/include/semphr.h#l289

That line is defining xSemphoreTake(), which is a public macro intended
for use by application code. Note this does not have the ‘Queue’ in the
name, so it is different to xQueueSemaphoreTake() which is not a
published API function and intended only for use by the kernel code
itself. Was line 289 the line you intended to highlight?

The function cannot be found, and throws a compilation error, in my
opinion there can be 2 solutions to this:

  1. Add semphr.h to the queue.c includes
  2. Change the functioncall in queue.c to xQueueSemaphoreTake

As per this link, I think it already is xQueueSemaphoreTake():
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V10.2.0/FreeRTOS/Source/queue.c#l670

rgqsch wrote on Tuesday, May 14, 2019:

Dear Richard,

It seems I have found the problem. My code says xSemaphoreTake. So I probably have made an error while updating FreeRTOS. The latest code indeed says xQueueSemaphoreTake.

Cheers!