Problem entering custom hardfault handler

[matt_C]

I am using SDK 14.2 in eclipse/GCC.

I have enabled HARDFAULT_HANDLER_ENABLED in sdk_config.h, hardfault_handler_gcc.c is in the project, and I also have hardfault_implementaion.c included. I have also added the DEBUG symbol to my project. 

The project compiles and runs, but doesn't enter my own "Hardfault_c_handler()".

I haven't changed hardfault_handler_gcc.c. My Hardfault_c_handler (called from "HardFault_Handler()" in hardfault_handler_gcc.c) just calls "HardFault_process()".

In "HardFault_process()" I simply turn on an LED and sit in a a "while(1) {}". 

However, when I cause a hardfault with "hardfault_genhf_invalid_fp();" in main, the processor restarts and doesn't sit in my custom hardfault handler. What am I missing to make the program use my hardfault handler. 

[MartinBL]

Are you able to figure out whether the files and functions are actually being compiled and included in your application? I.e. that it is not just all compiled away due to some missing define symbol like DEBUG? Do you see relevant file and function names in the .map file? Or can you set a breakpoint inside your own HardFault_process() function?

[matt_C]

The files and functions appear to be compiled and included in the application. I can't currently set breakpoints since we are using Atollic, we started using it before their purchase by ST, and we have issues with setting breakpoints since we are using a bootloader and soft device. I finally got my code to work, I was getting a fault inside "HardFault_c_handler" when I tried to stop the soft device, but the attached code should have worked as well since I wasn't trying to stop the soft device in it.

Does the soft device need to be stopped in the hard fault handler, or is it automatically stopped when the hard fault handler is entered?

[MartinBL]

As you can see in this figure the hard fault handler has higher priority than the Softdevice. So yes, if you stumble upon a hard fault then your Softdevice will be stopped. Unfortunately, that is simply how the hardware works and there is no way to keep the Softdevice alive while dealing with the hard fault.