This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_softdevice_enable HardFault

The Problem:  HardFault within sd_softdevice_enable. With HardFault breakpoint enabled, the debugger halts at address 0x8C8. With this breakpoint disabled, breakpoints after sd_softdevice_enable are not reached.

Hardware:  PCA10040 eval board (nRF52832)

Tools:  Segger Embedded Studio

What works:  ble_app_blinky

What doesn't work:  Project attempting to recreate ble_app_blinky. I copied main.c and flash_placement.xml from ble_app_blinky. To get it to compile, I did the following:

  • Added C files to the project for various libraries
  • Added directories to the header search path
  • Added the SoftDevice to the "Additional Load File[0]" in the Loader options

Ideas:

  • The instruction before the one where it halted (0x8C6) is "bx lr", and lr has an invalid address in it (0xfffffff9).
  • Single-stepping through the SVC call (in my project or ble_app_blinky) doesn't seem to work right. Is that a limitation of the SVC instruction, or are breakpoints always disabled in supervisor mode?
  • Hi,

    0x8C8 is the address of the Hard fault handler inside the MBR. This handler is responsible for forwarding the IRQ to the Softdevice which will then forward it to the app, as long as the hard fault breakpoint is disabled in SES. 

    The instruction before the one where it halted (0x8C6) is "bx lr", and lr has an invalid address in it (0xfffffff9).

    This is actually a legal LR value. Please refer to this link for more details (table 2.17): http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/Babefdjc.html#BABDBEII 

    Single-stepping through the SVC call (in my project or ble_app_blinky) doesn't seem to work right. Is that a limitation of the SVC instruction, or are breakpoints always disabled in supervisor mode?

    The Softdevice will raise an assert if you start single stepping through the code after enabling the Softdevice. The reason for this is that timers used for time-keeping internally are not halted when you hit a breakpoint, only the CPU is. So the protocol stack will detect that it's not meeting its real-time requirements and trigger an assert (error info will be forwarded to the app through the app error handler). 

    I suspect this has to do with your linker configurations. I would suggest that you compare the *.map file from your build against the one from ble_app_blinky and check if you use the same RAM start address (memory layout with softdevice).   

  • Hi Vidar,

    It works now. Thank you for the useful information. Comparing the .map files, I determined that the following need to be added to the list of c_preprocessor_definitions for the project:

    NRF_SD_BLE_API_VERSION=6;S132;SOFTDEVICE_PRESENT;

    Chris

Related