fstorage problem when update firmware OTA

[Brunelli]

Hi, in my project I'm using fstorage library to store some information that should be kept even after the firmware update.

For this we are reserving the memory address as shown below:

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
    .evt_handler = fstorage_evt_handler,

    .start_addr = 0x6F000,
    .end_addr   = 0x6FFFF,
};

This code was working great, but it started losing memory after an update.

What could be happening? Is it possible for this starting address to be different?

[Einar Thorsrud]

Hi,

As already mentioned you need to take in to account FDS if you use that. Referring to the memory layout in the bootloader documentation, you can see that the FDS pages are immediately below the bootloader. So your f_storage pages should be below that again, as explained by Timor .

As you only see the issue after a OTA DFU update, the problem here is likely not a conflict with FDS, though. An important point is that the bootloader must know which pages it should not touch. Most example projects in the SDK use 3 FDS pages for persistent storage, and nothing else. Therefore, the default configuration of the bootloader is also to not touch the first 3 pages immediately below the bootloader. However, you need to reserve also the page you use for fstorage, so that would be 4 pages below the bootloader in this case. To achieve this you must adjust NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h to 16384 (4 * 0x1000).

[Brunelli]

Thanks for the answers, so if I understood correctly, is it not possible for me to fix this problem with the products that are on the market, just correct it for the next products?

[Einar Thorsrud]

Hi,

Not necessarily. You can update the bootloader via DFU to a modified bootloader that has an updated NRF_DFU_APP_DATA_AREA_SIZE so that it will not touch the protected area for future updates.

It could be that the bootloader update would also touch the area that should be protected, but that depends on both the size of the application and the bootloader (see Dual-bank and single-bank updates). Best case, you can make an update zip with just the updated bootloader just to fix this, and you will be able to fix this. Worst case, you would overwrite the protected area in the process, but it would not happen for any subsequent DFU updates.