STM32WBA55 + BLE_p2pServerThreadX: Firmware does not start after Power-On Reset, only runs after manual Reset

[Kenwang]

Hello ST Community,

I am working with NUCLEO-WBA55CG and encountering a startup issue when using the BLE_p2pServerThreadX example from STM32CubeWBA v1.8.0.

Environment

• Board: NUCLEO-WBA55CG

• MCU: STM32WBA55 (single-core Cortex-M33)

• SDK: STM32CubeWBA v1.8.0

• RTOS: Azure RTOS ThreadX

• Example: BLE_p2pServerThreadX

• IDE / Toolchain: IAR Embedded Workbench 9.60

• Debugger: ST-LINK (on-board)

Problem Description

After programming the firmware to the board:

• :cross_mark: On cold power-on (Power-On Reset), the application does not start

• :white_heavy_check_mark: After pressing the RESET button, the application runs normally

• The issue is 100% reproducible

BLE advertising starts correctly only after a manual reset, not after initial power-up.

Additional Tests Performed

• The issue occurs even when Timebase Source is set to SysTick

• The MCU is confirmed to be STM32WBA55 (single-core)
  (not STM32WB, no wireless coprocessor)

• No user code is executed after early initialization during the failing POR case

• After RESET, behavior is normal without any code changes

---

Debug Observations

During the failing Power-On Reset case:

• HAL_GetTick() always returns 0

• SysTick interrupt does not appear to be running

• BLE initialization seems to stall during early startup (likely in timebase-dependent code paths)

During the RESET case:

• SysTick is correctly enabled

• HAL_GetTick() increments as expected

• BLE stack initializes and advertises normally

This strongly suggests that SysTick is not properly enabled or reinitialized after POR, possibly due to the interaction between:

• HAL_Init()

• ThreadX low-level initialization

• BLE initialization using HAL timebase–dependent APIs (e.g. HAL_Delay() or timeout loops)

---

Suspected Root Cause

This appears to be a startup sequencing issue specific to Power-On Reset when using:

• CubeWBA v1.8.0

• ThreadX

• IAR 9.60

SysTick may be left disabled or misconfigured after POR, while a manual RESET correctly reinitializes NVIC and SysTick state.

---

Questions

1. Is this a known issue in STM32CubeWBA v1.8.0 with ThreadX projects?

2. Is there an official workaround or patch recommended by ST?

3. Should SysTick be explicitly reconfigured before tx_kernel_enter() in WBA ThreadX applications?

4. Has this issue been fixed in a later CubeWBA release?

Any confirmation or guidance would be greatly appreciated.

Thank you for your support.