cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 - HardFault_Handler / HAL_TIMEOUT errors

C. Mart
Associate III

Hello!

We have 2 identical custom PCB using STM32F446RE MCU, we encounter the following issues and we can't find out what is happening.

I'll try to explain the best I can such problem, testing boards with simple LED blinking program:

while (1)
  {
	HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_10);
	HAL_Delay(500);
	HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_9);
	HAL_Delay(500);
    /* USER CODE END WHILE */
 
    /* USER CODE BEGIN 3 */
  }

board 1:

Program sometimes goes to HardFault with:

  • HCLK Clock = 82 Mhz
  • HSI RC = 16 Mhz

Program stops at HardFault_Handler with:

  • HCLK Clock >= 83 Mhz
  • HSI RC = 16 Mhz

Same happens with HSE = 16 Mhz

board 2:

Program sometimes goes to HardFault with:

  • HCLK Clock = 75 Mhz
  • HSI RC = 16 Mhz

Program stops at HardFault_Handler with:

  • HCLK Clock >= 76 Mhz
  • HSI RC = 16 Mhz

Here with HSE it gives HAL_TIMEOUT error when calling SystemClock_Config(), with the following values when debugging inside HAL_RCC_OscConfig:

  • tickstart = 101
  • HAL_GetTick() -> uwTick freezes at 101

External crystal is connected with 26pF caps

I add .ioc, main.c and pictures of front and back copper layer for the PCB as well as schematics.

We would greatly appreciate your thoughts.

Thanks in advance!

1 ACCEPTED SOLUTION

Accepted Solutions
Bob S
Principal

If the osc circuit is wonky then there is no software fix other than use the internal HSI RC osc - though the freq accuracy won't match an external crystal.

Might be able to hack the PCB to shorten traces and add correct/better cap values (cut trace stubs to jumpers and 2nd crystal).

View solution in original post

9 REPLIES 9
Bob S
Principal

Different user name but same schematic as this post: https://community.st.com/s/question/0D53W00001pITHOSA4/stm32f4-hardware-for-external-clock . See suggestions there for fixing the oscillator layout.

Yes! We are talking about the same design, just that I'm on the firmware side. Just trying to figure out if it could be something related to configuration of the MCU. We already have v1 of the design, and testing it out we encountered a dead end. ATM we are trying to figure out if we can maybe find a workaround the issue via software or if we need to modify hardware (in order to improve v2 and try hacking our way desoldering and resoldering stuff closer). Thanks!

The strange thing is that error still occurs when using HSI (internal clock source).

Bob S
Principal

If the osc circuit is wonky then there is no software fix other than use the internal HSI RC osc - though the freq accuracy won't match an external crystal.

Might be able to hack the PCB to shorten traces and add correct/better cap values (cut trace stubs to jumpers and 2nd crystal).

Then is it normal that we are not being able to go above HCLK -> 80 Mhz with a 16 Mhz HS Internal osc?

Bob S
Principal

What version of CubeMX are you using? I can get up to 180MHz from 16MHz HSI in ver 6.3.

Pipe HSE and PLL clocks out of PA8/MCO, and check clock performance.

Make sure HSE_VALUE matches your use case.

Check PLL math, the relationships aren't that complicated, use a calculator, perhaps output the clocks/speeds the HW thinks its running from. ie print of AHB/APB clocks, SystemClock, etc.

If USART don't work at right rates suggests internal inconsistencies in what system thinks its working with.

Just random Hard Faults, perhaps double check FLASH wait states, and VCAP capacitors/voltage.

Have a workable Hard Fault Handler outputting some actionable data, examples have been posted dozens of times.

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

Hello, I'm using version 6.5 of CubeMX now, but I was using v6.3 before I updated yesterday to see if it changed anything. On my Nucleo-64 I get up to 180 MHz without troubles. But once I flash the firmware on the custom PCB it does not go above 80 Hz, I'm starting to think it could be a counterfeit chip :\

I will check HSE clock performance and match its value. I also though of that, thats why I started working with HSI to try and narrow down the problem but the thing is with HSI it does not go above 80 MHz when it should go up to 180 MHz (as it does with a nucleo-64 with same chip and same code).

I will check flash wait states. VCAP is 1.138V I'm not sure what its value should be.

I did a quick search on HardFault debugging in st community and didn't find a tutorial per se, just advice for each casuistic.

Do you think this is a good resource to start off?:

https://interrupt.memfault.com/blog/cortex-m-fault-debug

And then follow your advice here:

https://community.st.com/s/question/0D53W000009gAQ6SAM/how-to-handle-hardfault

Because ATM I'm just like a monkey typing when it comes to debugging HardFaults. First time I get to debug one. I know how to read registers but have no idea where to look (lacking theory).

Thanks!

Bob S
Principal

PM0214 on ST's site (CortexM4 Programming Manual) describes the fault register bits. They should eventually lead you to the address of the instruction that executing when the fault happened, and in some cases the (data) memory address that was being accessed. If you are using CubeIDE, it has a "fault analyzer" window in the debugger that will decode the fault registers for you.