Stm32F405 CubeMX code lead to Hardfault

[nico]

Posted on March 04, 2014 at 19:42

Hi

I'm exploring the STM32F405 and for this, i wanted to create the initial project with the Cube MX tool. 

I've settet all the things up to my configuration. In minimal i just set the hole clock thing up.

I've burned this down to the chip just to make sure if the thing going to my while(1).

But the generated code leads to the Hardfault error handler.

I discovered that the fault is happening somewhere around when it calculates the latency for flash read write. 

This is in the beginning of the method: HAL_RCC_ClockConfig  located in stm32f4xx_hal_rcc.c

It jumps directly after command '' if(RCC_ClkInitStruct->SYSCLKSource == RCC_SYSCLKSOURCE_HSE) ''  (Line 782) to Address 0

I don't think that i have to change some lines in the library.. 

Probably the clock is set the wrong way.

here are the values out of the generated code:

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_LSE;

  RCC_OscInitStruct.LSEState = RCC_LSE_BYPASS;

  RCC_OscInitStruct.HSIState = RCC_HSI_ON;

  RCC_OscInitStruct.HSICalibrationValue = 6;

  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;

  RCC_OscInitStruct.PLL.PLLM = 10;

  RCC_OscInitStruct.PLL.PLLN = 210;

  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

  RCC_OscInitStruct.PLL.PLLQ = 7;

  HAL_RCC_OscConfig(&RCC_OscInitStruct);

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;

  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0);

#cubemx #stm32f4

[fauvarque.daniel]

Posted on March 04, 2014 at 19:51

Your problem is similar to this one:

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM32Java%2fBug%20in%20STM32Cube%20for%20STM32F417&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https%3A%2F%2Fmy.st.co...

A solution has been posted (redefine the

FLASH_LATENCY_0

constant to the correct value). This bug has been already fixed in our development tree currently under validation Regards Daniel

[Tesla DeLorean]

Posted on March 04, 2014 at 19:55

Realistically if you're running the processor at 168 MHz, the flash latency is going to need to be 5

The Hard Fault handler should be able to point you at exactly what assembler instruction caused the fault, you should then inspect that code and the internal registers to determine the cause.

[nico]

Posted on March 05, 2014 at 21:08

Hi,

Hanks for the fast Answers,

As i know i have 2 different errors. One is that related to the wrong latency which jumped to address zero. Then the other which leads to the harderror.

But also the harderror fault does not have to be happen with just the initial generated code base. I have no activated interrupts (just systick).

Up to now i didnt had the time to explore more.

But thanks for pointing out the latency error.