NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 08 Nov 2022 13:59:34 GMT

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.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 13:45:05 GMT

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.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 08 Nov 2022 13:36:35 GMT

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) \
  ))

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 13:24:59 GMT

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.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 13:21:59 GMT

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.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 08 Nov 2022 13:10:03 GMT

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 ?

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 12:27:53 GMT

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

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 08 Nov 2022 08:32:33 GMT

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

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 08:23:45 GMT

No I've double checked it the radio callback is only acting on the TIMER0 instance.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 08 Nov 2022 08:22:40 GMT

Yes, I guess the timesync code and you application may be trying to use the same timer instance.

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 08 Nov 2022 07:54:29 GMT

Okay I did a bit more investigation and found out that it only happens when I start our timesync routine which calls:

		APP_ERROR_CHECK(sd_radio_session_open(radio_callback));

		APP_ERROR_CHECK(request_next_event_earliest());

The code is from here:
https://github.com/wiesener/nRF5-ble-timesync-demo

If I comment these lines out and start a measurement everything works fine. But when I call these lines the capturing is stopped. Any guesses why?

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Tue, 25 Oct 2022 08:50:57 GMT

Can you take a screenshot of the TIMER4 peripheral registers when you see this random value?

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Constantin — Tue, 25 Oct 2022 06:32:01 GMT

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

RE: NRF_TIMER_TASK_CAPTURE4 of timer4 is permanent at the same value

Vidar Berg — Fri, 21 Oct 2022 11:14:51 GMT

Hello,

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

[quote user=""]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[/quote]

What value do you see?

Best regards,

Vidar