nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Positron — Mon, 07 Jul 2025 19:40:46 GMT

Hi! I used `sd_clock_hfclk_request` function to switch to HF clock at the beginning of the program (that's for SoftDevice).

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Udi Vahaba — Mon, 07 Jul 2025 18:33:04 GMT

Hi Positron!

I'm running into the same issue — would you be able to share some of your code showing how you solved it?

Thanks in advance!

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Positron — Sat, 03 Aug 2024 12:53:41 GMT

Hi.

I've run tests with the program that requests HFXO properly (with and without BLE), and it seems this is indeed the fix. With HFXO running there is no jitter whatsoever. As you mentioned, it increases the consumption a bit, but should be acceptable compared to outer components consumption (servo).

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Jørgen Holmefjord — Wed, 31 Jul 2024 08:38:38 GMT

[quote user="Positron"]Is timer EVENTS_COMPARE considered a HW event? In this case, there should be no difference in timings for low-power and constant-latency submodes, right? (judging from the table in your link)[/quote]

Yes, it is a HW event, and there should not be any difference in timing between the power modes for PPI.

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Positron — Tue, 30 Jul 2024 14:54:35 GMT

Hi, thanks for answering! I'll try to collect some more info.

[quote userid="14926" url="~/f/nordic-q-a/113517/nrf52810-timer-ppi-gpiote-pulsewidth-jitter-of-couple-microseconds/496262"]The time from HW event to PPI event should be only one 16MHz clock cycle[/quote]

Is timer EVENTS_COMPARE considered a HW event? In this case, there should be no difference in timings for low-power and constant-latency submodes, right? (judging from the table in your link)

RE: nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

Jørgen Holmefjord — Tue, 30 Jul 2024 14:44:34 GMT

Hi,

[quote user=""]I am using BLE, so I think the BLE functionality takes over the core from time to time, servicing its own interrupts or disabling interrupts, and this is what causes timing issues. Disabling BLE improved situation, but not much.[/quote]

Can you post the code you are using to configure and control TIMER+PPI+GPIOTE? If setup correctly, this should work fully without CPU intervention, apart from the time when you need to update the duty-cycle. BLE will affect interrupts, but TIMER+PPI+GPIOTE are pure HW peripherals that can work without interrupts.

[quote user=""]Since I am using BLE and that works fine, I assume HF crystal is used (switching to it helped in a similar case: RE: Jitter on Timer1+PPI+GPIOTE? ).[/quote]

HFXO is only enabled during radio operations when you are using BLE, it will not be enabled for all time you run the TIMER unless you explicitly enable this in the application (sd_clock_hfclk_request()). If HFXO is not started explicitly, the HFINT will be used as source for the TIMER, with an accuracy up to +/-8%. Note that keeping the HFXO on will have an impact on your current consumption.

[quote user=""]Could you advise on what could be the cause of this? Currently I suspect that the whole MCU goes to sleep and wakes up and this affects timer events timing, but I don't have enough knowledge to be sure.[/quote]

The time from HW event to PPI event should be only one 16MHz clock cycle (Device startup times).

Can you please share a logic trace of the output from the GPIO when this jitter occurs?

Best regards,
Jørgen