STM32CubeMX 6.17.0 breaks FreeRTOS

[Simon]

I upgraded to 6.17 this morning an have already had to roll back due to a bug in how it now generates fiels for FreeRTOS.

Under the FreeRTOS (Include parameters) options I have this vTaskDelayUntil set to Enabled.  This now changes the define name in the user config file (Core/Inc/FreeRTOSConfig.h) to be 

#define INCLUDE_xTaskDelayUntil 1

which is correct for the updated freeRTOS version, but in the file (Middleware/Thrid Party/FreeRTOS/Source/CMSIS_RTOS_V2/freertos_os2.h) it has not been updated so it now it throws an error stopping my projects from building. There are other places where vTaskDelayUntil has also not been updated to xTaskDelayUntil. This needs to be fixed.

[Ghofrane GSOURI]

Hello @Simon  

First let me thank you for posting.

Could you please provide your IOC?

I will be waiting for your feedback.

Thx

Ghofrane 

[Simon]

Hi Ghofrane,

Please find attached IOC.

[Ghofrane GSOURI]

Hello @Simon  

I am using STM32CubeMX 6.17.0.

After generating the code with your IOC configuration, I encountered the following error, which is currently under investigation:

In file included from ../Middlewares/Third_Party/LwIP/src/include/lwip/memp.h:58,
                 from ../Middlewares/Third_Party/LwIP/src/include/lwip/stats.h:43,
                 from ../Middlewares/Third_Party/LwIP/system/OS/sys_arch.c:38:
../Middlewares/Third_Party/LwIP/src/include/lwip/priv/memp_priv.h:89:5: error: expected expression before ')' token
   89 |     ) ,
      |     ^
arm-none-eabi-gcc "../Middlewares/Third_Party/LwIP/src/netif/ppp/chap-md5.c" -mcpu=cortex-m7 -std=gnu11 -g3 -DDEBUG -DUSE_PWR_DIRECT_SMPS_SUPPLY -DUSE_HAL_DRIVER -DSTM32H725xx -c -I../Core/Inc -I../LWIP/App -I../LWIP/Target -I../wolfTPM -I../Middlewares/Third_Party/LwIP/src/include -I../Middlewares/Third_Party/LwIP/system -I../Drivers/STM32H7xx_HAL_Driver/Inc -I../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy -I../Middlewares/Third_Party/FreeRTOS/Source/include -I../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2 -I../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F -I../Drivers/CMSIS/RTOS2/Include -I../Drivers/BSP/Components/lan8742 -I../Middlewares/Third_Party/LwIP/src/include/netif/ppp -I../Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../Middlewares/Third_Party/LwIP/src/include/lwip -I../Middlewares/Third_Party/LwIP/src/include/lwip/apps -I../Middlewares/Third_Party/LwIP/src/include/lwip/priv -I../Middlewares/Third_Party/LwIP/src/include/lwip/prot -I../Middlewares/Third_Party/LwIP/src/include/netif -I../Middlewares/Third_Party/LwIP/src/include/compat/posix -I../Middlewares/Third_Party/LwIP/src/include/compat/posix/arpa -I../Middlewares/Third_Party/LwIP/src/include/compat/posix/net -I../Middlewares/Third_Party/LwIP/src/include/compat/posix/sys -I../Middlewares/Third_Party/LwIP/src/include/compat/stdc -I../Middlewares/Third_Party/LwIP/system/arch -I../Drivers/CMSIS/Include -I../Middlewares/Third_Party/wolfSSL_wolfTPM_wolfTPM/wolftpm/ -I../wolfSSL -I../Middlewares/Third_Party/wolfSSL_wolfSSL_wolfSSL/wolfssl/ -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Middlewares/Third_Party/LwIP/src/netif/ppp/chap-md5.d" -MT"Middlewares/Third_Party/LwIP/src/netif/ppp/chap-md5.o" --specs=nano.specs -mfpu=fpv5-d16 -mfloat-abi=hard -mthumb -o "Middlewares/Third_Party/LwIP/src/netif/ppp/chap-md5.o"
make: *** [Middlewares/Third_Party/LwIP/system/OS/subdir.mk:19: Middlewares/Third_Party/LwIP/system/OS/sys_arch.o] Error 1
make: *** Waiting for unfinished jobs....
"make -j8 all" terminated with exit code 2. Build might be incomplete.

13:03:08 Build Failed. 3 errors, 0 warnings. (took 56s.577ms)

I have no build errors related to FreeRTOS, so I’m not sure what I’m missing. Could you please share a screenshot of the issue you described, where Middleware/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/freertos_os2.h is not updated and causes a build error?

THX

Ghofrane

[Simon]

So, I had to manually install a newer ARM.CMSIS pack 5.9.0 and then it built and the app mostly works, except now the ethernet functionality doesn't work. ARP packets are not getting through to the etharp_input function. I found a rather obscure breaking change mentioned in the release notes.

The suggested solution here is so simplistic that  it is not useful. How is this meant to be fixed in user application code?

[Ghofrane GSOURI]

Hello @Simon  

I suggest that you raise your question in the Embedded Software forum:
https://community.st.com/t5/stm32-mcus-embedded-software/bd-p/mcu-embedded-software-forum

There you will receive more dedicated technical support from  ST experts.

THX

Ghofrane

[Andrew Neil]

Related: Unable to generate FreeRTOS code after migration ?