RETAINING FLASH MEMORY AFTER DFU PROCESS

[arshdeep]

Hi Team Nordic,

I am trying to save my flash data after the DFU process but it keeps on erasing it. I saw a thread in which it was explained to increase the CODE_PAGE_SIZE in order to save the flash data. 

I did increase it:

#ifndef DFU_APP_DATA_RESERVED
#define DFU_APP_DATA_RESERVED (CODE_PAGE_SIZE * 254)
#endif

But still, the data that I am storing at address 0XB2000 and 0XB3000 is getting erased. 

Am I missing something here? Please suggest !!

Thanks,

Arshdeep

[tesc]

Hi,

What SDK version are you using?

The setting has changed a bit through the SDKs, and you may find that it can be set two places (e.g. in sdk_config.h and in nrf_dfu_types.h) which means you need to change it in the correct place as one definition will go through and the other will not.

In any case you should not increase it more than needed (i.e. CODE_PAGE_SIZE multiplied with how many flash pages of application data you have.) A setting of 254 multiplied with the code page size of 4096 gives 0xFE000, which is only two pages less than the total amount of Flash on the nRF52840 of 0x100000 (one MB), so that is expected to fail.

The magic constant (254 in your case) is the number of flash pages to reserve, and will typically be a one digit number. If you only use Flash Data Storage for storing application data, DFU_APP_DATA_RESERVED in the bootloader should be the same as FDS_VIRTUAL_PAGES * FDS_VIRTUAL_PAGE_SIZE * 4 bytes in the application. See FDS_VIRTUAL_PAGES.

Regards,
Terje

[arshdeep]

Hi Terje,

Thanks for your response. We are using SDK 15.3.0 with nrf52840 chip. So shall I change in sdk_config.h or in nrf_dfu_types .h?

Actually I want to reserve only a few pages. I am only using 0xB0000 - 0xBA000 to store app data. So will I have to reserve all the pages above this address or is there a way I can specify only these particular pages to reserve ???

In order to reserve the address 0xB0000 - 0xBA000, the magic constant comes out to be 191. So I changed the DFU_APP_DATA_RESERVED to  (CODE_PAGE_SIZE * 191). Also, changed the FDS_VIRTUAL_PAGES to 191 in the application. but it still did not work for me. 

Regards,

[tesc]

Hi,

The reserved area always starts right below the DFU bootloader. See Dual-bank and single-bank updates. Does this mean you are having a lot of unused flash between the app data area and the bootloader?

I do not quite understand where you get the number 191 from. There would be 256 flash pages in total (for MBR, SoftDevice, application, application data, bootloader, and bootloader and MBR settings pages.) Reserving 191 pages for app data would leave very little to MBR, SD, app, BL and settings pages.

A range of size 0xBA000 - 0xB0000 = 0xA000 is 10 pages.

Regards,
Terje

[arshdeep]

Hi

I got your point.. read this app note which says : 

Application data (like bonding information, system attributes, or data that the application wants to preserve between resets) that should be retained during a Device Firmware Update must be stored in a specific memory area between the application and the bootloader, right before the beginning of the bootloader. This is the default location where the examples provided in this SDK save Peer Manager data

How do I identify this specific memory area? is there a way in SES to do so? or can I identify it using the memory map file? 

Thanks,  

[tesc]

Hi,

Best way to find the area is to use BOOTLOADER_ADDRESS, defined in the SDK in app_util.h. The area below this address is available for app data, i.e. app data starts at BOOTLOADER_ADDRESS - [size of app data].

Regards,
Terje

[arshdeep]

Hi,

As you can see in the code , it says no bootloader start address is configured.

Do I have to make some changes here?

Thanks,

[tesc]

Hi,

If I am not mistaken the bootloader start address in UICR gets written together with the bootloader, from the bootloader hex file. Have you successfully programmed the DFU bootloader to the device?

Regards,
Terje