如何使用简单的指令或指令获取硬故障异常

Question

Currently we are hunting a phantom, which is in the form that when we compile in some code (without calling it) one specific call to memset generates an hard fault exception.

The address and length given to memset are valid. Stepping through it in single instruction mode showed that it always fails at an OR instruction. But instead of calculating the value, the processor decides to call 0xfffffff9, and then jumps into the hardfault handler, with the reason of an unknown instruction.

The disassembly of memset where it happens:

    0x80192f0  <+0x0020>        03 2c        cmp    r4, #3
    0x80192f2  <+0x0022>        2e d9        bls.n    0x8019352 <memset+130>
    0x80192f4  <+0x0024>        cd b2        uxtb    r5, r1
    # The following line crashes
    0x80192f6  <+0x0026>        45 ea 05 25  orr.w    r5, r5, r5, lsl #8
    0x80192fa  <+0x002a>        0f 2c        cmp    r4, #15
    0x80192fc  <+0x002c>        45 ea 05 45  orr.w    r5, r5, r5, lsl #16

Disassembly of 0xfffffff9:

    0xfffffff7                   00 00  movs    r0, r0
    0xfffffff9                   00 00  movs    r0, r0
    0xfffffffb                   00 00  movs    r0, r0

Where can we look to find the source of this exception?

We run the software on a STM32F429II, which is a Cortex-M4.

Answer 1

Bear in mind that for Cortex-M, the link register value indicates how to return from an exception, not the address to return to. The relevant address will be on the stack (assuming that stacking didn't fail as well).

• 0xFFFFFFF1 Return to Handler mode.
  Exception return gets state from the main stack. Execution uses MSP after return.

• 0xFFFFFFF9 Return to Thread mode.

  Exception Return get state from the main stack. Execution uses MSP after return.

• 0xFFFFFFFD Return to Thread mode.

  Exception return gets state from the process stack. Execution uses PSP after return.

Cortex-M can also never execute code from the 'local peripheral' memory space.

Answer 2

@Rudi! I hope you are already solved this. I've just encountered same issue and would like to share my experience.

The fact MCU goes HardFault from orr.w instruction does not mean that your problem is in instruction itself. I used HFSR register (mentioned by @starblue) to find a moment when it changes. If you use Eclipse - just add memory watchpoint or

(uint32_t)*((uint32_t *) 0xE000ED2C)

to expressions and find the line in which the value becoming not equal to zero.

In my case it was line with null pointer value assignment. And it was 15 assembly lines before the jump to Hardfault handler. In your case it could be even in other thread.