X-CUBE-EEPROM: writing stops when both pages full; data no longer read correctly.

[JVSS_Cermob]

I'm using the X-CUBE-EEPROM library on my STM32C031G6Ux to store keys in flash memory. I configured eeprom_emul_conf.h so that the emulated EEPROM starts at 0x08007000, with 2 pages of 2 KB each, and set NB_OF_VARIABLES to 240.

When I tried saving 240 variables once using EE_WriteVariable32bits and reading them back with EE_ReadVariable8bits, everything worked fine.

However, when I repeat this process three times, writing stops once both pages are full, and the data is no longer read correctly.

I experienced similar issues even with 120 variables. Interestingly, adding EE_CleanUp after all writes solved the problem for 120 variables.

I then tried the same approach with 240 variables, calling EE_CleanUp after all write operations, but it still didn’t work.

Is there a reason for this behavior? Am I limited to storing only 120 variables in flash?

[Khaled_DHIF]

Hello @JVSS_Cermob , 

Based on your description and based on the configurations you've provided, the page definitions should look like this for you:

/* Page definitions */
#define PAGE_SIZE               FLASH_PAGE_SIZE                                  /*!< Page size */
#define PAGE_HEADER_SIZE        EE_ELEMENT_SIZE * 4U                             /*!< Page Header is 4 elements to save page state */
#define NB_MAX_ELEMENTS_BY_PAGE ((PAGE_SIZE - PAGE_HEADER_SIZE) / EE_ELEMENT_SIZE) /*!< Max number of elements by page */
#define PAGES_NUMBER            2 // (Set to 2 pages instead) (((((NB_OF_VARIABLES + NB_MAX_ELEMENTS_BY_PAGE - 1U) / NB_MAX_ELEMENTS_BY_PAGE) * 2U) * CYCLES_NUMBER) + GUARD_PAGES_NUMBER )
                                                                                 /*!< Number of consecutives pages used by the application */
#define NB_MAX_WRITTEN_ELEMENTS ((NB_MAX_ELEMENTS_BY_PAGE * PAGES_NUMBER) / 2U)  /*!< Max number of elements written before triggering pages transfer */
#define START_PAGE              PAGE(START_PAGE_ADDRESS)                         /*!< Page index of the 1st page used for EEPROM emul, in the bank */

With this setup, and keeping the main.c logic from X‑CUBE‑EEPROM unchanged:

• A page transfer is triggered as soon as a page becomes full, because now
  NB_MAX_WRITTEN_ELEMENTS == NB_MAX_ELEMENTS_BY_PAGE.
• When the active page is full, the next page in the circular list becomes the receive page:
  • The element that caused the overflow (write n+1) cannot be stored in the full page,
    so PagesTransfer() writes it as the first element of the new receive page.
  • Then PagesTransfer() copies the latest values of the other variables from the old (now erasing) page into this new (now active) page.

However, with a 2 KB page and NB_OF_VARIABLES = 240:

• Each page can hold 252 elements, so after writing a complete set of 240 variables, there is still room for 12 additional writes.
• These extra writes (your second round of updates for the same variables) are appended at the end of the active page.
• When a transfer is triggered, only the latest values found by ReadVariable() are moved, not every individual historical write.
  Those trailing extra elements are effectively discarded when the old page is erased.

With only two pages, this creates a ping‑pong effect:

1. Page A is active, Page B is erased.
2. Page A fills → transfer to Page B (receive → active).
3. Page B then fills → transfer back to Page A (after erase), and so on.

Because you always have a small extra capacity after each full 240‑variable snapshot, the most recent writes of the third round can be the ones that finally dominate what gets transferred. After multiple rounds, the final page content may contain a mixture of values from different rounds (earlier and later updates), but this is still consistent with the X‑CUBE‑EEPROM logic and should not break the internal data‑integrity checks.

Kind regards,