2. Flash Organization

2.1. Partition Table

The product of the logical segmentation of the available space of the Flash results in partitions. In the Flash a partition is reserved to hold entries of the base addresses of all partitions present on the system. This partition takes one 4 KByte sector and is also known as Partition Table Partition. SDK middleware and possibly application code consult the partition table in order to locate and access groups of data stored in the Flash.

The partition table is created the very first time a new valid firmware boots. The default address at which the partition table will be created is 0x3FF000 and is specified in partition_table.h header file under {SDK_root}/sdk/bsp/config.

Warning

The default address that the partition table will be created at, is 0x3FF000 which is typically the last sector of a 32 MBit Flash. This address might not be valid for a Flash memory of lower capacity. A valid address should be used instead by using the relevant to size predefined header file. This can be done by defining USE_PARTITION_TABLE variations in config/custom_config* files.

Alternatively if a custom address should be used as the base of the partition table, a new such header file should be created and included instead of the default 4M/partition_table.h.

2.2. Partitions

Each logic segment of the Flash could consist a partition. While it is not necessary for all of the Flash space to be allocated in partitions, certain information has to be stored in specific partitions. A list of SDK predefined partitions can be found in the DA1469x Tutorial Flash Adapter Chapter 3.

In order to utilize all the features of DA1469x, the following partitions must exist:

  • NVMS_PRODUCT_HEADER_PART: This partition should occupy two sectors of the Flash, one for each product header. Each product header contains vital information for booting, like the address of target firmware’s Interrupt Vector Table and Flash initialization information. The typical reserved space for this partition is 8 KBytes.

  • NVMS_FW_EXEC_PART: This partition contains the Image Header and the Firmware Image that the system boots on PoR. The size of this partition, as is true for all partitions, is a multiple of sector size and it can never be larger than 0x7FE000 Bytes.

  • NVMS_FW_UPDATE_PART: This partition is for all purposes identical to NVMS_FW_EXEC_PART with the only difference that when not empty, the Firmware it stores is not the most recent or it is the latest update before it has been turned into the active firmware. For obvious reasons its size is also identical to NVM_FW_EXEC_PART.

  • NVMS_PARAM_PART: This partition occupies one Flash sector (4 KBytes) and is where trimming values and BLE related parameters are stored amongst others.

  • NVMS_GENERIC_PART: This partition behaves as a Virtual EEPROM in order to reduce the wearing levels caused by the constant update of user data such as bonding data or notification request entries per device. In general, a common way to use this partition’s space is by utilizing any ble_storage API. The partition is internally divided into eight equal parts which are written in rotation. The minimum size occupied is 16 KBytes by default(useful data load of 2 Kbytes times 8) however it is advised to use sector sized for each subpart.

  • NVMS_PARTITION_TABLE: This partition contains entries of each partition’s starting address custom partitions’ included. While a partition table is not necessary for the Firmware to boot, its contents are used by various middleware and external applications such as SmartSnippetsToolbox™ QSPI related tools.

Note

In our experience, the minimum size that can host commercial firmwares with FreeRTOS and SUOTA capabilities is 512 KBytes. This might require each firmware to be less than 250 Kbytes long and/or several features of the chip not being utilized.

The maximum size of a Flash that can be operated is the maximum allowed by 32-bit addressing as long as the constraints that follow are being respected.

It is strongly recommended to use a Flash of no less than 8 Mbit size in any design that includes DA1469x family.

2.3. Partition Constraints

There are certain conditions that must be met when defining partitions.

  1. All partitions must be Flash Sector aligned.

  2. There can be no overlapping sections between partitions.

  3. It is not mandatory to allocate all of the Flash space in partitions.

  4. Auto mode can address up to 32 Mbytes of Flash Memory. If a Flash has a larger capacity than 32 Mbytes then it must be operated in Manual mode.

  5. It is imperative to have enough space for both Firmware Exec and Firmware Update partitions in the first 128 MBits of the flash as it is impossible to boot from any address beyond this barrier. This happens because the ROM booter can only use 24bit addressing for Flash.

  6. The first 0x400 bytes of a firmware image consist the image header. The binary executable code starts at 0x400 offset from the start of the Firmware Exec or Firmware Update partition.

  7. The maximum size of a bootable firmware executable is 0x7FDC00 for any Flash with a capacity of at least 128Mbits.

  8. Neither Firmware Exec nor Firmware Update partitions should have a size larger than CACHE_FLASH_REG[FLASH_REGION_SIZE] so the firmware contents are all cashable. By default CACHE_FLASH_REG[FLASH_REGION_SIZE] has the value 6 which corresponds to 512 KBytes and the minimum size cache-able is 256 Kbytes. In order to alter this register’s value, the new value has to be written in the Configuration Script in the OTP so the system will boot with the new setting.

  9. Since ARM-M33 has the remapping feature, the Firmware Exec and Firmware Update partitions NEED to start at an address which is a CACHE_FLASH_REG[FLASH_REGION_SIZE] multiple plus an offset of zero to three sectors for the firmware binary executables hosted in the partitions to be bootable.