NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

[Constantin]

I am facing a problem. Two sensors are triggering with data_ready pins and a timer value is captured upon the event. But the value can be stored only in RAM if a context switch happens. But this depends on the processor usage. Therefore, it can happen that one sensor triggers a capture event, but the interrupt routine is delayed due to softdevice processing etc. and in the meantime the other sensor triggers a more recent capture. In this case the timing is screwed.

I've tried to use another capture channel of the same timer but somehow the NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value. But I have to admit that I am not sure if the event is correctly configured since the code in the header is always greyed out . And I do not know where TIMER_INTENSET_COMPARE4_Msk is defined.

/** @brief Timer tasks. */
typedef enum
{
    NRF_TIMER_TASK_START    = offsetof(NRF_TIMER_Type, TASKS_START),      ///< Task for starting the timer.
    NRF_TIMER_TASK_STOP     = offsetof(NRF_TIMER_Type, TASKS_STOP),       ///< Task for stopping the timer.
    NRF_TIMER_TASK_COUNT    = offsetof(NRF_TIMER_Type, TASKS_COUNT),      ///< Task for incrementing the timer (in counter mode).
    NRF_TIMER_TASK_CLEAR    = offsetof(NRF_TIMER_Type, TASKS_CLEAR),      ///< Task for resetting the timer value.
    NRF_TIMER_TASK_SHUTDOWN = offsetof(NRF_TIMER_Type, TASKS_SHUTDOWN),   ///< Task for powering off the timer.
    NRF_TIMER_TASK_CAPTURE0 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[0]), ///< Task for capturing the timer value on channel 0.
    NRF_TIMER_TASK_CAPTURE1 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[1]), ///< Task for capturing the timer value on channel 1.
    NRF_TIMER_TASK_CAPTURE2 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[2]), ///< Task for capturing the timer value on channel 2.
    NRF_TIMER_TASK_CAPTURE3 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[3]), ///< Task for capturing the timer value on channel 3.
#if defined(TIMER_INTENSET_COMPARE4_Msk) || defined(__NRFX_DOXYGEN__)
    NRF_TIMER_TASK_CAPTURE4 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[4]), ///< Task for capturing the timer value on channel 4.
#endif
#if defined(TIMER_INTENSET_COMPARE5_Msk) || defined(__NRFX_DOXYGEN__)
    NRF_TIMER_TASK_CAPTURE5 = offsetof(NRF_TIMER_Type, TASKS_CAPTURE[5]), ///< Task for capturing the timer value on channel 5.
#endif
} nrf_timer_task_t;

[Vidar Berg]

Hello,

Capture register 4 and 5 should be available if you use TIMER4 as you can see from the table here:

I've tried to use another capture channel of the same timer but somehow the NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

What value do you see?

Best regards,

Vidar

[Constantin]

I always see the same value. It seems to be a random value.

[Vidar Berg]

OK, why don't you take a screenshot of the TIMER4 registers before and after you have started the timesync routine?

[Constantin]

Okay I set a breakpoint before the call and afterwards. But cannot see any big difference except that the CC is incremented for CC1 CC3 and CC5. But afterwards only CC3 and CC1 get incremented. And CC5 stays constant.

I've double checked that the interrupt is still coming but it does not trigger a capture for CC5 anymore.

Before:

After:

Kind regards,

Constantin

[Vidar Berg]

Thanks. Looks like you are using Eclipse, are you able to trigger the capture 4 task from the peripheral viewer when the CPU is halted and then refresh CC[4] to see if the register gets updated?

Kind regards,

Vidar

Edit: Are you using the same TIMER instances as shown here for the sync mechanism: https://github.com/wiesener/nRF5-ble-timesync-demo/blob/master/nRF5_SDK_14.2.0_17b948a/examples/ble_peripheral/ble_app_uart/main.c#L710 ?

[Constantin]

Yes it can be triggered and the CC5 is updated.

@Edit: No only TIMER0 is used for the Radio according to the example and TIMER4 is used for the overall clock. The rest is not used.

[Constantin]

When I reenable the ppi connection after the code lines.

		APP_ERROR_CHECK(sd_radio_session_open(radio_callback));

		APP_ERROR_CHECK(request_next_event_earliest());

With

nrfx_ppi_channel_alloc(&m_ppi_channel2);
nrfx_ppi_channel_assign(m_ppi_channel2,
						 nrfx_gpiote_in_event_addr_get(MAGMTR_DRDY),
						 nrfx_timer_task_address_get(&m_timer4, NRF_TIMER_TASK_CAPTURE5));
nrfx_ppi_channel_enable(m_ppi_channel2);

It starts to capture correctly. So this means that somehow the call of sd_radio_session_open deletes the channel assignment.

Kind regards.

[Vidar Berg]

Interesting. So, it would probably be more interesting to look at the PPI registers before and after enabling the timeslot.

Can you check which ppi channel the driver allocates to you? The following channels are reserved to the Softdevice:

/**@brief Mask of PPI channels reserved by the SoftDevice when the SoftDevice is enabled. */
#define NRF_SOC_SD_PPI_CHANNELS_SD_ENABLED_MSK  ((uint32_t)( \
      (1U << 17) \
    | (1U << 18) \
    | (1U << 19) \
    | (1U << 20) \
    | (1U << 21) \
    | (1U << 22) \
    | (1U << 23) \
    | (1U << 24) \
    | (1U << 25) \
    | (1U << 26) \
    | (1U << 27) \
    | (1U << 28) \
    | (1U << 29) \
    | (1U << 30) \
    | (1U << 31) \
  ))

[Constantin]

It is channel 1!

No they are chaning and I guess I found the issue. The timesync example used fixed PPI channels 1 and 3 for rx and tx. Hence I need to allocate a channel different than these channels.

[Vidar Berg]

I was just about to ask about that. I see channel 0 and 1 are used here: https://github.com/wiesener/nRF5-ble-timesync-demo/blob/master/nRF5_SDK_14.2.0_17b948a/examples/common/time_sync.c#L616. Thanks for the update.