Hardfault_Handler() with minimum new project

[Stoufer]

Hi - I am new to the STM32CubeIDE - moving from Attolic.

I have created a new STM32 project using STM32CubeIDE 1.9.0 for a STM32L151VET6 using New Project.

Our board is built to use an internal oscillator. 

I can try to debug the basically empty new created project or add just a for loop in the while(1) in main() and either way it immediately stops on Hardfault_Handler. 

In the Fault Analyzer :

X Bus, memory management or usage fault (FORCED)

X Imprecise data access violation (IMPRECISER)

X Stacking error (STKERR)

I have set a breakpoint on the while(1) and on the for loop inside it and neither are ever hit.

I believe I have set the pins in the IOC to match my board ( UART, SPI, GPIO )

Any suggestions on how to proceed ?

Thanks!

[TDK]

IMPRECISER would point to a clock issue. Perhaps insufficient wait states for your voltage/clock settings. Step through the program starting at the reset handler and find out where things start to go wrong.

[Stoufer]

I did find the Reset_Handler and added a breakpoint at the first instruction ( inline asm ) - it never hits this one

either.. ( located in startup_stm32l151vetx.s )

 

[Stoufer]

I placed breakpoints at the following locations - and it goes directly to hardfault_handler and does not hit these breakpoints.

 

[TDK]

If you can't run ANY code, then certainly the code is not the issue. Seems odd though.

Perhaps recheck your layout, verify power rails, decoupling caps, etc. Can you share the schematic?

[Stoufer]

Thanks for your replies!!

This board has been in production for years with 30k+ units built...and the particular board I am using runs fine with our old firmware. We have been using Attolic and I wanted to use STM32Cube to create some new firmware - So I created just the minimum "New Project" project - with an empty main() except a while (1) loop... I did try my new firmware first and backed it all out when I was getting this fault. Then started over with a new empty project..got the Hardfault - so I added just a for loop with a delay in the while(1) thinking maybe it needed some code... same issue - immediate Hardfault

I thought maybe it was that we use an internal clock and maybe the default project it creates expects an  oscillator. But looking at the ioc it looks like its expecting internal

I am at a loss of what to even check at this point....

[Pavel A.]

What if you just rebuild the old firmware with CubeIDE? The Atollic toolchain is quite similar to the one of CubeIDE.

If it won't crash, we can exclude code/toolchain issues and move to checking your Cube pinout and generated code.

 

 

[Stoufer]

I did try that a few months ago - and ran into lots of build errors that I did not know how to resolve. Just tried again and I got 69 errors - all were : "multiple definition of ' nnnnnnn ' " so I guess Attolic is configured to ignore this - is there a way to set CubeIDE to ignore them also.

BTW - this firmware is written badly - but it works so we are trying not to change it much - but build a whole new firmware written like it should be... thats what I am trying to start!

[Stoufer]

I dig some digging and found that the above is a common issue with 1.9.0 - so I added the "-fcommon" preproc and the errors are gone!

The project built and when debugging - it stops on my breakpoint in main()....

So  - the toolchain seems OK.

Why is the default created project with a tiny code added to main() causing hardfault ?

Is there anything I can use from this working project to try in the new project ?

Thanks Guys !!!

[Pavel A.]

Good. Now compare the link scripts. Then the startup .s files. 

[Stoufer]

Thanks!!

I found it right away looking at the startup files. Realized the board I am using has a STM32L151V C T6, and I had selected a V E T6 because that is on another board on my desk - we use both in production.

Thanks for you guys help !

[jddz]

Thank you so much for posting your solution. I was fighting with my (first) custom board for the same reason you're describing: no code was executing at all, seemed to crash before break points even trigger, and looking in the SFRs (while debugging, upper right hand corner) under Cortex M4 -> Control -> CFSR I was seeing both STKERR and IMPRECISERR set.

Turns out, I wrote my code originally on a Nucleo featuring the STM32F401R E T6, but my board uses the STM32F401R C T6. I made a new project with the correct chip and it immediately worked. Thanks again!