2025-02-12 12:18 AM
Hi,
When the sample program FLASH_EDATA_EraseProgram is executed on the NUCREO-H563ZI board, it appears that 0xAA55 is correctly written to the high-cycle data flash. However, when debugging is terminated and the board is rebooted, the data in the latter half of the flash is not written, and it remains in the Erase state (0xFFFF).
Since the memory in the Erase state is not at a sector boundary, it cannot be considered that it was erased later. Also, although the memory in the Erase state causes an NMI interrupt when read, it is possible to write to it, and after writing it becomes possible to read normally.
Please give advice how to work with the high cycle data!
Thanks,
Kiyama
Solved! Go to Solution.
2025-02-16 7:14 PM
Self resolved.
The cause of the defect was due to the MCU going into a free-run state when the debugger was connected, erasing and reprogramming the FLASH memory.
As a result, all memory contents that had been written immediately before were lost, and since the debugger was reset during the reprogramming process, the second half of the FLASH memory was left in an ERASE state.
The problem was solved by inserting an appropriate weight after initializing the MCU to prevent the FLASH erase from being executed in the free-run state.
Thank you.
2025-02-12 6:46 AM
Hello @Kiyama,
>>Also, although the memory in the Erase state causes an NMI interrupt when read, it is possible to write to it, and after writing it becomes possible to read normally.
You can prevent this ECCD by following this section in RM:
You can refer to this article: Handling ECC errors in STM32H5 series: Reading unw... - STMicroelectronics Community
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-02-12 7:19 PM
Dear Sarra,
Thanks for the reply, FLASH_ECCDR is set to 0xffff as in the memory dump and the written data is lost.
My question is whether the “FLASH_EDATA_EraseProgram” code is programming FLASH correctly.
The “FLASH_EDATA_EraseProgram” code erases the FLASH memory from 0x0900000000 to 0x0900bfff and fills all of them with HALFWORD (0xAA55). The verification is performed immediately afterwards, and it is verified that all memory is filled with HALFWORD (0xAA55).
However, when the debugger is restarted, only about 1/4 of the FLASH memory from the top is written, and the rest remains in Erase state and the written data is lost.
If the example code is changed and the FLASH memory is intentionally overwritten with another value (e.g., 0x0000), something even more unexpected will occur. Immediately after writing, a DECC error state (ECCDR:0x0000) occurs, but when the debugger is restarted and the memory is checked, the overwritten value does not remain and the memory is in Erase state with 0xAA55.
It appears as if the data written by the backlight cache is not actually written to the FLASH memory. However, disabling ICHASH did not improve the phenomenon.
This is a situation where the sample code provided by CubeIDE is not saving data to FLASH properly. Could you please tell me the cause and how to safely program to FLASH?
2025-02-16 7:14 PM
Self resolved.
The cause of the defect was due to the MCU going into a free-run state when the debugger was connected, erasing and reprogramming the FLASH memory.
As a result, all memory contents that had been written immediately before were lost, and since the debugger was reset during the reprogramming process, the second half of the FLASH memory was left in an ERASE state.
The problem was solved by inserting an appropriate weight after initializing the MCU to prevent the FLASH erase from being executed in the free-run state.
Thank you.