HFCLK (HFXO) failure detection

[santosh athuru]

Hi,

We have below questions regarding HFXO. 

1.> Will softdevice or nordic HW be able to recognize that the 32 MHz crystal is non functional during run time (after the HFCLKSTART task is successful)?

Is there any interrupt or event generated on the fault detection?

2.>  Will the HFCLK be automatically sourced from HFINT when HFXO becomes non-functional during run time? 

3.> In softdevice what happens if HFCLKSTART event doesn't complete?

4.> From section 9.2.5 of S132 SoftDevice specification v6.1:- it is not clear on how the application can request the SoftDevice to have the external high-frequency crystal ready by the start of the timeslot.

Is application required to call some softdevice API to do the HFCLKSTART before softdevice is enabled?

Thanks

Santosh Kumar Athuru

[Simonr]

Hi

1. The SoftDevice needs the HFXO for radio operations, so it will return an error if there's something wrong with the HFXO crystal.

2. You will not be able to run the radio using the HFINT, as it is not accurate enough. If you're not using the SoftDevice, the application should be able to run on HFINT.

3. I believe the HFCLK startup will time out and return a timeout error.

4. Please check out the \<SDK_LOCATION>\components\softdevice\s132\headers\nrf_soc.h header file in your SDK. Here you can see that if p-request->hfclk_force_xtal is true the HF clock is guaranteed to be clocked from the external crystal.

Best regards,

Simon

[santosh athuru]

Hi Simon,

Simonr said:

1. The SoftDevice needs the HFXO for radio operations, so it will return an error if there's something wrong with the HFXO crystal.

on #1> can you point to the error that will happen, how can an application catch this error for handling?

Simonr said:

2. You will not be able to run the radio using the HFINT, as it is not accurate enough. If you're not using the SoftDevice, the application should be able to run on HFINT.

on #2> as per section 19.1, of nRF52832_PS_v1.4, HFINT will be used when HFCLK is requested and HFXO has not been started. Also few lines below the manual mentions that HFXO must be running to use the Radio. So this means there should be a specific error that gets triggered for the application to handle it - correct?

Simonr said:

3. I believe the HFCLK startup will time out and return a timeout error.

on #3> again how will the application know about timeout error, especially for cases when HFXO goes missing during runtime, there should be an asynchronous (or call back) way of informing about the error to the application, what is this and where is this documented?

Simonr said:

4. Please check out the \<SDK_LOCATION>\components\softdevice\s132\headers\nrf_soc.h header file in your SDK. Here you can see that if p-request->hfclk_force_xtal is true the HF clock is guaranteed to be clocked from the external crystal.

on #4> who or where in code, p->request->hfclk_force_xtal is being set?

Thanks

Santosh Kumar Athuru

[Simonr]

1. In our examples, the init functions are set up to wait for the EVENTS_HFCLKSTARTED event to be set to indicate that the HFCLK has been started. If this doesn't happen it will cause the timeout error I mentioned in A3 of the last reply. The application initializes the HFCLK like this:

    // 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.
    }

2. Again, in our examples, we always make sure to start the external HFCLK before starting the radio, to prevent this from occurring. We make sure that HFXO is running before starting the SoftDevice and radio, which needs the HFXO to work.

3. See the code snippet added above.

4. You set this request when you request a radio timeslot using the following function:

SVCALL(SD_RADIO_REQUEST, uint32_t, sd_radio_request(nrf_radio_request_t const * p_request));

Read more about the timeslot requests in the \...\<SDK_FOLDER>\components\softdevice\s132\headers\nrf_soc.h

Best regards,

Simon

[santosh athuru]

Hi Simon,

thanks for your reply. Can you be more specific, in SDK 15.0, other than ble_connectivity example, I don't see anywhere else the HFCLK being started.

For example ble_peripheral/ble_app_uart - I don't see the code you are referring to. How is the softdevice handling HFCLK in this example?

I've added the code that you mentioned about in my example and I see that current consumption is little bit higher because the crystal is always ON now. I verified this by reading HFCLKSTAT register.

If I don't add the code you mentioned and if I stop the 32 MHz clock input while BLE is connected, then the peripheral drops the connection and I don't see any advertisements either until I start providing the 32MHz clock input again. Also reading the HFCLKSTAT shows that SoftDevice turns ON and turns OFF HFCLK as needed on its own. 

Reading the HFCLKSTAT register in our test example (similar to ble_app_uart) tells that HFCLK is sourced from XTAL which is not the default, so some piece of SW is initializing it and I'm not able to find it because I don't do the code you mentioned in our example. 

Other important things is, while all the above is during startup, what happens if the crystal faults during run time, what type of error would the softdevice return. We don't use/call sd_radio_request in our example directly, is this something that SoftDevice software is using internally?

Thanks

Santosh Athuru

[Simonr]

Hi

The HFCLK is (in most examples) is started by the SoftDevice (in SOFTDEVICE_HANDLER_INIT), which is why you're not able to see the initialization of it. Sorry if I misunderstood, but I thought you wanted to know how you could start the HFCLK if you wanted. If the HFCLK is not available during startup, the SoftDevice will just wait for the HFCLK to become available, which is why the connection is lost and the device is not advertising.

If the application is already running and the HFXO (external HF clock) fails, it apparently does not return an error, and the SoftDevice will keep running (very inaccurately), and ultimately failing due to timing errors or similar.

Best regards,

Simon