IOVDD is constantly high

[simon belanger]

Hello,

I am using the nRF5340-DK board along with the nRF7002-EK companion. I noticed that current consumption was high while running my MQTT application on this setup, particularly at IOVDD. Current is averaging 700-800 uA at IOVDD while powered through the USB and it seems pretty constant, measured from both a PPKII and an ammeter. From reading the docs, it seems like the switch on the nRF7002-DK which is tied to GPIO P1.00 on the nRF5340 should activate/deactivate that switch in order to disconnect IOVDD when not necessary. However, it seems like this GPIO is maintained high all the time.

Do I need to configure the application in any particular way to enable switching? I have tried those configs with no success

CONFIG_PM_DEVICE=y

CONFIG_NRF_WIFI_LOW_POWER=y

CONFIG_NRF700X_QSPI_LOW_POWER=y

I have also tried running sample WiFi Shell and IOVDD is also maintained high all the time.

Thanks in advance

[Håkon Alseth]

Hi,

 

Are you running the PM_DEVICE API to place the bus interface in suspend mode?

int ret = pm_device_action_run(flash_dev, PM_DEVICE_ACTION_SUSPEND);
if (ret) {
    /* Handle error */
}
...
ret = pm_device_action_run(flash_dev, PM_DEVICE_ACTION_RESUME);
if (ret) {
    /* Handle error */
}

 

 

Or do you want to completely shut down the nRF7002? If yes, then there's a sample here that shows this use-case:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0/samples/wifi/shutdown/src/main.c

 

Kind regards,

Håkon

[simon belanger]

Hi,

to answer yout question, I would like the Wi-Fi chip to consume as little power as possible whenever it goes into extended power saving mode, after connecting to the AP. Ideally, I would remain connected to the AP.

 

I have tried the Wi-Fi shutdown sample as you suggested, I built it "as is" on my target using the following build command and i flashed it.

west build -d build_default -b nrf5340dk_nrf5340_cpuapp -p -- -DSHIELD=nrf7002ek

As for the nRF5340 SoC, when measuring current at VDD_nRF using the PPK2, the average value is 805 uA

however, this value goes down to 2 uA when we disable serial communication and logging by setting those config values:

 

CONFIG_SERIAL=n 
CONFIG_LOG=n

However when measuring current on the IOVDD pin of the nRF7002-DK using the PPK2, I do not observe any form of shutdown. Current at this pin is still 735 uA. 

 

 Is this normal behavior, for that particular example? It seems like the Wifi chip has a pretty high power consumption for a device that should be in shutdown state.

And also, I would like to know, because it does not seem clear to me

- Is the IOVDD switch on nRF7002-EK and tied to GPIO P1.00 (IOVDD_EN) meant to be operated manually by the application code or is it handled by the driver? I thought that this sentence (found in Hardware and layout )

"The control of the switch is handled by the Wi-Fi driver on nRF5340."

Meant that I did not have to manually control the power mode of the nRF7002. In response to your comment about the PM API.

Thanks in advance

[simon belanger]

Hi,

simon belanger said:

However when measuring current on the IOVDD pin of the nRF7002-DK using the PPK2, I do not observe any form of shutdown. Current at this pin is still 735 uA. 

Sorry I made a mistake, I meant the nRF7002-EK! The whole time my setup has been nRF5340-DK + nRF7002-EK.

I just tried performing the current measurements again for the Wi-Fi shutdown sample (with serial comm disabled). I measured VDD_nRF on the nRF5340-Dk board and IOVDD on the nRF7002-EK board. Here is what I got

which is what's expected. I probably did something wrong in my first measurement. RIght now, this confirms that the sample can shutdown the Wi-Fi chip in order to bring down power consumption.

Now, I am wondering how I can implement this behavior on my application. Will I have to reconnect to the AP if I bring up the interface after I put it into shutdown? For example, If my device is connected to an AP with a listen interval that makes it exchange data only once in an hour, could I bring the interface down in the meantime?

thanks in advance,

Simon

 

[Håkon Alseth]

Hi,

simon belanger said:

which is what's expected. I probably did something wrong in my first measurement. RIght now, this confirms that the sample can shutdown the Wi-Fi chip in order to bring down power consumption.

I am glad to hear that the measurements work as expected now!

 

simon belanger said:

