gpiote event -> ppi -> gpiote task latency

[victor passe]

Hi, I have a gpiote event setup that triggers a gpiote task via ppi,  this is the relevant code

NRF_POWER->TASKS_CONSTLAT = 1;

nrf_gpio_cfg_input(GPIO_OC,GPIO_PIN_CNF_PULL_Pullup);
nrf_gpiote_event_configure(GPIOTE_OC,GPIO_OC,comparator_idle_low?NRF_GPIOTE_POLARITY_LOTOHI:NRF_GPIOTE_POLARITY_HITOLO);
nrf_gpiote_event_enable(GPIOTE_OC);

nrf_gpiote_task_configure(GPIOTE_FET,GPIO_FET,NRF_GPIOTE_POLARITY_TOGGLE,NRF_GPIOTE_INITIAL_VALUE_LOW);
nrf_gpiote_task_enable(GPIOTE_FET);
NRF_GPIO->PIN_CNF[GPIO_FET] = (GPIO_PIN_CNF_DRIVE_H0H1 << GPIO_PIN_CNF_DRIVE_Pos);

nrf_ppi_channel_and_fork_endpoint_setup(ch,
(uint32_t)&(NRF_GPIOTE->EVENTS_IN[GPIOTE_OC]),
(uint32_t)&(NRF_PPI->TASKS_CHG[PPI_GROUP_RUN].DIS),//disregard this, the group has nothing to do with this i think
(uint32_t)&(NRF_GPIOTE->TASKS_CLR[GPIOTE_FET])
);

From rising edge on IO "GPIO_OC" to falling edge of "GPIO_FET" i get about 380ns
what can i do to lower this?

[victor passe]

or am i limited by gpio (1cycle) + gpiote (1cycle) + ppi (1cycle) + gpiote (1cycle) + gpio (1cycle) = 5-6 cycles = 380ns?

[Susheel Nuguru]

Yes, it is the path that the signal needs to take and to be sampled. The best case scenario is 1 clock cycle propagation of the event in interest thought a peripheral and worst case is 2 cycles.

I think I have seen similar propagation/sampling delays similar to your configuration in this thread. Try to see if enabling the constant latency in the power have any better results in your case.

[victor passe]

hi, thanks for your awnser, constant latency is the first line of my code.
is there anything else i must to to enable constant latency?
i can not get under 360-380ns

i also tested this:
*(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * GPIOTE_OC)) = 1;
now it is one clock cycle faster (~330ns), is there any way i could get any documentation of these type of "hidden" registers?

how does errata [156] play in to this?
I tried to use only odd, only even and changed tasks_clr -> tasks_out but no change in latency.
I can do not see any difference with constant latency or with low power. the fact that those are the same implies that i do not enter both, right? can i see what mode the nrf52805 is in?

[Susheel Nuguru]

victor passe said:

hi, thanks for your awnser, constant latency is the first line of my code.
is there anything else i must to to enable constant latency?
i can not get under 360-380ns

Unfortunately there is no documentation that describes the path delay for events between peripherals.

victor passe said:

how does errata [156] play in to this?

It is very likely that this errata is effecting in your case as you are using TASK_CLR. Are you seeing any power consumption increase? if not, then this errata does not effect you.

victor passe said:

i also tested this:
*(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * GPIOTE_OC)) = 1;
now it is one clock cycle faster (~330ns), is there any way i could get any documentation of these type of "hidden" registers?

I do not have access to hidden registers that are not published. Using them in any other way than the way published is very dangerous and can cause unpredictable behavior.