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 returnThe PC is not good, and even, looks to have resulted from a BX R1You'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?