nRF51822 memory layout and compilation

[bojan]

Hello, guys.

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

Here is what the memory footprint of our application code should look like:

We have SoftDevice, Application area, Application data area (for flash data storage and Peer Manager), Bootloader, ... In the image above you can clearly see the borders between different memory areas that we tried to specify in our application linker and bootloader linker files.

Application linker:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x1b000, LENGTH = 0x1E800
  RAM (rwx) :  ORIGIN = 0x20002028, LENGTH = 0x5f58
  /** Location of non initialized RAM. */
  NOINIT (rwx) :  ORIGIN = 0x20007F80, LENGTH = 0x80
}

Bootloader linker:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x3A400, LENGTH = 0x5800
  RAM (rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

  /** Location of non initialized RAM. Non initialized RAM is used for exchanging bond information
   *  from application to bootloader when using buttonluss DFU OTA.
   */
  NOINIT (rwx) :  ORIGIN = 0x20007F80, LENGTH = 0x80

  /** Location of bootloader setting in at the last flash page. */
  BOOTLOADER_SETTINGS (rw) : ORIGIN = 0x0003FC00, LENGTH = 0x0400

  /** Location in UICR where bootloader start address is stored. */
  UICR_BOOTLOADER (r) : ORIGIN = 0x10001014, LENGTH = 0x04
}

In the sdk_config.h file, we have reserved 3 pages for flash data storage (FDS) and specified that the virtual page size is equal to 1024 bits:

#define FDS_VIRTUAL_PAGES 3

#define FDS_VIRTUAL_PAGE_SIZE 1024

What we have noticed though is that, after adding some new features to the code, we come to the point when the device continuously reboots due to some error that happens during the FDS initialization (fds_record_write() function). We have caught this error with the app_error_fault_handler():

...

It seems that our application code overwrites the Application data flash area and thus corrupts the flash data storage (FDS) system. Our expectation was that the code will not compile and link successfully when the code is too big to fit into the Application flash area.

Do you have any idea what we are doing wrong here? Perhaps the borders between the flash areas have not been set properly (e.g. the border needs to be multiple of flash page size...)?

Thanks in advance for your time and efforts.

Sincerely,
Bojan.

[Susheel Nuguru]

The size that you are giving in FDS_VIRTUAL_PAGE_SIZE is in words. That is 1024 words is equal to 4096 bytes. 

4906 bytes = 4 Physical pages on nRF51.

Setting FDS_VIRTUAL_PAGES as 3 means that you are reserving 3*1024 words = 3072 words = 12,288 bytes = 12 physical pages for FDS.

I think your main confusion was thinking that FDS_VIRTUAL_PAGE_SIZE size is in bytes, but the size is in words  as described clearly in the documentation. (word = 4 bytes). As developers we are used to deal with sizes as bytes so, I understand your confusion :)

[bojan]

Thanks for the clarifications, Susheel Nuguru .

It is now clear to us that we would need to set:

#define FDS_VIRTUAL_PAGE_SIZE 256

if we want the Application data flash area of 3KB.

Now, if we create a new DFU image with such a setting (3KB Application data area) and update the nRF51 that runs with the old settings (12KB Application data area), would that update take effect without bricking the device?

Also, if our code does not fit in the Application area, why don't we get the error during the compilation and linking process that the code is too big? Are our settings of the Application and Bootloader linkers OK? Do we need to specify something else?

Regards,
Bojan.

[Susheel Nuguru]

bojan said:

Also, if our code does not fit in the Application area, why don't we get the error during the compilation and linking process that the code is too big? Are our settings of the Application and Bootloader linkers OK? Do we need to specify something else?

It seems like the way it is designed, and the memory pointers being use, the linked is not able to figure out that application is spilling into the application reserved space. The virtual pages number and size seems to be a runtime evaluation thing and not a link time.