nRF54L15 power on crystal load capacitor selection

[JerrySJ]

Hi

I have some questions regarding the 32 MHz crystal on the nRF54L15:

1. If my firmware is configured to use external capacitors, will the very first crystal startup waveform captured after power-on already be using the external capacitors? Or is it still using the internal capacitors at that moment?

2. The reason I’m asking is that I used the same PCB design but tested it with different firmware settings (external vs. internal capacitors). The measured frequency offset did not match my expectations. My external load capacitors are 12 pF, and the internal setting is the default 15 pF. However, the result I observed is that when using only the external capacitors, the frequency offset is actually 2 ppm slower compared to using the internal capacitors in firmware (with the external capacitors still mounted).

[Einar Thorsrud]

Hi,

That is unexpected. A too high frequency indicate too low load capacitor value, and vise versa. How do you measure this? The recommended way to measure is to set up a carrier frequency (I suggest you use the radio test sample) and measure the offset using a signal/spectrum analyzer).

At startup, the HFINT is used by default, and the HFXO is only started by firmware when an accurate clock is needed. And when the HFXO is started, the configured values for load capacitors are used from the start.

Which 32MHz crystal are you using? Can you share the datasheet? Also, how does your devicetree where you configure the load capacitors look like?

For reference using internal, it should look like this which is the default as you write (here with 15 pF, adjust value as needed):

&hfxo {
	load-capacitors = "internal";
	load-capacitance-femtofarad = <15000>;
};

Disabling internal can be done like this:

&hfxo {
      load-capacitors = "external";
};

[JerrySJ]

Hi Einar,

1. Our test setup uses a frequency counter (Agilent 53131A) and an active probe (Tektronix P6243) to measure the crystal frequency. The firmware we are using is based on nRF Connect SDK v3.0.0 – direct_test_mode, with the only modification being the setting to use either the external capacitor or the internal capacitor.

2. So can I conclude that when I measure the HFXO signal at the C19 node, the load-capacitor configuration is already active at that moment.

3.  Based on what I found in a forum discussion about capacitor selection, one of the replies mentioned that “the external capacitors are also physically present in parallel with the internal capacitors.”

Because of this, I assumed that when using the internal 15 pF setting, the internal capacitor would be in parallel with my external 12 pF capacitors, giving a total of around 27 pF.
Following this logic, when testing on the same PCB (which always has 12 pF external capacitors), the internal-cap setting should give a slower frequency than the external-cap setting.

However, in our actual measurements, both configurations show almost the same behavior, with an effective load close to 13 pF. This is still within the spec, but it is different from what we expected.
You can refer to the figure below.

 nRF54L15 crystal load capacitor selection 

4. We are using the X2C032000B81H-HS/HELE crystal, and the load capacitors are shown in the schematic above.

5.I confirmed with our FW engineer that the configuration is the same as the information you provided, as shown below.

[Einar Thorsrud]

Hi,

An INTCAP value of 0x2B looks sensible and can match 15 pF. (The exact value of the  register can vary between devices, as trim values are used in the calculation).

I am not sure if we can trust the measurement here, though? It is very difficult to see that you can have the same Tx frequency with so big difference in load capacitance. If I read this correctly, you get the same with no load caps, with internal or external load caps, and with both enabled. That should not be possible (the offset is also itself too large, but as I do not trust the results, I think we can focus on that later).

[JerrySJ]

Hi Einar,

Your suspicion was correct. Since the previous measurements were performed using a handheld spectrum analyzer, the accuracy was insufficient, and the results were therefore unreliable. We have re-tested the device using a Keysight N9000B, and the new measurement results are shown in the table below.

The results confirm that using external load capacitors only is sufficient to meet the crystal specification. In contrast, when the internal load capacitors are enabled, the frequency deviation becomes significantly larger and is already approaching the ±60 ppm HFXO specification limit of the MCU. This outcome better matches our expectations.

spectrum analyzer Keysight N9000B
PCB capacitor	PCB1 with 12pf
FW	Internal cap	External cap
Tx frequency(set2.478GHz)	2477871370	2477975742
Tx error	-5.19088E-05	-9.7893E-06
Read 0x5012071C	"0000002B	"00000000

We will rearrange the crystal frequency validation test to confirm whether the results are consistent with the current TX test results. In the meantime, do you have any additional suggestions that could help us further verify this issue?

[Einar Thorsrud]

Hi,

Thank you for confirming, this makes sense. I would suggest that you remove the external load capacitors as they are not needed and use only internal capacitors.

Your crystal is specified to 8 pF, so twice that minus a bit of trace capacitance results means that 15 pF is probably sensible (so I suspect your external capacitors are a bit too small in any case). I recommend that you test the frequency error/offset with different load cap values to find the optimal value experimentally.

[JerrySJ]

Hi,

I would like to ask for clarification regarding the register value 0x0000002B.
Based on the information available, the internal load capacitor range is 4 pF to 17 pF with a step size of 0.25 pF.
Using this rule, the calculated capacitance for 0x2B comes out to approximately 14.75 pF, not 15 pF.

Could you help explain how the value 0x2B corresponds to 15 pF? I would like to understand the calculation or mapping between these two values.

[Einar Thorsrud]

Hi,

The exact value can vary from device to device as it includes trim values. You can see the calculation in zephyr/soc/nordic/nrf54l/soc.c, which also include these trim valued read from FICR. This performs the calculations as described in the datasheet, with this formula for HFXO:

INTCAP = (((CAPACITANCE-5.5)*(FICR->XOSC32MTRIM.SLOPE+791)) + 
           FICR->XOSC32MTRIM.OFFSET*4)/256

If you would like to re-do these calculations by hand you need to read the TRIM values from the specific device and do the calculations for that yourself, but I recommend that you do not change this and use the implementation you can find in the latest SDK. (Note that this value has changed, so if you are using an old SDK, the formula used is not optimal and should be updated. SDK 3.1 and later use the correct formula, that matches the current datasheet).

[JerrySJ]

Hi

After reading the calculation explanation, I understand that the declared 15 pF is adjusted by slope and offset to produce the final value written to INTCAP (which we read as 0x2B). I would like to ask again: does 0x2B, according to the formula, represent the final INTCAP value — and is there a formula to convert 0x2B into pF? Or is it just a setting that cannot be directly converted to pF, and only indicates that after applying slope and offset the MCU’s CL will be 15 pF?

[Einar Thorsrud]

JerrySJ said:

After reading the calculation explanation, I understand that the declared 15 pF is adjusted by slope and offset to produce the final value written to INTCAP (which we read as 0x2B).

Yes, you are correct. And this slope and offset are trim values from FICR, that vary from device to device.

JerrySJ said:

Or is it just a setting that cannot be directly converted to pF, and only indicates that after applying slope and offset the MCU’s CL will be 15 pF?

Yes, that is correct. So it is important to remember that this can vary from device to device. Therefore I see no point in calculating this externally to the device. If you want to do this calculations none the less out of interest, you need to read out the FICR values. I do understand the need for this, as the code that does this is well tested, but if you want to that is no problem. You can do that using for instance nrfutil like this:

nrfutil device read --address 0x00FFC620 --direct

See the XOSC32MTRIM register documentation for details on where you find the SLOPE and OFFSET field. If you drop this into the formula together with the target CAPACITANCE, you will et the INTCAP register value that represents the target capacitance.