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

[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,

Did you have the opportunity to check my previous message, and could you please check if the current consumption of the final .hex I sent is now at normal levels?

Thank you very much,

João

[Stian Røed Hafskjold]

Hello,

I measured around 1mA in idle. Seems like some pins are floating (drifting current), so I need the pinout info so I can terminate the floating inputs. A schematic or similar would be nice.

What is the expected idle current? Are you running PWM, UART or any other peripherals?

[jloliveira]

Hi Stian,

Thank you for your answer.

As pinouts from the board we are only using 1 Button input and 3 LEDs output (in our custom board associated with a driver that drives a piezo buzzer) that are turned off from start and used on request from a mobile app, through a characteristic. Please find the schematics below in attachment.

We are just using PWM also on demand to light up the LEDs - which is uninitialised when starting the peripheral and after lighting up the LEDs - and no other peripherals.

Could you guess what might be causing such 1mA in idle? You previously referred I had a timer being triggered every 1ms but currently there is none.

Thank you again for your help,

João

[jloliveira]

Hi again Stian,

After a lot of debugging I found the culprit was in the adc_configure() function that I copied from the ble_app_proximity example and which is consuming 500uA continuously. The same applies to the saadc example which makes use of the ADC.

Is it a bug or is there a way to turn of the ADC while we are not using it? In our example, we are using the ADC to read the battery level every 8hours.

Looking forward to your reply,

Thank you,

João

[Stian Røed Hafskjold]

Hi, there is a low power mode in the saadc driver. Please check out this: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/hardware_driver_saadc.html?cp=4_0_0_2_0_12_1_1#saadc_nonblocking

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/group__nrf__drv__saadc__config.html?cp=4_0_0_6_9_0_19_0_0_1#ga7e7da65888f2c0169a53fbf379c1e79c

[jloliveira]

Hi Stian,

We tried to consider the LP mode saadc and it seems to indeed decrease the power consumption to normal levels.

Yet, we also tried in Normal ADC mode to initialize the adc before requesting a nrf_drv_saadc_sample and unintialized it after the saadc_event_handler is called and the power consumption also stays at normal levels. Both "always-on LP ADC" mode or "turn_on-read-turn_off Normal ADC" mode seem to retrieve the same voltage measurements.

Are both methods OK to use or would one be more precise than the other?

Thank you,

João