nRF: deep sleep increases power usage

[mrdalgaard]

CircuitPython version

Adafruit CircuitPython 7.0.0-rc.1 on 2021-09-02; Adafruit Feather nRF52840 Express with nRF52840

Code/REPL

import time, alarm
time.sleep(15)
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 15)
alarm.exit_and_deep_sleep_until_alarms(time_alarm)

Behavior

After startup my cheap multimeter measures around 0.5mA for the first 15 seconds, and over twice that for the last 15 seconds (in deep sleep)
Light sleep and time.sleep has the same consumption, but deep sleep having a larger consumption is unexpected.

Description

Easy workaround is to use

time.sleep(15)
import supervisor
supervisor.reload()

Instead of deep sleep, but deep sleep should be able to get the same consumption as light sleep.

Additional information

Same issue is present when using pin alarms instead

[hiredman]

I've recently run into this as well. Thought I would get my act together and use deepsleep, and it would give me a nice battery life boost in some ItsyBitsy nRF52840 Express based projects. Then I saw this report and ran some experiments. I get 1.5x to 2x the battery life just using time.sleep+supervisor.reload vs alarm.exit_and_deep_sleep_until_alarms.

I poked around a little looking at https://github.com/adafruit/circuitpython/tree/main/ports/nrf but have no idea where to start. A real bummer that deepsleep doesn't seem to be working correctly.

I'm now adding a 555 timer to those projects to cut power for some amount of time.

[tannewt]

This is what implements deep sleep:

circuitpython/ports/nrf/common-hal/alarm/__init__.c

Lines 263 to 284 in 488dca5

	void NORETURN common_hal_alarm_enter_deep_sleep(void) {
	alarm_pin_pinalarm_prepare_for_deep_sleep();
	alarm_time_timealarm_prepare_for_deep_sleep();
	#ifdef NRF_DEBUG_PRINT
	mp_printf(&mp_plat_print, "\r\ndeep sleep...");
	#endif
	int64_t timediff_ms = alarm_time_timealarm_get_wakeup_timediff_ms();
	tick_set_prescaler(PRESCALER_VALUE_IN_DEEP_SLEEP - 1);
	system_on_idle_until_alarm(timediff_ms, false, PRESCALER_VALUE_IN_DEEP_SLEEP);
	#ifdef NRF_DEBUG_PRINT
	mp_printf(&mp_plat_print, "RESET...\r\n\r\n");
	#endif
	reset_cpu();
	// should not reach here..
	while (1) {
	;
	}
	}

That file also includes light sleep.

[hiredman]

wild guess:

circuitpython/ports/nrf/supervisor/port.c

Lines 356 to 397 in 488dca5

	void port_idle_until_interrupt(void) {
	#if defined(MICROPY_QSPI_CS)
	qspi_disable();
	#endif
	// Clear the FPU interrupt because it can prevent us from sleeping.
	if (NVIC_GetPendingIRQ(FPU_IRQn)) {
	__set_FPSCR(__get_FPSCR() & ~(0x9f));
	(void)__get_FPSCR();
	NVIC_ClearPendingIRQ(FPU_IRQn);
	}
	uint8_t sd_enabled;
	sd_softdevice_is_enabled(&sd_enabled);
	if (sd_enabled) {
	if (!background_callback_pending()) {
	sd_app_evt_wait();
	}
	} else {
	// Call wait for interrupt ourselves if the SD isn't enabled.
	// Note that `wfi` should be called with interrupts disabled,
	// to ensure that the queue is properly drained. The `wfi`
	// instruction will returned as long as an interrupt is
	// available, even though the actual handler won't fire until
	// we re-enable interrupts.
	//
	// We do not use common_hal_mcu_disable_interrupts here because
	// we truly require that interrupts be disabled, while
	// common_hal_mcu_disable_interrupts actually just masks the
	// interrupts that are not required to allow the softdevice to
	// function (whether or not SD is enabled)
	int nested = __get_PRIMASK();
	__disable_irq();
	if (!background_callback_pending()) {
	__DSB();
	__WFI();
	}
	if (!nested) {
	__enable_irq();
	}
	}
	}

appears to skip sleeping if there are any background callbacks, and I don't see anything in the loop here

circuitpython/ports/nrf/common-hal/alarm/__init__.c

Line 182 in 488dca5

while (1) {

that immediately looks like it is processing background callbacks.
So maybe there is a background callback (dunno anything about cp internals and what those are or how they are used or if I can check for the presence of them from python), so it just spins in an a C loop until the timeout has elapsed instead of entering the deep sleep.

[tannewt]

RUN_BACKGROUND_TASKS; should process the background callbacks.

[hiredman]

yeah, missed that scanning for stuff followed by parens.

I wonder if it is softdevice related (which I guess is the radio?), if the softdevice is enabled it looks like it doesn't go into deepsleep, but instead waits for events from the sd

[furbrain]

I've had a play and tried turning off the softdevice - _bleio.adapter.enabled = False. This doesn't have any effect on current consumption - still about 2.0 mA on my setup

[furbrain]

I can confirm that I get about 0.9 mA when just doing a simple timed sleep -

I'm guessing the reason why true deep sleep isn't used is due to needing a possible timed wake up. And SYSTEM OFF doesn't have any timers. Is there any reason why we couldn't use SYSTEM OFF if there were no timers?

[hiredman]

Oh fun, when I do bleio.adapter.enabled = False in the repl running on the device, nothing happens. if I ctrl-d to exit the repl the device does a hard reset (serial port device disappears, lights blink, serial port device reappears). If I do the enabled=False in code.py without the repl, instant hard reset, and sometimes the device ends up in safe mode.

[furbrain]

@hiredman I don't suppose you are connecting to the REPL via bluetooth?

I've tried using uctypes to "manually" set up a pin alarm and deep sleep - and that seems to work really nicely, current consumption drops down to about 20uA as per my (fairly cheap) multimeter.

  pin_no = get_pin_no(hardware.BUTTON_A)
  if pin_no >= 32:
      gpio_base_addr = 0x50000300 
      pin_no %= 32
  else:
      gpio_base_addr = 0x50000000
  pin_cnf_addr = gpio_base_addr + 0x700 + pin_no * 4
  set_uint32_at(pin_cnf_addr,0x0003000C) # sense low, input buffer, pullup
  set_uint32_at(0x40000500, 1) # SYSTEM OFF

[furbrain]

Obviously this doesn't help if you are wanting it to wake after a specific time