Please help me select a good fstorage flash addr range.

[cpeng]

Hi Devzone:

It's really hard to piece together all the informations so I guess I will seek help here.

I need help choosing the location of one page flash storage for my project.

I'm working on nRF52840, I need one page of persistent flash storage for application use, referencing fstorage example.

And this project has a bootloader through USB for DFU firmware update, the code resides at

FLASH_START=0xf4000

FLASH_SIZE=0xa000

So is it safe to take 0xf3000~0xf4000 as my flash storage and then set the application code boundary from 0x01000~0xf2000 (leaving first page as MBR)?

The reason I ask this is I vaguely remember reading somewhere says the bootloader use some little space somewhere (?) to store some weird settings/temporary space(?) and all that weird stuff, so I am quite uncertain if I can claim this one page of space immediately below BL for my own use without causing issues.

Below is my 1MB of flash layout, Could you verify if it's OK?

0xFE000

        BL code

0xF4000

        One page of flash storage for my application

0xF3000

        Code + Softdevice(haven't added in, maybe in the future)

0x01000

        MBR

Also on the page that describe fstorage example,

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/fstorage_example.html

there's a picture showing the memory map

How come in this image, the bootloader stopped at 0x80000 which is half of the 1MB flash?

In the example secure bootloader project as I mentioned earlier, if you open up the section placement Macros, the code address is 

FLASH_START=0xf4000

FLASH_SIZE=0xa000

It's not what's shown in the image above! What's the matter here?

And what is that UCIR.NRFFW[0] anyway? I checked the spec it's a 32bit value! It's not even an address.

Thanks!

[Einar Thorsrud]

Hi,

So is it safe to take 0xf3000~0xf4000 as my flash storage and then set the application code boundary from 0x01000~0xf2000 (leaving first page as MBR)?

Yes. But you also need to make sure that both the application and bootloader does not use that flash page for something else.

Does the application use FDS? Even if it does not use it directly, it will use it if you use for instance the peer manager library for handling BLE bonding. If so, make sure that you put the flash page you use directly right below your FDS pages. The number of FDS pages are configured by the FDS_VIRTUAL_PAGES define in application's sdk_config.h (assuming that FDS_VIRTUAL_PAGE_SIZE equals the physical page size, which is 1024 words).

Is your bootloader the USB bootloader from the SDK? If so, it can be configured to stay away from a specified number of flash pages immediately below the bootloader, ensuring that they are not deleted or written to for temporarily storing an application. You should set NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h correctly in order to do this. Note that the value must be page-aligned, so even if it is in words, legal values are x * 0x1000 * 4.

How come in this image, the bootloader stopped at 0x80000 which is half of the 1MB flash?

In the example secure bootloader project as I mentioned earlier, if you open up the section placement Macros, the code address is 

FLASH_START=0xf4000

FLASH_SIZE=0xa000

It's not what's shown in the image above! What's the matter here?

This is from the SDK documentation, and exact addresses depends on the chip variant etc. You need to put in the values that are correct in your case, and draw the memory map. Then this should become clearer.

In short:

1. Write up a correct memory map for your device and your firmware, which includes bootloader, application, MBR (first page), FDS pages and your fstorage page. Make sure to put the fstorage page right below the FDS pages. Now you have all information you need to do the configuration.
2. Adjust NRF_DFU_APP_DATA_AREA_SIZE in the bootloader sdk-config.h to accomodate both the FDS pags and your custom fstorage page.
3. Adjust your application to use the fstorage page that you wound by writing up the memory map as suggested in 1.

[cpeng]

Thanks! This section in your answer is particularly what i was looking for, could you give a little more detail on this?

"Is your bootloader the USB bootloader from the SDK? If so, it can be configured to stay away from a specified number of flash pages immediately below the bootloader, ensuring that they are not deleted or written to for temporarily storing an application. You should set NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h correctly in order to do this. Note that the value must be page-aligned, so even if it is in words, legal values are x * 0x1000 * 4."

yes my bootloader is the USB bootloader from the SDK.

So that section you mentioned in sdk_config.h is:

// <o> NRF_DFU_APP_DATA_AREA_SIZE - The size (in bytes) of the flash area reserved for application data. 
// <i> This area is found at the end of the application area, next to the start of
// <i> the bootloader. This area will not be erased by the bootloader during a
// <i> firmware upgrade. The size must be a multiple of the flash page size.

#ifndef NRF_DFU_APP_DATA_AREA_SIZE
#define NRF_DFU_APP_DATA_AREA_SIZE 12288

The value is 12288 which is 0x3000. So What value should I set for fstorage upper boundary to avoid collision with bootloader?

Would it be 0xf4000-0x3000 = 0xf1000?

If so could you confirm the memory map now does look like below?

                                               Bootloader                          

                           0xf4000

                                               NRF_DFU_APP_DATA_AREA_SIZE

                           0xf1000 ( 0xf4000 - 0x3000)

                                               One page of fstorage

                           0xf0000 (0xf1000 - 1 page)

                                               Normal application and MBR

Btw I don't use fds for now.

[Einar Thorsrud]

Hi,

This looks almost good. Just note that the fstorage page should be within the app data area. So, NRF_DFU_APP_DATA_AREA_SIZE must be larger. This ensures that the bootloader stays away from your fstorage page as well as the FDS pages (which you don't use for now).

[cpeng]

 "Just note that the fstorage page should be within the app data area. "

Hi Einar, If you look at the memory map I wrote in the post, the fstorage is below app data area.

                                               Bootloader                          

                           0xf4000

                                               NRF_DFU_APP_DATA_AREA_SIZE

                           0xf1000 ( 0xf4000 - 0x3000)

                                               One page of fstorage

                           0xf0000 (0xf1000 - 1 page)

                                               Normal application and MBR

What do you mean "fstorage page should be within the app data area." ?

Does it mean I should include one page of fstorage inside NRF_DFU_APP_DATA_AREA_SIZE?

Could you write the correct memory map for me? If you do that would really clear my confusion.

"So, NRF_DFU_APP_DATA_AREA_SIZE must be larger. "

Does it mean current size (0x3000) is not large enough? How big is enough? Could you explain some more?

Thanks.

[Einar Thorsrud]

Hi,

cpeng said:

Hi Einar, If you look at the memory map I wrote in the post, the fstorage is below app data area.

Yes, that is exactly what I did see, and that is incorrect. It should be within the app data area. If not, you risk this data being overwritten during a DFU operation.

cpeng said:

What do you mean "fstorage page should be within the app data area." ?

The page you use to store data should be within the app data area you configure in the bootloader, so that the bootlaoder knows that it cannot use it for termporarily storing data during DFU procedures. If not, you risk loosing the data during DFU procedures.

cpeng said:

Could you write the correct memory map for me? If you do that would really clear my confusion.

"So, NRF_DFU_APP_DATA_AREA_SIZE must be larger. "

Does it mean current size (0x3000) is not large enough? How big is enough? Could you explain some more?

Just make it one page larger so that it covers all your application data (FDS pages) and the page you use directly.