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

[AScha.3]

the "system" is a audio player, decoding (in float) MP3 stream, output on I2S to a DAC;

cpu H743 , at 200MHz, i/o by DMA1 , stream coming from ESP8266 wlan radio.

system ok, running ...maybe 1..3 hours, then hang up:

just now got it first time, still in debug connection -> hard fault !!!!

what can happen here, after so long time running without error ?

SCB shows : (nothing, that helping me...)

 

what is running ? DMA (slave) input, MP3 decoder (in float) , DMA slave output; caches ON (data aligned (32)) .

i was thinking, problem coming, when internet/radio stream has dropout too long, buffers run empty and ISR callback waiting - until next callback coming. i put variable there, to stop waiting for data...most time, got no errors, when debug /conn. to PC , but seem to happen with some relation to dropouts on stream.

but what causes hard fault then?

[Tesla DeLorean]

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

[AScha.3]

Thx, Clive ,

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

here hard fault looks like:

[Tesla DeLorean]

startup.s

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

whatever debug serial channel you're using, or some other slack pin associated with a UART. On some parts SWDIO and/or SWCLK can be a UART-TX, or PB3 SWO pin for a Serial Wire Viewer (SWV)

[Piranha]

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.

[S.Ma]

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 ?