I have a uint16_t variable. It can increment till 16K. After every increment I want to store into Flash, so that even if there is a reset, I can restore the value.
1) With Flash Data Storage (FDS) whether can I achieve this.
2) Since Flash endurance cycle is 10K even FDS will helps.
3) My application will store 100k of other data into Internal flash. So will I come to know which pages are allocated as part of FDS so that it will not overlap with other data.
Thanks & Regards
1) Yes, you can use FDS for this. It might be that you could to it more efficiently without FDS as this is a very simple and specific use case, but that is up to you. FDS will write a new record every time you update the "variable", and that gives you 3 words (12 byte) overhead per record. This might not be a practical problem though, depending on how often you plan to update this variable.
2) Yes, FDS has basic wear leveling. (but you should also consider that there will probably be more writes to flash for your counter value than if you made a smart application specific algorithm for handling the counter value.)
3) The FDS pages always start right below the bootloader (assuming you use it), and you configure how many pages it uses in the projects sdk_config.h (FDS_VIRTUAL_PAGES).
Thank you for your inputs.
Can you please let me know more inputs on your statement "It might be that you could to it more efficiently without FDS as this is a very simple and specific use case"
I want to increment a word (4-byte) variable. Store the value into Flash. I cant write to same location without erasing entire page.
Simple algorithm I was thinking is,
1) Allocate a Flash memory of page size.
2) Increment variable and store the data into Flash. Next incremented value will be stored at (x + 4) Flash location. 'x' will keep increment by 4.
3) Once end of page reached, erase entire page and store the latest value at the beginning of Flash.
4) With this approach, before erasing entire page, we can increment & store the value up to 1024 (4096 / 4) times.
Please let me know your thoughts about your "Smart application specif algorithm for handling the counter value".
That was the kind of algorithm I was thinking about. Perhaps simple is a better word than smart, but still it is exactly what you need :) It looks good since it allows you to update the number often between each page erase, and you still respect the limitations of the nRF52832 flash. (The page size is 1024 words - 4096 byte - which is split in 8 blocks, so this will result in 128 writes per block, which is well within the limitation of max 181 writes per block before a page erase).
For better understanding, if I want to use FDS as is, then to write same variable of 4-byte size 16k (16000) times, whether do I need to change FDS_VIRTUAL_PAGES macro from 3 to 63 pages.
4 (data) + 12 (fds header) * 16000 (n. of records) = 256,000 bytes = (256,000 / 4096) = 62.5 pages.
Calculations are based on example in below link.
To my understanding, even though FDS_VIRTUAL_PAGES is 3, only 2 pages are used for FDS data operations. Once all 2 pages are full, I assumed, they will be erased and start writing with latest data. But I am not seeing any page erase happening.
If 63 pages are to be allocated then better to go with my algorithm. No meaning in allocating 63 pages.
Please correct my understanding.
Yes, that is correct.
beemavishnu said:To my understanding, even though FDS_VIRTUAL_PAGES is 3, only 2 pages are used for FDS data operations. Once all 2 pages are full, I assumed, they will be erased and start writing with latest data. But I am not seeing any page erase happening.
There will not be an automatic page erase. But when there is no more space left and you attempt to writ to FDS, you will get an error (FDS_ERR_NO_SPACE_IN_FLASH). Then you have to delete some records and perform garbage collection in order to free the flash space.
beemavishnu said:If 63 pages are to be allocated then better to go with my algorithm. No meaning in allocating 63 pages.
I agree that there is no meaning in this. FDS is simply not a good alternative in this case.