Micro/Nano/Pico flash filesystem for info segment

Maximilian Gauger said:

Before I start reinventing the wheel: how are you coping with this task?

It depends on many factors. Very important - data structure size versus flash size. Also update frequency. Do you need historical data?

My two usual approaches are:

1) For small records: ring flash buffer of fixed size records. Better if it spans two flash blocks. Free/used record indicator: structure first byte. If it is != 0xff, then flash area used.

2) For large config structures: RAM buffer which is written to flash occasionally (timer-based, like once per hour or something) or on power loss. write process is powered by big enough capacitor

IN my own projects, I solved this problem this way:

All non-volatile information is held in a structure. Also a CRC value. I use two INFO segments for storage (four, if it is too large to fit in one). So I have two alternative storage positions for the structure.
When a change has to be applied, I copy the currently active structure into the second storage position, including the new CRC, then I erase the first segment.
At program start, I check both locations for a valid structure (valid CRC) and set a pointer to it. And do a dummy erase to the second segment, to ensure it is immediately free for a write later. This way, I have always a valid set of data available, even if something goes wrong during write (e.g. power loss).

This method doesn't make use of an incremental write, to add new information without a complete write cycle. But it is safe even with critical information. And it doesn't need any ram (except two bytes for the pointer). The drawback is the relatively long time required when a change is made. But then, my data is usually configuration data and doesn't often change during normal operation (except for the operating hours counter)

I do not really know your requirements. But here is a straw man.

For each type of configuration parameter, you define an ID of a few bits. For example, if you only have two kinds, you can use binary 01 and 10 as the IDs. For three kinds, you can use 01, 100, and 101. For four kinds, you can use 01, 100, 101 and 110. For five kinds, you can use 010, 011, 100, 101, and 110. For six kinds, you can use 001, 010, 011, 100, 101, and 110. Note that the ID is never all 0s or all 1s.

Whenever you store a configuration parameter, you always pack it together with the ID as part of the first byte of that parameter. When you want to retire a configuration parameter, you write 0s over all the bytes of that parameter. And of course, unused Flash bytes are all 1’s.

Will this work for you?

old_cow_yellow said:

Whenever you store a configuration parameter, you always pack it together with the ID as part of the first byte of that parameter. When you want to retire a configuration parameter, you write 0s over all the bytes of that parameter.

[http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=SLAA334 has some information, but that application report hasn't been updated to specifically mention MSP4430F5xx series devices]

I think the Cumulative program time is 16 ms max., while the Word or byte program time is between 64 and 85 us. Thus you can write 188 times safely. Check the data-sheet.

old_cow_yellow said:

But here is a straw man.

On 1x devices, this probably won't work because the maximum allowed write time for 64 byte blocks won't allow 64 write operation (writing and invalidating 32 words). Well, it could work for 32 bit parameters (only 32 writes and 16 overwrites then), ore a larger number of parameters (since the valid ones don't need to be invalidated).

On 5x devices there's plenty of time.

Thank you all. Actually, I was not so much lacking the ideas (invalidating IDs is something I had implemented before...), but rather looking for some running, tested, debugged code.

Looks like I will have to do that part on my own. In the meantime, I have found out that my power supply gives me a few ms warning time before shutting down, so storing everything in RAM and time-triggered/shutdown-triggered writing to flash could be a reasonable alternative.

Max

Maximilian Gauger said:

Thank you all. Actually, I was not so much lacking the ideas (invalidating IDs is something I had implemented before...), but rather looking for some running, tested, debugged code.

Every engineer would be happy to get running, tested, debugged solution so he can relax and technically do not do his job ;)