• State Verified Answer
  • Replies 2 replies
  • Subscribers 93 subscribers
  • Views 655 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 333321
Options

Can't able to read/write on the Flash memory using Fstorage -Reg.

Ragu Palanisamy

Hi,

        Currently, I am working on ble_app_bps code and I alter it to be act as a beacon code and I can able to store a data in the flash memory area 0x30000 and it works fine without any issue. Later I want to implement the OTA application based on this link https://novelbits.io/nrf52-ota-dfu-ble-part-4/ and it works fine.

I am using nRF5_SDK_17.1.0_ddde560 SDK and the s132_nrf52_7.2.0_softdevice.hex version. Initially I am facing few memory issues so I alter my RAM address to 

RAM (rwx) : ORIGIN = 0x20002250, LENGTH = 0xddb0 to RAM (rwx) : ORIGIN = 0x20002DB0, LENGTH = 0xD250

I am altering Fstorage address to 0x5e000 because of using the bootloader  

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
/* Set a handler for fstorage events. */
.evt_handler = fstorage_evt_handler,
.start_addr = 0x5e000, //0x3e000,
.end_addr = 0x5ffff,
};

code is compiled and I flash the code using nrfjprog and I am write some data in flash memory it works.

After these changes OTA works well but Fstorage not works. I can't able to write the data. Initially I changed peripheral mode to beacon mode and stays in that mode only, whenever I press the button for 5 sec then I changed beacon mode to peripheral mode and then it suitable for OTA process and it works as expected. 

After OTA I am in the initial state peripheral mode to beacon mode and stays beaconing. In this I cant able to read/write Fstorage memory. 

After power on/off cycle I read the below memory areas initially after OTA Fstorage data is present but after write fstorage area is erased.

          

I am new to this so, guide me how to do DFU and Fstorage together and help me to solve this issue.

Any help would be appreciated,  

Thank you,

P Ragu.

Parents
  • 0

    Hi,

    The key here is to understand the memory layout when using a bootloader. You should place your persistent data below the bootloader. If you don't use FDS, you can place it directly below it. If you use FDS, you should place it below your FDS pages. Then you need to configure the bootloader to stay away from this region during updates. That is done by adjusting NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h. This reserves area immediately after the bootloader, and you pwrovide the size in bytes (but it must be a multiple of a full page, so a multiple of 4096).

    Looking at your configuration you can see that your fstorage data is placed futher down, which will cause it to get corrupted when you perform a DFU operation. So move it up right below the bootloader.

Reply
  • 0

    Hi,

    The key here is to understand the memory layout when using a bootloader. You should place your persistent data below the bootloader. If you don't use FDS, you can place it directly below it. If you use FDS, you should place it below your FDS pages. Then you need to configure the bootloader to stay away from this region during updates. That is done by adjusting NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h. This reserves area immediately after the bootloader, and you pwrovide the size in bytes (but it must be a multiple of a full page, so a multiple of 4096).

    Looking at your configuration you can see that your fstorage data is placed futher down, which will cause it to get corrupted when you perform a DFU operation. So move it up right below the bootloader.

Children
Related
Terms of service