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

[DietWall · Accepted solution]

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 :)