[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:
Open the example .ioc file located at: STM32CubeWBA\Projects\NUCLEO-WBA55CG\Applications\BLE\BLE_p2pServerThreadX\BLE_p2pServerThreadX.ioc
In STM32CubeMX, generate the project for STM32CubeIDE.
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:
Incorrect LD Generation: The default project generation seems to allocate insufficient RAM (likely 64KB) for a ThreadX + BLE Stack application which clearly requires >80KB.
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.
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!
