How to configure Settings?

[Torsten Robitzki]

Hello,

I have the task to persistently store some (2) configuration values in a Zephyr application (Nordic Version). The final version contains some external flash memory, will make use of MCUBoot, and Bluetooth (LE). The configuration values should be stored within the internal flash memory.

The application makes directly use of the QSPI peripheral and installs an interrupt handler (IRQ_CONNECT). According to the partition report (west build -t partition_manager_report), the `

settings_storage` partition is within the internal flash memory:

...
  flash_primary (0x100000 - 1024kB): 
+------------------------------------------+
| 0x0: app (0xfc000 - 1008kB)              |
| 0xfc000: settings_storage (0x2000 - 8kB) |
| 0xfe000: EMPTY_0 (0x2000 - 8kB)          |
+------------------------------------------+
...

The relevant part of the `prj.conf` file looks like this:

# Storing configuration values
CONFIG_FLASH=y
CONFIG_NVS=y
CONFIG_FLASH_MAP=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y

Without the `CONFIG_FLASH_MAP` configuration, the `CONFIG_SETTINGS_NVS` will be reset and the Settings backend will be some pointless default. But, when enabling `CONFIG_FLASH_MAP`, that module also defines an irq handler for the QSPI interrupt.

What do I have to do, to configure the Settings module to store configurations in the internal flash memory?

best regards

Torsten

[Einar Thorsrud]

Hi Torsten,

The settings related configs you have here look sensible. You should include CONFIG_FLASH_MAP, ans you can see that the same essential set of configs is used in the Bluetooth samples that support bonding.

