Low power mode in Zephyr

RE: Low power mode in Zephyr

Stian Røed Hafskjold — Fri, 22 Jan 2021 12:44:43 GMT

It looks like you have some leakage on the VDD domain since the base current between the spikes is so high. The varying current could be a floating GPIO input.

I think we should first try to verify the measurement setup. If you put the chip to system OFF mode the chip will consume less than 1uA. If you still see a high current there will be other things connected to the VDD that consumes current, or you have leakage through the GPIOs (if configured as output). Make sure that the pins controlling the LoRa module are set to a defined level before entering system OFF mode so that the LoRa module does not consume current (typically the chip select pin).

You said that you use the PPK in external mode, because of a shield. Does that mean that you are measuring on a DK? Which DK is this (PCA number and version)? Can you also please explain how you set up the PPK for measurements. If you connect the PPK directly to the external supply header on the DK you will be measuring the debugger on the DK as well.

RE: Low power mode in Zephyr

diocorreia — Fri, 22 Jan 2021 10:56:44 GMT

From my reading of the driver code, beside the SPI peripheral, the driver uses five GPIO pins: ANTENNA_ENABLE, TX_ENABLE, RX_ENABLE, RESET and DIO1. The first four pins are output pins, and are grounded during sleep. And the latter is an input pin, used by the LoRa board for callback.

Here are the plots with the device's current consumption, during sleep mode. The first plot shows the current consumption along all the sleep mode time. And, the second plot, is a zoomed view of the first one.

RE: Low power mode in Zephyr

Stian Røed Hafskjold — Thu, 21 Jan 2021 14:08:50 GMT

Hi, I'm not familiar with the SX126x driver, so I think we first need to figure out which peripherals are active. As I understand the communication protocol is SPI? The SPI should not consume any significant current unless it's actively transmitting. Any other peripherals being used?

Also the current consumption could be due to some polling feature in the LoRa driver. I recently had a case where a WiFi module driver was configured with a 1ms polling timer, which lead to a current consumption of 490 uA.

If you are able to plot the current consumption you should be able to see if there are any timers waking up the CPU regularly (be aware that there will be spikes due to DCDC switching, but they should be distinguishable from the wakeup timers).

RE: Low power mode in Zephyr

diocorreia — Wed, 13 Jan 2021 11:10:39 GMT

Hi, Stian. No, I haven't figured out how to solve this issue. Any idea?

RE: Low power mode in Zephyr

Stian Røed Hafskjold — Tue, 12 Jan 2021 22:05:03 GMT

Hi, sorry for not getting back to you, I missed your last reply. Were you able to figure out this? Did you get any help from the Zephyr mailing list?

RE: Low power mode in Zephyr

diocorreia — Fri, 11 Dec 2020 20:35:03 GMT

Having no success with my modifications on the driver. Tried to use the same method (device_set_power_state) with all GPIOs and the SPI device driver. When deactivating the first, nothing special appears to happen on the consumption. When I deactivate SPI, the consumption increases in the order of mA (guess is something related with the context loss that is described in zephyr documentation). Do you have any suggestion in how to address this issue? Or is it better to ask in zephy's mailing list?

Device Driver structure:

struct sx126x_data {
	const struct device *reset;
	const struct device *busy;
	const struct device *dio1;
	struct gpio_callback dio1_irq_callback;
	struct k_work dio1_irq_work;
	DioIrqHandler *radio_dio_irq;
#if HAVE_GPIO_ANTENNA_ENABLE
	const struct device *antenna_enable;
#endif
#if HAVE_GPIO_TX_ENABLE
	const struct device *tx_enable;
#endif
#if HAVE_GPIO_RX_ENABLE
	const struct device *rx_enable;
#endif
	const struct device *spi;
	struct spi_config spi_cfg;
#if HAVE_GPIO_CS
	struct spi_cs_control spi_cs;
#endif
	RadioOperatingModes_t mode;
#ifdef CONFIG_DEVICE_POWER_MANAGEMENT
	uint32_t pm_state;
#endif
} dev_data;

My PM function:

#ifdef CONFIG_DEVICE_POWER_MANAGEMENT

