Is it possible to conserve the flash erase/program cycles using append data strategy?

[GlebPlekhotko]

Hello, NXP Support Team.

The current product I'm working on poses a potential flash wear-off problem. The PC software has a set of configuration data it tends to unconditionally write to the LPC5528-based device upon each connection. Each such "generic" write consumes a certain number of erase/program cycles, because the software writes data to logically independent regions of the flash page (you may treat them as "files" of some sort).

So every time the PC connects it consumes, let's say, 20 to 30 erase/program cycles. Seems not too much taking into account claimed endurance of 100000 cycles at least. But if that happens 10 times a day, that poses a significant threat to completely wear off the flash before the product becomes obsolete.

So I'm thinking about the following scenario:

1. erase a page;
2. write a first chunk of data;
3. check if there is enough erased space, if not go to 1;
4. write the next chunk;
5. go to 3;

Each "write" is performed by reading out the page content and "ORing" it with a new chunk (of course with a distinct offset) and writing it back. Something like this:

FLASH_Read(pageBuf, sizeof pageBuf);
memcpy(pageBuf + offset, newChunk, sizeof newChunk);
FLASH_Write(pageBuf, sizeof pageBuf);

My question is: "Will it really help me to preserve the erase/page resource?".

The impact of "over-programming" the flash memory is not explained good enough in the user manual. It's just said in the ECC section, that: "Due to the presence of ECC, over-programming an already programmed word will likely result in inconsistent parity bits; for this reason, it is not allowed to program a memory word without erasing it first."

And yes, I'm familiar and have already run into the issues, which cause the Bus Faults when reading such "over-programming" data, like it is described in this post. It's fine, because Flash API deals with it just fine returning exactly what I expect.

Thanks for your answers.

[GlebPlekhotko]

Oh, venerable author of the mcuoneclipse blog answered my question. \:-) I'm your regular reader, big thanks for sharing your knowledge and experience there! 

In regard to your comment. It seems a decent alternative for the home-brew implementation we currently have. But on the other hand, I have some concerns in regard to its flash memory appetite. The project I'm currently working on is actually in production, full of features and more than 85 percent of the memory is already occupied. And more features and possible fixed to come in the future. So I want to save up as much as possible. Plus transition will cost us much time for development and testing. But I will take a note on your proposition. That might become handy in the upcoming projects. Thank you.

But anyway, it would be quite interesting to get a comment from the support. If that really helps to preserve erase/program cycles, that will definitely help in certain scenarios, like keeping a log of events.

Let's imagine we have a page dedicated to the log and that we have a 4-bytes long log entry (for instance, 3 bytes for the time stamp and 1 byte for the event id). That gives us 512 / 4 = 128 entries in the page. And the "traditional" approach to populating this log will cost us 128 erase/program cycles. Quite intensive wear off I think.

The approach I proposed above helps to address this issue (theoretically, of course), but poses another threat called, I believe, the over-programing. It makes it impossible to directly address the over-programmed region, only by means of the flash memory controller and its API. I've mentioned it here.

[ErichStyger]

Have you considered using a wear leveling file system in FLASH (I'm using LittleFS here: https://mcuoneclipse.com/2023/07/04/littlefs-file-system-with-mcu-internal-flash-memory/)?