Skip to main content
Associate III
January 7, 2025
Solved

CubeIDE includes wrong file for STM32WL33 when RTOS NEWLIB_REENTRANT defined

  • January 7, 2025
  • 4 replies
  • 1326 views

I am generating code for the STM32WL33 using CUBEIDE 1.17 and am using CMSIS V2. The IOC editor insists (but does not enforce) that NEWLIB_REENTRANT be enabled before generation. When compiling, the file "FreeRTOS.h" erroneously includes "newlib-freertos.h", which does not exist. Other projects I have that use a similar configuration have different content in the same file, including <reent.h>. Is this what it is supposed to be, and do I have the correct version of 'FreeRTOS.h'. This file looks like it is edited during the generation process, so do I have the wrong prototype? The source is below, with the modification it does compile. CubeMX behaves in the same manner.

 

 

/* Required if struct _reent is used. */

#if ( configUSE_NEWLIB_REENTRANT == 1 )

 

#include "newlib-freertos.h" // generated by WL33 IOC

-- OR --

#include <reent.h> // generated by a different project

#endif /* if ( configUSE_NEWLIB_REENTRANT == 1 ) */

Thanks.

 

Best answer by STTwo-32

Hello @divmstr 

I've been able to reproduce this behavior will USE_NEWLIB_REENTRANT parameter is enabled. If it is disabled, I have nothing. I've escalated this internally for correction (under internal ticket number 200839).

PS: Issue solved on the last release of the STM32CubeMX

Best Regards.

STTwo-32

4 replies

STTwo-32
Technical Moderator
January 7, 2025

Hello @divmstr 

I'm not able to reproduce this behavior on my side (code generated gives no compilation error). Could you please give me the .IOC file used to reproduce this behavior.

Best Regards.

STTwo-32

divmstrAuthor
Associate III
January 15, 2025

Please find the ioc file attached, and below are the error messages:

 

make: *** [Middlewares/Third_Party/FreeRTOS/Source/portable/MemMang/subdir.mk:19: Middlewares/Third_Party/FreeRTOS/Source/portable/MemMang/heap_4.o] Error 1

make: *** Waiting for unfinished jobs....

make: *** [Middlewares/Third_Party/FreeRTOS/Source/portable/Common/subdir.mk:19: Middlewares/Third_Party/FreeRTOS/Source/portable/Common/mpu_wrappers.o] Error 1

make: *** [Middlewares/Third_Party/FreeRTOS/Source/subdir.mk:37: Middlewares/Third_Party/FreeRTOS/Source/event_groups.o] Error 1

make: *** [Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM0/subdir.mk:19: Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM0/port.o] Error 1

make: *** [Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/subdir.mk:19: Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os2.o] Error 1

make: *** [Middlewares/Third_Party/FreeRTOS/Source/subdir.mk:37: Middlewares/Third_Party/FreeRTOS/Source/list.o] Error 1

make: *** [Middlewares/Third_Party/FreeRTOS/Source/subdir.mk:37: Middlewares/Third_Party/FreeRTOS/Source/croutine.o] Error 1

In file included from ../Middlewares/Third_Party/FreeRTOS/Source/queue.c:37:

../Middlewares/Third_Party/FreeRTOS/Source/include/FreeRTOS.h:108:14: fatal error: newlib-freertos.h: No such file or directory

108 | #include "newlib-freertos.h"

| ^~~~~~~~~~~~~~~~~~~

compilation terminated.

divmstrAuthor
Associate III
January 15, 2025

More  information: The FreeRTOS kernel version is 10.6.2. I have other code that does work, but it runs on V10.3.1 that does not seem to have the same problem.

 

divmstrAuthor
Associate III
January 15, 2025

More information: I found the FreeRTOS distribution for the kernel v10.6.2 on Github. In the include directory, there are three files that are missing from the CubeIDE include directory:

mpu_syscall_numbers.h

newlib_freertos.h

picolibc_freertos.h

I don't know how these are stored in CubeIDE, if you could tell me I can add them to the distribution master. FYI my CubeIDE is at rev 1.17

STTwo-32
STTwo-32Best answer
Technical Moderator
January 20, 2025

Hello @divmstr 

I've been able to reproduce this behavior will USE_NEWLIB_REENTRANT parameter is enabled. If it is disabled, I have nothing. I've escalated this internally for correction (under internal ticket number 200839).

PS: Issue solved on the last release of the STM32CubeMX

Best Regards.

STTwo-32