STM32F7 Hard and Memory Faults

[DietWall]

Hello,

I am working on a hobby project with https://www.st.com/en/microcontrollers-microprocessors/stm32f767zi.html.

I have my own build and development environment based on arm-gcc-none-eabi and CMake and all HAL Drivers and Libraries from STM.

The board starts properly up and I have started to work with GPIOs. Most of my initialization routines are copied from Example Projects. I think, that they are very similar, but I´m not 100% sure yet.

While initializing the LEDs, the MCU produces a HardFault (and sometimes a Memory Fault) from within the HAL Code. Currently HardFault occurs very consistently. First I want to take care about the HardFault and if MemFault is still occuring, I want to take care of this as well.

The error is thrown exactly at this line:

https://github.com/STMicroelectronics/stm32f7xx-hal-driver/blob/e1446fa12ffda80ea1016faf349e45b2047fff12/Src/stm32f7xx_hal_gpio.c#L191

Configurable Fault Status Register has:

precise error bit set

bfarvalid bit set

The value in BFAR Register is:  0x46bd3718 which is the address of:

GPIOx->OSPEEDR register

This exact register is read in the line, that is causing the HardFault.

I assume, my initialization routines are missing something, or the initialization order is wrong, or some type of Clock Configuration does not fit yet (SPEED Register).

What are the requirements for read access to this Register?

Or can anyone give me a hint how to find the error?

User manual describes it as Read/Write accessible.

Thanks in advance and Best Regards.

Dietrich

[TDK]

Can you show your code?

Perhaps generate a CubeMX project and see if it works there. If not, probably a hardware issue.

Perhaps wait states are wrong.

Is this a custom board? If so, show the schematic.

> What are the requirements for read access to this Register?

There are none. The issue is elsewhere.

[DietWall]

Hi @TDK 
Thank you for your reply.

The board is not custom, it´s the eval board STM32F767 from the link above.

I have bought it in 2022.

By answering your question about the code, I found at least the reason for my HardFault:

int main(void)
{   
    HAL_Init();
    MPU_Config();
    CPU_CACHE_Enable();
    SystemClock_Config();
    GPIO_Init();

    BSP_LED_Init(LED1);

    while (1)
    {
        BSP_LED_Toggle(LED1);
        HAL_Delay(1000);
    }
}

The GPIOs are enabled in GPIO_Init() and in BSP_LED_Init(LED1) by calling

HAL_GPIO_Init() 

At the second activation with very likely same arguments, Hardfault was thrown.

Without the second initialization, the board seems to be stuck in HAL_Delay(), I´ll check the initialization with an example/generated project.

Sometimes I just need a reminder to work more carefully. :)

The LED does not blink yet, but I can move on.

Is it ok to leave this thread open for few days until I figured the rest out?

Best Regards

Dietrich

[Pavel A.]

This code looks OK by itself. Maybe, abstain from using the caches until you're more confident.

The problem can be corruption of memory or stack. Or the number of flash wait states too small (see RM0410 , 3.7.1 FLASH_ACR)

[DietWall]

Thanks.

I don´t see a reason why stack would be corrupted in this case.

But flash wait states is something I have to solve anyway at some point.

I have just started Development with STMS and yet not really used to this Devices. The information about Flash wait states is very valuable.

[mƎALLEm]

Hello,

Information missing;

Show the content of your clock configuration:

SystemClock_Config();

What board are you using? custom or ST board? if ST board which one? if custom board show the schematics.

I suspect an overclocking of the system or/and bad Flash wait states.

[mƎALLEm]

Hello again:

You said:

---

@DietWall wrote:

Hi @TDK 
The board is not custom, it´s the eval board STM32F767 from the link above.

---

Do you mean this one?

[DietWall]

Hi,

This is SystemClock_Config:

void SystemClock_Config(void)
{
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;
  
  /* Enable HSE Oscillator and activate PLL with HSE as source */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.HSIState = RCC_HSI_OFF;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 8;
  RCC_OscInitStruct.PLL.PLLN = 432;  
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 9;
  RCC_OscInitStruct.PLL.PLLR = 7;
  if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    while(1) {};
  }
  
  /* Activate the OverDrive to reach the 216 Mhz Frequency */
  if(HAL_PWREx_EnableOverDrive() != HAL_OK)
  {
    while(1) {};
  }
  
  
  /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2 
     clocks dividers */
  RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;  
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;  
  if(HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_7) != HAL_OK)
  {
    while(1) {};
  }
}

[DietWall]

yes, this looks very similar. I just looked it up:

Board Model is: Nucleo-F767ZI.

MCU is STM32F767ZIT6U

[mƎALLEm]

---

@DietWall wrote:

yes, this looks very similar. I just looked it up:

Board Model is: Nucleo-F767ZI.

MCU is STM32F767ZIT6U

---

Yes it's the Nucleo-F767ZI. It's a Nucleo board not an Eval board.

Ok I don't see an issue in your system clock config. Doing the exercise in CubeMx:

It looks good.

Could you please zip you project and attach it here in the discussion so I could test it?