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

Initialising the SoftDevice at boot vs. when required

I’m new to development with the nRF platform and have a general question on using a SoftDevice. A bit of background: in our application we only need BLE for OTA updates and UART functionality for a special development mode we put the device in. At all other times BLE is not required.

Currently the SoftDevice is only initialised once the device enters this devmode. We are having issues with app_timer accuracies which appear to be fine when devmode is active, but run 6-7% faster during normal application. We only have an external 32MHz HF crystal and no external LF crystal.

It seems that including the SoftDevice (S112) in our firmware prevents the use of functions like nrf_drv_clock_calibration_start() which would allow us to calibrate the internal RC oscillator before the SoftDevice is activated.

So the question is this: if the SoftDevice is initialised but BLE is not active, are there any consequences? (e.g., increased RAM usage which could potentially affect battery life, or any other important things to note?)

If not, are there any advantages in our approach of only initialising the SoftDevice when it is required in devmode?

  • Hi,

    I do not see any good reason for not starting the SoftDevice immediately after reset. First of all, the current consumption consequence is negligible (a single RTC instance contributing 0.1 uA). Secondly, your primary reason for not wanting the SoftDevice is that it does not allow you to access the clocks directly, like triggering LFRC calibration using nrf_drv_clock_calibration_start(). However, the SoftDevice will calibrate the LFRC for you, based on the parameters it has been configured with.

    Assuming you use the SoftDevice handler module, which is used in the Bluetooth examples in recent SDK versions, the LF clock configuration is typically done in sdk_config.h. When using LFRC the following configuration is normally most sensible:

    //==========================================================
    // <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
     
    // <0=> NRF_CLOCK_LF_SRC_RC 
    // <1=> NRF_CLOCK_LF_SRC_XTAL 
    // <2=> NRF_CLOCK_LF_SRC_SYNTH 
    
    #ifndef NRF_SDH_CLOCK_LF_SRC
    #define NRF_SDH_CLOCK_LF_SRC 0
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
    #ifndef NRF_SDH_CLOCK_LF_RC_CTIV
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
    // <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
    // <i>  if the temperature has not changed.
    
    #ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
     
    // <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
    // <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
    // <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
    // <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
    // <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
    // <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
    // <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
    // <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
    // <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
    // <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
    // <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
    // <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 
    
    #ifndef NRF_SDH_CLOCK_LF_ACCURACY
    #define NRF_SDH_CLOCK_LF_ACCURACY 1
    #endif
    

    With this configuration LFRC calibration is automatically performed when the SoftDevice is initialized, and regularly, but only if the temperature has changed (as the LFRC is temperature dependent).

    A last reason for not waiting to start the SoftDevice is that many resources are blocked or protected by the SoftDevice, and requires you to use SoftDevice APIs to access them. If you are not consistent, you need to handle both these cases (some SDK libraries and drivers do this for you though).

  • This is exactly the response I was looking for. Brilliant. Thanks Einar.

Related