LWIP with CMSISv1 and static memory allocation

[djm]

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!

[Pavel A.]

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.

 

[djm]

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.

[Pavel A.]

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