I get following error while compiling FreeRTOS. This error occured after enabling configUSERECURSIVEMUTEXES: Error[Pe223]: function “xSemaphoreTake” declared implicitly …FreeRTOSSourcequeue.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

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

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

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

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 configUSERECURSIVEMUTEXES, 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

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 configUSERECURSIVEMUTEXES, 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

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!