generated CMakeLists.txt for STM32WBA25 BLE projects fails to link

missing --start-group around WBA2_LinkLayer_BLE_Full_lib.

Environment

• STM32CubeMX version: 6.17.0
• STM32CubeWBA firmware package: 1.9.0
• Target device: STM32WBA25CG (NUCLEO-48 board)
• Toolchain: GNU Tools for STM32 14.3.1+st.2 (arm-none-eabi-gcc/ld)
• Build system: CMake (toolchain selected via "CMake" in CubeMX project settings)
• Host OS: Windows 11

Steps to reproduce

1. Create a new STM32CubeMX project for STM32WBA25 (NUCLEO board).
2. Enable BLE (peripheral role, BLE_Full stack).
3. In Project Manager → Toolchain/IDE, select CMake.
4. Generate code.
5. Build with the generated CMakeLists (e.g. cube-cmake --build build/Debug).

Expected Build links cleanly.

Actual Link fails with:

ld.exe: stm32wba_ble_stack_full.a(le_ctrl.o): in function `LECTRL_LL_Init':
 le_ctrl.c:(.text.LECTRL_LL_Init+0xa): undefined reference to `ll_ble_events_init'
ld.exe: (ll_ble_events_init): Unknown destination type (ARM/Thumb) in
 stm32wba_ble_stack_full.a(le_ctrl.o)
 le_ctrl.c:(.text.LECTRL_LL_Init+0xa): dangerous relocation: unsupported relocation

Root cause The generated cmake/stm32cubemx/CMakeLists.txt emits the BLE archives in this order in MX_LINK_LIBS:

set(MX_LINK_LIBS
 :WBA2_LinkLayer_BLE_Full_lib.a
 :stm32wba_ble_stack_full.a
 ...
)

which produces the link line:

... -l:WBA2_LinkLayer_BLE_Full_lib.a -l:stm32wba_ble_stack_full.a -lm

The two archives are mutually dependent:

• stm32wba_ble_stack_full.a (le_ctrl.o) → LECTRL_LL_Init → references ll_ble_events_init
• WBA2_LinkLayer_BLE_Full_lib.a (ll_ble_events.o) → defines ll_ble_events_init → references ll_sys_ble_cntrl_init (defined in project sources / ll_sys_startup.c)

GNU ld only scans static archives in the order they appear and does not re-scan earlier archives by default. When stm32wba_ble_stack_full.a is processed and pulls in le_ctrl.o, the new undefined reference to ll_ble_events_init cannot be resolved because the link-layer archive has already been scanned. The follow-up Unknown destination type (ARM/Thumb) is a secondary error from ld attempting to emit an interworking veneer to a still-unresolved symbol.

I confirmed ll_ble_events_init is present and defined in WBA2_LinkLayer_BLE_Full_lib.a (arm-none-eabi-nm shows T ll_ble_events_init, size 8 bytes — a small Thumb-2 trampoline into ll_sys_ble_cntrl_init). So this is purely a link-ordering bug, not a missing-library issue.

Suggested fix in the CubeMX CMake template Wrap the two BLE archives in --start-group/--end-group so ld re-scans until all references are resolved:

set(MX_LINK_LIBS
 -Wl,--start-group
 :WBA2_LinkLayer_BLE_Full_lib.a
 :stm32wba_ble_stack_full.a
 -Wl,--end-group
 STM32_Drivers
 ${TOOLCHAIN_LINK_LIBRARIES}
 Utilities STM32_WPAN Common
)

(Or, for CMake ≥ 3.24, use $<LINK_GROUP:RESCAN,...>.) Simply swapping the order works for this specific symbol chain too, but the group is robust against any future circular dependency between the link-layer and BLE-stack archives. The IAR/MDK/Makefile templates appear unaffected because of how they emit the link command.

Workaround Manually edit cmake/stm32cubemx/CMakeLists.txt after each regeneration to add the --start-group/--end-group flags.