How to access the TIMER3 in wireless timer sync?

[Michael01101]

Hello,

I found this great blog entry about synchronizing timers on different devices: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices

It works just fine on a nRF52840DK and a nRF52DK. Timers on multiple nRF5 devices are synced by one device (master) sending sync packets containing captured timer values to other devices (nodes). (TIMER3 is free running, TIMER2 counts TIMER3 overflows).

At the moment I am struggeling to access this synchronized TIMER3 on the two boards. I am familiar with setting up a TIMER without wireless timer sync. 

So here are my questions:

1. How can I define CC, Prescaler, Mode, Bitmode, the interrupt handler and so forth when using wireless timer sync?

2. Can anybody provide me some advice how to access this synchronized TIMER3 properly? 

Thank you very much in advance.

[Audun]

Hi Michael,

Michael01101 said:

So I am still having the abrupt offset issue.

Do you have any other suggestions on how to solve this issue. We highly appreciate your help with our problem. It still looks like that the success of our project depends on your help.

Thanks for the update. I have spent time in the office today to set up a better test case to reproduce the issue you see:

On the receiver side I have a RTC set up to capture a timestamp every X ms, and I look at the relative difference between the current and previous timestamp to determine if this is a sane value. I think this is functionally equivalent of the setup you have?

I believe I see the issue, and will work on confirming my setup and work on a solution.

Best regards,

Audun

[Audun]

Hi again Michael,

there were some corner cases that triggered during the weekend, and I've made some further refinements to the code now. Can you try the following on your side?

static void timers_capture(uint32_t * p_sync_timer_val, uint32_t * p_count_timer_val, uint32_t * p_peer_counter)
{
    static nrf_atomic_flag_t m_timestamp_capture_flag = 0;

    nrf_atomic_u32_t peer_counter;

    if (nrf_atomic_flag_set_fetch(&m_timestamp_capture_flag) != 0)
    {
        // Not thread-safe
        APP_ERROR_CHECK_BOOL(false);
    }

    nrf_ppi_channel_t ppi_chn;
    nrfx_err_t ret = nrfx_ppi_channel_alloc(&ppi_chn);
    APP_ERROR_CHECK_BOOL(ret == NRFX_SUCCESS);

    ppi_counter_timer_capture_configure(ppi_chn);

    NVIC_DisableIRQ(m_params.egu_irq_type);

    bool counter_adjustment_triggered;

    // Loop if adjustment procedure happened close to timer capture
    do
    {
        counter_adjustment_triggered = m_params.egu->EVENTS_TRIGGERED[0];

        m_params.egu->EVENTS_TRIGGERED[1] = 0;
        m_params.egu->TASKS_TRIGGER[1] = 1;
        while (m_params.egu->EVENTS_TRIGGERED[1] == 0)
        {
            __NOP();
        }

        if (m_params.high_freq_timer[1]->CC[0] < 2 || m_params.high_freq_timer[0]->CC[3] < 2)
        {
            /* Capture again if capture happened too close to adjustment or wraparound */
            m_params.egu->EVENTS_TRIGGERED[1] = 0;
            m_params.egu->TASKS_TRIGGER[1] = 1;
            while (m_params.egu->EVENTS_TRIGGERED[1] == 0)
            {
                __NOP();
            }
        }

        if (counter_adjustment_triggered)
        {
            peer_counter = ((sync_pkt_t *) mp_curr_adj_pkt)->counter_val;
        }
        else
        {
            peer_counter = m_master_counter;
        }
    } while (counter_adjustment_triggered != m_params.egu->EVENTS_TRIGGERED[0] ||
             m_params.high_freq_timer[0]->CC[3] < 2);

    NVIC_EnableIRQ(m_params.egu_irq_type);

    ppi_counter_timer_capture_disable(ppi_chn);
    nrfx_ppi_channel_free(ppi_chn);

    *p_sync_timer_val  = m_params.high_freq_timer[0]->CC[3];
    *p_count_timer_val = (m_params.high_freq_timer[1]->CC[0]);
    *p_peer_counter    = peer_counter;

    nrf_atomic_flag_clear(&m_timestamp_capture_flag);
}

[Audun]

Hi again,

I still see a corner case with this one.. rethinking the approach a bit now.

Specifically I see corner cases around the time the timer wraps around (every 2.5 ms), or when the counter is cleared as part of the adjustment procedure on the receiver. The timer can just be sampled again when the corner case is adjusted and the new value captured, since this runs at 16 MHz and has no significant delay. One cannot wait for the counter in the same way, as this would incur a 2.5 ms delay. After some unsuccessful approaches to detect the counter corner case I'm trying to avoid clearing the counter altogether and keeping track of a diff instead of the transmitter counter total value. Will need to do some further testing to ensure no new issues have been introduced here.

Best regards,

Audun

[Jona]

Hi

I've been following this case lately since I've been experiencing similar issues as Michael01101 after upgrading my project to the new TimeSync version. This case has been very helpful so far, thanks!

I'm looking forward to a solution.

Best regards,

Jona