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,

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

[jloliveira]

Dear Stian,

Any news regarding my previous message and new power consumption tests?

Thank you,

João

[Stian Røed Hafskjold]

Hi sorry for the late reply. I checked the current consumption and I can see that you have enabled the PWM. Unfortunately the PWM requires the HF clock to be running all the time, which gives about 0.5mA consumption in idle. Also, I still see the 1ms spikes. This adds up to about 750 uA in idle for both of the hex files you sent.

[jloliveira]

Hi Stian,

Thank you for your reply.

I guess the 1ms timer was still there due to a missing #define in the code that activates it in debug mode - I'll send you a corrected .hex as soon as I solve the PWM issue you refer to.

How come the PWM consumes 0.5mA in idle mode? I just use the PWM to ring a buzzer for 10secs when requested by the user via mobile-app. How should I make sure the PWM is only activated and consuming when the user requires to ring the buzzer, and is totally deactivated afterwards?

 Thank you,

João

[Stian Røed Hafskjold]

You need to call nrf_drv_pwm_uninit() when you're not using the pwm. Try this and see what happens.

[jloliveira]

Dear Stian,

Hope this message finds you well after so long.

The development of our peripheral app is finally finished (with the nrf_drv_pwm_uninit() taken into account) and successfully migrated to SDK15 and SoftDevice6.0.0, while also making use of NFC T4T with read/write capabilities.

Can you please test the final .hex in attachment and check if the current consumption is now at normal levels for both advertising and connection, considering a Tx Power of +4dBm for both?

Thank you,

João

joliveira-app_tx4dbm_pca10056_s140.hex

[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