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 Einar,

thanks for taking a look into my issue. The problem is, that the flash_map sources define a `IRQ_CONNECT` handler with the very same IRQ number, as my flash driver. While my flash driver actually uses the QSPI peripheral, the flash_map should not use the QSPI peripheral, as the Settings should be written to the internal flash memory of the nrf53.

The concrete error message is: 

gen_isr_tables.py: error: multiple registrations at table_index 43 for irq 43 (0x2b)
Existing handler 0x4715, new handler 0x38897
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

With 43 from nrf5340_application.h:

  QSPI_IRQn                 =  43,              /*!< 43 QSPI                                                                   */

 

[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.