nRF5340 with internal load caps for 32M XTAL

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Thu, 07 Nov 2024 14:56:20 GMT

Hi,

I am glad to see you found the issue. This is a good point, I do not believe it is documented anywhere that you must configure the clock source on both the application and network core (and if you have several images like a bootloaders they also need the same clock configuration). I will forward this internally.

PS: As this is needed on all applications it makes sense to add it to your board files.

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Thu, 07 Nov 2024 00:37:48 GMT

Hi Einar,

Coincidentally, even though this configuration worked for advertising (with the synthesized LFCLK), I started experiencing disconnections when I ran another sample code for establishing a connection to the phone through the nRF Connect app.

"Reason 8" being Connection Timeout, I started investigating connection timing parameters and in my searches I stumbled upon this ticket.

nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

In here, it was mentioned that the RC oscillator configurations should be done on BOTH the App and Network cores. After doing so, I was able to start the radio using RC oscillators, and to establish a stable BLE connection without disconnections.

So in summary, I am no longer using HFXO to generate LFCLK. I enabled RC oscillators in both application MCU and network MCU (hci_ipc) in their respective prj.conf files.

#Internal 32kHz RC Oscillator

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Question: Is there any explicit documentation from Nordic which mentions that this configuration must be enabled in both app/network if an external 32kHz XTAL is not used? I could not find any.

Mikael

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Tue, 05 Nov 2024 09:34:28 GMT

Hi,

[quote user="mm784"]CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y[/quote]

PS: When using LFRC, you should set CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y (not 20 ppm). This does not actually make a difference if you are ony doing advertising, but for connections etc you need to set the correct accuracy for the LFRC, which is 500 PPM (the sleep clock accuracy is used for window widening in BLE).

[quote user="mm784"]My assumption that RC clocks are not stable enough to initialize the BLE stack is not based on empirical data, but rather on the RTT logs "HCI driver open failed" and "Bluetooth init failed".[/quote]

I see. That is not the case though. If you enable the LFRC with calibration, it will be within 500 ppm which is good enough for BLE. And regardless, an inaccurate clock would not result in this error.

[quote user="mm784"]Q. Could there be board to board variations that cause this?[/quote]

There could be board to board variations on the LFRC as well as other parameters, but that would not explain what you are seeing. BLE products without the 32.768 kHz clock is common.

The error you are seeing (HCI driver open failed (-11) does not indicate a clock issue specifically. Instead, it indicate that the BT host is not able to communicate with the BT controller (which should be running on the net core). So it seems you have not programmed the BT controller. This should normally happen automatically though. Another potential issue is that something went wrong in the controller iside (it might be clock related as you see a difference when you use synthesized LF clock).

Some questions in order fo rme to understand more:

These failure, are you seeing them on the nRF5340 DK or a custom board?
If it is a custom board, can you share your board files?
Also, can you share the project with all your changes? Please include the build folder so that I can see how you configure and build your project.
Which SDK version are you using?
Does the standard Zephyr beacon sample work on your device or do you see the same or other issues there?

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Mon, 04 Nov 2024 20:22:22 GMT

Hi Einar,

Thank you for your detailed response and your explanations. I am not trying to do anything unconventional. To test out the radio, I am running the example from Nordic Bluetooth Fundamental course, specifically "Lesson 2, Exercise 2". In this exercise the device is supposed to start advertising as a Nordic Beacon. I am using the code provided in the solution for this exercise as is - I did not change anything in the source code. But since I don't have an external 32.768kHz XTAL, I added following to prj.conf to enable RC Oscillators and I chose the lowest jitter at 20ppm.

#Enable 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

#Disable use of 32kHZ XTAL

CONFIG_SOC_ENABLE_LFXO=n

#Configure 32MHz Clock

CONFIG_SOC_HFXO_CAP_INTERNAL=y

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=24

With this build, the beacon does not work and in RTT logs I get the following:

-----------------------------------------------------------------------

Then I tried another option of generating the LFCLK, this time by using the HFXO and generating LFCLK from it. I changed my prj.conf to the following

#Synthesize LF Clock

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

#Disable use of 32kHZ XTAL

CONFIG_SOC_ENABLE_LFXO=n

#Configure 32MHz Clock

CONFIG_SOC_HFXO_CAP_INTERNAL=y

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=24

With this build, the beacon works. I see it in the nRF Connect App and RTT logs show the following:

----------------------------------------------------------------------

I do not want to jump to conclusions. My assumption that RC clocks are not stable enough to initialize the BLE stack is not based on empirical data, but rather on the RTT logs "HCI driver open failed" and "Bluetooth init failed".

Q. Could there be board to board variations that cause this?

Mikael

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Mon, 04 Nov 2024 09:00:17 GMT

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.

[quote user="mm784"]I am assuming the RC oscillators are not stable enough for BT stack to initialize. [/quote]

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?

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Fri, 01 Nov 2024 21:47:04 GMT

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

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Fri, 01 Nov 2024 10:04:58 GMT

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?

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Thu, 31 Oct 2024 15:39:50 GMT

This is the crystal I am using

ABM11W-32.0000MHZ-8-B1U-T3

32MHz, +-10ppm

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

devzone.nordicsemi.com/.../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

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Thu, 31 Oct 2024 15:35:01 GMT

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

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Thu, 31 Oct 2024 08:45:32 GMT

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.

RE: nRF5340 with internal load caps for 32M XTAL

mm784 — Wed, 30 Oct 2024 18:05:22 GMT

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

RE: nRF5340 with internal load caps for 32M XTAL

Einar Thorsrud — Thu, 03 Oct 2024 13:00:53 GMT

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.