-
CONFIG_BT_SETTINGS
¶
Store Bluetooth state and configuration persistently
Type: bool
Help¶
When selected, the Bluetooth stack will take care of storing (and restoring) the Bluetooth state (e.g. pairing keys) and configuration persistently in flash.
When this option has been enabled, it’s important that the application makes a call to settings_load() after having done all necessary initialization (e.g. calling bt_enable). The reason settings_load() is handled externally to the stack, is that there may be other subsystems using the settings API, in which case it’s more efficient to load all settings in one go, instead of each subsystem doing it independently.
Direct dependencies¶
SETTINGS
&& BT_HCI_HOST
&& BT_HCI
&& BT
(Includes any dependencies from ifs and menus.)
Defaults¶
No defaults. Implicitly defaults to n
.
Symbols selected by this symbol¶
Symbols that imply this symbol¶
Kconfig definition¶
At <Zephyr>/subsys/bluetooth/host/Kconfig:180
Included via <Zephyr>/Kconfig:8
→ <Zephyr>/Kconfig.zephyr:34
→ <Zephyr>/subsys/Kconfig:9
→ <Zephyr>/subsys/bluetooth/Kconfig:239
Menu path: (Top) → Sub Systems and OS Services → Bluetooth
config BT_SETTINGS bool "Store Bluetooth state and configuration persistently" selectMPU_ALLOW_FLASH_WRITE
ifARM_MPU
depends onSETTINGS
&&BT_HCI_HOST
&&BT_HCI
&&BT
help When selected, the Bluetooth stack will take care of storing (and restoring) the Bluetooth state (e.g. pairing keys) and configuration persistently in flash. When this option has been enabled, it's important that the application makes a call to settings_load() after having done all necessary initialization (e.g. calling bt_enable). The reason settings_load() is handled externally to the stack, is that there may be other subsystems using the settings API, in which case it's more efficient to load all settings in one go, instead of each subsystem doing it independently.
(The ‘depends on’ condition includes propagated dependencies from ifs and menus.)