Hello, I’m working on a low-power BLE peripheral design on an STM32WBA63 and I’ve hit a timing issue that I’m hoping someone can help me with.
Hardware / software
- MCU: STM32WBA63CIUx
- STM32CubeMX: 6.15.0
- Firmware package: STM32Cube FW_WBA V1.7.0
- Wireless stack: STM32_WPAN (BLE)
- RTOS: FreeRTOS 1.3.1 with tickless idle enabled
- Low power mode: STOP1 (not standby/off)
- BLE role: peripheral advertising
- Advertising interval: ADV_INTERVAL_MIN = 0x0640 (1 s)
- IDE/toolchain: EWARM V9.60
Issue:
Advertising is stable until I add some application-side work in the FreeRTOS tickless idle pre-sleep / post-sleep hooks. After that, advertising becomes intermittent and sometimes appears to stop completely.
It looks like the device wakes from STOP, but then misses the BLE Link Layer scheduling point for the next advertising event.
I instrumented the post-sleep hook and measured the time spent in post-sleep processing, which resulted in a 0.477ms delay.
Integration details (what was changed):
We started from the CubeMX-generated tickless idle implementation and added calls to:
- configPRE_SLEEP_PROCESSING()
- configPOST_SLEEP_PROCESSING()
around the low-power entry/exit in vPortSuppressTicksAndSleep() (in the project this is in app_entry.c as generated by STM32CubeMX).
In our current integration, the post-sleep hook is executed before interrupts are re-enabled. We realize this may be relevant for radio/LL timing, but we are unsure what the recommended ordering is for STM32WBA + STM32_WPAN.
Relevant STM32CubeWBA code we found:
We noticed a “wake-up offset” mechanism in the STM32_WPAN glue code that appears to wake the Link Layer early relative to the next scheduled radio event (for LL deep sleep use cases):
- LL deep sleep helper: APP_SYS_BLE_EnterDeepSleep() (/STM32CubeWBA/Projects/Common/WPAN/Modules/app_sys.c)
- It subtracts `wakeup_offset` from the remaining time: `radio_remaining_time > wakeup_offset` (/STM32CubeWBA/Projects/Common/WPAN/Modules/app_sys.c)
- Wakeup offset setter: APP_SYS_SetWakeupOffset() (/STM32CubeWBA/Projects/Common/WPAN/Modules/app_sys.c)
However, since our system is using STOP 1, it is unclear whether an equivalent “early wake margin” is supported/needed for STOP mode.
Questions for ST:
1) For STOP1 mode + FreeRTOS tickless, is there an ST-recommended mechanism to ensure the system/stack wakes up with enough margin to meet LL radio event timing (e.g., advertising), similar to the `wakeup_offset` used in `APP_SYS_BLE_EnterDeepSleep()`?
2) In a recommended integration, should FreeRTOS' `configPOST_SLEEP_PROCESSING()` run after interrupts are re-enabled to avoid delaying radio IRQ servicing? If yes, is there a reference project in STM32CubeWBA that demonstrates the expected ordering?
