Doubts about fstorage in sdk 16.0

RE: Doubts about fstorage in sdk 16.0

Yadhu KP — Wed, 04 Mar 2020 03:01:11 GMT

Thanks, Mr haakonsh for this valuable information.

RE: Doubts about fstorage in sdk 16.0

haakonsh — Tue, 03 Mar 2020 13:07:38 GMT

Yes, some basic flash wear leveling(https://en.wikipedia.org/wiki/Wear_leveling) will help a lot.

The most basic routine is to always write sequentially to flash and never to the same address over and over again. Wait until you've filled a page before you erase it. Use as many pages as you can, and distribute the number of erase cycles across them.

More advance usage is to run error-checking checksums on pages in order to identify pages with memory corruption and disable their use. You can also run error-correcting algorithms to extend the lifetime of a page instead of disabling it, alternatively blacklist certain memory addresses that are corrupt.

RE: Doubts about fstorage in sdk 16.0

Yadhu KP — Tue, 03 Mar 2020 03:05:11 GMT

Thank you so much mr haakonsh for your answer, Is there any way to minimize this erase cycle, and write variable in to a page?

RE: Doubts about fstorage in sdk 16.0

haakonsh — Mon, 02 Mar 2020 14:40:06 GMT

1. Basically this Electrical specification. There is very little overhead of storage vs CPU read/write to flash.

2. Most likely nothing, but eventually you'll have a few bits that are corrupted. Note that that is 10 000 erase cycles. Not how many times you write to a block.

3. fstorage is used by a lot of modules, there's simply not enough time to test every corner-case in our build tests, that's why we label it as experimental. We use it in almost every module that needs persistent storage and we consider it as production worthy for all normal use-cases.