:orphan:

.. title:: CONFIG_BT_SETTINGS

.. kconfig:: CONFIG_BT_SETTINGS

CONFIG_BT_SETTINGS
##################

*Store Bluetooth state and configuration persistently*

Type: ``bool``

Help
====

.. code-block:: none

    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
===================

\ :kconfig:`SETTINGS <CONFIG_SETTINGS>` && \ :kconfig:`BT_HCI_HOST <CONFIG_BT_HCI_HOST>` && \ :kconfig:`BT_HCI <CONFIG_BT_HCI>` && \ :kconfig:`BT <CONFIG_BT>`

*(Includes any dependencies from ifs and menus.)*

Defaults
========

No defaults. Implicitly defaults to ``n``.

Symbols selected by this symbol
===============================

- \ :kconfig:`MPU_ALLOW_FLASH_WRITE <CONFIG_MPU_ALLOW_FLASH_WRITE>` if \ :kconfig:`ARM_MPU <CONFIG_ARM_MPU>`

Kconfig definition
==================



At ``<Zephyr Subsystem>/bluetooth/host/Kconfig:123``

Included via ``Kconfig:8`` → ``Kconfig.zephyr:44`` → ``<Zephyr Subsystem>/Kconfig:9`` → ``<Zephyr Subsystem>/bluetooth/Kconfig:174``

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

.. code-block:: kconfig

    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.)*