This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High current consumption (2mA) in SystemOn and SystemOff Sleep (SDK16, no Softdevice) with some other peripherals.

There are aready quite a lot topics about high current consumption in sleep mode, but none really seems to fit out problem:

We have a small board with a nRF52832 (actually a https://www.yuden.co.jp/or/product/category/module/EYSHCNZXZ.html) and some simple peripherals which we bought with a preinstalled firmware. With this firmware the 60mAh battery (via external linear 3v voltage regulator) lasts more than a week in advertising mode. We are currently developing a custom firmware for that board based on SDK 16 with Segger SES. We do not use a softdevice and only do basic stuff (sample SPI sensor, LEDs, switches, control MOSFET). We have a pushbutton that is programmed to put the device in sleep mode and wakes it up again with another press.

When we device is put into sleep mode (SYSTEMOFF) it still draws around 2mA of current. To investigate the problem we built a minimal example based on the "Blinky" example that only does the following:

#include "boards.h"

int main(void) {
    NRF_POWER->SYSTEMOFF = 1;

    while (true) {
    }
}


but the high current drain remains. No Logs are enabled in sdk_config.h and we changed the preprocessor symbol for the board definition to "BOARD_CUSTOM" (custom_board.h is empty).

We changed the code in the main function a little and measured the following currents (Release builds, SES -> Built and Run, measured with Multimeter in series to battery):

1. Only an empty "while(true) {}" loop: still connected to debgger: 7.57mA, after removing board debugger and reapplying power: 2.22mA

2. System-On Sleep: "while(true) { __WFE() }": 2.06mA, after removing debugger: 2.22mA

3. System-Off: "NRF_POWER->SYSTEMOFF=1; while(true) {}": 2.06mA, after removing debugger: 2.22mA

4. After erasing the chip (nrfjprog --eraseall): 4.62mA, after removing debugger: 6.22mA

Unfortunately we do not have a nRF52 DK yet, so we could not try the same code on a DK. We have a nRF51 DK though (pca10028) and I built the same minimal example based on the Blinky example from SDK 12.30 (using Keil) and there the current consumption is fine (few microamps).

For me there are only a few possible explanations:

1. GPIO configuration during SYSTEMOFF: Maybe something else on the board is drawing a lot of power: With the original firmware the power consumption is fine and I took a look at all the SPI/I2C ICs on the board: when not explicitely activated they all are in standby mode drawing only microamps. Do the nRFs GPIOs connected to other parts have to be configured in a specific way before SYSTEMOFF is initiated? E.g.:

- Pins that are used for SPI / I2C

- GPIO/ADC for battery voltage measuring through voltage divider (14MOhm, so the voltage divider itself is not drawing much current)

- GPIOs connected to LEDs (GPIO -> Resistor -> LED -> GND)

Here is the schematic of the board: https://mbientlab.com/community/uploads/editor/f6/3zbfr2s08vsb.pdf

2. Maybe we have some incorrect configurations / preprocessor definitions / etc. but I guess then the minimal exampled based on blinky should have worked.

3. Possible bug in SDK 16 or perhaps something that was changed in 16 and was not updated in the examples?

Any ideas appreciated what the problem could be or how we could debug the problem.

Parents
  • Hi, the system OFF code you posted will "per definition" consume less than 1 uA.The default reset configuration for GPIOs are 0x2 (input, disconnected buffer), which means that they will not drive any external devices, hence no leakage current. The only leakage sources are pullups/down on SWD, and pull up on nRESET, so if the debugger is disconnected you should be fine. However, If the external devices require non-floating inputs, especially on CS, as mentions, they will probably be in a undefined state, consuming a lot of current if the output from nRF52 is floating.

Reply
  • Hi, the system OFF code you posted will "per definition" consume less than 1 uA.The default reset configuration for GPIOs are 0x2 (input, disconnected buffer), which means that they will not drive any external devices, hence no leakage current. The only leakage sources are pullups/down on SWD, and pull up on nRESET, so if the debugger is disconnected you should be fine. However, If the external devices require non-floating inputs, especially on CS, as mentions, they will probably be in a undefined state, consuming a lot of current if the output from nRF52 is floating.

Children
No Data
Related