...

This note describes how to use the SPI Flash with the Thingy-9151-Lite platform.

2. Hardware Implementation

...

There is a generic jedec,spi-nor driver in Zephyr that should be able is used to handle SPI flash Flash devices compatible with the JESD216 JEDEC standard. This driver operates as a middleware between an underlying driver for the SoC-specific SPI controller and the low-level flash Flash API. This

The driver is enabled available when the SPI_NOR configuration parameter is enabled in the build-configuration. The level of auto-configuration is selected with the SPI_NOR_SFDP parameter:

For the full list of driver parameters available in the device tree, refer to https://docs.zephyrproject.org/latest/build/dts/api/bindings/mtd/jedec%2Cspi-nor.html#std-dtcompatible-jedec-spi-nor Note, that

3.1. Support for QSPI Flash

Note that the jedec,spi-nor driver runs on top of the SPI driver, so the DSPI and QSPI features are not supported by this solution. For some Nordic chips (nRF5340 in particular), there is a nordic,qspi-nor driver that supports operating in QSPI mode, with its own set of flash parameters. nordic,qspi-nor is not affected by SPI_NOR_SFDP, all required parameters need to be supplied in the device tree node.

3.2. Software APIs

There are several API levels that allow access to SPI flashFlash.

3.2.1. Low Level Flash Access

This level can be used to access the SPI Flash , as a raw Flash device.

The following calls are the core for the flash Flash API defined in zephyr/include/zephyr/drivers/flash.h:

__syscall const struct flash_parameters *flash_get_parameters(const struct device *dev);
__syscall size_t flash_get_write_block_size(const struct device *dev);
/* access functions */
__syscall int flash_erase(const struct device *dev, off_t offset, size_t size);
__syscall int flash_write(const struct device *dev, off_t offset,
                          const void *data,
                          size_t len);
__syscall int flash_read(const struct device *dev, off_t offset, void *data,
                         size_t len);
/* specific to SPI flash, if supported by driver and enabled by CONFIG_FLASH_JESD216_API */
__syscall int flash_read_jedec_id(const struct device *dev, uint8_t *id);
__syscall int flash_sfdp_read(const struct device *dev, off_t offset,
                              void *data, size_t len);

There are more to flash APIthe Flash API’s, please refer to Zephyr documentation https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html for details.

There are also the zephyr/samples/drivers/jesd216 and zephyr/samples/drivers/spi_flash demos that demonstrate using use of low-level API.

3.2.2. Flash Partitioning

Zephyr additionally has API’s that can be used to partition SPI Flash. The goal is to provide a facility to split a single chip Flash device into several named areas to be used independently and preventing out-of-bounds access.

There is a predefined flash Flash map that is created from the “fixed-partition” compatible entries in the DTS file. Internally, each flash Flash area is described with a descriptor, providing: offset, length, underlying flash driver. This Those descriptors are identified by globally unique ID numbers. To obtain the ID from the device tree label for “fixed-partition” use the FIXED_PARTITION_ID() macro.

It is also possible to create flash partition during Flash partitions at the runtime.

The following functions are the core of flash Flash area API defined in zephyr/include/zephyr/storage/flash_map.h

...

Refer to Zephyr documentations https://docs.zephyrproject.org/latest/services/storage/flash_map/flash_map.html for details. Note , that when using multi-image builds, the Nordic SDK overrides the partitions defined in the device tree with Partition Manager .

The zephyr/samples/subsys/fs/littlefs sample illustrate using illustrates use of a fixed partition to create a file system over it. mcuboot is another useful example.

3.2.3. High-

...

Level Non-

...

Volatile API

There are several high-level storage API API’s provided by Zephyr that can be used over flashFlash (or flash a Flash area):

1. https://docs.zephyrproject.org/latest/services/storage/nvs/nvs.html can be used to store elements, represented as id-data pairs.

2. https://docs.zephyrproject.org/latest/services/storage/fcb/fcb.html provides an abstraction through which you can treat flash Flash like a FIFO.

3. https://docs.zephyrproject.org/latest/services/storage/stream/stream_flash.html module takes contiguous fragments of a stream of data (e.g. from radio packets), aggregates them into a user-provided buffer, then when the buffer fills (or stream ends), writes it to a raw flash Flash partition.

4. https://docs.zephyrproject.org/latest/services/file_system/index.html allow to have several independent file systems.

See samples/fs/littlefs, samples/subsys/usb/mass for an example of how to use filesystem over SPI flashFlash.

In the nrf-app application use the CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL, CONFIG_PM_PARTITION_REGION_SETTINGS_STORAGE_EXTERNAL, and CONFIG_PM_PARTITION_REGION_NVS_STORAGE_EXTERNAL to relocate corresponding partition to SPI flashFlash.

3.3. Zephyr Shell Commands

The nrf-app application comes preconfigured to use SPI flashFlash, and with support for the relevant Zephyr shell commands enabled. The following shell commands are supportedavailable:

erase [<device>] <page address> [<size>]
read [<device>] <address> [<Dword count>]
test [<device>] <address> <size> <repeat count>
write [<device>] <address> <dword> [<dword>...]
load [<device>] <address> <size>
page_info [<device>] <address>
read_test [<device>] <address> <size> <repeat count>
write_test [<device>] <address> <size> <repeat count>
erase_test [<device>] <address> <size> <repeat count>
erase_write_test [<device>] <address> <size> <repeat count>

In the above, [<device>] is an optional flash Flash device name (as given in the device tree). If not present, value of zephyr,flash in the choosen node will be used.

When specifying the <address> and <size> values, use an 0x prefix for the hexadecimal values. <size> for test operations is limited by the CONFIG_FLASH_SHELL_BUFFER_SIZE parameter and defaults to 0x4000.

The following procedures can be used to verify raw Flash access. Note, that the low-level API is used and in the example, which can destroy any available partition data can be destroyed by this test:

1. Run a generic erase/write/read/compare test:

   Code Block
   uart:~$ flash test gd25wb256e3ir@1 0 0x4000 1 Erase OK. Write OK. Verified OK. Erase-Write-Verify test done.

2. Run read and write measurements:

   Code Block
   uart:~$ flash erase gd25wb256e3ir@1 0 0x4000 Erase success. uart:~$ flash write_test gd25wb256e3ir@1 0 0x4000 1 Loop #1 done in 53 ticks. Total: 53ms, Per loop: ~53ms, Speed: ~301.9KiBps uart:~$ flash read_test gd25wb256e3ir@1 0 0x4000 1 Loop #1 done in 16ms. Total: 16ms, Per loop: ~16ms, Speed: ~1000.0KiBps

3.4. Configuring for

...

a Different SPI Flash Device

This chapter explains how to configure a different flash device using GD25WB256E Flash device. Specifically, the GD25WB256E Flash device installed on the Thingy-9151-Lite platform is used as an example.

3.4.1. Get JEDEC info

First step when setting a new SPI flash Flash is to obtain information about it. To do so, we need to create minimal a minimally required description of the flashFlash. Let’s start with the following overlay:

...