This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52 hard fault when running sd_softdevice_enable

Received my nRF52 preview board yesterday and have been battling to get my S130 based nRF51 code running on it with the S132 soft device (the code is here: github.com/.../HomeKit including the current state of the NRF52 build under gcc/eclipse).

The code starts up and gets to the call to sd_softdevice_enable call in softdevice_handler.c. When it executes this call it always hits the HardFault_Handler seemingly regardless of the arguments I've tried it with. The last instruction it executes before the exception is "vmsr fpscr, r0" which I believe just moves the value of r0 into the floating point unit.

Any thoughts on what might be causing this greatly appreciated.

Thanks

  • Is the FPU enabled? It's a while since I read the FPU unit documentation but I remember most instructions cause a fault if the FPU isn't. There's code to enable it in system_nrf52.c

    I am however a little surprised the FPU is used in the softdevice since it's not required to be enabled and, apart from just generically setting things up to a known state, I can't see why the softdevice would use it.

    Do you have an address of that instruction, any other addresses in the stack would be handy too, I was going to take a look at the assembler see what's going on.

    I wish I had more time to play with my 52 devkit .. sigh.

  • You're correct; the FPU does need to be enabled. I hadn't bothered because I couldn't imagine the softdevice would be using it and my code doesn't either. I didn't realize it was disabled by default to save power. I had to force-enable it however. I tried using the -mfloat-abi=softfp option which appears to enable the system_nrf52.c code, but then my code crashed somewhere in _start. Just forcing the FPU on by hand worked though (not a great long term solution).

  • Hmm - something a bit smelly here - I agree the softdevice shouldn't need FP support .. unless it's using some of the vector functions - an answer from Nordic here would help.

    -mfloat-abi=soft 
    

    can't be right, I think you need

    -mfloat-abi=hard -mfpu=fpv4-sp-d16
    

    both of those. My guess would be your crash in _start was the compiler compiling some something for the wrong fp unit. Those flags should hopefully trigger the _start code to turn the FPU unit on too.

  • After more experimenting I found this combination to compile, enable the FPU and not crash in the startup code:

    -mfloat-abi=softfp -mfpu=fpv4-sp-d16
    

    I have some assembly code which, though it doesn't use floating point, didn't like the hard float option.

  • I asked a separate question about this here devzone.nordicsemi.com/.../

    The use of the FPU in the SD 132 is unintentional and the requirement should eventually disappear, which is good news.

Related