Power consumption of the nRF52832 (PCA10040 and custom board)

[jrg]

Hi,

We are troubleshooting high power consumption on a custom nRF52832 board. It has taken us down to just

1. Enable RTC,

2. Setup GPIOs,

3. With and without NRF_POWER->DCDCEN |= 1;

3. Go into a sleep loop (while(1) { __WFE(); __SEV(); __WFE(); }

Confirming the power consumption on a PCA10040 still keeps us in high 15 uA, with peaks up to 60 uA at ~40 Hz.

Also, not enabling the RTC and leaving all GPIOs in default states leaves us with these weird-looking spikes.

Running the same code on a custom nRF52811 leaves at a low 3-4 uA current consumption which is very expected.

We are testing with the current measurement probes on a DK10040, and are using SDK15.30 with armgcc.

int main(void)
{
	NRF_POWER->DCDCEN |= 1;
    while (1)
    {
        __WFE();
        __SEV();
        __WFE();
    }
}

Thanks

Johan

[Simonr]

Hi Johan

Do you see ~15uA on your custom board as well? How are the NFC pins configured now? As the product specification says, some increased leakage current between the two pins is to be expected if they are used in GPIO mode, and are driven to different logical values. To save power the two pins should always be set to the same logical value whenever entering one of the device power saving modes.

Can you try setting P0.09 and P0.10 back to NFC pins and see if the current consumption changes at all to confirm/dismiss this theory?

Best regards,

Simon

[jrg]

I will test again with the NFC-pins as configured to NFC pins and report back the current consumption.

For now they are both in the default setup - I believe this should be high impedance input so no current should flow between the pins.

Johan

[jrg]

Hi,

We've tested both with NFC as GPIO and as NFC

(CFLAGS += -DCONFIG_NFCT_PINS_AS_GPIOS)

Has there been any errata-fixes in newer SDK's since 15.3 that handles power consumption? Could you please share a good-working hex with us to flash the board and confirm low power consumption?

Johan

[jrg]

Hi,

The example-code has been tested with

SDK 17.1.0 and armgcc "GNU Arm Embedded Toolchain/9 2020-q2-update"

We still measure ~15uA power consumption with spikes at 60 uA at around 40 Hz.

Could you please provide us with a working firmware in sleep/WFE at ~2uA for us to continue to investigate?

Johan

[Simonr]

Hi again

After discussing this with a colleague here is some input. 

The spikes you see are expected. These are the refresh spikes from the auto controlled refresh mode that kicks in when the current consumption is low in order to maximize efficiency by charging up internal capacitors regularly to provide power to the chip. This happens every 25ms.

The floor current in your application seems to be ~14µA indicating some kind of leakage on VDD. Is the uploaded current consumption from the DK or the custom board? On a Development kit it's expected to see ~12µA in sleep mode if the device is powered from the USB, as there is some noise from the USB (see picture below).  The floor current between these smaller noise spikes are at ~2µA though. I can also take the time to set up with an external board supply if you need the numbers there as well, but we're in the middle of the summer "rush" where most of our support engineers are on summer vacation, so I'm very busy at the moment to be honest.

So our theory is that your custom board has a leakage on the VDD somewhere of ~15µA and since you see similar power consumption on the DK (with USB noise) you assume this is the case for both devices. We also have a blog post on optimizing power consumption on nRF52 designs if you haven't checked it out already. It's important to make sure that things like logging is disabled to achieve the lowest possible current consumption, etc.

What we'd like to do is a schematics and PCB layout review of your custom board to see if there is something that can explain the 15µA leakage current there.

Best regards,

Simon

Sleep current on a DK with USB noise:

BLE heart rate sample .hex file that advertises for 10 seconds and goes to sleep and accompanying SoftDevice:

4857.ble_app_hrs_pca10040_s132.hex6318.s132_nrf52_7.2.0_softdevice.hex