Internal Flash Read/Write with word-aligned addresses instead of page aligned address

Hi Team,

We have allocated the 2 pages for our config data storage. In that each page divided into 4 sub groups, likes each 1k size allocated for one group.

Is there any way to update the specific address in that page. Eg: Page start Address is 0xF4000(4k), in that F4400 is start with another group of data.F4800 start with another type of data.

Is it possible to update the Individual address spaces like F4400  and F4800 as a start address instead of F4000 as start address.

And in some scenarios we need to write or read the only 4 bytes of data from that specific start address.

please suggest us is there any way to update word-aligned addresses like multiple of 4 bytes not entire page at a time.

Regards,

Srinivas.V

Parents
  • Hi Einar,

    Thanks for your reply. As as a summary we can write and read the data with 4 byte alignment , but when it comes to erase we can only erase only page wise.

    Is there any flash write optimization techniques we have in Nordic, please let us know we will use the same.

    Regards,

    Srinivas.V

  • Srinivas V said:
    Thanks for your reply. As as a summary we can write and read the data with 4 byte alignment , but when it comes to erase we can only erase only page wise.

    Yes, that is correct.

    Srinivas V said:
    Is there any flash write optimization techniques we have in Nordic, please let us know we will use the same.

    Which SDK are you using? If you are using the nRF5 SDK, then you can use fstorage for low level flash access. That will require you to handle most yourself, though. Therefor we also provide a simple file system built on top of fstorage, which is FDS. (FDS is also used by the peer manger module for flash storage, so most Bluetooth applications will already be using that).

    If you are using the nRF Connect SDK there are also several options like nvs or perhaps more relevant, littlefs via Zephyr's file system API. See littlefs File System Sample Application for that.

  • Hi Einar,

    Thanks for your reply. We are using the Nrf5 SDK  with the version nRF5_SDK_17.0.0_9d13099.we are not using the FDS, using the fstorage only.

    We have allocated two pages for cfg purposne. In that two page we have portioned the page into 4 parts for different categories. To write to different categories we have created the offset bytes for each category and each time we are loading only one offset. In this way we are reducing the flash wearout impact.

    Please let us know is there any better way to reduce the endurance cycles of flash.

    Regards,

    Srinivas.V

Reply
  • Hi Einar,

    Thanks for your reply. We are using the Nrf5 SDK  with the version nRF5_SDK_17.0.0_9d13099.we are not using the FDS, using the fstorage only.

    We have allocated two pages for cfg purposne. In that two page we have portioned the page into 4 parts for different categories. To write to different categories we have created the offset bytes for each category and each time we are loading only one offset. In this way we are reducing the flash wearout impact.

    Please let us know is there any better way to reduce the endurance cycles of flash.

    Regards,

    Srinivas.V

Children
  • Hi Srinivas,

    With two pages that means you only have the option to fill up to one page with data if you want to be able to update data, as to do that safely, you will need to temporarily write it to a different page. I do not know how you use the flash and if updating data in a safe manner is important, but if it is you would need something like the FDS. Then I would recommend using FDS from the SDK instead of implementing something similar yourself. FDS also include basic wear-leveling.

    Einar

Related