Current consumption of connectkit_nrf52840 board

[whati001]

Hi makerdiary team,

currently I am trying to optimize the sleep current consumption of your connectkit nrf52840 board (with ufl connector). Unfortunately, I am unable to achieve an acceptable sleep current. I hope you can help me to find my problem and further reduce the current consumption.

Steps I have performed:
As a starting point I have used the basic blinky sample from zephyr (samples/basic/blinky) and applied Stian Røed Hafskjold's answer from this thread. Further I have disabled the QSPI and the console and serial entirely via KConfig.
The final setup looked like this:

KConfig:

CONFIG_GPIO=y

CONFIG_LOG=n
CONFIG_SERIAL=n
CONFIG_CONSOLE=n
CONFIG_PM_DEVICE=y

Overlay:

&usbd {
    status = "disabled";
};

&qspi {
    status = "disabled";
};

Powering the board via the VBUS (+5V) and GND pins yields the following current consumption, which is way to high for my usecase:

If I power the device via the 3.3 (3.3V) and GND pins yields the following current consumption, which is still to much:

To be honest, I am not sure where I leak so much current. In addition, the consumption trace does not look like a peripheral to me.

---

In addition, I have flashed the same example on a nrf52840dongle which yielded the expected current consumption:

KConfig:

CONFIG_GPIO=y

CONFIG_LOG=n
CONFIG_SERIAL=n
CONFIG_CONSOLE=n
CONFIG_PM_DEVICE=y
CONFIG_BOARD_SERIAL_BACKEND_CDC_ACM=n

Overlay:

&usbd {
    status = "disabled";
};

Power trace when powered via VBUS (+5V) and GND:

This result brings up the question, if the connectkit leaks somewhere current to GND.

Please be so kind and help me to reduce the current consumption if powered via the VBUS and GND pin.

[caizelin]

@whati001 Hi, there are three points you can follow to optimize the current consumption of nRF52840 Connect Kit:

1. Put the DC-DC convert in power-save mode by setting P1.13 LOW
2. Disable the UART in the DTS
3. Put the QSPI flash in low power mode. The QSPI flash will cost about 2mA while not in low power mode.

If you still can not fix the issue, I will push an example while updating the ncs-playground repo.

[whati001]

For everybody who wants to reduce the current consumption of the connectkit board.
As stated by @caizelin (point 1), this can be done by using the DC-DC regulator into pulse frequency modulation (PFM) via pulling P1.13 to low. The easiest way to achieve this is by changing the active how polarity of the used regulator. Simply overwrite the GPIO_ACTIVE_HIGH with GPIO_ACTIVE_LOW via an devicetree overlay file containing the information below.

// change regulator GPIO polarity to active low (0 = active high, 1 = active low)
&tps63802_force_pwm_mode {
    enable-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
};

[whati001]

@caizelin I need to apologize, the FLASH really consumes a lot of current even if it is not used.
After hours where I have tried to find a way to send custom command via the QSPI bus, I finally used the nrf nor flash pm implementation to disable the flash. I am not sure why Zephyr states that the flash is not ready, but it disables it properly. Please find below my solution to disable the flash via the pm subsystem.

KConfig:

# Enable PM subsystem
CONFIG_PM=y
CONFIG_PM_DEVICE=y

# enable NOR FLASH to disable it
CONFIG_FLASH=y
CONFIG_NORDIC_QSPI_NOR=y

Code:

#include <zephyr/pm/device.h>
static const struct device *flash_dev = DEVICE_DT_GET(DT_NODELABEL(mx25r64));
void flash_disable(void)
{
	if (!device_is_ready(flash_dev)) {
		printk("Flash device not ready\n");
		// return;
	}

	// use PM to power down flash device
	int rc = pm_device_action_run(flash_dev, PM_DEVICE_ACTION_SUSPEND);
	printf("Device PM Off: %d\n", rc);
}

By using the low power mode of the DC-DC (PFM), disabled UART, and disabling the flash, the current consumption is down to 118 uA when the led is not active (blinky.c example).

[whati001]

Do you may know why the device still wakes up very 40ms?

[whati001]

Ok I finally down at ~11uA when sourcing the chip via SYS pin and shutting down the nrf chip entirely.
The spikes seem to be from the DC-DC converter and another problem was my USB cable. I have not investigate further but the cable leaked some current internally.

The final solution was as @caizelin stated:
https://github.com/orgs/makerdiary/discussions/10#discussioncomment-10378742