Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How slow can an nrf52 be clocked, to extend battery life?

How slow will an nrf52832 run, using an external crystal, for the purpose of extending battery life?  Or am I looking at the wrong processor?  I'm looking for a processor for a battery powered sensor project, we're hoping to get 2+ years from 4 AA lithium batteries.  The Bluetooth will only be used for configuration changes, but will be turned completely off 99.9% of the time, and I'm thinking we can use the internal oscillator to run at the full 64MHz during the times BT is required, then revert back to the slower external crystal when BT is off.  The processor will be sampling from the ADC between 240Hz and 1kHz, do some math on the readings then toggle a single output pin based on the values read.  The specifications say 58uA/MHz, but I didn't see the clock range specified.  Am I going about this all wrong?  Thanks in advance! 

  • There is no such thing as slow clocking this microcontroller nor most any that do radio communications. The clock is 32MHz (internally converted to 64 MHz) and must always be that way.  The 32MHz clock is used as the reference for the radio frequency and is required for any BLE or custom protocol radio comms.

    The way to save power is to run power manage (ie, sd_app_evt_wait(); ) when you call this API, all unused peripherals are shut down and the processor is essentially clocked off of the RTC. When an ISR or event happens the processor wakes up and initially runs off of HF_RC (lower power but woefully inaccurate 32MHz) then when HF_EXT is required the software turns it on.  You can also turn on HF_EXT manually if you require a high accuracy 32MHz clock.

    During power manage the whole thing draws about 1.6uAmps. The actual value heavily depends on your choice of RTC.  The internal RTC draws considerably more power.

    GPIO stays alive during power manage so don't litter your board with pull-ups/downs as some people foolishly do.   This is cmos an none of that junk is required. Only long runs of SPI or i2c might actually require a termination.  Even then these protocols are forgiving and often they aren't required.

    And certainly don't leave LED's on.

    Make it a point to read through the SDK docs and errata.  Not all peripherals are perfect and you may need to manually uninit stuff you are done with.

Related