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.

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_RPC_STACK) || (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

BT_MESH_PONOFF_SRV

Kconfig definitions

At <Zephyr>/subsys/bluetooth/host/Kconfig:123

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:33 → <Zephyr>/modules/Kconfig:6 → <nRF>/doc/_build/kconfig/Kconfig.modules:2 → <nRF>/Kconfig.nrf:92 → <nRF>/subsys/Kconfig:10 → <nRF>/subsys/bluetooth/Kconfig:38 → <nRF>/subsys/bluetooth/rpc/Kconfig:196

Menu path: (Top) → Modules → nrf (/home/runner/work/sdk-nrf/sdk-nrf/ncs/nrf) → Nordic nRF Connect → Bluetooth Low Energy → BLE over nRF RPC

config BT_SETTINGS
    bool "Store Bluetooth state and configuration persistently"
    select MPU_ALLOW_FLASH_WRITE if ARM_MPU
    depends on SETTINGS && BT_HCI_HOST && BT_RPC_STACK
    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.

At <Zephyr>/subsys/bluetooth/host/Kconfig:123

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:44 → <Zephyr>/subsys/Kconfig:9 → <Zephyr>/subsys/bluetooth/Kconfig:180

Menu path: (Top) → Sub Systems and OS Services → Bluetooth

config BT_SETTINGS
    bool "Store Bluetooth state and configuration persistently"
    select MPU_ALLOW_FLASH_WRITE if ARM_MPU
    depends on SETTINGS && 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.)