1mA active mode troubleshooting

[loren]

Hi,

We have a rev3 nrf51822 system running S110 v7.3 and using SDK6.1.0. We are having trouble tracking down a ~1mA baseline current consumption when in system on/low power mode. Going to System Off mode reduces current to ~12uA. We can see with a scope that there is a ~1mA constant baseline otherwise.

We've looked at devzone.nordicsemi.com/.../ and various other posts, and it seems like something is keeping the internal RC HFCLK active (we can see on the scope that the external 16MHz xtal is only active during radio transmission.)

This is not a debugger-related issue as it persists after the debugger is disconnected and the system is power-cycled.

This problem happens with or without a bootloader, so it's not this problem.

We've tried disabling the various peripherals that are in use in our system but still have this 1mA baseline.

We have also run the HRM example (modified slightly for our board) and see reasonable current consumption (~200uA during connection).

How can we determine exactly what is keeping the clock running, if that is the problem? We've tried for example the method below, but none of the flags are set. Is there any way to determine for certain that the internal RC 16MHz clock is running?

Any help appreciated.

loren

#define PWR_REQ_UART 	(1<<0)
#define PWR_REQ_SPIS 	(1<<1)
#define PWR_REQ_SPI0	(1<<2)
#define PWR_REQ_SPI1	(1<<3)
#define PWR_REQ_TWI0	(1<<4)
#define PWR_REQ_TWI1	(1<<5)
#define PWR_REQ_GPIOTE	(1<<6)
#define PWR_REQ_ADC		(1<<7)
#define PWR_REQ_TIMER0	(1<<8)
#define PWR_REQ_TIMER1	(1<<9)
#define PWR_REQ_TIMER2	(1<<10)
#define PWR_REQ_TEMP	(1<<11)
#define PWR_REQ_RNG		(1<<12)
#define PWR_REQ_ECB		(1<<13)
#define PWR_REQ_QDEC	(1<<14)
#define PWR_REQ_CONSOLAT (1<<15)
/**
 * Check all possible sources that can keep the HFCLK active.
 * See Table 33 on pp. 48 of PSv3.1 for
 * list of peripherals that can request the clock.
 * \return flags indicating which sources are active
 */
uint32_t pwr_check(void)
{
	uint32_t pwr_reqs = 0;

	if (NRF_UART0->ENABLE)
		pwr_reqs |= PWR_REQ_UART;

	if (NRF_SPIS1->ENABLE)
		pwr_reqs |= PWR_REQ_SPIS;

	if (NRF_SPI0->ENABLE)
		pwr_reqs |= PWR_REQ_SPI0;

	if (NRF_SPI1->ENABLE)
		pwr_reqs |= PWR_REQ_SPI1;

	if (NRF_TWI0->ENABLE)
		pwr_reqs |= PWR_REQ_TWI0;

	if (NRF_TWI1->ENABLE)
		pwr_reqs |= PWR_REQ_TWI1;

	if (NRF_GPIOTE->TASKS_OUT[0])
		pwr_reqs |= PWR_REQ_GPIOTE;
	if (NRF_GPIOTE->TASKS_OUT[1])
		pwr_reqs |= PWR_REQ_GPIOTE;
	if (NRF_GPIOTE->TASKS_OUT[2])
		pwr_reqs |= PWR_REQ_GPIOTE;
	if (NRF_GPIOTE->TASKS_OUT[3])
		pwr_reqs |= PWR_REQ_GPIOTE;

	if (NRF_ADC->ENABLE)
		pwr_reqs |= PWR_REQ_ADC;

//	Can we check if the timers are running
	//PWR_REQ_TIMER0	
	//PWR_REQ_TIMER1	
	//PWR_REQ_TIMER2	

	// Temp is a one-shot, so probably not an issue, also not clear if we can read back
	//PWR_REQ_TEMP	

	// Unclear if there's a way to read the power states of these back?
	//PWR_REQ_RNG		
	//PWR_REQ_ECB

	if (NRF_QDEC->ENABLE)
		pwr_reqs |= PWR_REQ_QDEC;

	if (NRF_POWER->TASKS_LOWPWR)
		pwr_reqs |= PWR_REQ_CONSOLAT;

	return pwr_reqs;
}

[loren]

Also, we notice that the current in the system does drop down into the ~uA range every 1.4 seconds, for about 10ms. This time doesn't obviously correspond to anything in our firmware -- could this be something in the SD, or a clue to what's going on with our 1mA baseline?

[Ole Bauck]

Sounds like something is requiring the HFCLK, you can see which resources need it in the "block resource requirements" table in the Product Specification, part 8.3.

Task registers like NRF_POWER->TASK_LOWPWR are only used to set a task, so the register will be cleared after. Therefore there is no use in reading it. You can try with NRF_POWER->TASK_LOWPWR = 1 and see if the current consumption decreases.

What SDK peripherals are you using?

[loren]

Hi Ole,

Thanks for your quick response. We are using:

TWI, but we stop it (NRF_TWI1->ENABLE = 0;) after use. GPIOTE for app_button and waking up the system; ADC for infrequent periodic measurements, but we stop (NRF_ADC->TASKS_STOP = 1;) after each measurement PWM using nrf_pwm.c with the PAN73 workaround described here

We have also tried removing each of these from our firmware but still see the baseline.

We are also using: app_timer app_button app_fifo app_gpiote app_scheduler

loren

[Ole Bauck]

I guess you are disabling the pwm or else this would keep the timer running (which requires HFCLK). What clock source are you using in SOFTDEVICE_HANDLER_INIT()? What hardware are you running (PCA...)?

[loren]

Hi Ole,

We are using SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_100_PPM, true);

The hardware is custom, but the chip is rev 3 and we see the problem on both QFAA and QFAC parts.

We are disabling PWM when not in use, but because of the known issue with PWM we also went to the trouble of completely removing from the build, and still see the problem. It would really be nice if there was some way to programatically determine what is using the HFCLK resource.

Thanks again for your help.