High Power Consumption on Custom nRF52811 Board (~4mA vs 17µA on DK)

RE: High Power Consumption on Custom nRF52811 Board (~4mA vs 17µA on DK)

Simonr — Thu, 06 Nov 2025 12:20:55 GMT

What SDK version are you working on here? As long as your project is not using a SoftDevice the NRF_POWER->SYSTEMOFF = 1; should power off the nRF52811 correctly if that's the only thing you want to test.

If the same project draws down in the micro amps on a DK but not on the custom board. You likely have the correct GPIO settings, and that points to this being a HW issue.

I think the first step should be to do a HW review. We can help you with that if you'd like. If you upload the schematics as a .pdf and HW layout as gerber files we can review it and see if something obvious seems off here.

Best regards,

Simon

RE: High Power Consumption on Custom nRF52811 Board (~4mA vs 17µA on DK)

Purvesh patel — Wed, 05 Nov 2025 12:50:38 GMT

Hi Simon,

Thank you for the quick response and suggestions!

Testing System OFF Mode

To isolate whether this is a hardware or firmware/configuration issue, is there a way to force the nRF52811 into System OFF mode to achieve absolute minimum current consumption? This would help determine if:

Hardware issue: Current remains high (~3-4mA) even in deepest sleep → PCB/layout problem
Configuration issue: Current drops significantly → Something in firmware keeping chip awake

I tried using this code to disable everything and force sleep, but I'm still seeing the same ~3.66mA consumption:

// UART
NRF_UART0->ENABLE = 0;

// SPI/SPIM
NRF_SPI0->ENABLE = 0;
NRF_SPIM0->ENABLE = 0;
NRF_SPIM1->ENABLE = 0;

// TWI/TWIM
NRF_TWI0->ENABLE = 0;
NRF_TWIM0->ENABLE = 0;

// Timers - CRITICAL for removing periodic wakeups
NRF_TIMER0->TASKS_STOP = 1;
NRF_TIMER0->TASKS_SHUTDOWN = 1;
NRF_TIMER1->TASKS_STOP = 1;
NRF_TIMER1->TASKS_SHUTDOWN = 1;
NRF_TIMER2->TASKS_STOP = 1;
NRF_TIMER2->TASKS_SHUTDOWN = 1;

// RTC
NRF_RTC0->TASKS_STOP = 1;
NRF_RTC1->TASKS_STOP = 1;

// GPIOTE
NRF_GPIOTE->INTENCLR = 0xFFFFFFFF;
for (int i = 0; i < 8; i++) {
    NRF_GPIOTE->CONFIG[i] = 0;
}

// Other peripherals
NRF_SAADC->ENABLE = 0;
NRF_PWM0->ENABLE = 0;
NRF_COMP->ENABLE = 0;
NRF_RADIO->POWER = 0;

// Stop clocks
NRF_CLOCK->TASKS_LFCLKSTOP = 1;
NRF_CLOCK->TASKS_HFCLKSTOP = 1;

// Disable DC/DC
NRF_POWER->DCDCEN = 0;
__disable_irq();
NVIC->ICPR[0] = 0xFFFFFFFF;

nrf_delay_ms(100);

// Sleep with WFE
while(1) {
    __WFE();
}

Result: Still seeing ~3.66mA, no change from normal operation.

Questions

How can I properly disable all GPIOs? Should I configure them as:
- Input with pulldown?
- Disconnected input buffer?
- Something else for nRF52811 specifically?
Is there a recommended test sequence to enter absolute minimum power state (System OFF)?
Should I try entering System OFF mode directly using NRF_POWER->SYSTEMOFF = 1; to see the absolute floor current consumption?

edit:- on trying this code
int main(void){
NRF_POWER->SYSTEMOFF = 1;
for(;;){}
}
in ble_blinky example i got this

RE: High Power Consumption on Custom nRF52811 Board (~4mA vs 17µA on DK)

Simonr — Wed, 05 Nov 2025 12:21:38 GMT

1. From the current consumption it seems that the floor current is ~3mA, which means that either the nRF52811 doesn't go to sleep correctly, or there is something else on the board that draws this excess current.

2. Most likely a PCB layout issue. Leakage current or some other chip drawing power.

3. No, except removing the inductors and capacitor from the DCC pin there should be no HW changes necessary.

4. I think the first step should be to do a HW review. We can help you with that if you'd like. If you update the schematics as a .pdf and HW layout as gerber files we can review it and see if something obvious seems off here. Are there for example any other chips/MCUs on your board that might be drawing current?

The next thing if we can't find anything in the HW files would be to debug the custom board physically and try to find out where this current disappears to. That would mainly be done with a multimeter of sorts while the device is running in what should be a low power mode and checking from which pin/decoupling cap the current escapes to.

Do you see the same behavior on more than one board or have you only tested on one specific custom board? Making sure it's reproducible on more than one board is a good way to see if this is just not a soldering issue.

Best regards,

Simon