How big is the delay when erasing and writing to configuration storage?
Its noticeable and it stops my running threads as well.
it erases entire of sector 128K, so no less than 1 second, around 2-3 seconds.
Can you change that in the next version so it does not lock threads?
I don’t know when to now save to configuration storage.
I had it on some interrupts, but my other threads need to work.
Putting it on a separate thread every 20 seconds or similar also freezes other threads.
If write only then it is very fast.
Are you keeping erasing every time writing?
If i don’t erase before write i get this:
#### Exception System.ArgumentException - 0xfd000000 (8) ####
#### Message:
#### GHIElectronics.TinyCLR.Devices.SecureStorage.SecureStorageController::NativeWrite [IP: 0000] ####
#### GHIElectronics.TinyCLR.Devices.SecureStorage.SecureStorageController::Write [IP: 004b] ####
Exception thrown: 'System.ArgumentException' in GHIElectronics.TinyCLR.Devices.SecureStorage.dll
An unhandled exception of type 'System.ArgumentException' occurred in GHIElectronics.TinyCLR.Devices.SecureStorage.dllHow large data are you writing every time?
I believe the Flash memory only has an endurance of 10,000 Writes. A write every 20seconds will burn out your flash after about 55hrs.
1 Like
5 bytes in a 32 byte chunk on block 0
really only 10 000? that’s really low, if only 20 writes per day that’s 500 days, that’s not even warranty period
Maybe it is called configuration storage because it should be used for storing configurations which are relatively static?
For data, SDs and USB storage are much better solutions.
1 Like
Yeah but a 10$ SD card 16GB which is probably lowest you can buy, for storing 5 bytes is an overkill
if only 5 bytes then I think I have better way.
write 32 bytes (because chunk is 32 bytes). First 5 bytes is yours data, mark last byte 31 is 0x00.
When you need to read this data, just scan every 32 byte in 128K (start from end), read bytes 31 and check if it is 00 or 0xFF.
if it is 0xFF, continue scan other blocks
if it is 0x00, then this is latest data you wrote.
for 32 byte each:
128*1024 / 32 = 4096 time write * 20 seconds = 81920 sec = 22 hours.
Every 22 hours you erase only one time.
Reading 4096 times to scan like nothing with SC20xxx and non-block because they are C#.
Am I wrong something?
An I2C FRAM chip would be the ideal solution. Virtually unlimited writes and requires no battery to keep after power removed.
1 Like
Or there is ‘Battery Backed Memory’ Real Time Clock (ghielectronics.com)
There is 4KB and read/write that you can try
I2c is not free, the pins are used by PWM
SPI? There is also SPI FRAM as well. Otherwise, as @Dat_Tran suggested Battery-backed RAM would be the other option.
What SitCore device are you using?
SCM20100E, on other devices im using M24C16, that has 4m write cycles.
Anyway… im not that much worried about write cycles (they are executed on button press), its the 1-2 second delay when erasing that’s a thorn in my eye. All my other code stops when its erasing.
Any chance you are using the external QSPI Flash with the SCM20100E? That gives you a minimum 100K writes. Not sure if TFS does any wear-leveling but you could just cycle thru multiple files.
Not sure if it would have the same delay while erasing.
Still, seems to me that RTC BK Ram is the best. Read/Write fast and no need to be erased.
1 Like
TFS does wear-leveling, the data is written to the storage using a log structure and will initiate a GC when the storage approaches capacity.