Skip to main content
Associate III
March 9, 2026
Solved

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

  • March 9, 2026
  • 1 reply
  • 518 views

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!

Best answer by Mahmoud Ben Romdhane

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

 

1 reply

Technical Moderator
March 9, 2026

Hello  @Kenwang 

Let me thank you for posting.

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

Thanks.

Mahmoud

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Technical Moderator
March 9, 2026

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

 

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
KenwangAuthor
Associate III
March 10, 2026

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