3. Non-Volatile Memory Storage

This section analyzes the way the SDK handles the Non-Volatile memory storage. The DA1469x SDK defines a set of storage classification rules that allow proper storage handling and budget estimation. For each storage type a dedicated region is mapped in the QSPI FLASH memory which can be identified by a unique ID. Table 1 explains the available partition IDs, defined in /sdk/adapters/include/partition_def.h. The exact memory mapping depends on the FLASH memory model used (size, sector size) and needs to be specified at compile time. The SDK provides a few ready-to-use partition tables that can be found under /sdk/config folder. By default, the 4M model is enabled and perfectly fits in the ProDK QSPI Macronix 32-Mbit FLASH memory (4 MByte with sectors of 4 kB). For more information on the used Flash, read its Datasheet.

Table 1 NVMS Partition IDs

Tag ID



This entry is used during a non-SUOTA enabled application for storing the application image


This entry is used during a non-SUOTA/SUOTA enabled application for storing BLE related information (for example, the BD address of the target device).


This entry is used during a non-SUOTA enabled application for storing binaries.


This entry is used during a non-SUOTA/SUOTA enabled application for logging events or values.


This entry is used during a non-SUOTA/SUOTA enabled application for storing generic data such as bonding data. This is the only area marked as VES (Virtual EEPROM).


This entry is used during a non-SUOTA/SUOTA enabled application for storing platform-specific information.


This entry is used during a non-SUOTA/SUOTA enabled application and contains information on the partition table used.


This entry is used during a SUOTA enabled application for storing the application image


This entry is used during a SUOTA enabled application and contains the new updated firmware version.


This entry is used during a non-SUOTA/SUOTA enabled application and contains information on the target FLASH used as well as various application-specific parameters.


This entry is not used during either a non-SUOTA or SUOTA enabled application. It is kept for compatibility reasons with the DA1468x SoC

The partition layout significantly differs between a SUOTA enabled build and a non-SUOTA enabled build.

3.1. Creating Custom Partition Tables

This section describes the steps required to successfully create a new partition table. It utilizes the default 4M FLASH memory model for a non-SUOTA enabled application and slightly modifies it. It splits the default NVMS_BIN_PART into two areas. To do this, the SDK provides some macros in /sdk/adapters/include/flash_partitions.h file.

'Modifying the 4M Model Partition Table'

Figure 4 Modifying the 4M Model Partition Table


  1. The size of a partition entry should be multiple of sector size, 4 kB in our case (this is device-specific information).

  2. It is recommended not to change the default location of the NVMS_PARTITION_TABLE. However, if you do change the location, the starting address should be declared in /sdk/adapters/include/flash_partitions.h file, as illustrated below: #define PARTITION_TABLE_ADDR NVMS_PARTITION_TABLE_START

  1. Establish a connection between the target device and your PC through the USB1 port of the Pro DevKit.

  2. Import and then make a copy of the freertos_retarget sample code found in the SDK of the DA1469x family of devices.


It is essential to import the folder named python_scripts to perform various operations such as building, debugging, downloading.

  1. In the target application, create a new folder as well as a header file under the project’s /sdk/config/ folder. It should look like this:

'Creating a Custom Partition Table'

Figure 5 Creating a Custom Partition Table

  1. In the newly created file add the following code to define the new partition scheme:

#define NVMS_FIRMWARE_PART_START        0x002000
#define NVMS_FIRMWARE_PART_SIZE         0x07E000

/* +----------------512KB---------------------+ */

#define NVMS_GENERIC_PART_START         0x0E0000
#define NVMS_GENERIC_PART_SIZE          0x020000
#define NVMS_PARAM_PART_START           0x1FF000
#define NVMS_PARAM_PART_SIZE            0x001000

/* +------------------2MB---------------------+ */

#define NVMS_LOG_PART_START             0x200000
#define NVMS_LOG_PART_SIZE              0x100000

#define NVMS_BIN_PART_START             0x300000
#define NVMS_BIN_PART_SIZE              0x080000

#define NVMS_CUSTOM_ENTRY_PART_START    0x380000
#define NVMS_CUSTOM_ENTRY_PART_SIZE     0x07F000

#define NVMS_PARTITION_TABLE_SIZE       0x001000

PARTITION2( NVMS_LOG_PART             , 0 )
PARTITION2( NVMS_BIN_PART             , 0 )
  1. In /sdk/adapters/include/partition_def.h file, modify the nvms_partition_id_t enum to add new IDs for the newly defined entries. A possible modification is illustrated below:

 * \brief NVMS Partition IDs
typedef enum {
        NVMS_FIRMWARE_PART              = 1,
        NVMS_PARAM_PART                 = 2,
        NVMS_BIN_PART                   = 3,
        NVMS_LOG_PART                   = 4,
        NVMS_GENERIC_PART               = 5,
        NVMS_PLATFORM_PARAMS_PART       = 15,
        NVMS_PARTITION_TABLE            = 16,
        NVMS_FW_EXEC_PART               = 17,
        NVMS_FW_UPDATE_PART             = 18,
        NVMS_PRODUCT_HEADER_PART        = 19,
        NVMS_IMAGE_HEADER_PART          = 20,

         * New IDs for the newly defined entries!
        NVMS_CUSTOM_ENTRY_PART         = 21,

} nvms_partition_id_t;
  1. Modify the /sdk/config/partition_table.h file to include another condition for selecting the new partition scheme. It should look like this:

#include <1M/suota/partition_table.h>
#include <4M/suota/partition_table.h>
#elif (dg_configENABLE_DA1469x_AA_SUPPORT == 1)
#include <1M/partition_table.h>
#include <4M_Custom_Table/4M_Custom_Table.h>
#include <4M/partition_table.h>
  1. In config/custom_config_xxx.h file add the macro for selecting the new partition scheme.

#define USE_MY_CUSTOM_PARTITION_TABLE           (1)
  1. Erase the whole flash memory contents either via the serial port or jtag interface. The following uses the second option.

    1. Run the script to erase the flash through jtag.

'Flash Erase Script #1'

Figure 6 Select the Flash Erase Script

  1. In the displayed pop-up window click Yes. Wait for the process to complete.

'Flash Erase Script #2'

Figure 7 Erase the Flash


When changing a partition table, it is essential to erase the old one in order for the new one to be taken into consideration.

  1. Build the project either in Debug_QSPI or Release_QSPI mode and burn the generated image to the chip.

3.1.1. Verifying with the SmartSnippets Toolbox

  1. Open a new instance of the SmartSnippets Toolbox and switch to the QSPI Partition Table window (1).

'Configuring the SmartSnippets Toolbox #1'

Figure 8 SmartSnippets Toolbox - Display the Partition Table Area

  1. In the Partition Table area, click Connect (2). A rotating cursor is displayed waiting for the connected device to reset.

  2. Press button RESET on the Pro DevKit to reset the device.

  3. Wait for the cursor to stop rotating and click Read (3).

    All the partition entries are displayed. The custom defined entries will be displayed as Unknown areas since their corresponding IDs are not recognized by the SmartSnippets Toolbox.

'SmartSnippets Toolbox, Partition Table Area*'

Figure 9 SmartSnippets Toolbox, Partition Table Area


If the new partition table is not shown or updated, unplug and then plug the USB cable from the USB1 port of the motherboard, wait for the device to connect and then execute the steps 1 - 4 again.