Measure LFXO 32.768 kHz on nRF5340

[ChriglSEI]

Hi there

I want to measure the accuracy of the 32.768 kHz oscillator connected to a nRF5340

I have tried a lot of other devzone tickets, but most of them are too old or don't work for nRF5340.

I  also tried to use a pwm-led output with 4096Hz to measure the accuracy, but it was more than 5000 ppm inucurate (got 4117.4Hz)

Do you have a recommondation to test the LFXO accuracy with a nRF5340?

Could you provide example code?

Thank you, 

Chris

[Einar Thorsrud]

Hi,

You can use the PPI trace sample. It does not include config files for the nrF5340 DK, but you can use these files:

2117.nrf5340dk_nrf5340_cpuapp.overlay

7888.nrf5340dk_nrf5340_cpuapp.conf

Drop them into nrf/samples/debug/ppi_trace/boards. Then you can build for nrf5340dk_nrf5340_cpuapp. With this pin 4 will toggle with half the frequency of the LF crystall, so if you measure that with a frequency counter or simlar and multipy it by two, you have the frequency of your LF clock source (regardless if this is an external crystal or the internal LFRC).

If you are using a custom board, rename the conf-files above to your custom board name, and that should work as well (and adjust the pin configuration if needed).

[ChriglSEI]

Hi Einar

Thank you for your prompt replay.

I allready tried the ppi sample earlier but I failed building it for nRF5340DK.

Now with your files I was able to build and run it 

I have found the 16.384kHz signal on Pin 5 of a nRF5340DK;-) 

On pin 4 was the 50ms alarm signal.

The problem now is, that the signal has a high jitter of around 200ns:

When I want to measure the accuracy of the LFXO I need to measure in sub-ns range. 

10ppm would be a difference 0.3ns.

I have tried disabling ppi_trace_pin_setup of COMPARE_EVT and STARTED_EVT but jitter stayed.

Do you have an idea what could lower jitter?

Thank you

[Einar Thorsrud]

Hi,

You can measure the average frequency of the crystal this way, but you will not be able to measure the jitter as what you are measuring here is the output of the GPIO toggeling, where you have digital logic, clock-crossing between the 32.768 kHz and the 16 MHz peripheral clock (derived from the high frequency clock source, whether that is HFINT or HFXO), etc. Maybe you will get better results by starting the HFXO (see how it is done by clock_init() in nrf/samples/peripheral/radio_test/src/main.c.

[ChriglSEI]

Hi,

I have also found the Clock_skew sample

I have tuned the HFXO-crystal earlier with an frequency spectrum analyzer and hence, I know the accuracy of the HFXO.

With CONFIG_APP_ENABLE_HFXO=y set in the example, I get a err of the LFXO in ppb which matches my measurements with k_uptime_get() over several hours.

I will further test the sample, but it looks promissing

The sample prints:

*** Booting nRF Connect SDK 3758bcbfa5cd ***
Power-up clocks: LFCLK[ON]: Running LFXO ; HFCLK[OFF]: Off HFINT
Enable HFXO got 0
Start timer@f000: 0
Timer-running clocks: LFCLK[ON]: Running LFXO ; HFCLK[ON]: Running HFXO
Checking timer@f000 at 16000000 Hz against ticks at 32768 Hz
Timer wraps every 268 s
Started sync: 1

Ty       Latest                      Base                      Span                        Err
HF      00:08:21.281414     00:00:00.017208   00:08:21.264206
LF       00:08:21.972534     00:00:00.714813   00:08:21.257720     -00:00:00.006486
RHF    00:08:21.281429                                                                    00:00:00.000014
Skew  1.000013 ;   err -12993 ppb

My HFXO runs at +2ppm and with time consuming k_uptime_get() measurement I got -15ppm for the LFXO

Do you also think, that using Clock_skew sample gives correct values?

[Einar Thorsrud]

Hi,

The sample should work well. But note that this compares HF and LF clock source, which is not the same as measuring with a known good (and probably regularily calibrated) instrument. If both the HF and LF clock are off in the same direction and same relative order of magnitude, you could get very good results here even thought the clocks may not be that accurate. Depending on what you are going to use your measurements for that may or may not be a problem.