Closed khevessy closed 1 year ago
See also STM32CubeF1#11.
ST Internal Reference: 135576
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,
Describe the set-up Custom board with STM32H735V.
Describe the bug Function
EE_VerifyPageFullyErased()
is broken. It always checksAddress
value againstPAGE0_END_ADDRESS
when in reality it should be dependent on theAddress
starting value (even the function header mentions that Address can bePAGE0_BASE_ADDRESS
orPAGE1_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#L321How To Reproduce If there is an inconsistency in pages (both pages start with header 0x0000 in my case),
EE_Init()
andEE_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: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.