Cleaning up the flash memory in interrupt or polling mode

Once the valid elements are transferred to a new set of pages, the previous set of pages needs to be erased. The EEPROM emulation driver raises a flag requesting the main application to clean up the flash memory. This clean up can be delayed by the application program until the real time constraints on the application are lowered (for instance, before going to low power mode).

This flash memory cleanup can be done in polling mode (by calling the EE_CleanUp function) meaning that the cleanup function does not return before one set of flash memory pages used for EEPROM emulation is erased. It can also be done in interrupt mode (by calling the EE_CleanUp_IT function) meaning that the cleanup function returns immediately and following page erases are done by subsequent interrupt service routines.

For most STM32 microcontroller series, the flash memory content is not intended to be modified while the application is running. Thus, on some STM32 microcontrollers, if flash memory data is cached and then modified, this modification is ignored by the cache, and its content becomes incoherent (the data in the cache is different to its new value in flash memory). The X-CUBE-EEPROM firmware implements code to keep the caches coherent so that the user can activate the caches as they wish (instruction cache, data cache, prefetch buffer and so on. Refer to your product reference manual to see which cache is proposed).

For example, for the STM32L5 series X-CUBE-EEPROM example, the MPU (memory protection unit) is used to define the EEPROM flash memory area as noncacheable. Another example is the STM32L4 series, where the DCACHE is flushed after page-erasing operations, as is advised by its reference manual.

This section describes the driver implemented for EEPROM emulation using the STM32Cube firmware for your device series, provided by STMicroelectronics.

• User-configured EEPROM size.
• Supports 8-bit, 16-bit, 32-bit (and 96-bit variables on the STM32U5 and STM32H5 series).
• Increased EEPROM memory endurance versus flash memory endurance.
• Wear-leveling algorithm.
• Possible interrupt servicing during program and erase operations.
• Robust against asynchronous resets and power failures.
• Optional protection implementation for flash memory sharing between cores in multicore STM32 devices (for example STM32WB series products).

The EEPROM emulation software is provided as a dedicated software package called X-CUBE-EEPROM. It is classified as a middleware utility to be compliant with all development boards and product series.

A sample demonstration project using the EEPROM emulation driver is also supplied to demonstrate how to manage 1000 nonvolatile variables. Sample projects are provided for the boards listed in Table 7 Boards covered. They are located in the Projects\STM32xx\EEPROM_Emul package folders, and can easily be tailored to other boards using the same STM32 MCU series.

One more example is provided for the P-NUCLEO-WB55.Nucleo board. It is located at Projects\STM32WB\BLE_HeartRate_EEPROM_Emul\P-NUCLEO-WB55.Nucleo. The Nucleo board maintains a Bluetooth® LE connection and communication in addition to processing EEPROM operations. By using the DUALCORE_FLASH_SHARING preprocessor-defines symbol, this example follows the flash memory sharing mechanism and timing rules described in Dual core considerations.

The project contains four source files:

• eeprom_emul.c: contains the EEPROM emulation firmware functions that can be called from the user program:

  EE_Format
  EE_Init
  EE_ReadVariable32bits
  EE_WriteVariable32bits
  EE_ReadVariable16bits
  EE_WriteVariable16bits
  EE_ReadVariable8bits
  EE_WriteVariable8bits
  EE_Status EE_ReadVariable64bits
  EE_Status EE_WriteVariable64bits
  EE_Status EE_ReadVariable96bits
  EE_Status EE_WriteVariable96bits
  EE_CleanUp
  EE_CleanUp_IT
  EE_DeleteCorruptedFlashAddress

• flash_interface.c: contains the functions needed to handle the STM32 flash specific features.
• main.c: this application program is an example using the described routines to configure, write to, and read from the emulated EEPROM.
• stm32xxxx_it.c: shows an example of interrupt service file using the EE_DeleteCorruptedFlashAddress function in the NMI handler.

For the Bluetooth® LE STM32WB series example, BLE_HeartRate_EEPROM_Emul, the code illustrating the driver exploitation can be found in the Core/Src/app_entry.c file. In particular, the functions EEPROM_Emul_Init and EEPROM_Emul_Operation are examples of sequencer tasks for EEPROM driver initialization and exploitation (read and write operations).

The EEPROM emulation algorithm parameters need to be configured according to the application needs. They are located in the eeprom_emul_conf.h file:

• NB_OF_VARIABLES (default 1000, 100 for STM32C0 series(a)): Number of nonvolatile elements, each element value being 8-, 16-, 32-or 96-bit.
• START_PAGE_ADDRESS: Address of the first flash memory page used for EEPROM emulation. For dual-bank capable devices, the first address of the second bank is a good example value for this parameter to benefit from this feature (see Real-time considerations).
• CYCLES_NUMBER (default 1): The number of kcycles, X, for the equivalent EEPROM endurance. If CYCLES_NUMBER equals 10, the emulated EEPROM has an equivalent endurance of 10 x X kcycles. X is the flash memory endurance for the product used and listed in Table 5 Flash memory endurance.
• GUARD_PAGES_NUMBER (default 2): Number of guard pages used to reduce pressure on flash memory. This number has to be even.
• CRC_POLYNOMIAL_LENGTH (default 16): No need to modify in most cases. A 16-bit CRC is optimized in terms of computational speed and flash memory size, and offers a very good detection rate.
• CRC_POLYNOMIAL_VALUE (default 0x8005): No need to modify in most cases. This ANSI CRC is optimized in terms of computational speed and flash memory size, and offers a very good detection rate

To activate the dual-core flash memory sharing mechanism in the context of the Bluetooth® LE stack of the STM32WB series, DUALCORE_FLASH_SHARING must be defined as a preprocessor symbol in user software.

The set of functions that can be called by the applicative program are described in Table 8 API definition. They are defined in the eeprom_emul.c module.