System on high current when wifi is disconnected

Question

Hi, 
 We are evaluating NRF5340+NRF7002 setup for our customer. We are currently using https client example(sdk v3.0.2) and we would like to benchmark current consumption of the individual chips.I have set up the PPK2s as explained in your technical documentation. 
 We would like the application to run in a loop where it wakes up and posts some data over https and goes back to sleep. It is not possible at the moment to wakeup periodically from system off state as there is no wakeup option to achieve this without external component. Hence we would like to remain in system on state and try to achieve as low power consumption as possible when device is in sleep. We noticed that bringing up the net interface takes a long time due to a known bug as posted here -> NRF7002DK boot up time - Nordic Q&A - Nordic DevZone - Nordic DevZone . Hence we are avoiding calls to conn_mgr_all_if_up and conn_mgr_all_if_down within the loop. The loop now just establishes connection before http request and then disconnects. This puts the nrf7002 in relatively low power state (average ~16uA). But we noticed that nrf5340 still consumes around ~200uA constant current. On digging deeper it looks like the BUCKEN and IOVDD pins are the reason for this. These are needed to keep nrf7002 powered on and are only disabled when conn_mgr_all_if_down is called. If powered down I believe nrf7002 loses all context and need to be reinitialized. Without powering down nrf7002(using these pins) it looks like it is not possible at the moment to reduce current consumption on host MCU below ~200uA. 
 Could you please let me know if there is a way to achieve low power consumption (~1-10uA) in system ON keeping nrf7002 chip on and how this can be done? Else are there any other alternative approaches? 
 Best Regards, 
 Arjun

Håkon Alseth · Accepted Answer

Hi Arjun,

I tested the same version as you, and I can confirm that I see similar results (around 360 uA):

I think there are two problems here:

1. GPIOTE IN channel used for HOST_IRQ

2. QSPI IO1 (MISO line) and IO3 looks to be idle high.

The first is forced by using GPIOTE PORT event for wakeup/IRQ. Second is fixed by setting the two pins to floating (ie. expected driven by nRF7002)

Could you try the following overlay?

&pinctrl {
	qspi_test: qspi_test {
		group1 {
			psels = <NRF_PSEL(QSPI_SCK, 0, 17)>, 
					<NRF_PSEL(QSPI_IO2, 0, 15)>;
			bias-pull-down;
		};
		group2 {
			psels = <NRF_PSEL(QSPI_CSN, 0, 18)>,
					<NRF_PSEL(QSPI_IO0, 0, 13)>;
			bias-pull-up;
		};
		group3 {
			psels = <NRF_PSEL(QSPI_IO1, 0, 14)>,
					<NRF_PSEL(QSPI_IO3, 0, 16)>;
		};
	};
};

&gpio0 {
    sense-edge-mask = <(1 << 23)>;
};

&qspi {
	status = "okay";
	pinctrl-0 = <&qspi_test>;
	pinctrl-1 = <&qspi_sleep>;
	pinctrl-names = "default", "sleep";
};

I used wifi/sta sample, with these added configs:

CONFIG_LOG=n
CONFIG_PINCTRL=y
CONFIG_NET_LOG=n
CONFIG_CONSOLE=n
CONFIG_SERIAL=n
CONFIG_DEBUG_COREDUMP=n
CONFIG_DEBUG_COREDUMP_BACKEND_LOGGING=n
CONFIG_DEBUG_COREDUMP_MEMORY_DUMP_MIN=n

After these I see approx 24 uA in the sleep events:

Could you check if this helps on your end as well? Please note that setting "sense-edge-mask" is for debugging purposes, as this is a lesser accuracy mode.

Kind regards,

Håkon

System on high current when wifi is disconnected

Top Replies