• State Verified Answer
  • Replies 4 replies
  • Subscribers 72 subscribers
  • Views 3142 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112739
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

fs_data usage in DFU bootloader and ble_app_hrs_*_with_dfu

Lucas Magasweran

I'm trying to fully understand how DFU works and am going through the nRF5 SDK v11.0.0 example bootloader (dfu_dual_bank_ble_s132_pca10040) and app (ble_app_hrs_s132_with_dfu_pca10040) linker .lds files (for armgcc Makefile projects).

Each contain a different fs_data section definition and placement. However, as far as I can tell, neither applications use flash storage sections to store configuration data.

  1. Are these sections only needed if section variables are used? If so, can I remove these do they need to be defined with zero length?
  2. Why is the bootloader is using RAM (> 0x2000_0000) whereas the application is using the base (0x0000_0000) of flash?
  3. Why are the section names different (i.e. fs_data and fs_data_out)?

App with DFU

ble_app_hrs_gcc_nrf52.ld:

SECTIONS
{
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM
} INSERT AFTER .data;

s132_pca10040.map:

.fs_data        0x20002108        0x0
                0x20002108                PROVIDE (__start_fs_data, .)
 *(.fs_data)
                0x20002108                PROVIDE (__stop_fs_data, .)

DFU Bootloader

dfu_gcc_nrf52.ld:

SECTIONS
{
  .fs_data_out ALIGN(4):
  {
    PROVIDE( __start_fs_data = .);
    KEEP(*(fs_data))
    PROVIDE( __stop_fs_data = .);
  } = 0
}

nrf52832_xxaa_s132.map:

.fs_data_out    0x00000000        0x0
                0x00000000                PROVIDE (__start_fs_data, .)
 *(fs_data)
                0x00000000                PROVIDE (__stop_fs_data, .)
Parents
  • 0

    Hi Lucas,

    fs_data is the use of the Section variable library in the fstorage. fstorage in ble_app_hrs handles the storing of bond information in the application.

    fs_data hold the configuration value for fstorage module, it is placed in RAM. It's the RW data that will be stored in flash but copied to RAM when the chip bootup.

    The bootloader doesn't use fstorage so you will see the section is not initialized and remain at 0x00. The bootloader uses pstorage_raw instead, to handle the flash management.

    You don't have to worry about the fs_data when doing DFU, it's not related.

Reply
  • 0

    Hi Lucas,

    fs_data is the use of the Section variable library in the fstorage. fstorage in ble_app_hrs handles the storing of bond information in the application.

    fs_data hold the configuration value for fstorage module, it is placed in RAM. It's the RW data that will be stored in flash but copied to RAM when the chip bootup.

    The bootloader doesn't use fstorage so you will see the section is not initialized and remain at 0x00. The bootloader uses pstorage_raw instead, to handle the flash management.

    You don't have to worry about the fs_data when doing DFU, it's not related.

Children
Related
Terms of service