Verifying 32MHz Operation

[Andrew]

We have a product that uses a module containing NR52832 and also both 32kHz and 32MHz crystals.  This has been operating correctly and is in full scale production.

On our latest batch of boards we have found that there is a noticable failure rate of these modules whereby 5% of units seemingly run the firmware correctly but there is no BLE transmissions at the point we would expect it.

We have used power profiler and can see the distinctive waveform of the BLE transmission, albeit 5-10% larger.

Using a pickup coil we were able to measure the 32MHz oscillations on a working unit but picked up no such signal on the units that operate but fail to transmit a BLE signal.

I am keen for us to update the firmware to self test for whatever this failure mode is and generate a fault message on our production tester.

I understand the HFCLK gets switched on and off automatically to save power, so I'm not sure which register to use, but wondered if there were a way I could interrogate certain flags to see if the board were working, or use the 2 crystals to verify the presence of one another, and give an approximation of the relationship between the two frequencies.

[Simonr]

Hi

So you're not seeing any activity on the external 32MHz crystal what so ever in a small percentage of your boards, is that right? A common mistake that we see when the 32MHz crystal is malfunctioning or not working at all is that the crystal itself has been mounted incorrectly on the board (offset by 90 degrees) as it is possible to solder on both ways. Please check if this might be the case.

I assume you're using our SDK and SoftDevice in your application, what version of these are you using? The SoftDevice will start and stop the HFXO whenever it needs to (for radio operations that is), but you can also start the HFXO by yourself with a function like this for example:

static void clock_init(void)
{
    // Start 64 MHz crystal oscillator.
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART    = 1;

    // Wait for the external oscillator to start up.
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
        // Do nothing.
    }
}

As for cross-checking the external crystals against each other, that has been explained in this thread, so please check it out if that interests you.

Best regards,

Simon

[Andrew]

Thankyou Simon.  Yes that is correct, a small percentage of boards from our latest batch show no 32MHz crystal activity.

I have managed to identify the errant boards in firmware by using the code below in SDK15.   I trust this relates to the same registers as you have described.

Unfortunately the placement of the crystal and the capacitors is beyond our control as we are placing a pre populated module.  The module manufacturer is currently investigating how these might have failed to help with future production, but I shall be using this firmware routine to test existing boards that have been built up.

 

sd_clock_hfclk_request();

..pause..

if (nrf_drv_clock_hfclk_is_running())
{
    ... board is good ...
}
else
{
    ... board has failed ...
}

sd_clock_hfclk_release();

[Simonr]

I see, let me know if there is anything else I can do for you! If you are able to get to the bottom of this I'm sure it would be helpful for the community as a whole to know what the issue was and how it was resolved!

Best of luck and regards,

Simon