CPU clock speed nRF52840

[Nop Microwave]

Hello,

I have an application where I need to keep the 32 MHz running with its timer. What may be the best solution to get lowest CPU current consumption while in idle, i.e. just keeping running the 32 MHz and the timer

Is this possible to set the CPU at 1 MHz/ 4 MHz ?

Thanks,

Nop

[Einar Thorsrud]

Hi,

It is not possible to change the CPU frequency. However, the typical way to achieve low power on an nRF device is using the "race-to-Idle" strategy. That is why you will see that most example in the nRF5 call WFE one way or another in the main loop (often via some library or SoftDevice call), and why the idle thread in the nRF Connect SDK does the same.

If the CPU sleeps, it will not contribute to the current consumption. However, you wills till see a significant current consumption of your device if you need the high frequency clock and a timer running at all times, which it seems you do. May I ask why you need that? Do you strictly need that level of accuracy and resolution during sleep, or could you make do with an RTC to wake up at a certain point in time? If so, you could achieve a sleep current of a few micro amps.

[Nop Microwave]

Hi,

I am working on a radio stuff used to distribute very fine time stamp over a network. Thanks to the 16 MHz Radio peripherical clock, time stamp resolution is enough, but keeping the CPU at 64 MHz just to let the Timers running is not optimized for my use case.

Another solution may be to calibrate the external 32 KHz with the 32 MHz Quartz during syncrhonization phase and just before going into idle/sleep stage.

My concern is : how to be sure that during wakeup I can still get a coherent / synch between the Timer based on external 32 MHz only base on the external 32 KHz source ?

Thanks for your support

Nop

[Einar Thorsrud]

Hi,

I don't have the full picture of what you want to do, so I am not able to make very specific suggestions (also you know your use case much better). However, when it comes to what the nRF can do, the 32.768 kHz clock can be either based on an internal RC, which an be 500 ppm when calibrated against the 32 MHz crystal, or based on an external crystal. If the latter, the accuracy of the crystal dictates the accuracy. So if you for instance obtain a 10 ppm 32.768 kHz crystal, that should be all most as good as it gets.

Nop Microwave said:

My concern is : how to be sure that during wakeup I can still get a coherent / synch between the Timer based on external 32 MHz only base on the external 32 KHz source ?

From what you write it seems you want to calibrate a 32.768 kHz clock running of an external crystal based on the 32 MHz crystal. The nRF does not have any mechanism for doing that, so you would have to do this in SW (adding or subtracting ticks). And for that the CPU must run, so I would think you would need to wake up a bit early so that you know you have time, and let the CPU do the calibration calculations and wait for the time when you need to do work, and go back to sleep again, if you need this as accurately as possible, but still relying on the 32.768 kHz clock.I wonder if it is needed though? I don't know your requierment, but how high accuracy do you need? Could it be enough to use (say) a 10 ppm 32.768 kHz crystal and wake up based on that?

[Nop Microwave]

Dear,

I need ~or less < 1 PPM drift control, so keeping less than 1 us drift during 500 ms / 1 s (1 PPM per definition).

I will perform some test trying to calibrate 32.768 KHz Quartz (removing/adding ticks)  from 32 MHz Quartz, but time resolution for a 32.768 KHz is 30.517 us, which is to big. I will have to make some SW processing to manage this.

Thanks !

[Nop Microwave]

Dear,

Can you please provide more details on the way to add / substract ticks on both timer (the one running on the 32 MHz and the one running on the 32.768 KHz ?). I wonder if this SW process takes fixed CPU ticks, and what may be the lowest value to be added or substracted.

Thanks,

Nop

[Einar Thorsrud]

Hi Nop,

You can collect RTC ticks (based on the 32.768 kHz oscillator) and TIMER ticks (based on the 32 MHz oscillator). Further more, you can for instance use PPI with the fork mechanism to START or STOP both at the same time. Then, if you start, let it run for some time, then stop, you can calculate the expected ratio in ticks (based on the nominal frequency) and the actual difference in ticks (caused by the clocks not being perfect). With this you can compensate.

I am not sure how good ti will work in practice as the, at least not if the 32.768 kHz clock is based on the internal RC. If you use an external crystal the variation over temperature etc will be less, so that would make this better. We do not have any libraries for doing this, but there are examples on using PPI with TIMERS in the SDK that you can refer to (if using nRF Connect SDK you can look under modules/hal/nordic/nrfx/samples/src/nrfx_gppi/fork/main.c and if using nRF5 SDK, look under examples/peripheral/ppi)