2023-08-04 01:58 PM - edited 2023-08-04 03:00 PM
Hello there.
In my project, I am using LWIP with FreeRTOS at CMSISv1 and static memory allocation (configSUPPORT_STATIC_ALLOCATION = 1, configSUPPORT_DYNAMIC_ALLOCATION = 0). Is this a supported configuration? When I generate code, LWIP/Target/ethernetif.c:low_level_init contains calls to xSemaphoreCreateBinary(), which is defined only when dynamic allocation is enabled. Is this a known bug? If so, what is a workaround that I can use? Buildable code would have calls to xSemaphoreCreateBinaryStatic() instead. Right now, I am unable to fix the code in such a way that the changes will not be wiped out by the next CubeMX code generation, as the code is not within a USER CODE section.
For reference, I am using a STM32H743BITx MCU, V1.10 firmware package and STM32CubeMX version 6.6.1. If this is an issue that has been resolved in a higher version, please let me know.
Thank you!
Solved! Go to Solution.
2023-08-05 10:41 AM
> I am unable to fix the code in such a way that the changes will not be wiped out by the next CubeMX code generation, as the code is not within a USER CODE section.
Now this is clearer, thanks. But we'll have to live with this, at least until ST fixes something (which is not warranted). My advice is - develop a procedure that includes a. review of changes caused by re-generation and b. discarding unwanted changes.
2023-08-04 02:11 PM
Workaround: replace the "CMSIS RTOS" crutches with direct calls to FreeRTOS API as appropriate (in static allocation variant). There isn't a lot of places to fix, just a few.
Be happy.
2023-08-04 02:59 PM
Pavel,
The xSemaphoreCreateBinary*() calls are part of the FreeRTOS API, not CMSIS. The fix to this bug would be to have calls to xSemaphoreCreateBinaryStatic() instead of xSemaphoreCreateBinary(). I am unable to fix the code in such a way that the changes will not be wiped out by the next CubeMX code generation, as the code is not within a USER CODE section. I have updated the original post with this clarification. I hope this makes sense.
2023-08-05 10:41 AM
> I am unable to fix the code in such a way that the changes will not be wiped out by the next CubeMX code generation, as the code is not within a USER CODE section.
Now this is clearer, thanks. But we'll have to live with this, at least until ST fixes something (which is not warranted). My advice is - develop a procedure that includes a. review of changes caused by re-generation and b. discarding unwanted changes.