title: GDB backtrace from hard fault handler on ARM cortex M0 NRF51822
body: <p>I'm on an ARM Cortex M0 (Nordic NRF51822) using the Segger JLink.  When my code hard faults (say due to a dereferencing an invalid pointer), I see only the following stack trace:</p>
  
  <pre><code>(gdb) bt
  #0  HardFault_HandlerC (hardfault_args=&lt;optimized out&gt;) at main_display.cpp:440
  #1  0x00011290 in ?? ()
  </code></pre>
  
  <p>I have a <a href="http://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/" rel="nofollow">hard fault handler</a> installed and it can give me the lr and pc:</p>
  
  <pre><code>(gdb) p/x stacked_pc
  $1 = 0x18ea6
  (gdb) p/x stacked_lr
  $2 = 0x18b35
  </code></pre>
  
  <p>And I know I can use addr-to-line to translate these to source code lines:</p>
  
  <pre><code>&gt; arm-none-eabi-addr2line -e main_display.elf 0x18ea6
  /Users/cmason/code/nrf/src/../libs/epaper/EPD_Display.cpp:33
  &gt; arm-none-eabi-addr2line -e main_display.elf 0x18b35
  /Users/cmason/code/nrf/src/../libs/epaper/EPD.cpp:414
  </code></pre>
  
  <p>Can I get the rest of the backtrace somehow?  If I stop at a normal breakpoint I can get a backtrace, so I know GDB can do the (somewhat complex) algorithm to unwind the stack on ARM.  I understand that, in the general case, the stack may be screwed up by my code to the point where it's unreadable, but I don't think that's whats happening in this case.</p>
  
  <p>I think this may be complicated by Nordic's memory protection scheme.  Their bluetooth stack installs its own interrupt vector and prevents access to certain memory regions.  Or maybe this is Segger's fault?  On other examples of Cortex M0 do most people see regular back traces from hard faults?</p>
  
  <p>Thanks!</p>
  
  <p>-c</p>