Now, I am wondering how I can implement this behavior on my application. Will I have to reconnect to the AP if I bring up the interface after I put it into shutdown? For example, If my device is connected to an AP with a listen interval that makes it exchange data only once in an hour, could I bring the interface down in the meantime?

The shutdown sample will effectively be a full power-off of the nRF7002, ie. by turning off the voltage to it.

If you then wake it up again, it means a full re-connect and re-initialization of the net interface.

If you take the STA sample, which enables DTIM power saving by default, you should see a similar VDDIO current draw like this:

This is the wifi/sta sample, where I connect to a network. The driver will dynamically draw current based on communication.

Each peak is reflected for each transmission over the SPI interface.

 

Now, if you include the host controller into the current measurement, you will have to ensure that interfaces such as the logger (serial) is disabled.

 

Kind regards,

Håkon

[simon belanger]

Hi,

Håkon Alseth said:

If you take the STA sample, which enables DTIM power saving by default

Ok thats looks more like what I am trying to do with my application, where my device (STA) stays connected to the AP but consumes less because it is in power saving mode. 

I tried the Wi-Fi Station sample to make sure I could get the power consumption you measured. I built the sample for my target using the following command and then flashed it. The Wi-Fi credentials were configured as described in docs.nordicsemi.com/.../README.html

west build -b nrf5340dk_nrf5340_cpuapp -p -- -DSHIELD=nrf7002ek

The serial monitor indicates that the sample is working as expected. I also see LED 1 blinking when the device connects to the AP.

*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
[00:00:00.697,753] <inf> net_config: Initializing network
[00:00:00.697,784] <inf> net_config: Waiting interface 1 (0x20000ee0) to be up...
[00:00:00.697,937] <inf> net_config: IPv4 address: 192.168.1.99
[00:00:00.697,998] <inf> net_config: Running dhcpv4 client...
[00:00:00.698,852] <inf> sta: Starting nrf5340dk with CPU frequency: 64 MHz
[00:00:01.699,035] <inf> sta: Static IP address (overridable): 192.168.1.99/255.255.255.0 -> 192.168.1.1
[00:00:01.699,066] <inf> sta: Waiting for Wi-Fi to be ready
[00:00:03.250,915] <inf> wifi_mgmt_ext: Connection requested
[00:00:03.250,946] <inf> sta: Connection requested
[00:00:03.250,976] <inf> sta: ==================
[00:00:03.251,007] <inf> sta: State: SCANNING
[00:00:03.551,177] <inf> sta: ==================
[00:00:03.551,208] <inf> sta: State: SCANNING
[00:00:03.851,348] <inf> sta: ==================
[00:00:03.851,379] <inf> sta: State: SCANNING
[00:00:04.151,519] <inf> sta: ==================
[00:00:04.151,550] <inf> sta: State: SCANNING
[00:00:04.451,690] <inf> sta: ==================
[00:00:04.451,721] <inf> sta: State: SCANNING
[00:00:04.751,861] <inf> sta: ==================
[00:00:04.751,892] <inf> sta: State: SCANNING
[00:00:05.052,032] <inf> sta: ==================
[00:00:05.052,062] <inf> sta: State: SCANNING
[00:00:05.352,203] <inf> sta: ==================
[00:00:05.352,233] <inf> sta: State: SCANNING
[00:00:05.652,374] <inf> sta: ==================
[00:00:05.652,404] <inf> sta: State: SCANNING
[00:00:05.952,545] <inf> sta: ==================
[00:00:05.952,575] <inf> sta: State: SCANNING
[00:00:06.252,716] <inf> sta: ==================
[00:00:06.252,746] <inf> sta: State: SCANNING
[00:00:06.552,886] <inf> sta: ==================
[00:00:06.552,917] <inf> sta: State: SCANNING
[00:00:06.853,057] <inf> sta: ==================
[00:00:06.853,088] <inf> sta: State: SCANNING
[00:00:07.153,228] <inf> sta: ==================
[00:00:07.153,259] <inf> sta: State: SCANNING
[00:00:07.453,399] <inf> sta: ==================
[00:00:07.453,430] <inf> sta: State: AUTHENTICATING
[00:00:07.652,282] <inf> sta: Connected
[00:00:07.759,185] <inf> sta: ==================
[00:00:07.759,185] <inf> sta: State: COMPLETED
[00:00:07.759,216] <inf> sta: Interface Mode: STATION
[00:00:07.759,246] <inf> sta: Link Mode: WIFI 5 (802.11ac/VHT)
[00:00:07.759,277] <inf> sta: SSID: GPHY
[00:00:07.759,338] <inf> sta: BSSID: 9C:53:22:46:AE:2B
[00:00:07.759,368] <inf> sta: Band: 5GHz
[00:00:07.759,368] <inf> sta: Channel: 153
[00:00:07.759,399] <inf> sta: Security: WPA2-PSK
[00:00:07.759,429] <inf> sta: MFP: Optional
[00:00:07.759,429] <inf> sta: RSSI: -32
[00:00:10.679,595] <inf> net_dhcpv4: Received: 192.168.68.110
[00:00:10.679,779] <inf> net_config: IPv4 address: 192.168.68.110
[00:00:10.679,779] <inf> net_config: Lease time: 7200 seconds
[00:00:10.679,809] <inf> net_config: Subnet: 255.255.255.0
[00:00:10.679,870] <inf> net_config: Router: 192.168.68.1
[00:00:10.679,992] <inf> sta: DHCP IP address: 192.168.68.110

