cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4 HardFault_Handler?

MCrew.1
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
MCrew.1
Associate III

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.

View solution in original post

6 REPLIES 6
sanctified
Associate II

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

Perhaps your search is too narrow? This topic has been covered quite repeatedly here for Cortex-Mx processors for a decade plus

https://community.st.com/s/question/0D50X0000Az372YSQQ/stm32l412-hardfault-while-using-minimal-cubeide-example

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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?

TDK
Guru

Look at the SCB registers to see the cause of the fault.

If you feel a post has answered your question, please click "Accept as Solution".

>>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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
MCrew.1
Associate III

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.