[BUG] BLE_p2pServerThreadX RAM Overflow on NUCLEO-WBA55CG - STM32CubeWBA V1.9.0 / STM32CubeMX v6.17.0

[Kenwang]

Hello ST Community,

I am reporting a 100% reproducible build failure when using the latest STM32CubeWBA SDK and tools for the NUCLEO-WBA55CG. It appears the default configuration generated by STM32CubeMX for the BLE_p2pServerThreadX application results in a RAM overflow and linker warnings.

Environment:

• MCU: STM32WBA55CGUx

• Board: NUCLEO-WBA55CG

• SDK: STM32Cube_FW_WBA_V1.9.0

• STM32CubeMX: v6.17.0

• STM32CubeIDE: v2.1.0 (with GNU Tools for STM32 14.3.rel1)

Steps to Reproduce:

1. Open the example .ioc file located at: STM32CubeWBA\Projects\NUCLEO-WBA55CG\Applications\BLE\BLE_p2pServerThreadX\BLE_p2pServerThreadX.ioc

2. In STM32CubeMX, generate the project for STM32CubeIDE.

3. Open the project in STM32CubeIDE v2.1.0 and perform a Clean Build.

Observed Error (Scenario A - Default settings):

The linker fails with a RAM overflow of 17,288 bytes:

ld.exe: BLE_p2pServerThreadX.elf section `.bss' will not fit in region `RAM'
ld.exe: region `RAM' overflowed by 17288 bytes

Observation (Scenario B - Manually adjusting RAM to 128K):

When I manually modified the linker script (STM32WBA55CGUX_FLASH.ld) to increase the RAM size to 128K (matching the actual hardware specs of WBA55), the build "finishes" but still reports a critical warning and a build failure code:

ld.exe: warning: .../crtn.o: missing .note.GNU-stack section implies executable stack
NOTE: This behaviour is deprecated and will be removed in a future version of the linker

Build Output Summary:

• text: 226,680 bytes

• data: 16,844 bytes

• bss: 65,976 bytes

• Total RAM Usage (data + bss): ~82,820 bytes (Exceeding the default 64K allocation in many template LD files).

Issues:

1. Incorrect LD Generation: The default project generation seems to allocate insufficient RAM (likely 64KB) for a ThreadX + BLE Stack application which clearly requires >80KB.

2. Toolchain Compatibility: The newer GCC 14.3 linker is flagging the missing .note.GNU-stack section, which might be an issue with the provided startup files or libraries in the SDK.

3. Out-of-the-box Failure: A standard SDK example should build without manual linker script intervention.

Could the ST team please verify if the Linker Script template for WBA55 needs an update in CubeMX, or if there is a specific middleware configuration that is causing excessive .bss usage?

Looking forward to your guidance. Thank you!

[Mahmoud Ben Romdhane]

Hello  @Kenwang 

Let me thank you for posting.

I am currently checking this behavior, and I will get back to you ASAP.

Thanks.

Mahmoud

[Mahmoud Ben Romdhane]

Hello @Kenwang,

While building the example [BLE_p2pServerThreadX] on Cube IDE, I get these build errors:

make: *** No rule to make target 'C:/Users/benromdm/STM32Cube/Example/BLE_p2pServerThreadX/Drivers/STM32WBAxx_HAL_Driver/Src/stm32wbaxx_hal_gtzc.c', needed by 'Drivers/STM32WBAxx_HAL_Driver/stm32wbaxx_hal_gtzc.o'. Stop.

make: *** Waiting for unfinished jobs...

"make -j8 all" terminated with exit code 2. Build might be incomplete.

10:29:26 Build Failed. 2 errors, 0 warnings. (took 51s.5ms)

Thanks.

Mahmoud

[Kenwang]

Hi @Mahmoud Ben Romdhane ,

Hello Mahmoud,

Thank you for your support.

Regarding your question, I would like to clarify how I generated my project.
My .ioc file was copied directly from the official STM32Cube_FW_WBA package, located at:

C:\Users\User1\STM32Cube\Repository\STM32Cube_FW_WBA_V1.9.0\
Projects\NUCLEO-WBA55CG\Applications\BLE\BLE_p2pServerThreadX\
BLE_p2pServerThreadX.ioc

I did not modify the .ioc file at all.

Here is the exact procedure I followed:

1. I created a new empty directory and copied the original .ioc file into it.
2. I opened this .ioc using STM32CubeMX v6.17.0.
3. In CubeMX, I selected Toolchain/IDE = STM32CubeIDE, then clicked Generate Code.
4. I opened a clean, empty workspace in STM32CubeIDE v2.1.0, and imported the newly generated project.
5. Without making any changes after import, I immediately built the project — and the build failed.

Since the .ioc comes directly from the official example and I followed the standard CubeMX/CubeIDE workflow without modifications, could you please help verify whether the SDK version, CubeMX version, and CubeIDE version you used during your test are the same as mine?

• STM32Cube_FW_WBA: V1.9.0
• STM32CubeMX: v6.17.0
• STM32CubeIDE: v2.1.0

Thank you very much for checking this.

Best regards,
Kenwang

[Mahmoud Ben Romdhane · Accepted solution]

Hello @Kenwang 

After increasing the RAM Memory Size to 128K in STM32WBA55CGUX_FLASH.ld, you should add this flag 

-z noexecstack under (Project > Properties > C/C++ Build > Settings > MCU/MPU GCC Linker > Miscellaneous > Other Flags) and the build will be finished with 0 errors.

[See Attachments]

I will be waiting for your feedback.

Thanks.

Mahmoud

[Kenwang]

Hello Mahmoud,

Thank you very much for your solution — it works perfectly on my side.

I have two additional questions:

1. Which file inside STM32Cube\Repository\STM32Cube_FW_WBA_V1.9.0 should be modified so that STM32CubeMX will automatically generate new projects with the
   -z noexecstack option already included under:
   Project > Properties > C/C++ Build > Settings > MCU/MPU GCC Linker > Miscellaneous > Other Flags?
   I would like future CubeMX‑generated projects to include this flag by default.

2. Could this fix be added in the next release of the STM32WBA SDK so that new projects no longer require manual modification?

Thank you again for your help.

Best regards,
Kenwang