However, there is something wrong with my current consumption. Net VBAT seems right, I can observe the Wi-Fi beacons and 10 uA in between them. But net IOVDD shows a mean current of around 500 uA. There seems to be a DC current draw of 500 uA on IOVDD and I do not know why. I do not think IOVDD is behaving the way it should.

 

Also, I am using SDK version 2.7.0, and I took the sample from that version of the SDK.

Simon

[Håkon Alseth]

Hi Simon,

 

Thank you for the detailed description and your patience in this matter.

I can confirm that there is a pin conflict on the nRF5340-DK, where the pins P1.01/P1.00 is connected to the SEGGER IC, specifically for the RXD/TXD handling for the uart bridge, which is causing an incorrect power up sequence on "BUCK_EN" and "IOVDD_EN"

The fix for this is unfortunately not straight forward, which is to break the SB29 and SB30:

https://docs.nordicsemi.com/bundle/ug_nrf5340_dk/page/UG/dk/solder_bridge.html

 

This will then render that specific UART port enumerated in the OS, unavailable.

 

Kind regards,

Håkon

[simon belanger]

Hi,

so by breaking solderbridges SB29 and SB30, UART1 of the nRF5340 SoC is disconnected from the Interface MCU (which is another nRF5340 chip and not a SEGGER IC on nRF534-DK by the way). Also, I thought that having the DK in mode nRF_ONLY meant that these connections were broken anyway?

Anyway, I broke the solderbridges and I still measure a 500 uA power consumption for the nRF7002 IOVDD. So this advice did not solve the issue. 

Will that consumption issue happen with nRF7002-DK? If this board does not have that issue, I might use it instead if that can be simpler.

Simon

[Håkon Alseth]

Hi Simon,

 

My apologies for the inconvenience.

simon belanger said:

 Also, I thought that having the DK in mode nRF_ONLY meant that these connections were broken anyway?

I agree, there is something else in addition that is drawing current here. I'll report this internally, so that we can update our docs in this matter.

simon belanger said:

Will that consumption issue happen with nRF7002-DK? If this board does not have that issue, I might use it instead if that can be simpler.

I can confirm that the nRF7002-DK does not have this current consumption issue.

 

Kind regards,

Håkon

[simon belanger]

Hi Håkon,

thank you for the support, I will purcahse a nRF7002-DK and try the Station Sample on this development kit and I will keep you posted on the measurements.

Best Regards, 

Simon

[Håkon Alseth]

Hi Simon,

 

Always happy to help.

I checked the nRF7002-DK in both QSPI and SPI transport, and it had a normal current consumption curve, ie. no offset as observed with the nRF7002-EK.

Let me know if you run into any issues or have questions.

 

Kind regards,

Håkon

[simon belanger]

Hi Håkon, 

just for closure, I tested the nRF7002DK board and I did measure a current draw that was similar to yours at both IOVDD and VBAT. Here are the measurements:

In the end it seems like it was the nRF5340DK + nRF7002EK which were drawing more current than expected. I won't be using that board combo for evaluation of consumption from now on.

Thanks for the support