hard fault handler (main load)

[david lion]

Posted on March 06, 2017 at 18:38

Hi, I have a problem when I try to load my program. I use the arm compiler (armcc) with a stm32l073.

When I use my debugger I have an Hard Fault handler every times before the main.

I use a standard statup file (startup_stm32l073xx.s). and with the debugger I can see that when  

 BX R0 is called the program goes in HardFault_Handler. 

I use 40kb of flash and 14kb of ram.

Here the emplacement where the program crashes :

Reset_Handler PROC

                           EXPORT Reset_Handler [WEAK]          IMPORT __main          IMPORT SystemInit                            LDR R0, =SystemInit                            BLX R0                            LDR R0, =__main                            BX R0                            ENDP

If someone knows where is the problem ...

Thanks ! 

#cm0+ #stm32l0

[Tesla DeLorean]

Posted on March 06, 2017 at 18:50

__main initializes the statics in your program before calling your main() function.

You should pay attention to how much memory the linker thinks it has for RAM (scatter file, or target pane dialog), and how big of an allocation it is using. Look at the .MAP file.

Step INTO the __main code, see what address it touches when it faults.

Faulting as it jumps to R0 might indicate an invalid address there, but you don't specify what it is.

[david lion]

Posted on March 07, 2017 at 16:04

Hi, I notice that when I Load the bin file, the programs works. But It's only when I try to use the debug (with axf file) that I have this error.

Moreover, weird things, is that when I comment one function that use static varible the debug works. 

I do not know if this picture can helps you : 

The place where the program crash : 

The code size :

[Tesla DeLorean]

Posted on March 07, 2017 at 16:17

The register content at the faulting instruction would be what you need.

A hard fault handler that isn't a while(1); loop would also be able to provide more diagnostics. See code suggested by Joseph Yiu

Going to suppose this part doesn't have any external memory. Faults typically occur when touching memory that isn't present/decoded.

You could check the stack and heap allocations in the startup_stm32xxxx.s file.

The Cortex-M0 is going to be intolerant of misaligned pointers (ie 32-bit variables at Odd addresses)

[david lion]

Posted on March 08, 2017 at 18:38

Hi, I have resolved my problem by a simple trick. My program works when I flash the program without using the debug. So I just flash the board, with ST-Link, and after I launch the debbuger but without loading the executable. Thanks to that the debugger works.