Low Power consumption for nRF52 series of devices

[ujur007]

I was looking for different power options for nRF52/53 series of devices and possible want more information on how to reduce power such that device can run for months on a battery.

There was one interesting thread which discuss this for nRF51 series of devices. But that one is quite old (over 9 years now). So can someone from Nordic guide on this how to reduce power consumption of the device and individual blocks of SoC?

https://devzone.nordicsemi.com/f/nordic-q-a/1657/how-to-minimize-current-consumption-for-ble-application-on-nrf51822

Note: I have selected some tags to address topic for power consumption discussion.

[ujur007]

538705.zephyr.hex

Hi, here is the hex file...

[Jared]

Hi,

Do you only use the GPIO peripheral? Do you use the BLE or any of the internal Timers/Clocks?

I flashed your fw to my nRF52840 DK and I measured about 2 µA during sleep:

I would say that this is acceptable and within the expected IDLE sleep current for the nRF52840,

regards

Jared

[ujur007]

Hi,

Thanks for posting that screenshot. Well, I intend to use GPIO 1&2 only.

Apart from that I use BLE just for advertising, That's why in that image there are two verticals lines nearly every 4 seconds or so.

I do not use timers/internal clocks. I use external 32.xx Khz clock.

Should usbd be disabled in the code when the upload is finished? Or it is taken care of by the interface MCU and the firmware itself?

Below is generated .dts file.

8206.zephyr.dts

If there are no more optimizations needed it is fine for now. I would accept it as you have already measured it using PPK.

[Jared]

ujur007 said:

Apart from that I use BLE just for advertising, That's why in that image there are two verticals lines nearly every 4 seconds or so.

Yes, this was exactly why I asked this question ;)

ujur007 said:

Should usbd be disabled in the code when the upload is finished? Or it is taken care of by the interface MCU and the firmware itself?

This should be taken care of the MCU itself, programming the chip should not "turn on" the USBD peripheral in the application. The chip will use the SWD pins for programming and debugging.

ujur007 said:

Below is generated .dts file.

8206.zephyr.dts

If there are no more optimizations needed it is fine for now. I would accept it as you have already measured it using PPK.

Great,

I think it looks ok,

regards

Jared