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,

mm784 said:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

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).

mm784 said:

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".

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.

mm784 said:

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

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:

1. These failure, are you seeing them on the nRF5340 DK or a custom board?
2. If it is a custom board, can you share your board files?
3. 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.
4. Which SDK version are you using?
5. Does the standard Zephyr beacon sample work on your device or do you see the same or other issues there?

[mm784]

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

[Einar Thorsrud]

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.