Accuracy issue between k_uptime_ticks() and hardware pwm outputs

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Thu, 09 Jan 2025 14:19:48 GMT

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.

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Simonr — Thu, 09 Jan 2025 14:15:06 GMT

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

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Thu, 09 Jan 2025 08:08:34 GMT

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!

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Wed, 08 Jan 2025 15:16:26 GMT

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?

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Fri, 20 Dec 2024 10:43:51 GMT

In case anyone else reads this with the same problem, yes it was possible!

Using a GPIOTE task channel, and assigning it's SET task address together with a timers START task address in a DPPI channel (this is nrf5340 so DPPI not PPI) with the RTC TICK event address allows for setting a pin for every clock tick, and starting the timer at same time.

Then connecting the timers COMPARE event to a second DPPI channel to the same GPIOTE task channel CLR task allows for clearing pin after a suitable half period that can be accurate enough for this use.

Finally the SHORT in the timer must be set to RESET timer and STOP timer upon COMPARE.

This all results in reproducing the LFCLK coming from the LF XTAL on a pin so external sensors can use this as reference and the internal RTC and systick now matches any external exactly. This completely eliminates clock drift between sensor and internal timekeeping in Zephyr.

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Wed, 18 Dec 2024 13:19:20 GMT

This would probably create an event only every tick which is once every clock cycle, and thus toggle would cause it to output at half frequency. I guess it could be possible to trigger a one shot timer based on same event and instead use SET task with the timer expiring and triggering a CLR task? The duty cycle would be close enough by using a fixed on time of approx half the cycle length.

This is getting complicated but is it possible?

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Wed, 18 Dec 2024 12:15:30 GMT

The RTC (that runs off the LFCLK) appear to have a EVENTS_TICK for when counter is incremented. Could this serve as a source for PPI?

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Wed, 18 Dec 2024 12:06:41 GMT

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.

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Simonr — Wed, 18 Dec 2024 12:03:00 GMT

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

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Mon, 16 Dec 2024 13:46:43 GMT

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.

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Kyrre Aalerud — Mon, 16 Dec 2024 13:06:03 GMT

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.

RE: Accuracy issue between k_uptime_ticks() and hardware pwm outputs

Susheel Nuguru — Mon, 16 Dec 2024 13:00:31 GMT

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.