peripheral_dis logs:

[dwalton65]

SDK Environment: nRF Connect SDK v1.7.1

Target: Decawave DWM1001-DEV. This uses the nRF52832

If I add CONFIG_LOG=y to "prj.conf" in the zephyr sample peripheral_dis, when run I get the following:

** Booting Zephyr OS build v2.6.99-ncs1-1  ***
[00:00:00.000,366] <inf> sdc_hci_driver: SoftDevice Controller build revision:
                                         3f 47 70 8e 81 95 4e 86  9d d3 a2 95 88 f6 30 0a |?Gp...N. ......0.
                                         7f 53 49 fd                                      |.SI.
[00:00:00.002,746] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.005,371] <err> bt_gatt: Failed to save Database Hash (err -2)
Bluetooth initialized
Advertising successfully started

Why is "<err> bt_gatt: Failed to save Database Hash (err -2)" being logged?

I have attached the complete project.

I initially built this with west build -b decawave_dwm1001_dev2 -d build2 -- -DBOARD_ROOT=\ncs\myapps\peripheral_dis_test

peripheral_dis_test.zip

[Amanda Hsieh]

Hi, 

Sorry for the delay. From the team:

This error will not affect real-world applications.

The source of the error is the use of CONFIG_SETTINGS_NONE=y in prj.conf. Selecting this causes the settings subsystem to return an error when attempting to write settings. The Bluetooth Host is logging this error. `CONFIG_LOG=y` simply enables printing this error. A real-world application would not use CONFIG_SETTINGS_NONE=y.

However, we should not allow an error to occur in our samples. Possible resolutions:

• We could make CONFIG_SETTINGS_NONE black hole the write and return success.
• Use a real Settings back end in the sample. This may be the better option since CONFIG_SETTINGS_NONE is an undocumented feature.

-Amanda

[dwalton65]

Thanks, now I know where the error is coming from.

Amanda Hsieh said:

A real-world application would not use CONFIG_SETTINGS_NONE=y

I would like to think that I could start building a real-world application using a sample as a starting point. Based on this I would much prefer the second option. Although I do recognize the aim to keep samples as simple as possible.

Amanda Hsieh said:

Use a real Settings back end in the sample. This may be the better option since CONFIG_SETTINGS_NONE is an undocumented feature.

[dwalton65]

Referring to Persistent storage

Would this seem reasonable for "prj.conf"

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DIS=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_DIS_MODEL="Zephyr Model"
CONFIG_BT_DIS_MANUF="Zephyr"
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_DIS_SW_REV=y
CONFIG_BT_DIS_SERIAL_NUMBER_STR="Zephyr Serial"
CONFIG_BT_DIS_FW_REV_STR="Zephyr Firmware"
CONFIG_BT_DIS_HW_REV_STR="Zephyr Hardware"
CONFIG_BT_DIS_SW_REV_STR="Zephyr Software"

CONFIG_BT_DEVICE_NAME="DIS peripheral"

# Below is setup to let DIS information be read from settings
CONFIG_SETTINGS_RUNTIME=y

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

CONFIG_BT_DIS_SETTINGS=y
CONFIG_BT_DIS_STR_MAX=21

CONFIG_DEBUG_THREAD_INFO=y

CONFIG_LOG=y

Does anything else need to change? The sample peripheral_dis already calls settings_load()

[Amanda Hsieh]

Looks fine from my side. Let me know if you have any issues regarding that. 

-Amanda