Anything would be better than a while(1) loop of silent death.
I've gone over this topic space ad nauseam, does Google not function for people, do I live in a bubble of service? Learn how to use search properly. Look harder, use better search terms.
https://community.st.com/s/question/0D50X0000Az372YSQQ/stm32l412-hardfault-while-using-minimal-cubeide-example
Instrument your code, output diagnostic/telemetry data to a serial ports so you know WTF your code, that you wrote, is doing.
If you have to single-step everything to unpack your own logic, you have failed.
Do static analysis of your call tree. Use that, and some margin, and understanding of interrupt call trees to pick a minimum depth.
Do dynamic analysis of your stack usage, measure how deep it gets, determine some high/low water marks. Enable stack-checking where supported.
Wrap malloc()/free() usage so you know if you are leaking resources, or double releasing memory.
Walk the allocation lists, determine if the list is fragmented.
Walk the stack.
Write routines that walk the stack/heap automatically. Write routines that can dump internal state information, and decompose peripheral/register settings.
Have your production code output enough data to the user that they can provide useful diagnostic information on a call.
If you're not good at detective work, or the behaviour of your own code/logic, consider trace tools, that can allow for dynamic profiling, and how-did-I-get-here failure analysis.
Don't use the Error_Handler(void), use the Error_Handler(__FILE__, __LINE__) so you have some idea where it faulted, better yet have effective failure recovery, or fail safe behaviour, at the points you would have called it. Output a diagnostic message.
I feel a lot of this is basic (embedded) programming competency, but I suspect having multi GHZ/GB systems tends to hide the complications of a resource bound system.
#GroundhogDay #EmbeddedKindergarten
