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]

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.

[Stian Røed Hafskjold]

Okay, seems like resetting the radio with the POWER register before you go to sleep is a good idea then. Are you able to send me any code so I can try to figure out what state the radio is in when it is draining current?

[butch]

This is after POR so the radio should be in a reset configuration and state. But let me test some more, I discovered another issue that might be the cause of my symptoms. In other words, once I fix that issue, I will try to reproduce whether clearing NRF_RADIO->POWER really has any effect.

[pbljung]

Hi Stian, I ran

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

and still measure 1.4mA current on our rigid-flex PCB. I measure the same idle current on multiple rigid-flex boards so it is a systemic problem.

I physically cut the flex to remove other circuitry to try to identify what part of the board was pulling current but the idle current does not change. The attached schematic contains the BLE module, regulator, charger, flash memory which uses 1.4mA in idle. Other GPIO goes to the now removed circuitry.

A solderless breadboard with the same components (but no Segger) measures 11.6uA in idle. Current for individual components in idle: BLE module 3.3uA, regulator 1.6uA, charger ~0, flash 8uA.

Our app and Nordic example apps run fine on the rigid-flex board, except that idle current is very high for all apps.