Hard Fault hang in BLE stack

[SteveHx]

I have a nicely working application that occasionally hangs. I have managed to trap a "hard fault" under the debugger (using VS with GCC). I have the system halted with the debugger open, but can't find a way to trace further to see what precipitated the fault. Where do I go from here?

[awneil]

Have you googled general articles on Cortex-M Hard Fault debugging?

Joseph Yiu's "Definitive Guide" books have a section on Faults and their handling ...

https://www.elsevier.com/books/the-definitive-guide-to-arm-cortex-m0-and-cortex-m0-processors/yiu/978-0-12-803277-0

https://www.elsevier.com/books/the-definitive-guide-to-arm-cortex-m3-and-cortex-m4-processors/yiu/978-0-12-408082-9

[SteveHx]

That's not particularly helpful. I know what hard faults are and their various causes. I have the debugger stopped at a hard fault, but having trouble finding a way to backtrack to the root cause. What in the BLE stack is likely to cause a hard fault, or how can I backtrack to the origin of this one?

[Vidar Berg]

Hi, 

I think the easiest way to back trace a hard fault is to use the Hardfault library provided in the SDK (link). Which SDK version are you on?

That said, this won't work if the program is stuck in the softdevice's hardfault handler. Generally it should forward all fault exceptions to the application, but it can fail in some rare cases as mentioned in this thread or if you have "vector catch" enabled in GDB (probably vector catch if PC is below address 0x1000).