nRF5340 with internal load caps for 32M XTAL

[mm784]

Hello,

The target MCU on nRF5340 DK seems to use internal load caps for the high frequency 32MHz XTAL because the board does not have external load caps. 

The nRF5340 specification sheet mentions that the internal caps must be configured before enabling them. 

Does it mean that every sample application configures this on the nRF5340?

When I load the "blinky" example, I see the following in the Output .config

1. In what config file is this configured and what are the default values?

2. What is the default startup clock of the SoC? Since the internal caps for the crystal must be configured first, I imagine the SoC must use another clock source before the external XTAL is enabled. 

[Einar Thorsrud]

Hi,

You configure this with CONFIG_SOC_HFXO_CAP_INTERNAL=y and CONFIG_SOC_HFXO_CAP_INT_VALUE_X2 set to the value you want, as described in this thread.

The default startup clock is the internal RC oscillator.

[mm784]

Hello, 

After setting the prj.conf

CONFIG_SOC_HFXO_CAP_INTERNAL=y

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=24 

Since C1/C2=12pF

How to enable HFXO?

Thank you,

Mikael

[Einar Thorsrud]

Hi Mikael,

The HFXO uses more power than the internal HFINT, and is normally only used when a high accuracy clock is needed. This is for instance whiel the radio is active, and our radio stacks (Bluetooht and others) will automatically enable it when needed. However, if you need an accurate in other cases you can enable it using z_nrf_clock_control_get_onoff() which you can see an example of in clock_init() the radio test sample. Note that unless power consumption is not important for your product, you should release/disble the HFXO when you no longer need an accurate clock.

[mm784]

Hi Einar,

Thank you for the explanation. I was loading sample code from the Bluetooth Fundamentals course onto my board. This example is simply an advertising Nordic Beacon". The code works fine on the nRF5340 but on my board, the same code does not generate any activity on the 32MHz clock. 

For you reference I am not using an external LF XTAL, so I am using RC oscillator.

And HF XTAL relies on internal caps. So these are the configurations I added to the example code:

#Internal 32kHz RC Oscillator

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

#32MHz Clock

CONFIG_SOC_HFXO_CAP_INTERNAL=y

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=24

CONFIG_SOC_ENABLE_LFXO=n

Is anything else required to operate the HF 32MHz clock? I am getting these errors:

Thank you,

Mikael

[mm784]

This is the crystal I am using

ABM11W-32.0000MHZ-8-B1U-T3

32MHz, +-10ppm

Cload = 8pF, so internal C1/C2 = 12pF

ABM11W.pdf

Instead of RC oscillators I used this and the radio is working now. So the radio can't work with RC oscillators?

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

[Einar Thorsrud]

Hi Mikael,

There is no need to do any adjustments in firmare to get the HF clock running with BT, as taht is always handled by the stack.

The error you get here indicate that the app core is not able to communiacte with the net core. Have you programmed the bluetooth controller (hci_ipc or hci_rpmsg depending on SDK version) to the network core?

[mm784]

Hi Einar,

The only thing I changed was enable this config, so LFCLK is synthesized from HFXO

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

instead of using internal RC oscillators

 

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

I am assuming the RC oscillators are not stable enough for BT stack to initialize. 

Thank you,

Mikael

[Einar Thorsrud]

Hi,

Using synthesized LFCLK is usefull in some cases (particulrily during testing), but it is not much used in production, because it leads to a high current consumption. It is also not used during our BLE testing, so unless you have a good reason for using it(?) I suggest you do not.

mm784 said:

I am assuming the RC oscillators are not stable enough for BT stack to initialize. 

Thsi sounds strange. Can you elaborate? The BT stack works well with th ecalibrated LFRC, but that is used for keeping track of time (waking up on connection events etc). When the radio is used, the HFXO is started, and when the radio is no longer needed, it iss topped (this could be for instance between BLE connection events or advertising events or similar).

I am a bit unsure about the background for these quiestions. Are you facing another issue that you are tryign to resolve? Perhaps you can backtrack a bit and explain what you are trying t achieve/fix?