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.
orr
instruction is not available in ARMv6-M / Cortex-M0. Also, in the hardfault handler you can look at various status registers (e.g. HFSR, CFSR) to find out more. – starblue