confusing hardfault in STM32F407

[Fristedt.Jan]

Posted on June 14, 2015 at 16:59

I get a hardfault in an STM32F407 I can't figure out.

My speculation is that the processor tries to execute code beyond the flash end.

The debug window says the following:

Thread[1](Suspended: Signal 'SIGINT' received. Description: Interrupt.)

5 irqGetStackFrame() irq.c:924 0x08028338

4 <signal handler called>() 0xfffffff9

3 <symbol is not available> 0x08563b54

2 movAvgFInit() util.c:346 0x08020e06

1 movAvgFInit() util.c:346 0x08020e06

The stack frame is:

StackR3     0x10005cb4    

StackR0     0x10005bcc    

StackR1     0x00000005    

StackPC     0x08563b54    

StackR12    0x00000000    

StackR2     0x10005c0c    

StackLR        0x08020e07    

StackPSR    0x21000200    

stackframe  0x10006640

*stackframe 0x10005bcc    

The fault registers are:

MMSR  00

BFSR  01

UFSR  0000

HFSR  40000000

DFSR  00000009

MMAR  E000ED58

BFAR  E000ED58

AFSR  00000000

In BFSR IBUSERR is set, as far as I can unerstand this probably flags the execution at 0x08563b54.

In HFSR FORCED is set, looks like it's some problem with some exception handler.

In DFSR HALTED and VCATCH are set, halt request in NVIC and vector catched event.

The registers are:

Core    

    r0    0x10006640    

    r1    0x08563b54    

    r2    0x21000200    

    r3    0x10004788    

    r4    0x00000000    

    r5    0x00000000    

    r6    0x10005e2c    

    r7    0x10005c0c    

    r8    0x10005c64    

    r9    0x10005dec    

    r10    0x10005bcc    

    r11    0x10005dac    

    r12    0x00000000    

    sp    0x10006640    

    lr    0xfffffff9    

    pc    0x08028338    

    xpsr    0x61000003    

I have checked the interrupt vectors and they look ok.

[Tesla DeLorean]

Posted on June 14, 2015 at 17:31

Problem with these things is that you need to dig interactively with the debugger/disassembler, and the stack content.

The LR of 0xFFFFFFF9 is a magic number controlling the IRQ/Fault return

The PC is not good, and even, looks to have resulted from a BX R1

You'd want to look at the code prior to 0x08020e07, ie  movAvgFInit()

Understand how it's loading the register, and if that's a result of a bad computation or a value held on the stack being corrupted.

If there's stuff in the code you can sanity check, then do that, and add output to understand flow at/near the failure.

[Fristedt.Jan]

Posted on June 14, 2015 at 17:49

Thank you for your advice. I will try to dig deeper...

[Fristedt.Jan]

Posted on June 15, 2015 at 12:19

Now I have digged into the problem and can draw a few conclusions, I think...

The problem is not related to movAvgFInit() util.c:346 0x08020e06, I have single stepped the assembly code and I'm almost certain it's OK. The problem occurs at other places as well.

I added some code to toggle an I/O pin. The problem disappeared. I removed the code and expected the problem to return. It didn't.

I think it could be some kind of weird timing problem causing an exception but can't prove/understand it and that makes me unhappy. Even more unhappy about the problem disappearing without explanation...

I have read Joseph Yiu's book on the Cortex-M3 about exception handling but it hasn't helped so far. Any other recommendations?

[Tesla DeLorean]

Posted on June 15, 2015 at 12:30

Using a GNU/GCC based tool chain?

Would double check the flash wait state and prefetch settings.

You'd want to look at a disassembly of the code around the faulting location.

[Fristedt.Jan]

Posted on June 15, 2015 at 13:50

Yes, I'm using GCC 4.8 2014q3.

I will check the flash settings.

I have single stepped the assembled code at two of the locations where it failed.

Thanks for helping!

[Tesla DeLorean]

Posted on June 15, 2015 at 14:18

I have single stepped the assembled code at two of the locations where it failed.

Yes, but the debugger is going to distort the timing, and cache/prefetch behaviour. I'd do static analysis but have no visibility.

[Fristedt.Jan]

Posted on June 15, 2015 at 15:25

My FLASH_ACR wasn't set up correctly. Or the debugger give me false information. I also found an error in RM0090, the location of the VOS bit.I will download new documentation and double check the settings.

What do you mean by ''I'd do static analysis but have no visibility''? I'm aware that you couldn't trust the debugger but I don't understand what you mean.

[Fristedt.Jan]

Posted on June 17, 2015 at 11:27

Unfortunately I was completely wrong about the contents of FLASH_ACR, it was correct.

I looked at the wrong address, the RCC_CR. That explains the very strange value.

The VOS error in RM0090 is not corrected in the latest revision, rev 9. Is there some place I can report it?