Hard Fault hang in BLE stack

RE: Hard Fault hang in BLE stack

Vidar Berg — Wed, 15 Aug 2018 15:02:05 GMT

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).

RE: Hard Fault hang in BLE stack

SteveHx — Wed, 15 Aug 2018 14:24:28 GMT

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?

RE: Hard Fault hang in BLE stack

awneil — Wed, 15 Aug 2018 14:15:07 GMT

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