Setting up App Data preservation with DFU

RE: Setting up App Data preservation with DFU

Vidar Berg — Thu, 29 Nov 2018 09:36:57 GMT

Yes, FDS will automatically use the app data region which gets placed below the bootloader as shown here. The region end add address (where bootloader starts) is found by reading out the BL start address stored in NRF_UICR->NRFFW[0], see fds.c ->flash_end_addr() .

You may chose how many flash pages you want allocated to FDS by changing FDS_VIRTUAL_PAGES define in sdk_config.h. But note that APP_DATA_RESERVED define in the bootloader code must correspond with FDS_VIRTUAL_PAGES value used by the app to ensure that user data is not erased by a DFU.

[quote user="erosembedded"]
For Volatile, I meant define it so the compiler will not optimize out any usage I have of the data. But using the FDS may get rid of the need for that. [/quote]

FDS will simply copy the data from a given source address so you should assess your code to determine the structure should be declared volatile.

RE: Setting up App Data preservation with DFU

erosembedded — Thu, 29 Nov 2018 02:24:29 GMT

FDS sounds like the way to go.

I had a question, does the FDS automatically use the persistent "app data" region in flash that the bootloader does not write to? I don't see any set up for where the file system is located. Is it set up so that whatever I write to the file system will not be overwritten by the bootloader?

For Volatile, I meant define it so the compiler will not optimize out any usage I have of the data. But using the FDS may get rid of the need for that.

I don't plan on writing to my configuration file very often. It will only be written to once in a while with long periods (days, weeks) in between.

RE: Setting up App Data preservation with DFU

Vidar Berg — Wed, 28 Nov 2018 09:44:55 GMT

You may know this but there are a few things to keep in mind when dealing with flash storage. 1. flash must be erased before you can write to it. I.e.,, to update existing data in flash you need to ensure that the flash page you are writing to is erased. 2. Flash can only be erased in units of flash pages (4kB on nRF52 series). 3. Page erase is a relatively time consuming task (<85 ms) and the softdevice may fail do schedule it if there's too much BLE activity (short connection interval, etc), see Flash API for more information on how the scheduling works.

Generally I think FDS is the best option, especially if you need to update data regularly. Instead of erasing a flash page every time existing data is updated FDS will invalidate the old record by writing one bit then write a new one. When there is no more flash pages you can run garbage collection to remove invalidated data.

[quote user="erosembedded"]I do not need to use a file system. I just need to define a simple C structure with maybe 1kBytes of data max. I need to be able to update this app data in the application code as well. If the configuration changes or the data structure changes I need to write new data.[/quote]

FDS/Fstorage does not care about data types but the data source must be from one contiguous block in memory and the length must be a multiple of 4 bytes (word). It might make sense to split up the structure in smaller data records if you parts of the structure is being updated more frequently.

[quote user="erosembedded"]It is also important that I be able to define the structure I put in the app data as "packed" (packed attribute) and sub structures within it as packed as well. It also needs to be volatile as well[/quote]

FDS/Fstorage does not care whether the structure is packed or not. I'm not sure what you mean by 'volatile' in this context but the source data must be kept in static memory until the flash operation is completed.

The following examples demonstrate usage of fstorage and FDS in the SDK:

Flash Data Storage Example

Flash Storage Example

Note: if you end up using FDS, it is not necessary to initialize it as it being done by the PM. Just register a new user.

void flash_callback(fds_evt_t const * p_evt)
{
    switch (p_evt->id)
    {
        case FDS_EVT_INIT:
            if(p_evt->result == FDS_SUCCESS)
            {
                NRF_LOG_INFO("FDS initialized");
            }
            break;
            
        //TODO: add fds event handling
}

void flash_init(void)
{
    uint32_t err_code;

    err_code = fds_register(flash_callback);
    APP_ERROR_CHECK(err_code);
}

RE: Setting up App Data preservation with DFU

erosembedded — Wed, 28 Nov 2018 00:37:26 GMT

The buttonless BLE DFU PCA100040 example uses the peer manager so it is also in my code as well.

It has this function:

/**@brief Function for the Peer Manager initialization.
 */
static void peer_manager_init()
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
    sec_param.bond           = SEC_PARAM_BOND;
    sec_param.mitm           = SEC_PARAM_MITM;
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;
    sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
    sec_param.oob            = SEC_PARAM_OOB;
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    sec_param.kdist_own.enc  = 1;
    sec_param.kdist_own.id   = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id  = 1;

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

I do not need to use a file system. I just need to define a simple C structure with maybe 1kBytes of data max. I need to be able to update this app data in the application code as well. If the configuration changes or the data structure changes I need to write new data.

It is also important that I be able to define the structure I put in the app data as "packed" (packed attribute) and sub structures within it as packed as well. It also needs to be volatile as well

So I'm guess using fstorage directly with peer manager as you mentioned would be best?

RE: Setting up App Data preservation with DFU

Vidar Berg — Tue, 27 Nov 2018 16:11:13 GMT

Hi,

Device manager and pstorage have been replaced with the peer manager and FDS/fstorage. Instructions on how you can implement persistent storage depends on whether you intend to use the peer manager (support BLE pairing) or not and if you want to use fstorage or directly or use FDS on top (file system). Please let me know if you are using the peer manager and if you prefer fds or fstorage.

It's not necessary to define the app data section in your linker script but you need to make sure that the application does not grow into this section.