1.4mA in sleep on custom board

[pbljung]

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();
    	}				
    }
}

[Stian Røed Hafskjold]

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?

[butch]

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.

[Stian Røed Hafskjold]

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

[butch]

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?

[Stian Røed Hafskjold]

The POR state for the radio is DISABLED. If you then start the radio it is important to disable the radio before going to sleep through the TASKS_DISABLE (the SoftDevice will handle this). This is however not the same as the POWER register, although you could use the POWER register to reset the radio peripheral. Despite its name, the POWER register does not "power" up anything on the radio peripheral, it is more like an enable function, if that makes sense. But please keep me updated on what you figure out, if you find something that contradicts what I'm saying we need to investigate that further.

You say something about VCC is climbing towards 3.6V. The maximum specified rise time (t_R_VDD, Chapter 7 in nRF51822 PS) is 100ms. If the rise time is greater than this the chip will end up in an undefined state.

[butch]

Yes, the radio state is distinct from the NRF_RADIO->POWER register. Yes, what you say about the NRF_RADIO->POWER seems to correspond to the solar beacon example code (using that register to reset the radio configuration. And my earlier statement was wrong, that code does NOT clear the bit before sleeping, but leaves it set permanently.) Re my reported symptoms after clearing the bit early in the boot sequence on the nrf52, I did not experience the same on the nrf51. Re Vcc rise time, my app is like the solar beacon, a load switch switches power to the nrf52 at 1.9V (with a quick rise time) but thereafter Vccswitched continues to rise slowly as the nrf52 sleeps and the solar cell provides current. Before I changed the code to clear the POWER bit early, something was draining the current. I definitely need to retest, but don't have an oscilloscope.