HardFaults at random places in code on an STM32F722

[ABous.3]

Hello,

I am facing random HardFaults on a STM32F722. They happen at various places in code, sometimes even during stack's initialization.

Stack's analysis do not show any risk of overflow : most of the time, the problem happens while executing main() loop, and stack's width is never more than 2 levels.

Looking at Fault status Registers shows:

_ bit FORCED of HFSR is set to 1

_ CFSR = 0x1000000 = bit UNALIGNED of UFSR set to 1: unaligned memory access. 

bit UNALIGNED_TRAP is set to 0

Looking around PC and LR, I only see "unoffensive" instructions (typically, ldr, str, or ldr.b and str.b), and the code registered in stack is part of my main's infinite loop, which most of the time executes without any trouble. So I do not understand how it could sometimes trigger a memory alignment fault...!

I read https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/43707/unable-to-determine-offending-instruction-usage-fault-illegal-unaligned-load-or-store-cortex-m7-keil-mdk-pro, and the associated links, but did not find what could trigger this fault on my board.

One track that seemed interesting was https://www.keil.com/support/docs/3777.htm, but I am not using an external SDRAM...

I also saw the following topic, which seems to be exactly the same issue than mine: https://community.st.com/s/question/0D50X00009XkiJw/stm32f7-hardfault-unaligned-memory-access?t=1612969638024. But my HCLK is at 16 MHz, so, according to STLM32F7xx's reference manual, the only latency that I can use for flash accesses is 0 WS, which is already the case...

I am using HAL for startup code and basic (while(1)) fault handlers (so I do not understand why my UsageFault escalated to HardFault, as UsageFault handler is pressent in my code).

I am using gcc and gdb with Atollic TrueStudio as IDE.

Can you please help me to solve this issue?

Regards

[Uwe Bonnes]

Too high frequency, to few wait states and a flacky supply are first points to look at.

[ABous.3]

Hi Uwe,

Thank you for your response.

My CPU is running at 16 MHz. This is the lowest frequency I can set on my hardware, and at this speed, STM32F7xx's reference manual gives choice between 0 WS and 0 WS for flash latency.

Concerning power supply, my hardware's colleague did not see any problem on the past

[Piranha]

What is the initialization value of the stack pointer? Is it valid and 8-byte aligned?

Are the compiler and runtime library FPU settings appropriate?

[ABous.3]

Hi Piranha,

Thank you for your response.

My stack pointer is initialized at 0x20040000, so perfectly aligned.

As I am not using floating points in my code, I tried to disable FPU in my compiler's settings (it was enabled previously). For the moment the fault has not appeared, but as it is triggered very randomly, maybe this is just a matter of luck...

[Piranha]

Just in case...

Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries.

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

Therefore disabling FPU with -mfpu option (or adding +nofp to -march or -mcpu) also requires setting -mfloat-abi=soft.

[Uwe Bonnes]

Strip down the program to the bare minimum showing the problem. Port to a known working F722 board and test there.

[Tesla DeLorean]

+1 known hardware

If problem not software, look at hardware issues.

Check voltage and capacitors placed on VCAP pin(s)

The F722 uses a newer ARM core than the F746

Use a Hard Fault handler that dumps the register, not sure what you've got, not showing a full register set and stack top here.

Could double fault if stack at wrong address. Check for corruption.

Random faults, need to be looking at interrupts. SysTick, others..

[waclawek.jan]

+1 for hardware and for trying it on a "known good" hardware as Disco or Nucleo.

JW

[ABous.3]

Hi all,

Thank you for your advices.

Here is a print screen of micro's state the last time Hard Fault happened:

I will also check hardware with my colleague tomorrow, and keep you in touch.

Best regards

[Tesla DeLorean]

You want to look at the code disassembly to put the register content in context.

Are the values here volatile, are they flagged in a TIM or SYSTICK interrupt.

Does behaviour change if optimization level dropped?

[ABous.3]

Hi everyone,

Thank you for your advices.

On friday my colleague saw that some capacitors were missing on my board, and corrected this. My board has been running for the weekend, and no hardfault happened. I am leaving it running a longer time to ensure this was not luck. I also flashed another board with my software and will let it run.

I will keep you informed.

Have a nice week!

Best regards

[ABous.3]

Hi all,

Just to keep you in touch: I have run my software on two boards for a week, and faced no hardFault. So it seems like the problem was a hardware one.

Thank you for your advices

Best regards