STM32WL LoRaWAN End Node LBM – CubeMX regeneration breaks project

[KennyD1]

Hello,

I am working with the STM32WL55 Nucleo board using the official LoRaWAN_End_Node_LBM example from STM32CubeWL firmware package v1.5.0.

I am trying to modify the project using STM32CubeMX with STM32CubeIDE toolchain, but I consistently run into issues after regenerating code from the .ioc file.

After CubeMX regeneration the project often stops building correctly. I get missing HAL driver references such as undefined reference to HAL_SPI_Init or missing stm32wlxx_hal_spi.c during linking (after adding SPI in CubeMX). In some cases there are also errors like no rule to make target stm32wlxx_hal_tim.c. Looks like CubeMX removed some files when generating code.

There are also problems with the LoRa radio middleware. After regeneration I sometimes see multiple radio drivers being included even though the STM32WL uses the integrated SX126x radio. This leads to conflicts with sx127x, sx128x, lr11xx or llcc68 components being pulled into the build even though they are not used in this hardware.

What is important is that the original ST example builds correctly without any modifications. The problems only appear after regenerating the project using CubeMX, especially when using STM32CubeIDE toolchain or when changing configuration in the .ioc file.

I have seen older forum discussions describing similar behavior and I am wondering whether this issue has been resolved or if it is still expected behavior.

Any clarification on the recommended workflow would be appreciated.

Thank you!

[KennyD1]

Duplicate - merged.

---

Hello,

I am working with the STM32WL55 Nucleo board using the official LoRaWAN_End_Node_LBM example from STM32CubeWL firmware package v1.5.0.

I am trying to modify the project using STM32CubeMX with STM32CubeIDE toolchain, but I consistently run into issues after regenerating code from the .ioc file.

After CubeMX regeneration the project often stops building correctly. I get missing HAL driver references such as undefined reference to HAL_SPI_Init or missing stm32wlxx_hal_spi.c during linking (after adding SPI in CubeMX). In some cases there are also errors like no rule to make target stm32wlxx_hal_tim.c. Looks like CubeMX removed some files when generating code.

There are also problems with the LoRa radio middleware. After regeneration I sometimes see multiple radio drivers being included even though the STM32WL uses the integrated SX126x radio. This leads to conflicts with sx127x, sx128x, lr11xx or llcc68 components being pulled into the build even though they are not used in this hardware.

What is important is that the original ST example builds correctly without any modifications. The problems only appear after regenerating the project using CubeMX, especially when using STM32CubeIDE toolchain or when changing configuration in the .ioc file.

I have seen older forum discussions describing similar behavior and I am wondering whether this issue has been resolved or if it is still expected behavior.

Any clarification on the recommended workflow would be appreciated.

Thank you!

[Ghofrane GSOURI]

Hello @KennyD1 

Could you please share the .ioc file in which you applied your modifications and encountered these errors?

THX

Ghofrane

[Andrew Neil]

Are you being sure to keep all your code changes within USER sections?

Have you tried doing a diff between before & after regeneration - to see exactly what is getting changed?

Could you post your initial project which works, and also one which fails after regeneration?

[KennyD1]

Of course,

this is my ioc file.

It is basically new project from example Lora End Node. 

I did change toolchain in CubeMX to STM32CubeIDE, and added SPI. 

Thank you for your answer :)

[KennyD1]

Thank you for your response.

At this stage I have not added any application-level code yet, so USER CODE sections are not relevant for this issue.

I have attached two project states: one before CubeMX regeneration and one after regeneration. The issue is fully reproducible by generating code from the same .ioc file using STM32CubeIDE toolchain, without any manual code changes.

The problem appears immediately after regeneration and results in build failures related to missing HAL sources and middleware inconsistencies.