nRF51822: How to properly define FLASH region boundaries in the case secure Bootloader is used

[bojan]

Hello, guys.

We are using nRF51822 SoC together with nRF5 v12.3.0 SDK.

According to the nRF51822 memory layout, half of the 256KB flash memory space is taken by the Softdevice, MBR, and Bootloader.

The other half (~127KB) is at our disposal for the Application code.

Now, in the case we are using a secure Bootloader, do we need to properly adjust the FLASH region size in a linker script of our application so that only 0x1B000 - 0x3AC00 FLASH region is at our disposal for storing the application code, constants, and initialized/uninitialized data? To have: 

MEMORY
{
  FLASH (rx) : ORIGIN = 0x1B000, LENGTH = 0x1FC00
  RAM (rwx) :  ORIGIN = 0x20002028, LENGTH = 0x5fd8
}

instead of:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x1B000, LENGTH = 0x25000
  RAM (rwx) :  ORIGIN = 0x20002028, LENGTH = 0x5fd8
}

Should we reserve any flash memory area between the application and bootloader to serve some purpose (that we are currently unaware of)? According to the single-bank application update described here (our application is ~100kB in size so the only way to update it would be through a single-bank update), there should not be any FLASH space between the application and the Bootloader, but we would just like to double-check with you.

Thanks in advance for your time and efforts.

Sincerely,

Bojan.

[bojan]

Hello, guys.

Any suggestion?

[Sigurd]

Hi,

Now, in the case we are using a secure Bootloader, do we need to properly adjust the FLASH region size in a linker script of our application so that only 0x1B000 - 0x3AC00 FLASH region is at our disposal for storing the application code, constants, and initialized/uninitialized data?

Yes, I see the buttonless DFU example started doing that from SDK 13, so yes, I would modify it to compensate for the bootloader. i.e. set it to 0x1FC00

Should we reserve any flash memory area between the application and bootloader to serve some purpose (that we are currently unaware of)?

If you use the Peer Manager/ FDS module, then data stored by this module(e.g. bonding information) will be placed at the end of the application space. The bootloader is aware of this, and will not overwrite data stored here during the DFU. You don't need to do anything in your MEMORY configuration for this.See this page: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.3.0%2Flib_bootloader_dfu_banks.html&cp=8_5_10_3_5_1_2_2&anchor=lib_bootloader_dfu_appdata

[bojan]

Thanks for your reply, Sigurd !

We are indeed using both Peer Manager and FDS module with the following settings:

#ifndef FDS_VIRTUAL_PAGES
#define FDS_VIRTUAL_PAGES 3
#endif

#ifndef FDS_VIRTUAL_PAGE_SIZE
#define FDS_VIRTUAL_PAGE_SIZE 1024
#endif

Are the data stored by those two modules (Peer Manager and FDS module) already accounted for in the application compilation report (already in the application space)?

If affirmative, then we don't need to leave any space between our application space and the bootloader area. If negative, I am afraid we would need to account for Peer Manager and FDS areas.

Regards,

Bojan.

[Sigurd]

Hi,

bojan said:

Are the data stored by those two modules (Peer Manager and FDS module) already accounted for in the application compilation report (already in the application space)?

No, as far as I can see it is not. PM/FDS claims this area at run-time.

[bojan]

Hi,  Sigurd 

If the application compilation report does NOT contain Application Data (PM/FDS), this would mean that we need to take into account the size of the Application Data area when defining available FLASH space for the application in the linker script. Please confirm.

How we can know the size of the Application data area? Our FDS module contains 3 blocks of 1kB each so I suppose 3kB will be taken by FDS. What about PM, how can we figure out what is size needed for the PM block?

Regards,

Bojan.