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

[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