Zephyr OS Bluetooth Startup: Restore Settings After Enablement Before Advertising

Loading application settings early in boot does not prove that Bluetooth settings were restored at the right time. In a Zephyr application with persistent Bluetooth settings enabled, stack enablement and settings restoration have an explicit order. Review that order before investigating a reboot as though every missing identity were a pairing failure.

This article uses Zephyr 4.4.0's public Bluetooth API and host settings implementation. It describes a startup integration review and hypothetical failure cases. It does not claim a successful reconnection test on a particular controller or peer.

Make enablement completion a real boundary

The tagged Bluetooth API requires Bluetooth settings to be loaded after bt_enable() successfully completes when CONFIG_BT_SETTINGS is enabled. Loading them before enablement is insufficient. It permits settings_load() or settings_load_subtree("bt"), recommending the subtree approach when settings were already loaded earlier. An asynchronous enable callback runs in the system workqueue.

Represent these stages explicitly in startup state: enable requested, enable completed successfully, Bluetooth settings loaded, then the intended Bluetooth activity allowed to start. In an asynchronous design, submitting enablement is not the same event as completing it. Keep error paths from advancing the state machine as if initialization succeeded.

This is particularly important when application configuration and radio initialization are owned by different modules. A generic “settings ready” flag may refer to an earlier load that cannot satisfy the Bluetooth ordering requirement. Give the Bluetooth restoration stage its own completion evidence.

Understand why an early load can be misleading

The tagged host settings implementation returns without applying its setting handler when the Bluetooth-enable flag is absent. Its comments explain that restoring identities needs communication with the controller. The commit handler has the same pre-enable guard.

Consequently, the absence of a fatal error during an early settings pass does not establish that the later Bluetooth state contains the expected restored values. Examine the actual ordering rather than treating an apparently successful boot-wide settings operation as sufficient proof.

A hypothetical device may load general preferences first, enable Bluetooth later, and immediately start advertising. If the required Bluetooth load is missing between those last steps, changing advertising intervals or repeatedly pairing the peer does not address the startup sequence. First make the documented restore boundary explicit.

Restore before deciding to create more identities

The public API describes a restore-first approach for randomly generated persistent identities: enable the stack, load settings, inspect recovered identities with bt_id_get(), then create additional identities if needed. Treat the observed identity count as meaningful only after the required restoration stage.

A product should also define when identity creation is allowed. First provisioning and every normal boot are different situations. Creating new state simply because an earlier phase saw no identity can turn a recoverable initialization-order bug into persistent identity churn.

Keep factory-reset and reprovisioning paths separate from normal startup diagnosis. Do not erase bonds or identity storage merely to make a demonstration reconnect. Such erasure changes the state being investigated and can force users through unnecessary re-pairing.

Gate activity on the complete startup policy

Advertising is a useful visible milestone, but visibility alone does not demonstrate that persistent state was restored correctly. Start the intended Bluetooth activity only after the application's required initialization and restoration checks have passed. Record the enable result, restoration result and selected identity without exposing secret key material in logs.

For testing, compare a fresh provisioned device with a reboot of the same stored state. Exercise both synchronous and asynchronous enablement paths that the product actually uses. Introduce a controlled storage-load failure and verify that the application takes its defined degraded or error path instead of silently acting like a clean first boot.

The review is complete when the product can explain exactly which operation restored Bluetooth state after enablement, and why subsequent advertising or identity creation is permitted. That removes an ordering ambiguity before radio timing, peer compatibility or security behavior are blamed.