Please listen to the trouble and cause when debugging with CubeIDE that I was troubled with
The cause is very simple once you understand it, but I couldn't think of it at the time of trouble.
Details of the trouble
A CubeIDE sample program was executed to test FLASH read/write. The program seemed to work correctly, but when the debug connection was made again, only a part of the FLASH content was recorded and the second half of the memory was in ERASE state.
Cause
As you probably know, when you run debugging using ST-LINK on CubeIDE
- programming code to MCU
- after the code program is finished, the MCU enters an uncontrolled free-run state
The MCU is not controlled by the debugger (free-run) and the written code is executed. - Start of debugging process
MCU is reset and stops at the start code
Although it depends on the environment, the free-run state lasts about 1 second, and in this sample program, the erasure of FLASH was completed and the programming of FLASH was executed until halfway through.
This caused me a lot of trouble because the contents of the FLASH memory at the start of debugging were mysteriously reprogrammed halfway through the free-run state.
This cause can explain all the strange phenomena that were bothering me:
- ERASE area is starting outside of sector boundaries.
- The beginning address of the ERASE area is not constant.
- The problem does not occur in standalone mode.
- No memory left after double-programming FLASH memory
Workaround
To work around this issue, simply insert a wait of several seconds with HAL_Delay() before FLASH_ERASE to avoid destroying FLASH in the free-run state.
How to check for free-run
After initializing the program, output “Hellw World” to the console and you should see it by the time debugging starts
Tips
If you are debugging a program that performs non-volatile operations such as erasing and writing FLASH right after the program starts, we recommend you to insert a wait to avoid destroying FLASH by free-running.
I'd be happy to help anyone with any tips.
Thanks.
