Another SoftDevice LFCLOCK issue, this time on nRF52840

RE: Another SoftDevice LFCLOCK issue, this time on nRF52840

Rob R — Fri, 01 Nov 2019 17:18:39 GMT

Hi Bjørn,

Thanks for that, it worked!

(SDK v16, SoftDevice 240)

Best Wishes

Rob

RE: Another SoftDevice LFCLOCK issue, this time on nRF52840

bjorn-spockeli — Fri, 01 Nov 2019 13:26:13 GMT

Hi Rob,

Which SDK and SoftDevice version are you using?

All SoftDevices for the nRF52840 support both 32kHx XTAL and the use of the internal 32kHz RC oscillator

You should only have to set the following defines in sdk_config.h for the nRF52840 to use the RC oscillator instead of the XTAL

// </h> 
//==========================================================

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <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

// </h> 
//==========================================================

Best regards

Bjørn

RE: Another SoftDevice LFCLOCK issue, this time on nRF52840

Rob R — Fri, 01 Nov 2019 12:27:01 GMT

Following up my own post,

Aggressive cleaning and rebuilding has revealed different behaviour: ble_init trips an assertion if any clock source other than XTAL is selected. The root cause of this seems to be that sd_softdevice_enable returns an error code. (That symbol corresponds to an entry point on the softdevice binary.)

So that would seem to be an end to the matter (Somewhere I read something that Softdevices on this silicon don't yet support non XTAL clocks)

For the sake of completeness...

I've noted that there are three separate macros in the config file.

NRFX_CLOCK_CONFIG_LF_SRC which is read by nrfx_clock_enable and which may be overridden by CLOCK_CONFIG_LF_SRC (Sadly I don't have the time to fully unwind the inclusion graph of the project.)

CLOCK_CONFIG_LF_SRC (might override the above, also used for some logic in regard of calibration enabling.)

NRF_SDH_CLOCK_LF_SRC which is used to populate a structure in nrf_sdh_enable_request, which it passes to sd_softdevice_enable,

I applied a breakpoint to nrfx_clock_enable, and it doesn't seem to get called, which is a little surprising, it would seem that the SoftDevice handles that internally rather than using the callbacks.

I've noticed that when the crystal is selected but missing, the Heart Rate sensor app tends to get caught waiting for the clock to start, but the mouse simulator stalls on trying to read the UART: Waiting for either a BRK or to receive 0x01.