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

NRF52 Softdevice S132 use of FPU

This question devzone.nordicsemi.com/.../ appears to show that S132 expects the FPU to be available and activated.

Does the S132 really need/use the FPU or is this an artefact of how it's been built, with some standard startup code or similar? I was hoping to only enable the FPU on the new chip in projects which really needed floating point and leave it powered-down on those which don't, or only power it up for FP operations.

If it does need the FPU then I think it should either enable it itself if disabled or, better, return an error code on startup which indicates you need to build your code with FPU support.

  • ill look into it today RK. Are you using Keil to test this or GCC?

  • Hi RK,

    S132 has instructions that enable the floating point unit and this was unintentional. Softdevice have no requirements for FPU being enabled as it does not use any of its instructions explicitly. We were not able to identify it earlier as this will happen while scatter loading is done (i.e. sd_softdevice_enable is called). This will always be the case as long as any of the libraries linked with the Softdevice has the FPU enabled.

    Because of this, the SCB->CPACR register needs to be configured correctly when scatter loading is called, and since the softdevice does not configure this register then the application has to correctly configure it before calling sd_softdevice_enable. If the latter register is not configured by the application to use FPU, then the execution of VMSR while in sd_softdevice_enable will cause a hardfault. You can now see that SCB->CPACR is configured by SystemInit in system_nrf52.c file and it will only be done when the FPU is enabled by the application (Keil has settings for this in options, and GCC has to set this in compile flags).

    In short, all applications using the current S132 releases must have FPU enabled. Since we do not actually need an FPU in the Softdevice, in future we should make sure that it is built without the FPU enabled and applications will be able to decide whether to use the FPU or not.

    Until then, application can enable FPU , call sd_softdevice_enable() and then disable FPU, and all will work as expected.

    SCB->CPACR |= (3UL << 20) | (3UL << 22); 
    __DSB();
    __ISB();
    
    // Initialize SoftDevice.
    err_code = sd_softdevice_enable(clock_source, softdevice_assertion_handler);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }
    
    SCB->CPACR = 0; 
    __DSB();
    __ISB();
    

    As said earlier, next release of S132 after the current version(S132-SD.1.0.0.3_alpha) would have this fixed.

  • Thanks very much - that's the answer I hoped for, that it didn't need it and it was unintentional. Thanks for checking that out and giving a comprehensive answer.

Related