Another question i have, having also implemented crc8 checksum, thinking that in my particular implementation even though the data is just a mere few bytes, I would reserve and write the same data to 2 separate blocks at once for redundancy/error correction, then take the first to pass the crc check. I feel this beats something like writing the data 3 times and voting best 2 of 3.
Or is this largely unnecessary given the durability of flash? I mean apparently you cant even set a bit even if you mean to do it… Or are bit flips entirely based on something else and this does not influence durability?
After reading this thread stating that flash is limited to 10,000 writes, i feel the need to perhaps spread things around a bit.
RTC memory looks good for persisting, not config data, but perhaps state data, as in after an exception/crash where you dont expect battery disconnect/drain while the device restarts…
It also appears unmanaged but without any read/write restrictions secure seems to have, Ill hope to implement core functionality that can be reused by each these memory locations…
@mcalsyn might you be able to help me figure out what is going wrong with my secure storage memory writing algorithm…
Considering your statements:
I had written a memory manager, in which on successive writes, it will use every last byte of the memory area to help reduce wear.
Meaning after writing say a byte at index 0, on the subsequent write it wouldn’t just write to the next block, it would seek the next unused byte which is at index 1 in the same block, and start writing there. But it proves I am unable to do this.
I find that once the block is not empty, i am unable to write to it getting a ArgumentException, no other definitive information given.
Now i understand the description that you will not be able to flip bits from 0 to 1, but as i mention, the function was to merely write to the unused bytes in the block that are still ‘empty’ having only been written previously with (0xff).
To confirm, might it in fact not be possible to write to the same block twice? Of course I always could be doing something entirely unrelated wrong
I can’t actually say. Generally, I have considered that rounding to the nearest 32 byte boundary is cheap, so I have not tried byte-level packing. Maybe there is a check in firmware as to whether the block is truly empty or some limitation in the STM32 architecture that you are seeing bubbled up as an exception.
How big are your config blobs? I find it kind of hard to imagine that within 10,000 write cycles, that those few bytes of rounding cost you any significant lifespan of the device.
Well i was looking to create a library so i wouldn’t ever need to do it again, hopefully it could be useful for anyone’s application, therefore it would be best if not required, to consider the application could have very little config data that may change repeatedly.
That said, personally i have applications with config data as little as 8 bytes, without the overhead of my library, that would be a 75% loss in and of itself, with over head just under 50% loss. There are other points also that would cause a great loss. Like 33 bytes, or just over 4K, and depending on the rate of use, i think you can see the impact/waste.
Now i cant see a device i create standing the test of time and wearing out due to this but…
(other than the exception im getting) where might i learn more about the particular memory used and confirm if there is a limitation?
thanks
