This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52 Flash write and read

Hai

I have an NRF52840 Development board with 1MB of flash. I have an requirement to store a large amount of data in a flash around 6k samples in one record.

For this, I'm using an FDS_VIRTUAL_PAGES  of 32 and an FDS_VIRTUAL_PAGE_SIZE of 4096. With this configuration of settings, I can write and read 30 records.

The above part can be one requirement. In addition to this if I try to write on any single record i.e, 31st record. There is a failure of writing flash and reading flash in among the 1 -30 records.

I Only write and read the 1-30 records I can perform the operations, But sometimes this writes and read behaviour is unpredictable.

So can anyone tell me how can we write and read a large amount of data into flash without fail?

Thanks in Advance.

Parents
  • Hi,

    With FDS_VIRTUAL_PAGES of 32 and FDS_VIRTUAL_PAGE_SIZE of 4096, you use half a MB of Flash for FDS. One of the virtual pages is used as a swap page, leaving you with 31 data pages. Each data page has 16384 bytes, with 8 bytes for page header, leaving 16376 bytes for records. Each record has a 12 byte header. A record must be fully contained in one virtual page (it cannot cross virtual page boundaries). I suspect that you get only one 6K sample record per virtual page. With 31 records, you therefore have filled all of the FDS pages and cannot fit another one.

    In order to update a record, there needs to be space in flash for the new updated version to be written. Since there is not space in flash for a full such record, it cannot be updated (and new records cannot be written.) Running garbage collection will not free the space that you need, because the issue is not deleted (or old version of updated) records taking the space. The issue is all flash pages filled with valid records and too little free space in each virtual page to fit another one.

    In your situation, you could put a cap on the number of records, so that you always have some "room to spare" for updating existing records. You would have to keep track of that from the application side.

    You may also want to look into optimizing the size of records, so that they better fill the space. For instance if you fit the record size (including the 12 byte header) so that it fits an exact number of times in the virtual page after the 8 bytes header of the virtual page is subtracted. You may also consider dividing that large chunk of 6k samples into several smaller records, as that would be easier to work with to get things to fit in FDS.

    Regards,
    Terje

Reply
  • Hi,

    With FDS_VIRTUAL_PAGES of 32 and FDS_VIRTUAL_PAGE_SIZE of 4096, you use half a MB of Flash for FDS. One of the virtual pages is used as a swap page, leaving you with 31 data pages. Each data page has 16384 bytes, with 8 bytes for page header, leaving 16376 bytes for records. Each record has a 12 byte header. A record must be fully contained in one virtual page (it cannot cross virtual page boundaries). I suspect that you get only one 6K sample record per virtual page. With 31 records, you therefore have filled all of the FDS pages and cannot fit another one.

    In order to update a record, there needs to be space in flash for the new updated version to be written. Since there is not space in flash for a full such record, it cannot be updated (and new records cannot be written.) Running garbage collection will not free the space that you need, because the issue is not deleted (or old version of updated) records taking the space. The issue is all flash pages filled with valid records and too little free space in each virtual page to fit another one.

    In your situation, you could put a cap on the number of records, so that you always have some "room to spare" for updating existing records. You would have to keep track of that from the application side.

    You may also want to look into optimizing the size of records, so that they better fill the space. For instance if you fit the record size (including the 12 byte header) so that it fits an exact number of times in the virtual page after the 8 bytes header of the virtual page is subtracted. You may also consider dividing that large chunk of 6k samples into several smaller records, as that would be easier to work with to get things to fit in FDS.

    Regards,
    Terje

Children
No Data
Related