Hi,
Very, very, unlikley to be flash corruption. Much more likely to be a memory referencing issue.
It sounds like a stack problem or a pointer/indexing variable that is not being initialized to the correct values at start up so that it ends up pointing to an "invalid" part of the memory space. Or it could be the same thing, but the variable is being incremented to the point where it indexes an invalid part of memory.
Are you using an operating system like FreeRTOS or is it a bare metal project? If you are then it could be you are over-running a task stack or you aren't creating the tasks, semaphore or timer correctly. I've run into this a couple of times due to forgetting to do something. These can be tricky faults to find because the hard fault occurs in the operating system.
To test whether you are over-running the stack, fill the stack with a pattern, I use 0xA5A5A5A5 and then when it crashes, look at this memory to see whether all of the stack pattern has been over-written. If it has then you are most likely over-running the stack. Then make the stack as big as you can and test again. If its still being overwriiten it looks like a recursive use of a function that keeps pushing data onto the stack without ever popping data i.e. returning from the function. Also have a look at the stack pointer and see whether it's pointing to an address expected by your program.
If it isn't the stack go through you code with a fine-tooth comb looking at every variable for correct intialisation. I once had a FIR filter generated with an automatic code generator that didn't intialize the circular buffer pointer to zero. The pointer could start with any random values some of which would cause the algorithm to access non-existing or flash memory and bring up the dreaded HARD FAULT.
Another good trick is to use printf debugging and use the hard-fault handler to print the hard fault data to tera terminal or the printf debug window.
Are you using STM32CubeIDE, if you are have a look at smart breakpoints which can output values defines by the user whilst in debug mode.
Sometimes a project will run OK when started from the debugger, but fail when power recycled. I don't know whether yours is doing this, but if it is it most likely because the debugger is intitilizing ram behind the scenes so the program runs OK, but when you power recycle (no debugger) the variables aren't zero'd out and the thing fails. In this case it is probably not a stack thing but an initialization thing.
Have a look at my post on debugging hard faults outside the debugger, that may help.
"How to debug faults which only occur with the debugger disconnected. STM32H7B3I-DK"
Regards
Rob
