How to find reason for hard fault , very rarely occurring ?

You'd typically look at the registers in hex, and in the context of the faulting code, and with the stack.

Have a Hard Fault Handler that dumps out enough information you can unpack.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

Doesn't need a debugger to be running, and you can look at a disassembly/listing of the code. Trying to identify what fails, if it's consistent, or entirely random location. Add sanity checking and instrumentation to catch issue, and flow dynamics to that point.

Perhaps there's some buffer or encoding issue with the data.

Check stack depth/low-water-mark

Thx, Clive ,

but where the args are coming ? and printf() prints to ?

here hard fault looks like:

Don't forget a simple looking and analyzing of the call stack at the moment you catch the hard fault with a debugger. And, besides analyzing the hard fault, also the old "divide et impera" can also be used - separate out parts of the project and test to narrow down the problem zone.

But honestly, using HAL/Cube code, especially on H7, and expecting it to work and be reliable is a nonsense. Try setting the optimization to maximum (Ofast+LTO) and see if something works at all! If it doesn't, it means the code is definitely broken. Fix everything until it works with any optimization level.

Would defaulg debug code in hardfault handler in ST example or generated code seem a sensible helping hand for new coders in the embedded space ?