nRF52810 Timer+PPI+GPIOTE pulsewidth jitter of couple microseconds

[Positron]

Hi. I am trying to control a RC servo with a nRF52810 MCU (in short, a servo needs pulses in range of 1000-2000us once every 20ms to move to specific position. Minimal change in pulse width for servo to move is around 5-10us). At first I configured a 1MHz Timer1 and a CC interrupt to fire at required intervals, and controlled a GPIO in an interrupt. However I noticed that the servo jitters when controlled with this scheme. I've measured the signal with an oscilloscope and saw occasional pulse width changes of ~10us, which causes the servo to jitter. This happens irregularly with couple seconds intervals. My project runs on a small battery, so servo moving when it should be idle will negatively affect battery life.

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.

Then I decided to move to Timer1+PPI+GPIOTE and forgo timer core interrupts altogether, so that the interrupts will not corrupt my waveform. Surprisingly and unfortunately, this did not remove the problem completely and the jitter still presents itself from time to time, in range of couple microseconds, that still causes servo to jitter.

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? ).

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.

PS The jitter doesn't happen if I use a cheap chinese servo tester instead of an MCU, so the problem is in the MCU, not the servo.

PPS I would like to not use PWM component, as it is taken by other tasks..

[Jørgen Holmefjord]

Hi,

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.

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.

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? ).

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.

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.

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

[Positron]

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

Jørgen Holmefjord said:

The time from HW event to PPI event should be only one 16MHz clock cycle

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)