Accuracy issue between k_uptime_ticks() and hardware pwm outputs

[Kyrre Aalerud]

Running into a slight issue where the timebase for system (reference time + uptime aka k_uptime_ticks()) drifts relative to sensor sampling rates.
Attempt to synchronize the timebases by using nRF53 pwm system to output clock for external sensors still drifts as the timebase for pwm appears to be HFCLK based of HF XTAL while system ticks come from LFCLK based of LF XTAL.

What is the recommended method to synchronize these while keeping power consumption low?
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH may be an option but how will this impact power consumption, and will it prevent sleep?

[Simonr]

Hi

Using the pins for XL1 and XL2 as both GPIOs and clock pins won't be possible as far as I'm aware. How low do you require to keep the power consumption exactly? This will be a trade-off between the need for accuracy versus the need for low power consumption I think. Using the K32SRC_SYNTH source as the LF clock source will definitely be the most accurate way, but it will also keep the HF clock on when using the LF clock, so it will affect the power consumption quite a bit. Using a more accurate LF XTAL could also be an option, if you find a "high-end" 32.768kHz crystal for your design with a lower PPM drift that might be an idea to keep it accurate but also at low power.

Best regards,

Simon

[Kyrre Aalerud]

One question... It appears my "hack" has a side effect of keeping Zephyr from sleeping.
I believe Zephyr uses RTC1 for some of it's scheduling, and it appears to use the WFE instruction for sleeping.
I have not found any way to avoid waking from the TICK event on RTC0 even though the reason for enabling it is only to generate events for the DPPI system. Is there no disabling this effect?

[Kyrre Aalerud]

I think I have narrowed it down to the TIMER that is started by the event and stopped by it's own COMPARE. Configuring the timer appears to enable the interrupts for the timer by default in nrfx.

Edit: After digging some more I found a stray nrfx_gpiote_trigger_enable() which basically meant enabling input trigger for the output pin. Every time it changed state this would wake the CPU leading to my excessive power draw!

[Simonr]

I see, that sounds like a probable root cause, indeed. I hope taking care of this stray function call let you get down to the expected current consumption numbers again. If not, let me know, and I will take another look.

Best regards,

Simon

[Kyrre Aalerud]

I can confirm with the PPKII that the power consumption is back to expected level and the hack using 1 timer and RTC0 with the DPPI system did not increase consumption much at all.

Zephyr appears to use RTC1 however and ideally one would just want to use a tick event from that instead of enabling an extra RTC. I tried this and it appears to either throw off Zephyr task scheduling or confuse it. I assume this is because Zephyr does not expect anyone to change anything on it's RTC and I believe it must be stopped in order to do so as well.
Since there was not any noticeable extra draw I think this is ok.