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

[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]

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

 

Board Model is: Nucleo-F767ZI.

MCU is STM32F767ZIT6U

[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.

[DietWall]

There were 2 invocations of HAL_GPIO_Init(). One directly from main and the other hidden inside BSP_LED_Init().

The second invocation caused the Hardfault. After commenting it out, code was stuck inside HAL_Delay(). It looked like the underlying counter was not incremented, thus not leaving this while loop implemented inside Delay.

I would like to keep this thread open, until some first functionality works, then I want to press "Accept as Solution"

[mƎALLEm]

As I requested before you need to share your complete project so we can test it from our side.

[TDK]

How do you expect people to help if you don't share the code that is at fault?

CubeMX will happily generate the initialization code. Perhaps use that.

Calling HAL_GPIO_Init multiple times for the same pins does not cause a hard fault.

[DietWall]

Guys.... Relax.... Christmas is near :)

 

I´m not looking for help right now (actually since yesterday afternoon), but trying to solve the issue on my own. Once I´m done I´ll describe the issue and the solution. If not, I will describe a different one.

Is this wrong??

[MM..1]

Not wrong is start learn STMS with F7 same as sit in Maserati without driver license. Good luck

[DietWall]

Thanks, luckily I have driven F1 cars before :)

Just to stay in that metaphor.

[DietWall]

To be honest: F1 is exaggerated, lets call that Lamborghinis and Ferraris. :)

 

It works now, I generated a new project, integrated it in my build environment and went through some debugging sessions.

 

I still don´t know why HardFault appeared before. But it doesn't anymore and I don´t want to go back to this state right now. As I said, it appeared right at the second initialization of GPIOs and it did this very consistently, otherwise I could not have read the Fault Status Registers.

 

The reason for stucking in HAL_Delay was just a missing call to HAL_NVIC_EnableIRQ(). I assumed, HAL does it somewhere inside generated code.

There were also some wrong clock calculations on my side, but it magically seems to work now. Maybe I forgot to rebuild after changing the code.

 

Next step is taking care of USART3, to have some logging. But this will be a different thread, if I face something new.

Thanks all :)