Another EEPROM emulation example bug

[khevessy]

Describe the set-up Custom board with STM32H735V.

Describe the bug Function EE_VerifyPageFullyErased() is broken. It always checks Address value against PAGE0_END_ADDRESS when in reality it should be dependent on the Address starting value (even the function header mentions that Address can be PAGE0_BASE_ADDRESS or PAGE1_BASE_ADDRESS). All three examples for EEPROM emulation in this project have the same bug. https://github.com/STMicroelectronics/STM32CubeH7/blob/5975bffae9358bc2b2890a35a203d940a395efef/Projects/STM32H743I-EVAL/Applications/EEPROM/EEPROM_Emulation/Src/eeprom.c#L321 https://github.com/STMicroelectronics/STM32CubeH7/blob/5975bffae9358bc2b2890a35a203d940a395efef/Projects/NUCLEO-H743ZI/Applications/EEPROM/EEPROM_Emulation/Src/eeprom.c#L321 https://github.com/STMicroelectronics/STM32CubeH7/blob/5975bffae9358bc2b2890a35a203d940a395efef/Projects/NUCLEO-H7A3ZI-Q/Applications/EEPROM/EEPROM_Emulation/Src/eeprom.c#L321

How To Reproduce If there is an inconsistency in pages (both pages start with header 0x0000 in my case), EE_Init() and EE_Format() functions may not fix the issue as it won't erase the second page. Program would then be never able to write something to the EEPROM anymore.

Additional context I suggest replacing the condition similarly to EE_VerifyPageFullWriteVariable() function:

// ...
/* Get the valid Page end Address */
uint32_t PageEndAddress = (uint32_t)((Address - 1) + (uint32_t)(PAGE_SIZE));

/* Check each active page address starting from end */
while (Address <= PageEndAddress)
{
  // ...
}
// ...

Additionaly, I would consider renaming variable AddressValue to something more sane. In all other occurrences in this file, AddressValue means virtual address. In this case, we are not looking at the virtual address, we just want to make sure the page is completely virgin (if I am understanding this correctly).

Lastly, I have a suggestion for you, do you consider porting the driver from EEPROM emulation package to STM32H7 family? I know it probably is not of much priority because of the large page size of the flash and inefficiency of this approach here, but those older drivers seem to be full of bugs, so maybe the rewritten ones would be better. I will try to port the newer driver to our board either way.

[ALABSTM]

See also STM32CubeF1#11.

[ALABSTM]

ST Internal Reference: 135576

[ALABSTM]

Hi @Irisbus,

Thank you for this report. You're absolutely right about this point. It is currently being fixed and will be available in a future release hopefully. We will keep you informed.

With regards,