Device crashes when I use a Crystal substitute

[Tarik]

Hello,

When I use the recommended X1 and X2 crystals from Epson (Q22FA12800025 and FC-135 32.768KHZ ±20PPM,9.0PF) the device works properly, crystals from ECS did work too in the past. However due to supply shortage we need to always find replacements for those two crystals. When we use a replacement the device stops working. (The watchdog timer gets triggered everytime after the firmware crashes at ble_stack_init() )

When this happens I try to change the source of LFCLK to internal RC or synthesized but sometimes it works sometimes it does not. I also tried to change CLOCK_LF_ACCURACY to bigger values, it does not work too. I tried with multiple crystal models so far and the only ones working seems to be the (Q22FA12800025 and FC-135 32.768KHZ ±20PPM,9.0PF) and (ECS-320-8-37B-7KM-TR and ECS-.327-9-34B-TR).

I measured the LFCLOCK Xtal frequency and it's 32.68KHz which is within 100ppm accuracy from the 32.768 KHz specified. I could not however measure the 32 MHz crystal (any idea how I can measure this accurately with an oscilloscope ? )

What are your suggestions to solve the issue ? is it indeed a crystal problem or could it be something else ? Have you tried other crystal models ? Have you tried with less known crystal brands (Chinese and Taiwanese brands ) ?


Thanks

[Martin Sivertsen]

Hello Tarik,

I'll take a look at this and get back to you tomorrow.

Best regards,

Martin S.

[Tarik]

I just made some rework on the PCB, and replaced both the crystals by Epson's Q22FA12800025 and FC-135 32.768KHZ ±20PPM,9.0PF and put the Substitute crystals on an old working PCB.

The Old working PCB is still working even with the new substitute crystal, while the new PCB is still not working even with the Epson recommended crystals. 

This means the issue does not come from the crystals. What other hardware issue can cause ble_stack_init() to crash? 

(I tested the PCB with peripheral test example firmwares, and it seems to be working properly it only crashes with bluetooth examples at ble_stack_init())

Thanks

[Martin Sivertsen]

Hi Tarik,

It could indeed be the crystals, both the frequency tolerance (as you've touched upon) and that the crystals have the same load capacitance as the ones we recommend.

Here you can see the frequency tolerance limits and load capacitance we operate with for the nRF52832: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/clock.html?cp=4_2_0_18_3#unique_582893628

Have you checked that these parameters are within spec?

Best regards,

Martin S.

[Tarik]

Hi Martin,

Thanks for the feedback. is there a way to reliably measure the high frequency 32 MHz crystal with an oscilloscope ?

Thanks

[Martin Sivertsen]

Hi,

What we do is measure the radio signal using a coaxial probe connected a signal and spectrum analyzer and look at the carrier frequency while the nRF device is in TX mode. You can see the offset of the carrier frequency and measure the frequency offset in parts per million by dividing the offset (in kHz) by the carrier frequency (in GHz), for example an offset of 15 kHz on a 2.44 GHz signal gives an offset of 15/2.44 = 6.15 PPM.

If this is not an option for you, you can measure directly on the crystal, but would have to use active probes with a very low capacitance. The trouble is that the probes might add load capacitance and change the frequency of the crystal. 5 to 10 pF is enough to alter the frequency by a significant amount (up to tens of kHz).

Best regards,

Martin S.