High Current Consumption with nRF52840 DK

[jloliveira]

Dear Madam/Sir,

I'm measuring the nRF52840 DK current consumption with my custom ble_peripheral app and other example ble_peripheral apps, namely ble_app_proximity, ble_app_pwr_profiling, and I'm registering in my ampere meter some continuous 0.800mA while advertising/in connection in both example apps (with the default parameters) and 0.200mA in my app. I'm powering the DK with a power supply set at 3.0V. My app is running in DC/DC with the advertise interval set to 2.25s and the connection interval set to 1s, and TX Power set to +9dBm. I also checked my app running on a oscilloscope and the connection/advertise TX peaks measure 14-15mA instead of the supposed 13.6mA.

The nRF Power Source switch is set to VDD, and I attempted both options on the nRF Only / Default switch. When setting the VEXT->nRF ON the consumption even increases.

In all three apps I commented all LOGGING related calls and all LEDs are turned off. I also tried running the DK on all three apps with the CR2032 battery but the current consumption is kept nearly the same. Do I need to also disable the NRF_LOG_ENABLED define in sdk_config.h to make sure it is turned off?

Is there a way to guarantee, through Firmware and/or Hardware, that no pinouts are enabled and causing the high consumption? Is there anything else that may justify such high consumption and that I should take special attention?

Thank you for your help,

João

[Stian Røed Hafskjold]

Hi, most likely the current you are seeing is because of logging. The best way to disable this is to set  NRF_LOG_ENABLED to 0 in sdk_config.h. You should leave all the logging related calls in the code as they are originally, setting NRF_LOG_ENABLED to 0 is sufficient to completely disable logging.

When using the VEXT->nRF switch the current bypasses the debugging chip (and everything else on the DK) and goes directly from P21 (external supply) to nRF. Because of this you need to keep the main USB cable connected in order to power the rest of the components on the chip. Otherwise you get higher current draw.

If you want you can post your hex file here and then I can do measurements for you.

Regarding the radio TX peak current. You mean +8dBm right? From the PS:

ITX,PLUS8dBM,DCDC

TX only run current (DCDC, 3V) PRF =+8 dBm

14.1

mA

Also, this current is without HFCLK and DMA current. So you should add another 0.8mA to this. The current consumption scenarios chapter in the PS is supposed to cover this, but it does not include +8dBm yet unfortunately. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/pmu.html#unique_1132745023

[jloliveira]

Dear Stian,

Thank you for your help.

Regarding the Logging, I didn't know setting NRF_LOG_ENABLED to 0 would be enough to totally disable Logging. Yet, I have a define that unconsiders all Logging calls, thus it shouldn't consume. I don't have access to the measuring instruments right now, so I just set NRF_LOG_ENABLED to 0 and send you the hex file in attachment for your measurements - thank you very much for it. If possible, please provide me the measurements in advertise and connection modes.

But is there any ble_peripheral example that is optimized for low consumption, running DC/DC, and that I should consider for comparison? I also send you in attachment the hex of the original ble_app_pwr_profiling with NRF_LOG_ENABLE set to 0 for your measurements (have to press button1 for it to start).

Regarding the TX peak current, although the infocenter reports 14.1mA at +8dBm, the PS pdf in page 286 states that it consumes 13.6mA at +9dBm, both DC/DC at 3V. Why the difference?

And is HFCLK and DMA 0.8mA current drain supposed to occur persistently during run-time or only during radio events? Is there a way to turn them off?

jloliveira-app_pca10056_s140.hexble_app_pwr_profiling_pca10056_s140.hex

Thank you,

João

[jloliveira]

Dear Stian,

Any news regarding my previous message and questions?

Thank you,

João

[Stian Røed Hafskjold]

NRF_LOG_ENABLED = 0 also ensures that the UART peripheral is not turned on, which is the reason for the current consumption. Not the logging data itself. So it might not be enough to only avoid logging calls. But I'm not sure how you did it, so maybe it works. Anyways, in the hex files you sent, logging seems to be properly turned off. So I'm attaching plots from the measurements below

From what I can see you have a timer which wakes up the chip every 1ms. This leads to an additional 140 uA in idle (between BLE events)

During advertising (2.25s interval) average current is 151 uA:

In connection I see that you continue to advertise every 4 seconds, and connection interval is about 1.16 s? Average current is 148 uA:

To compare with the pwr_profiling application you sent. You can see that the idle current is a lot lower:

A good idea would be to increase the timer wakeup interval. You should be able to get the idle current down a lot by increasing the interval.

Last plot is the pwr_profiling hex you sent with log disabled. You can use this as a reference for your measurements. As far as I know all the examples in the SDK has logging enabled by default.

Regarding the radio current in the PS v0.5 pdf, this is an old version of the PS, the newest is now 0.5.1. The numbers are expected to change because this is still an alpha release of the documentation.

HFCLK and DMA are only running when requested by peripherals (unless you manually start the HF crystal). The radio needs HFCLK and DMA, hence they are requested, and can not be turned off during radio activity. After the BLE event they will be turned off and therefore will not have an impact on idle current.

[jloliveira]

Dear Stian,

Thank you very much for your clarification and tests.

I found the culprit for the 1ms timer you reported, cleaned the whole code and migrated the app to SDK15 and Softdevice6.0.0, with TX_Power +8dB/+4dBm and NRF_LOG_ENABLE = 0, but now also using the PWM Driver, which is initialised in the beginning but only operated via characteristic commands to control the LEDs.

Can you please retest the .hex file in attachment in advertise and connection modes, with TX_Power +8dBm and TX_Power +4dBm, to check the overall current consumption and if there are still means to decrease it?

Thank you,

João

jloliveira-app_tx8dbm_pca10056_s140.hex

jloliveira-app_tx4dbm_pca10056_s140.hex