internal rc slow clock problems with sdk12 and sdk14

[robotjosh]

For ble central devices on nrf52, there are problems with the internal rc slow clock. When I load the project ble_app_uart_c onto the PCA10040, everything works as expected. The only thing changed is to set the LF source to 0 for internal rc, CTIV = 12 and TEMP_CTIV = 2 as the recommended values. The dev kit works as expected on sdk12 and sdk14. On my custom device which is the same except without the external low frequency crystal, sdk14 crashes on startup with an invalid instruction hard fault that happens within the softdevice. With sdk12, it runs and is able to scan and advertise, but connecting fails every time, which is this issue I reported here devzone.nordicsemi.com/.../

We are going to add the external slow clock to our next revision but this seems like a pretty serious bug that we would like to see fixed soon.

[Jørgen Holmefjord]

Are you sure that you set the clock source in the correct place? In SDK 14, you can change the clock source using the sdk_config.h macros:

//==========================================================

// <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 12
#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_XTAL_ACCURACY  - External crystal clock accuracy used in the LL to compute timing windows.
 
// <0=> NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_XTAL_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_XTAL_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_XTAL_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM 

#ifndef NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 7
#endif

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

[robotjosh]

Have you tested this on a device which does not have the low frequency crystal placed?

[Jørgen Holmefjord]

Yes, I have tested this on PCA10040 board with SB1/SB2 cut and SB3/SB4 soldered.

[robotjosh]

I have also cut these traces on my dev kit and can see the code runs as expected. I am stumped why my design hard faults with invalid instruction when it appears to be the exact same configuration running the exact same code. Other code that only scans and advertises runs on my design as expected. Only if the firmware supports connections the code hard faults on startup.

[robotjosh]

It was the uart rx pin not pulled high, thought it was always receiving.