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, sorry for the late reply!

Michael01101 said:

My ts_temp_disable() and my ts_re_enable(&rf_config) function work now. And the time sync works as it should when it is enabled.

At the moment I am a bit worried by simply removing this line of code. To be honest, I do not really know what this line of code does. Does this have any consequences?

Are there any side effects, which I sould be aware of?

I looked at the changes you made and the error you describe.

I assume the error you see is actually coming from main.c. The callback you commented out (m_callback(&m_trigger_evt)) is probably going to this case in main.c: https://github.com/nordic-auko/nRF5-ble-timesync-demo/blob/master/nRF5_SDK_16.0.0_98a08e2/examples/ble_peripheral/ble_app_uart/main.c#L771 , which in turn calls ts_set_trigger(). This function will return an error when m_timeslot_session_open is false. This error is probably what triggers the assert.

Considering that you only use the timestamp functionality, and not the ts_set_trigger() functionality, I think your changes should be fine. I think also that the trigger functionality isnt strictly speaking depending on that the timeslot being active, but this was probably the easiest way of checking if the required setup was done already. You could probably comment out this check and have the triggering too work fine when the radio is temporarily turned off to save power.

Audun

[Michael01101]

Hello Audun,

thank you very much for your answer.

Audun said:

sorry for the late reply!

That is absolutly no problem. I really appreciate your great help with my 'time_sync' specific problems.

At the moment I am working on my central device (nRF52840DK). I am using the following timestamp function, which I call when a GPIO changes from high to low:

uint64_t ts_timestamp_get_ticks_u64(void);

As you mentioned in your notes to this function:

 * @note When @ref TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT is non-zero,
 *       this function should be called from context priority @ref TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY or lower

I have to make sure, that this function gets only called from the TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY, because there are some parts in the timers_capture which are not thread safe.

At the moment TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY is set to 7. This is the lowest priority, which is set by default.

Here is my problem: I need that the ts_timestamp_get_ticks_u64() gets called from a higher priority (6 or lower). I need to achieve that my GPIO capturing has a higher priority than my UART.

So here is my question:

Are there any side effects or any consequences which I sould be aware of, if I change TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY to 6 or lower?

Thank you in advance.

Best regards

Michael

[Audun]

Hi Michael,

Michael01101 said:

Are there any side effects or any consequences which I sould be aware of, if I change TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY to 6 or lower?

No direct side effects that I'm aware of. But there could be indirect side effects depending on what the application does with the event handler callback. If your application runs code directly in the event handler then that code could in turn have side effects.

However, I don't think your application uses any of the events in the callback anyway?

Best regards,

Audun

[Michael01101]

Hello Audun,

thank you very much for your reply.

At the moment I am having a bit of a weird problem. Hopefully you have some tips for me.

I am using the wireless timer synchronization code on a nRF52840DK (central) and a nRF52DK (peripheral). The time sync works at first as it should.

Here is my problem: About ~1180 seconds after I started the timer sync, the timer synchronization has abrupt an 3ms offset. This offset stays for exactly 10 seconds. After these 10 seconds the time sync returns to perfect operation and the offset is gone.

Unfortunately, I do not know what causes this abrupt offset. Maybe these two definitions has something to do with this problem (they are exactly 10 seconds)?:

#define TIME_SYNC_DESYNC_TIMEOUT 10000000 /* Timeout for desynchronization [us] */
#define TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT 10000000 /* Set to 0 to disable [us] */

Do you have any suggestions what causes this weird behaviour? Any kind of feedback is always appreciated.

Thank you very much in advance.

Best regards,

Michael

-----------------------------------

# Edit (07.04.2021)

After some further debugging I figured the following out:

It looks like that the master-timer on the central works fine. The problem/offset occurs on the peripheral with its slave-timer. (The central sends sync beacons. The peripheral receives the sync beacons).

Here is a example of the offset, when it occures:

Timer Central: 1170003 (ms)

Timer Peripheral: 1170000 (ms)

As I already mentioned, after these 10 seconds, both timers are equal again.

Maybe the values of the sync beacon do not get applied on the peripheral in time?

I am still not able to solve this issue. Any kind of feeback is always appreciated. Thank you very much in advance.

Best regards,

Michael

[Audun]

Hi Michael,

did you try to set TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT to 0?

Another developer discovered a race condition if the timer value is updated very close to the wraparound. The workaround was to check the timer value and dont apply any adjustments close to the wraparound. This has the side effect that valid sync packets are discarded when close to the wraparound. The TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT was an attempt to avoid the issue entirely by having the transmitter send packets at "safe" times.

By setting TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT  to 0 the original workaround will be used, which might be the safest approach here.

Best regards,

Audun

[Michael01101]

Hello Audun,

thank you very much for your reply.

As you suggested, I set TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT to 0. Unfortunately, this does not fix my problem. When I set TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT  to 0, the abrupt offset is even higher. (Abrupt offset of about 99ms)

To apply this change, I had to also change a data type (uint32_t to int32_t) in time_sync.c:

From this:

static uint32_t calculate_tx_start_offset(void)
{
    return 0;
}

to this:

static int32_t calculate_tx_start_offset(void)
{
    return 0;
}

Do you know why there was an uint32_t used instead of an int32_t?

----------------------------------------------------------------------------------------

These are my definitions in time_sync.h at the moment:

#ifndef TS_SOC_OBSERVER_PRIO
#define TS_SOC_OBSERVER_PRIO 0
#endif

#ifndef TIME_SYNC_TIMER_MAX_VAL
#define TIME_SYNC_TIMER_MAX_VAL (16000) // 40000
#endif

#ifndef TIME_SYNC_RTC_MAX_VAL
#define TIME_SYNC_RTC_MAX_VAL   (0xFFFFFF)
#endif

#ifndef TIME_SYNC_DESYNC_TIMEOUT
#define TIME_SYNC_DESYNC_TIMEOUT 10000000 /* Timeout for desynchronization [us] */
#endif

#ifndef TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT
#define TIME_SYNC_TX_OFFSET_REALIGN_TIMEOUT 0 // 10000000 /* Set to 0 to disable [us] */
#endif

#ifndef TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY
#define TIME_SYNC_EVT_HANDLER_IRQ_PRIORITY 6 // 7 /* Priority of event handler */
#endif

So I am still having the problem with the abrupt offset.

Do you have any other suggestions what could cause this behaviour?

Can you provide me some guidance how to solve this issue?

I am really stuck with this at the moment. It looks like the success of my project depends on your help.

Thank you very much in advance.

Best regards,

Michael