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

1.4mA in sleep on custom board

We have a custom board using the ISP130301 BLE module (containing a nRF51822, 16MHz xtal, 32kHz xtal). Our apps work fine (gcc, SDK6, S110v7) except for high system on idle power. We are measuring about 1.4mA in sleep using a variation of the system_on_wakeup_on_gpio (Keil5, SDK10, no softdevice) with peripherals disabled. We suspect that the board is still in debug mode but cannot get into a lower power mode.

We've read many threads regarding this but haven't been able to resolve it.

We use a Segger jlink connected to TC2030 pads on the board. We disconnect power, disconnect the TC2030 probe, and reapply power (which should put the board in normal mode), press the button (which turns off LED and CPU) and measure 1.4mA. We tied SWDCLK to GND and reapply power but no change in current measurements. We tried "nrfjprog --pinreset" with no change.

All other peripherals (memory, charger, regulator, switches, LEDs) are off or disabled. All other GPIO are floating. We've measured the enabled (mA) and disabled current (uA) of each individual peripheral on breadboards. Any ideas on how to get to low power in system on idle?

We use a Fluke 189 to measure mA and uA currents across the power leads which works fine on the pca10028. This can sample 250us events to capture both max current during connection events and min current during idle.

#include <stdbool.h>
#include <stdint.h>
#include "nrf_gpio.h"

#define CS 1

int main(void)
{	
	// pin 23 LED exists on pca10028 & LSLF1
	nrf_gpio_cfg_output(23);
	nrf_gpio_pin_clear(23); // LED on
	
	#if CS
	// U8 memory /CS
	nrf_gpio_cfg_output(12);
	nrf_gpio_pin_set(12); // memory disabled, expect 8uA
	#endif
	
	// Configure button
	nrf_gpio_cfg_input(17, NRF_GPIO_PIN_PULLUP);

    while (true)
    {	
	    	if (nrf_gpio_pin_read(17) == 0) { // pressed?
		    	nrf_gpio_pin_set(23); // LED off
					
		    	// system on idle
		    	 __WFE(); __SEV(); __WFE();
    	}				
    }
}
  • I have similar issue on nrf52. Just some ideas: are you sure you sleep (you could turn on led after the sleep?) Someone might know what peripheral that current corresponds to. Have you discharged the bypass caps when unpowering to reset? Do any of the errata apply? Can you assert(peripherals off) just before you sleep? Maybe cut all traces to your external peripherals? Try another module instance? I empathize, its a hard problem to debug.

  • I doubt that it is debug mode if you tie SWDCLK to ground and reset. Make sure that the chip is reset completely, i.e. that no decoupling caps keeps it on. Could you try to run just the following code to see if that changes anything?

    int main(void){
        for(;;) __WFE();
    }
    

    Or even System OFF:

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

    If I understand you correctly the current consumption seems fine on the pca10028, so then I would guess that it is some issues with any of the external components on your custom board. Could you please post the schematic so we can have a look?

  • I just discovered that the radio is powered on after POR reset on both the 51 and 52. I always assumed most bits were reset to 0, but the docs show NRF_RADIO->POWER bit 0 resets to 1, i.e. power enabled to the radio. I haven't examined the docs re the idle current of the radio.

  • Did you see any difference in current consumption? The POWER register set to 1 shouldn't have an impact on this.

  • It seemed to make a difference if I cleared that bit the first thing in main. My power supply is ultra low, i.e. solar and a capacitor. Before, Vcc stopped climbing at say 2V (not as designed) and after Vcc climbed towards 3.6V (as designed.) But I not certain yet. I looked in the Nordic docs for power consumption for the condition: radio is enabled and not active (RX or TX), but I could not find any spec, just something like "doesn't consume much". I also read the source for the Nordic solar beacon on GitHub, and the code does disable the radio before sleeping (but not first thing in main boot sequence.) Surely it is important for power saving to disable the radio using that register?

Related