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?

[Susheel Nuguru]

Can you please show me the code on how your trying to synchronize the LFCLK ? I see that this is a genuine problem on trying to get a better accuracy of the ticks than the XTAL for LFCLK can provide. But maybe just use CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH as lfclk source, if you have a dependency on HFCLK to calibrate the tick anyways. Let this calibration happen under the hood instead of your application trying to do it on the top level? This obviously will make HFCLK on most of the time, but seems like you are trying to do that anyways by your manual attempt to sync in your app. Try the solution provided here even though it is for the older SDK, it might be helpful.

[Kyrre Aalerud]

I can only find calibration in drivers for using the RC oscillator. The external LF Xtal does not alow calibration. Same goes for the external HF Xtal oscillator. I have tried using CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH and this breaks BLE communication. I do not know if this is due to timing or the stopping of HF clock in sleep modes. From what I understand Zephyr idle thread does this automatically.

Simply using PWM and outputting a reference clock did not work due to the difference between the two Xtal's and 1 tick change in rate was enough to go from positive to negative error meaning the drift would be too large. Since the samplerate is too high for the timer resolution I can not just timestamp the samples using the LFCLK to make this the timebase.

[Kyrre Aalerud]

XL1 and XL2 are technically on GPIO pins for nRF53 so I am wondering if there is a way to use for example pin-change interrupts (edge mode, low->high and high->low) without enameling actual software interrupt, and instead using PPI to trigger a "out high" and "out low" task. This would drive a pin at same frequency as the LFCLK and let me use this as a clock input for the sensor while avoiding external hardware with buffering if I were to tap the XL2 signal directly.

[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]

I am using a quite good LF XTAL but the external sensor uses a (rather poorly) calibrated internal oscillator unless I can feed it a better reference. When I tried using the SYNTH option BLE connections would fail to complete although unit was still discoverable.