Flash endurance parameter

[kvrbek]

Hi,

Can somebody please explain what the "Flash memory endurance" value in the datasheet means? The max number of overall writes to the flash page or the max number of writes in the particular "cell" inside the page?

Simple context:
Let's say that the MCU has a page size of 2kB, a write granularity of 8bytes (64 bits, the "cell" - 256 of them in the page), and endurance in the datasheet 10k.
The application writes from the beginning of the page toward the end. Reaching the end, rollover happens, the page is erased, and the same cycle repeats.
How many application cycles are needed to reach the endurance value from the datasheet, 10k or 10k/256?

Best Regards,
Krunoslav

[STOne-32 · Accepted solution]

Dear @kvrbek 

Flash endurance cycle corresponds to the number of Page Erase cycle numbers and not the Programming ( Writes of 0x0).  Once the Page is Erased it becomes 0xFF with all cells.  Hope it helps on the endurance question.

Cheers,

STOne-32

[kvrbek]

Hi @STOne-32

Thank you for the answer.

Seems to me that the implementation in the EEPROM emulation library (X-CUBE-EEPROM v6.1.0) "allocates" more memory than is needed (at least for the cases when the max. number of the variables is much less than the number of variables that a single page can hold).

Example 1:
#define NB_OF_VARIABLES (1U)
#define CYCLES_NUMBER (10U)// Request 100k minimum writes
#define GUARD_PAGES_NUMBER (0) // AN4894 document: No guard page is necessary if the number of emulated variables leaves significant room in the ACTIVE page

Page size is 2KB and possible variable elements that a single page can hold is 252.

Taking the AN4894 document, Figure 5. Data update flow, the two pages are enough to fulfill the minimum writes requested (2 pages x 252 updates x 10k page endurance = ~5M, 5M > 100k). But the library "allocates" 20 pages.

Example 2 (probably more practical):
#define NB_OF_VARIABLES (50U)
#define CYCLES_NUMBER (10U)// Request 100k minimum writes
#define GUARD_PAGES_NUMBER (0) // AN4894: No guard page is necessary if the number of emulated variables leaves significant room in the ACTIVE page

The 3 pages (4 if the even number of the pages is mandatory) are needed to fulfill 100k (average) updates per variable: ((3pages x 202 updates)/50) x 10k = ~120k /* on page switch, all variables are transferred to the new page, therefore 50 slots are immediately occupied */. Again, the library "allocates" 20 pages.