2020-12-02 04:55 AM
Hello,
I am very new to STM32 MCUs and hoping someone can explain to me the HardFault_Handler and possible reasons why my code is jumping to here? If there is a good resource which discusses this, that would also be very useful but I haven't been able to find anything myself.
Thanks,
Matthew
Solved! Go to Solution.
2020-12-02 07:39 AM
I solved the issue by having a closer look at the data in memory as it was mentioned as one of the possible reasons for entering the HardFault_Handler. I was writing data to an array of a set size however I did not have any constraint on how many samples could be written during a certain process. By adding this constraint, the HardFault_Handler is never entered.
2020-12-02 05:23 AM
Hi Matthew,
In Summary, The Hard Fault Handler traps illegal Memory accesses and illegal program behavior.
So for us to be of any good help, we need to know what you are doing or have done and maybe with some code too :)
And as per resource, this might be helpful : https://www.segger.com/downloads/application-notes/AN00016
Also look at this topic: https://community.st.com/s/question/0D50X00009XkhMS/hardfaulthandler-how-to-capture-them-and-debug-the-faults-in-scbcfsr
Best
Oseihie
2020-12-02 05:26 AM
Perhaps your search is too narrow? This topic has been covered quite repeatedly here for Cortex-Mx processors for a decade plus
Frequent causes:
Access to undecoded memory address, errant pointers
Unaligned accesses (LDRD, STRD)
Stack corruption, or too small
Attempt to execute 32-bit ARM ISA
Write to unerased Flash
Memories needing clock enabled, or QSPI / F(S)MC not initialized
Use of coprocessor (FPU) without enabling
Root Cause:
Inspect registers, and code surrounding failure.
Writes will typically be deferred, via write buffers, look back slightly.
Look at disassembly, relate to C code, look for pointers (in registers) and types of access.
2020-12-02 06:06 AM
For this specific project, I am analyzing 6000 samples on an ADC per second to complete further computations based on the received signal. I am using HAL libraries and custom code. I have implemented a buffer within the putchar function used by printf so that I can store data to this buffer which is then printed via USB VCP while waiting for more data to be received. The HardFault_Error occurs after the first 6000 samples are received and analyzed, and all the data from that loop has been printed. Also, I am specifically using the STM32L4A6VGT MCU. What sort of code would be useful for you to see?
2020-12-02 06:18 AM
Look at the SCB registers to see the cause of the fault.
2020-12-02 06:20 AM
>>What sort of code would be useful for you to see?
The stuff it is actually faulting on..
Register content, and perhaps half-dozen assembler instructions before/after the fault address.
Associate it with the C lines involved.
Faulting at random locations, perhaps interrupt related, trashing stack context.
2020-12-02 07:39 AM
I solved the issue by having a closer look at the data in memory as it was mentioned as one of the possible reasons for entering the HardFault_Handler. I was writing data to an array of a set size however I did not have any constraint on how many samples could be written during a certain process. By adding this constraint, the HardFault_Handler is never entered.