Is there a problem when you include this? If so, what is it (that the parition is placed on the external flash where you do not want it, or somehting else?). In addition to understanding what the problem is, it would be usefull to see your partition layout (both the generated as well as any static partitions you have configured.

Br,

Einar

[Torsten Robitzki]

Hi,

I now, figured out, that I could set `CONFIG_NORDIC_QSPI_NOR` to `n` to prevent Zephyr from linking in the qspi-nor library. According to `zephyr/drivers/flash/Kconfig.nordic_qspi_nor` this configuration flag should depend on `DT_HAS_NORDIC_QSPI_NOR_ENABLED`. So I thought, the more appropriate solution to my problem would be to disable qspi in the device tree:

&qspi {
    status = "disabled";
};

My current design is based on the `nrf5340dk/nrf5340/cpuapp` board. By disabling the qspi peripheral, I though, that the dependency for `CONFIG_NORDIC_QSPI_NOR` would not be given and thus, `CONFIG_NORDIC_QSPI_NOR` would not have been set to `y`. But that didn't worked out as expected. Any idea, as to how to make the `DT_HAS_NORDIC_QSPI_NOR_ENABLED` dependency fail, so that `CONFIG_NORDIC_QSPI_NOR` will not get set to `y`?

best regards

Torsten

[Einar Thorsrud]

Hi Torsten,

Good to see you found the relevant config. Is CONFIG_NORDIC_QSPI_NOR set somethwere else, in a project or board specific Kconfig?

[Torsten Robitzki]

The resulting `build/zephyr/zephyr.dts` has a `qspi` node, with the `status` attribute set to `disabled`. However, the resulting kconfig (`build/zephyr/.config`) contains this entry: `CONFIG_DT_HAS_NORDIC_QSPI_NOR_ENABLED=y`.

Further more, it contains directly has the `CONFIG_NORDIC_QSPI_NOR` flag set to `y`:

...
#
# Nordic nRF Connect
#
CONFIG_WARN_EXPERIMENTAL=y
CONFIG_BT_BUF_CMD_TX_COUNT=10
CONFIG_INIT_ARCH_HW_AT_BOOT=y
CONFIG_NORDIC_QSPI_NOR=y
...

The "Nordic nRF Connect" text comes from the nrf/Kconfig.nrf file, which, at the end, also includes:

rsource "samples/Kconfig"
rsource "subsys/Kconfig"
rsource "modules/Kconfig"
rsource "lib/Kconfig"
rsource "drivers/Kconfig"
rsource "ext/Kconfig"
rsource "tests/Kconfig"

From which "samples/Kconfig" contains an other include to "samples/common", from which on, things get a little bit "confusing".

If there is a way to further track down, why (first of all) CONFIG_DT_HAS_NORDIC_QSPI_NOR_ENABLED is set, or why CONFIG_NORDIC_QSPI_NOR is set, I would invest some more hours into this. If there is no way to figure out, why I have this settings, I would stick to directly setting CONFIG_NORDIC_QSPI_NOR to n.

As we are developing a medical device, I would really love to understand, how we could avoid getting drivers linked in, that we are not going to use.

[Einar Thorsrud]

Hi,

Which SDK version are you using, and can you share all your Kconfigs? If you use CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y that implies CONFIG_NORDIC_QSPI_NOR also in nRF Connect SDK 2.7, but that will be fixed in 2.8 (and is fixed in main).

[Torsten Robitzki]

I'm on a local branch, that is based on 2.7, but contains a lot of commits after 2.7. I could update to 2.8 and see, if my required fixes are included and then report, if that also fix this issue.

Here is the configuration:

# Temporary workaround for https://devzone.nordicsemi.com/f/nordic-q-a/107445/colon-in-soc_cpu_idle-h-leads-to-failing-build-with-arm-none-eabi-gcc-version-12-2
CONFIG_SOC_NRF53_ANOMALY_168_WORKAROUND=n

# drivers/external_pin.cpp is defining the GPIOTE interrupt handler
CONFIG_GPIO_NRFX_INTERRUPT=n

# Enable support for C++
CONFIG_CPP=y
CONFIG_REQUIRES_FULL_LIBCPP=y
CONFIG_NEWLIB_LIBC=y
CONFIG_STD_CPP20=y

CONFIG_MAIN_STACK_SIZE=16384

CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_LOG_PRINTK=y
CONFIG_LOG_MODE_DEFERRED=y
CONFIG_LOG_BUFFER_SIZE=16384

CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_NRF_SECURITY=y
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y
CONFIG_PSA_WANT_ALG_SHA_256=y

CONFIG_I2C=y

# USB
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Lovelace Pod"
CONFIG_USB_DEVICE_PID=0x0001
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y

# MQTT
CONFIG_MQTT_SN_LIB=y
CONFIG_NETWORKING=y
CONFIG_MQTT_SN_LOG_LEVEL_DBG=y

# Analogue Frontend uses ZERO_LATENCY IRQs to call the SPI preparation callbacks
CONFIG_ZERO_LATENCY_IRQS=y

# For debugging only!
#CONFIG_LOG_MODE_IMMEDIATE=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_ASSERT=y

# Bootloader
#CONFIG_BOOTLOADER_MCUBOOT=y

# Enable SMP Server
#CONFIG_MCUMGR=y
#CONFIG_MCUMGR_GRP_IMG=y

# CONFIG_MCUMGR_GRP_IMG dependencies
#CONFIG_FLASH=y
#CONFIG_IMG_MANAGER=y

# CONFIG_IMG_MANAGER dependencies
#CONFIG_STREAM_FLASH=y

# CONFIG_MCUMGR dependencies
#CONFIG_NET_BUF=y
#CONFIG_ZCBOR=y

#CONFIG_MCUBOOT_BUILD_STRATEGY_FROM_SOURCE=y
#CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
#CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
#CONFIG_UPDATEABLE_IMAGE_NUMBER=2
#CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y

# Storing configuration values
CONFIG_FLASH=y
CONFIG_NVS=y
# Required to actually use the NVS backend, conflicts with QSPI usage:
# https://devzone.nordicsemi.com/f/nordic-q-a/114760/how-to-configure-settings
CONFIG_FLASH_MAP=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y
CONFIG_NORDIC_QSPI_NOR=n

# Bluetooth
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Lovelace Pod"
#CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

I would love to get rid of the `CONFIG_NORDIC_QSPI_NOR=n` configuration, or in general, I would love to get rid of all unused drivers (as back in the good old days where library where statically linked ;-) )

[Einar Thorsrud]

Hi,

There are (probably too) many dependencies which makes things like this a bit tricky in general, so it makes sense to set CONFIG_NORDIC_QSPI_NOR=n on your end. I agee that needing to disable something you never ment to enable in the first place is not very elegant, but in the end the key is that the generated .config file is correct.