PPI / GPIOTE clock query

RE: PPI / GPIOTE clock query

snoopy20 — Tue, 18 Feb 2025 10:19:00 GMT

Hi,

Yes it's been confirmed by multiple customers as working perfectly. It was really to aid my understanding and perhaps will aid others if they search similar.

Regards,

Andrew

RE: PPI / GPIOTE clock query

Hung Bui — Tue, 18 Feb 2025 10:12:16 GMT

Hi Andrew,

I agree that 5MHz is in the ballpark of the limit for the setup. I assume that reduce the COMP speed to low is an OK solution for you ?

RE: PPI / GPIOTE clock query

snoopy20 — Mon, 17 Feb 2025 14:52:50 GMT

Hi,

I'm already running TASKS_CONSTLAT = 1;

I'm not using GPIOTE IN event for this part of the system (though it is in use elsewhere, but I assume doesn't effect the output of a GPIOTE channel).

So if PPI takes 1 cycle and GPIOTE takes 2 cycles @ 16MHz that's 16/3 = 5.3MHz

Which is close to the 5MHz "normal" mode of the COMP. Given that the behaviour is random sometimes taking minutes and sometimes hours I think there's another cycle being taken somewhere. Or maybe the 5MHz for the COMP is a ballpark figure not an absolute. It's a little close for comfort so I think the reason is potentially established.

Regards,

Andrew

RE: PPI / GPIOTE clock query

Hung Bui — Mon, 17 Feb 2025 14:41:21 GMT

Hi Andrew,

You can take a look at the Clock Control section in the spec:

The HFCLK clock control receive the oscillation either from the external 32MHz crystal or the internal HFINT. It then output the PCLK16 16 Mhz to the peripherals.

You can choose to start the HFXO or leave it to the HFINT (default)

When there is a peripheral that requires PCLK16 then the HFCLK will be kept active.

[quote user="snoopy20"]How about the GPIOTE, how fast does it react to the PPI event?[/quote]

Actually it may take up to 2 cycles for the GPIOTE task to output on GPIO pin.
You can take a look at this ticket:

gpiote event -> ppi -> gpiote task latency

and this ticket:
Delay from GPIOTE Event until a Task is started over PPi on nRF52

Seems that the latency needed is about 380ns (from GPIOTE IN event to GPIO output)

You can try to set NRF_POWER->TASKS_CONSTLAT = 1; to switch to constant latency mode, but I don't think it would reduce the latency in your case, as the COMP should keep the HFCLK running all the time.

RE: PPI / GPIOTE clock query

snoopy20 — Mon, 17 Feb 2025 13:48:34 GMT

Hi Hung,

How is the 16MHz clock generated, half the 32MHz clock (so RC or crystal), and forced always on so long as PPI is enabled?

How about the GPIOTE, how fast does it react to the PPI event?

The issue isn't that it's not detecting the recovery (which at COMP 'slow mode' 1.5MHz works just fine), it's that in 'normal' 5MHz mode then either/and PPI or GPIOTE can't keep up.

The 16MHz clock suggests it should, given 1/5MHz is plenty of tolerance.

Regards,

Andrew

###

Flow is:

COMP(UVLO) -> PPI -> GPIOTE -> [Toggle] -> LED_PWM_DRIVER

Where COMP is measuring the voltage going to the LED_PWM_DRIVER. LED_PWM_DRIVER will be very fast turn-off but very slow turn-on (slow current ramp on turn-on).

RE: PPI / GPIOTE clock query

Hung Bui — Mon, 17 Feb 2025 13:30:11 GMT

Hi Andrew,
Could you let me know the frequency of your input signal ?
You can read more about the clock that the PPI align to:

So there can be up to one clock cycle delay.

I don't fully understand your setup, can you show it with a schematic or a figure explaining how it work ?