Persistent circular buffer with CC3220SF

Question

I'd like to share with you some thoughts about a project to see if there are better solutions than mine...

I'm designing a board based upon CC3220SF, that requires an external flash (16 Mbit) where it stores system's and user's files.

My application MUST have a persistent circular buffer of 512/1024 kbytes. This is because the board acquires some sensors periodically and send them to the cloud. But if the connection is not available it MUST save the data for later uploading.

Some ideas:

• use the internal RAM: reducing a bit the requirements about the buffer size, the space is enough but it seems it isn't reliable across resets (please note my system is battery powered: if the battery dies it's acceptable to loose the last records - if any)
• use the external flash: there is plenty of space, but it seems there it's not possible to "overwrite" a file changing only the bytes involved: any write operation leads to a complete rewrite of the whole file. This limits the expected life of about 100,000 records. No way.
• add an external S/F/D/NV-RAM: after some searches I found DRAMs are very cheap but require a parallel bus. The other types are quite expensive for that capacity.
• ok, the last idea that comes to my mind is to add a second flash memory. Now I can write to it directly (without any file-system) but I have to select one that not requires a full page write.

Some other information:

• the expected life of the battery should allow to acquire more than 130,000 records
• of course after replacing the battery the board must be still functional...
• due to the expected environment, it is very likely that the board might acquire hundreds of records every day WITHOUT an available connection. Then it will upload them at once during the night.

Any suggestions would be appreciated.

Answer 1

A typical external serial NOR flash would allow individual bytes to be written, but must be erased in 4K chunks. If all you need is a single rolling buffer, a simple approach would use a page-status byte on each page to keep track of where data should go. At any given time, there would be three "special" pages:

1. The current page, to which new data would be written.
2. The garbage page, which would be the one after that (or first page if the current is the very last one), which might contain anything, but whose contents should be presumed meaningless and thus ignored.
3. The tagged page, which would be the one after that (wrapping as above), and will be the only page (other than the garbage page, which could contain anything) where the page-status byte is programmed.

If there's room in the current page to add data, append there. Otherwise, erase the garbage page, and program the page-mode byte on the page following the tagged page, turning that page into the tagged page, the previous tagged page into the garbage page, and the previous garbage page into the current page.

The tagged page may be identified because it will be the only page whose tag byte is programmed, but whose successor's tag byte isn't. Note that the tag byte on the garbage page might read as be programmed, but its successor's tag byte will also be programmed.