Behavior when a single PPI channel triggers 2 timer tasks

[XavierYin]

nRF52832 / SDK 14.2 / SD5.1.0

There might be two configurations to setup a PPI channel to assign some peripheral event to both timer capture & clear task:

nrf_drv_ppi_channel_assign(event, (uint32_t)&NRF_TIMERX->TASKS_CAPTURE[Y]);
nrf_drv_ppi_channel_fork_assign(event, (uint32_t)&NRF_TIMERX->TASKS_CLEAR]);

nrf_drv_ppi_channel_assign(event, (uint32_t)&NRF_TIMERX-> TASKS_CLEAR );
nrf_drv_ppi_channel_fork_assign(event, (uint32_t)&NRF_TIMERX->TASKS_CAPTURE[Y]]);

Q1

Is there any difference between the above two configurations?

Q2

What will be the value of NRF_TIMERX->CC[Y] after the PPI channel is triggered by event?

In PS_v1.4:

22 PPI — Programmable peripheral interconnect Each TEP implements a fork mechanism that enables a second task to be triggered at the same time as the task specified in the TEP is triggered.

24.3 Task delays After the TIMER is started, the CLEAR task, COUNT task and the STOP task will guarantee to take effect within one clock cycle of the PCLK16M.

It looks like the above descriptions indicates that there should be no difference for Q1, is this correct? And since capture task delay is not specified, I have no idea about Q2.

[MartinBL]

Hi, I have asked for a comment from the designers, but it might take a few days.

[MartinBL]

Hi,

The word from the HW architects is that:

1. No, it does not make a difference whether you assign the main event before or after the fork event.
2. Unfortunately the TASKS_CLEAR will have priority over TASKS_CAPTURE and the value captured in the CC register will be 0.

[XavierYin]

It nice that at least there is deterministic behavior. Thanks for this clear answer from Nordic.

[joeyh]

About your answer to #2, it seems to be contradictory to the example provided here:

https://devzone.nordicsemi.com/f/nordic-q-a/34547/ppi-configuration-to-count-pulses

In the example, it has code like this:

// Capture counter timer using PPI to make sure this is not delayed by BLE interrupt
err_code = nrf_drv_ppi_channel_assign(ppi_channel_2, timer_read_compare_event_addr, timer_count_capture_task_addr);

// Clear counter timer using PPI to make sure this is not delayed by BLE interrupt
err_code = nrf_drv_ppi_channel_fork_assign(ppi_channel_2, timer_count_clear_task_addr); 

It works as intended by the code, which is to capture the counter, then clear it.

I am confused.

Joseph

[snoopy20]

Need clarification on this.