I’m working on a wearable based on SF32LB56X and trying to put HCPU in deep sleep while BLE keeps advertising / handling connections, to maximize battery life.
My target setup:
LCPU runs RT-Thread + my app + SIBLES (BLE host)
BLE controller in chip ROM (as usual)
HCPU stays in standby, woken only on user events
What I tried:
I linked lib_bt_gcc.a into the LCPU image (RAM expanded to fit, link OK), then called sifli_ble_enable() from LCPU main(). Init runs but BLE_POWER_ON_IND never fires.
Digging further, I found:
The BLE host stack initializes far enough to dispatch HCI commands, but nothing reaches the air (verified with nRF Connect — no advertising visible).
Looking at the task table inside lib_bt_gcc.a, only host-side tasks are present (AHI, AHI_INT, APP, COMMON, GAPC, GAPM, GATTC, GATTM, L2CC). The controller tasks (LC, LLD, LLM, HCI) are
missing — they appear to live in chip ROM and be reachable only through the mailbox HCI channel that HCPU normally drives.
SDK examples seem to confirm this:
example/ble/peripheral keeps everything on HCPU.
example/ble/ancs_dualcore runs BLE on LCPU but is explicitly LB55X-only.
example/pm/ble/src/lcpu/main.c guards all BLE init with #ifdef SF32LB55X — on LB56X, the LCPU side does no BLE.
My questions:
Is running the BLE host (SIBLES) on LCPU officially supported on SF32LB56X, or is HCPU mandatory?
If it is supported, is there a reference / app note for bringing up the HCI mailbox link from the LCPU side (which queue ID, init sequence, ROM symbols to call)?
If not supported on LB56X — is this a hardware limitation or just a configuration that hasn’t been productized? Any plan to enable it?
The mechanisms of 56 and 55 are different, so it’s not supported.
Additionally, since it only involves broadcasting and maintaining connections, the big core doesn’t need to intervene. The SIBLE-related interfaces are only called when the remote end has data. Therefore, as long as there’s no data exchange, the big core can remain in deep sleep while Bluetooth broadcasting and connection remain normal.
Thanks for the clear answer. Three follow-up questions:
Clarify “not supported”. Does that mean: (a) technically impossible on LB56 (HW-level constraint, no future patch will enable it), (b) not productized today but possible with custom work, or (c) planned for a future SDK / chip revision?
Useful for our architecture doc to mark this decision as final.
Scan/wake behaviour. Our use case isn’t just peripheral — we also scan continuously (mesh-style: many nodes around, each advertising heartbeats every ~5s). In standard BLE, every received adv packet during scan generates a host event →
constant HCPU wake-ups. Does the LB56 chip-ROM controller support hardware-level scan filtering (whitelist, manufacturer-data filter, RSSI threshold) so HCPU only wakes on matching packets? Or is HCPU deep-sleep only realistic for
peripheral-only / non-scanning roles?
Other SoCs supporting BLE-on-LCPU. I can see example/ble/ancs_dualcore runs BLE on LCPU but only on LB55X boards. Does LB58X or LB52X support the same topology? Anything in your roadmap?
Due to firmware design limitations, there are no plans for future support. Similarly, models 52 and 58 are also not supported—only model 55 is supported.
Currently, Scan only supports standard protocol filtering, i.e., the whitelist method. We have plans to support custom filtering conditions pre-configured in the Controller, but this is a long-term plan. It will be supported in our future chips; it’s unlikely that model 56 will receive a patch for this feature.
Follow-up — which BLE peripheral example actually runs on SF32LB56X?
Thanks for confirming BLE host must run on HCPU on LB56X (option 1). We can’t get any example to actually advertise.
HW: SF32LB56-DevKit-LCD | SDK: v2.4.6 (e8ef925b)
Note: SDK v2.4.6 doesn’t ship a sf32lb56-devkit-lcd board config in customer/boards/ (only ec-lb56* / eh-lb56*). We use the board
package shipped with the kit — please confirm if there’s a canonical one we’re missing.
We followed BLE peripheral示例 - SiFli SDK编程指南 文档 with all menuconfig flags enabled
(BLUETOOTH, BLE_GAP_CENTRAL, BLE_GATT_CLIENT, BSP_BLE_CONNECTION_MANAGER, BSP_BLE_NVDS_SYNC, NVDS_AUTO_UPDATE_MAC_ADDRESS). Built
clean, no source changes.
Tested:
example/ble/peripheral + board sf32lb56-lcd_n16r12n1 → stalls at LCPU patch install
example/ble/peripheral + board sf32lb56-devkit-lcd → bluetooth_init completes, then no BLE ready!
example/ble/hid + board sf32lb56-devkit-lcd → same as above
Common symptom on devkit-lcd:
[I] sibles: enable BLE Core. Lib ver: bt.2.0.1d93d6c0
[D] nvds: NVDS Update Addr res 6, addr bc-03-00-52-fd-5c
[I] ble_cm: read_bond_infor_from_flash: 1
<nothing more — no “BLE ready!” — invisible on nRF Connect>
SIBLES host finished init and is waiting for SIBLES_SVC_READY_IND from LCPU controller, which never arrives (bf0_sibles.c:616
LOG_I(“BLE ready!”) never prints). main thread suspended on its mailbox, KE_EVT0/2/3 suspended, sifli_mbox already exited.
We also noted lcpu_rom_config() in peripheral/main.c is guarded #ifdef SF32LB52X_58, but the hid example (no such guard) shows the
same stall — so EM config alone isn’t the cause.