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

[jhennrich]

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.

[jhennrich]

To further investigate the problem I wanted to see if the current drain is constant over time or consists of short bursts. For that I measured the current of the minimal example with a scope. I do not have current probes, so I put a 10 Ohm resistor in series to the battery and measured with regular scope probes across the resistor (so in the scope 10mV correspond to 1mA current drain).

For the first three test cases from my original post (1. "while(true) {}", 2. while(true)  {__WFE(); }" and 3. "NRF_POWER->SYSTEMOFF=1; while(true) {}" the scope looks the same:

In the scope it looks like the current draw is very constant.

[hmolesworth]

Flash, Mag, pressure and accelerometer /CS signals i/o drive pins must all be configured as outputs and driven high since there are no pull-ups on the board. Without setting the pins they float, and although some SPI devices may have internal pull-ups on /CS most do not. Try and see if that makes a difference .. most likely the flash which always takes most current (/CS can float low if not driven):

"When /CS is brought low, the device will be selected, power consumption will increase to active levels"

The is a further issue with /CS on the flash, it must track rising VCC at first power-on: "The /CS input must track the VCC supply level at power-up and power-down (see “Write Protection” and figure 43). If needed a pull-up resister on /CS can be used to accomplish this."

On first power-on the nRF52 pins are floating and not driven; parasitic and pin capacitive loading will hold the /CS pin low so this should be considered a design flaw on the board.

[Stian Røed Hafskjold]

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 hmolesworth mentions, they will probably be in a undefined state, consuming a lot of current if the output from nRF52 is floating.

[jhennrich]

Thanks, that fixed it! I configured all /CS as output high and the overall current drain decreased to 11uA. That is already low enough for me, but when I have time I will do some calculations what all ICs in standby, the external voltage regulator and the voltage dividers *should* drain.

Another small mistake I made (just in case someone else reads this and has the same problem) at first was setting the /CS to output/high right after sending the standby command (via SPI) to the accelerometer. A nrf_delay_ms(1) between those commands solved the issue.

Lastly: setting for example the GPIOs connected to the LEDs to output/high or input/disconnected should make no difference I guess? In both cases there should be no current flowing...