static int sx126x_lora_pm_control(const struct device *dev, uint32_t ctrl_command,
				 void *context, device_pm_cb cb, void *arg)
{
	int ret = 0;
	struct sx126x_data *data = (struct sx126x_data *)dev->data;

	switch (ctrl_command) {
	case DEVICE_PM_SET_POWER_STATE:
		if (*((uint32_t *)context) == DEVICE_PM_ACTIVE_STATE) {
			data->pm_state = DEVICE_PM_ACTIVE_STATE;
			device_set_power_state(data->reset, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			device_set_power_state(data->busy, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			device_set_power_state(data->dio1, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			#if HAVE_GPIO_ANTENNA_ENABLE
				device_set_power_state(data->antenna_enable, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			#endif
			#if HAVE_GPIO_TX_ENABLE
				device_set_power_state(data->tx_enable, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			#endif
			#if HAVE_GPIO_RX_ENABLE
				device_set_power_state(data->rx_enable, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
			#endif
		} else {
			data->pm_state = DEVICE_PM_OFF_STATE;
			device_set_power_state(data->reset, DEVICE_PM_OFF_STATE, NULL, NULL);
			device_set_power_state(data->busy, DEVICE_PM_OFF_STATE, NULL, NULL);
			device_set_power_state(data->dio1, DEVICE_PM_OFF_STATE, NULL, NULL);
			#if HAVE_GPIO_ANTENNA_ENABLE
				device_set_power_state(data->antenna_enable, DEVICE_PM_OFF_STATE, NULL, NULL);
			#endif
			#if HAVE_GPIO_TX_ENABLE
				device_set_power_state(data->tx_enable, DEVICE_PM_OFF_STATE, NULL, NULL);
			#endif
			#if HAVE_GPIO_RX_ENABLE
				device_set_power_state(data->rx_enable, DEVICE_PM_OFF_STATE, NULL, NULL);
			#endif
			ret = 0;
		}
		break;
	case DEVICE_PM_GET_POWER_STATE:
		*((uint32_t *)context) = data->pm_state;
		break;
	default:
		ret = -EINVAL;
	}

	if (cb != NULL) {
		cb(dev, ret, context, arg);
	}
	return ret;
}
#endif /* CONFIG_DEVICE_POWER_MANAGEMENT */

#ifndef CONFIG_DEVICE_POWER_MANAGEMENT
DEVICE_AND_API_INIT(sx126x_lora, DT_INST_LABEL(0),
		    &sx126x_lora_init, NULL,
		    NULL, POST_KERNEL, CONFIG_LORA_INIT_PRIORITY,
		    &sx126x_lora_api);
#else
DEVICE_DEFINE(sx126x_lora, DT_INST_LABEL(0), &sx126x_lora_init,
	      sx126x_lora_pm_control, &dev_data, NULL, POST_KERNEL,
	      CONFIG_LORA_INIT_PRIORITY, &sx126x_lora_api);
#endif /* CONFIG_DEVICE_POWER_MANAGEMENT */

RE: Low power mode in Zephyr

diocorreia — Wed, 09 Dec 2020 16:47:31 GMT

No, I'm using an nRF52832.

After some tests, I reached to the conclusion that the problem is probably in the LoRa module driver (sx126x) that is using GPIO and SPI without managing their power usage. I'll try to modify the driver in order to optimize the power consumption.

RE: Low power mode in Zephyr

Stian Røed Hafskjold — Wed, 02 Dec 2020 16:10:07 GMT

Hi, are you using nRF52840? I have a feeling that the extra current is a result of UART1 being turned on. All UART instances are turned on by default in Zephyr.

Create a file called nrf52840dk_nrf52840.overlay in the project root folder and add this:

&uart1 {
    status = "disabled";
};

Unfortunately there's no easy way to see which devices are turned on in zephyr. Other than that I think your code looks good. The way you turn off logging (and hence UART0) looks fine:

device_set_power_state(cons, DEVICE_PM_OFF_STATE, NULL, NULL);

[quote user=""]PS: these values were measured using the power profile kit in external mode due to the presence of a shield in the development board.[/quote]

How do you connect the PPK? If you are measuring on a nRF52 DK and power the DK thorugh the external supply header, the idle current is expected to be high because you power the debugger chip as well.