This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

HFCLK (HFXO) failure detection

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

Parents
  • 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

Reply
  • 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

Children
  • 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

Related