Supervision timeout following connection parameter updates on limited devices

RE: Supervision timeout following connection parameter updates on limited devices

Simonr — Thu, 17 Mar 2022 12:22:43 GMT

I can't give you any crystal recommendation from specific vendors, but you can look at the bill of materials for reference designs and DKs to see what kind of crystals we have used there if that's helpful (downloadable here). The product specification should also explain what kind of crystals are fitting to use as LF crystals.

Best regards,

Simon

RE: Supervision timeout following connection parameter updates on limited devices

BretH — Wed, 16 Mar 2022 19:53:18 GMT

Does Nordic have LF crystal part recommendations? We are using a low capacitance crystal that may have too stringent of a load capacitance range.

RE: Supervision timeout following connection parameter updates on limited devices

Simonr — Wed, 09 Mar 2022 09:22:04 GMT

Glad to hear the LF SYNTH resolved the issues. That means our assumption that the XTAL being off was correct.

I'm sorry, but my last reply might have been misleading. There's not really a reliable way to calculate the LF oscillators accuracy in firmware, as the PPI is not "timeless" and might take a clock cycle or so to report, which will result in inaccurate numbers (9000ppm is way off for the RC oscillator at least, as it is specified to +-500ppm in our spec. The most accurate way to determine the accuracy of the clock sources would be to make a GPIO toggle at the frequency of the LF clock source, and measure this with external HW.

Best regards,

Simon

RE: Supervision timeout following connection parameter updates on limited devices

BretH — Tue, 08 Mar 2022 13:20:08 GMT

I did try SYNTH for the clock source and it resolves the issue. However, I'd still like to characterize the issue with our XTAL to better understand the distribution of error across units.

To do this, I created a small test for comparing the HF and LF clocks. I used the RTC, a Timer, and PPI. I set a RTC compare event to trigger a timer clear through PPI, and another RTC compare event to trigger a timer capture through PPI 10 seconds later.

When using RC or XTAL for LF clock sources, I found the accuracy to be about 9000ppm (10090ms elapsed on timer vs 10s elapsed on RTC). This scaled if I increased or decreased the time, always being 9000ppm.

To verify the test setup, I tried the SYNTH LF clock source. Over 10 seconds on the RTC, the timer read 9999.924ms (8ppm). I'd expect this to be closer to 0ppm, but I understand there is slight inaccuracies due to the different time domains.

Are my PPM calculations incorrect, or is this a faulty test?

#define COMPARE_COUNTERTIME  (10UL)

nrf_ppi_channel_t ppiStartChannel;
nrf_ppi_channel_t ppiStopChannel;
const nrfx_timer_t timer = NRFX_TIMER_INSTANCE(4);
const nrfx_rtc_t rtc = NRFX_RTC_INSTANCE(2); /**< Declaring an instance of nrf_drv_rtc for RTC0. */


static void rtc_handler(nrf_drv_rtc_int_type_t int_type)
{
    if (int_type == NRF_DRV_RTC_INT_COMPARE0)
    {
        uint32_t capture_time = nrfx_timer_capture_get(&timer, (nrf_timer_cc_channel_t)0);
        NRF_LOG_DEBUG("RTC INT COMPARE PPI %d", capture_time)
        NRF_LOG_DEBUG("RTC INT COMPARE non-ppi %d", nrfx_timer_capture(&timer, (nrf_timer_cc_channel_t)0))
    }
    else if (int_type == NRF_DRV_RTC_INT_COMPARE1)
    {
        NRF_LOG_DEBUG("NRF_DRV_RTC_INT_COMPARE1")
        NRF_LOG_DEBUG("RTC INT COMPARE start %d", nrfx_timer_capture(&timer, (nrf_timer_cc_channel_t)0))
    }
}

/** @brief Function initialization and configuration of RTC driver instance.
 */

void timer_event_handler(nrf_timer_event_t event_type,
                        void            * p_context)
{

}

void rtc_config(void)
{
    uint32_t err_code;

    // CONFIGURE RTC
    //

    //Initialize RTC instance
    nrf_drv_rtc_config_t config = NRF_DRV_RTC_DEFAULT_CONFIG;
    config.prescaler = 4095;
    err_code = nrf_drv_rtc_init(&rtc, &config, rtc_handler);
    APP_ERROR_CHECK(err_code);

    //Set compare channel to trigger interrupt after COMPARE_COUNTERTIME seconds
    err_code = nrf_drv_rtc_cc_set(&rtc, 0, 2 + (COMPARE_COUNTERTIME * 8), true);
    APP_ERROR_CHECK(err_code);

    //Set compare channel to trigger interrupt after COMPARE_COUNTERTIME seconds
    err_code = nrf_drv_rtc_cc_set(&rtc, 1, 2, true);
    APP_ERROR_CHECK(err_code);


    // CONFIGURE TIMER
    //
    nrfx_timer_config_t timer_config =
    {
        .frequency = NRF_TIMER_FREQ_1MHz,
        .mode = NRF_TIMER_MODE_TIMER,
        .bit_width = NRF_TIMER_BIT_WIDTH_32,
        .interrupt_priority = NRFX_TIMER_DEFAULT_CONFIG_IRQ_PRIORITY,
        .p_context = 0
    };
    err_code = nrfx_timer_init(&timer, &timer_config, timer_event_handler);
    APP_ERROR_CHECK(err_code);
    nrfx_timer_clear(&timer);
    nrfx_timer_enable(&timer);


    // CONFIGURE PPI
    //
    err_code = nrfx_ppi_channel_alloc(&ppiStartChannel);
    APP_ERROR_CHECK(err_code);
    err_code = nrfx_ppi_channel_alloc(&ppiStopChannel);
    APP_ERROR_CHECK(err_code);

    const uint32_t rtc_compare1_event = nrfx_rtc_event_address_get(&rtc, NRF_RTC_EVENT_COMPARE_1);
    const uint32_t timer_start_task = nrfx_timer_task_address_get(&timer, NRF_TIMER_TASK_CLEAR);
    err_code = nrfx_ppi_channel_assign(ppiStartChannel, rtc_compare1_event, timer_start_task);
    APP_ERROR_CHECK(err_code);

    const uint32_t rtc_compare0_event = nrfx_rtc_event_address_get(&rtc, NRF_RTC_EVENT_COMPARE_0);
    const uint32_t timer_capture_task = nrfx_timer_capture_task_address_get(&timer, 0);
    err_code = nrfx_ppi_channel_assign(ppiStopChannel, rtc_compare0_event, timer_capture_task);
    APP_ERROR_CHECK(err_code);

    err_code = nrfx_ppi_channel_enable(ppiStartChannel);
    APP_ERROR_CHECK(err_code);
    err_code = nrfx_ppi_channel_enable(ppiStopChannel);
    APP_ERROR_CHECK(err_code);


    // START RTC
    //
    nrf_drv_rtc_enable(&rtc);
    NRF_LOG_INFO("RTC started");
}

RE: Supervision timeout following connection parameter updates on limited devices

Simonr — Tue, 01 Mar 2022 13:01:02 GMT

The RTC peripheral (example project available here) for instance, uses the LF clock for example.

You can also try setting the LF clock source to synthesize from the HF clock instead, which will be the most accurate way to run the LF clock, but also the most current consuming. This is done by setting the NRF_SDH_CLOCK_LF_SRC define in sdk_config.h to 2. If you're able to connect at better PPM values than with the LF XTAL I think it's safe to say that the connection issues are caused by the LF crystal.

Best regards,

Simon

RE: Supervision timeout following connection parameter updates on limited devices

BretH — Mon, 28 Feb 2022 15:17:01 GMT

Do you have any recommendations for ways firmware can evaluate the LF clock accuracy relative to the HF clock? If we have high confidence in our HF clock (we do or else BT PHY would be problematic), then we should be able to estimate LF clock frequency. However, in the product spec, I can find several peripherals driven by PCLK1M or PCLK16M, but there are no references to PCLK32KI (via Ctrl-F). Which peripherals are LFCLK-driven that could be helpful in comparing clock performance?

RE: Supervision timeout following connection parameter updates on limited devices

Simonr — Mon, 28 Feb 2022 09:19:18 GMT

Glad to hear you broke some ground here. This sounds like a damaged crystal to me as well. Setting the accuracy to 250ppm will mainly just effect the radio's accuracy, but also other peripherals using the LF clock, so timers, RTCs, etc. will also be somewhat less accurate.

Best regards,

Simon

RE: Supervision timeout following connection parameter updates on limited devices

BretH — Thu, 24 Feb 2022 14:13:59 GMT

We've had a lot of activity in the past 24 hours regarding this issue. At first, we were struggling to identify which combination of phones and nRF52 devices would reproduce the issue, but now we finally got some traction.

We determined that our nRF52 device is the problem. We can reproduce the issue with several phones on a specific nRF52 device, and the same phones with a different nRF52 device do not reproduce the issue.

We've also determined that the issue is more likely to be reproduced when the phone's clock tolerance is narrower. By looking at the CONNECT_IND payload, a phone with a 31-50ppm tolerance has a higher failure rate than a phone with a 251-500ppm tolerance.

We also did as you recommended and incrementally increased the NRF_SDH_CLOCK_LF_ACCURACY. With one device combination, we found 150PPM failed but 250PPM was successful.

This suggests potentially significant issues with our crystal, either damage during manufacturing or a capacitance issue. We'll be assessing the power impact of 250PPM NRF_SDH_CLOCK_LF_ACCURACY vs 20PPM, but it seems likely to be negligible. Apart from RX WINDOW WIDENING, is there any other major factor affected by the value of NRF_SDH_CLOCK_LF_ACCURACY ?

RE: Supervision timeout following connection parameter updates on limited devices

Simonr — Thu, 24 Feb 2022 12:49:32 GMT

Just to make sure I understand correctly. Is this reproducible on some phones no matter what nRF52 device it's tested with? Or is it reproducible on some nRF52 devices no matter what phones they connect to? Or is it just with specific combinations of some nRF52 devices and phones? Can you specify what phone models you see this issue on, cheaper models tend to have clock drift and a relaxed relationship to the BLE specification, which can cause trouble unfortunately, for example by disconnecting because of two high of an accuracy.

It could indeed be a problem with some of the LF crystals on your boards. They might have been damaged during soldering, have the wrong capacitor values mounted, or have a bad connection to the nRF52 for example. One way to check is to lower the NRF_SDH_CLOCK_LF_ACCURACY slightly, not all the way to 500ppm, often it's enough to set it to 50ppm for example, and you will still have good accuracy. If this fixes the issue, and accuracy is not critical in your application, that can be an okay fix.

You can also try desoldering the LF crystal and soldering on a new one without changing anything else to see if it's a HW issue with the crystal itself.

Best regards,

Simon