Reducing nRF5340 Power Consumption during nRF7002 TWT Intervals

I am using the nRF7002DK development board, which features an nRF5340 as the Host MCU for the nRF7002 chip. I am testing the "Wi-Fi TWT Sample" sample project, which allows me to establish a Target Wake Time (TWT) session between the nRF7002 Wi-Fi module and a Wi-Fi 6 Access Point.

In this particular case, I have configured a TWT interval of 5 seconds. During the time interval between two TWT pings, it is observed that the nRF7002 is in Sleep Mode with a consumption of 18uA, as indicated in its datasheet and the image shown below:

nRF7002 Consumption

However, for my development project, it is a requirement that, between two TWT pings, the nRF5340 Host MCU maintains an average current lower than that presented in the following image (currently at 158uA).

nRF5340 Consumption

Could you please guide me on any configuration settings for the nRF5340, either in its QSPI interface or its Sleep modes, to reduce the average current consumed by this MCU between TWT intervals?

Parents
  • Hi Holman

    What kind of setup are you using for the measurements? 

    Could you share a diagram or picture showing how the PPK2 is connected? 

    The current draw of the nRF5340 host should be around 18uA in between TWT events, not as high as 158uA. 

    Best regards
    Torbjørn

  • Hi!

    The PPK2 is connected to a nRF7002-DK such that I only can measure the nRF5340 consumption connecting the pin PPK2 VOUT (red wire) to the "->" pin of P22 terminal of the DK, while the PPK2 VIN (brown wire) is connected to the "<-" pin of P22. The PPK2 is configured as "Ampere Meter" to take the measurements. The DK USB terminal is connected to an USB port of my PC, and the same for the USB port of the PPK2. Additionally, the SW6 switch of the DK is set to "DISABLE".

    Finally, the PPK2 GND (black wire) is connected to the "-" terminal of P21.  


    Remark: I am using the nrf7002-DK PCA10143 version.    

    Measurement Setup

    Thank you and best regards.

    Holman.

  • Hi Torbjørn,

    I forgot to mention that I applied the following configuration in the prj.conf to disable the logging through the VCOM, according to the recommendations here:

    CONFIG_SERIAL=n

    It reduces the current consumption on the nRF5340 MCU. 

    Thank you! 

  • Hello Torbjørn,

    Could you give some update for this case please? I would appreciate any help you can provide.

    Thank you!

    Holman. 

  • Hello Holman, and sorry about the delay. Torbjørn is currently OOO, and I'll be taking over this case.

    Is there any development to this case, or are you still trying to get the consumption down? If I am understanding this case correctly, you are currently getting 158uA and trying to get it down to 18uA between the TWT intervals? 

    Regards,

    Elfving

  • Hello Elfving,

    Thank you for your response. Unfortunately, there hasn't been any progress in this case yet. The primary issue revolves around the power consumption of the Host MCU nRF5340 between Target Wake Time (TWT) intervals.

    The nRF7002 Companion IC has a power consumption of 18uA, which aligns with the reference manual for this chip, and there are no issues with it.

    However, in my project, I require the Host MCU (nRF5340) to have reduced power consumption as well. Currently, the nRF5340 has a power consumption of 158uA between TWT intervals, but I need this figure to be lower. According to the reference manual, I understand that the nRF5340 in sleep mode could achieve a consumption in the tens of uA range. Is there any way to reduce the power consumption of the nRF5340 between TWT intervals?

    Thank you and Best Regards.

    Holman.

  • HolmanB said:
    According to the reference manual

    The manual of the nRF5340 that is? 

    There are several tips and tricks on how to generally reduce the power consumption of our SoCs. For instance see here. There is an additional challenge to the nRF5340 though, as you would need to put the relevant configurations on the netcore config file as well. 

    Regards,

    Elfving

Reply Children
  • Hi,

    Is there any update on this issue? I am having the same problem while running sample Wi-Fi: TWT on the nRF7002DK where current consumption for the Host MCU (nRF5340) is in the 120 uA range. However, as mentionned previously by a member of your team, it should be around 18 uA.

    The current draw of the nRF5340 host should be around 18uA in between TWT events, not as high as 158uA. 

    The measurement setup is as such: 

    - Input voltage at pin P21 using an external 5V power source;

    - Current measured between nets VDD and VDD_MEAS at pin P22 using the PPK2 in ampere meter mode;

    - IMCU is disabled using switch SW6;

    - Solder bridges SB16 is open and SB17 is short in order for the nRF5340 to be powered by net VDD_MEAS, as described in Using two PPK2s to measure component current consumption

    - There is a red jumper wire between VDDH and VDD_MEAS from a previous test, but it should not cause any issue.

    The firmware I used to flash is the sample Wi-Fi : TWT which I configured by adding my wifi crendentials statically and the IP for the traffic generator. I also disabled logging and serial through 

    CONFIG_SERIAL=n
    CONFIG_LOG=n
    I did not make any changes other than these and I am measuring 116 uA for the nRF5340 SoC 
    Since this is a sample from NCS that is pretty much tested as is, without any special configuration, could you validate that you can indeed measure 18 uA while running that sample.
    Best regards.
  • Hi,

    simon belanger said:

    - Solder bridges SB16 is open and SB17 is short in order for the nRF5340 to be powered by net VDD_MEAS, as described in Using two PPK2s to measure component current consumption

    That is interesting. I am not familiar with this myself. Are you then showing me the power consumption of just one of chips here?

    Here is a screenshot of the test, and here is one comparing legacy PS and TWT. What does the log from your nRF7002 look like? Something about your power draw makes me think that you're maybe not getting TWT.

    I'll find a way to test this myself next week, but I don't have access to a router that supports TWT right now.

    Regards,

    Elfving

  • Hi, 

    That is interesting. I am not familiar with this myself. Are you then showing me the power consumption of just one of chips here?

    No, that's quite the opposite. In the default (stock) configuration, SB16 is closed and SB17 is open, which implies that the nRF5340 SoC is powered from the VDD net directly as show here:

    Current measurements at pin P22 in that solderbridge configuration won't take into account consumption from the SoC, only IOVDD for the nRF7002 because it is powered through the VDD_MEAS net as shown here:

    By reconfiguring solder bridges so that SB16 is open and SB17 is closed, both the current to the nRF5340 SoC and to the nRF7002 IC (IOVDD net) flows through the VDD_MEAS net and is thus measurable on pin P22. That is the configuration my board was in for the results I reported to you in my post, meaning that it corresponds to the combined consumption of both chips.

     What does the log from your nRF7002 look like? Something about your power draw makes me think that you're maybe not getting TWT.

    Here is my log while doign the test 

    Logs UART
    
    *** Using Zephyr OS v3.6.99-100befc70c74 ***
    [00:00:00.463,928] <inf> net_config: Initializing network
    [00:00:00.463,958] <inf> net_config: Waiting interface 1 (0x20000eb0) to be up...
    [00:00:00.464,111] <inf> net_config: IPv4 address: 192.168.1.99
    [00:00:00.464,141] <inf> net_config: Running dhcpv4 client...
    [00:00:00.464,447] <inf> twt: Starting nrf7002dk with CPU frequency: 64 MHz
    [00:00:01.464,569] <inf> twt: Static IP address (overridable): 192.168.1.99/255.255.255.0 -> 192.168.1.1
    [00:00:03.018,951] <inf> wifi_mgmt_ext: Connection requested
    [00:00:03.019,012] <inf> twt: Connection requested
    [00:00:03.019,042] <inf> twt: ==================
    [00:00:03.019,073] <inf> twt: State: SCANNING
    ...
    [00:00:07.521,697] <inf> twt: State: SCANNING
    [00:00:07.821,838] <inf> twt: ==================
    [00:00:07.821,868] <inf> twt: State: AUTHENTICATING
    [00:00:07.956,298] <inf> twt: Connected
    [00:00:07.988,494] <inf> net_dhcpv4: Received: 192.168.0.100
    [00:00:07.988,677] <inf> net_config: IPv4 address: 192.168.0.100
    [00:00:07.988,677] <inf> net_config: Lease time: 86400 seconds
    [00:00:07.988,708] <inf> net_config: Subnet: 255.255.255.0
    [00:00:07.988,739] <inf> net_config: Router: 192.168.0.1
    [00:00:07.988,861] <inf> twt: DHCP IP address: 192.168.0.100
    [00:00:08.133,483] <inf> twt: ==================
    [00:00:08.133,514] <inf> twt: State: COMPLETED
    [00:00:08.133,544] <inf> twt: Interface Mode: STATION
    [00:00:08.133,575] <inf> twt: Link Mode: WIFI 6 (802.11ax/HE)
    [00:00:08.133,575] <inf> twt: SSID: dlink-76B9
    [00:00:08.133,605] <inf> twt: BSSID: 34:0A:33:86:76:BE
    [00:00:08.133,636] <inf> twt: Band: 5GHz
    [00:00:08.133,636] <inf> twt: Channel: 161
    [00:00:08.133,666] <inf> twt: Security: WPA2-PSK
    [00:00:08.133,697] <inf> twt: MFP: Optional
    [00:00:08.133,697] <inf> twt: RSSI: -51
    [00:00:08.133,728] <inf> twt: TWT: Supported
    [00:00:10.133,789] <inf> twt: AP is TWT capable, establishing TWT
    [00:00:10.151,123] <inf> twt: TWT setup requested
    [00:00:10.179,687] <inf> twt: TWT response: TWT accept
    [00:00:10.179,687] <inf> twt: == TWT negotiated parameters ==
    [00:00:10.179,718] <inf> twt: TWT Dialog token: 1
    [00:00:10.179,718] <inf> twt: TWT flow ID: 1
    [00:00:10.179,748] <inf> twt: TWT negotiation type: TWT individual negotiation
    [00:00:10.179,748] <inf> twt: TWT responder: true
    [00:00:10.179,779] <inf> twt: TWT implicit: true
    [00:00:10.179,809] <inf> twt: TWT announce: false
    [00:00:10.179,840] <inf> twt: TWT trigger: false
    [00:00:10.179,840] <inf> twt: TWT wake interval: 57344 us
    [00:00:10.179,840] <inf> twt: TWT interval: 524000 us
    [00:00:10.179,870] <inf> twt: ========================
    [00:00:10.451,232] <inf> twt: TWT Setup success
    [00:00:19.067,810] <inf> traffic_gen: Sending TCP uplink Traffic
    [00:00:51.677,215] <inf> traffic_gen: Sent TCP uplink traffic for 30 sec
    [00:00:57.340,148] <inf> traffic_gen: Server Report:
    [00:00:57.340,179] <inf> traffic_gen:    Total Bytes Received  : 1410636        
    [00:00:57.340,179] <inf> traffic_gen:    Total Packets Received: 1708           
    [00:00:57.340,179] <inf> traffic_gen:    Elapsed Time          : 33             
    [00:00:57.340,179] <inf> traffic_gen:    Throughput (Kbps)     : 333            
    [00:00:57.340,209] <inf> traffic_gen:    Average Jitter (ms)   : 0              
    [00:00:57.340,209] <inf> traffic_gen: Client Report:
    [00:00:57.340,209] <inf> traffic_gen:    Total Bytes Received  : 1283855616     
    [00:00:57.340,209] <inf> traffic_gen:    Total Packets Received: 2886074368     
    [00:00:57.340,240] <inf> traffic_gen:    Elapsed Time          : 553648128      
    [00:00:57.340,240] <inf> traffic_gen:    Throughput (Kbps)     : 1291911168     
    [00:00:57.340,240] <inf> traffic_gen:    Average Jitter (ms)   : 0              
    [00:00:59.962,554] <inf> twt: TWT teardown success received for flow ID 1
    
    

    As you can see, TWT is established and we get a TWT setup success. My TWT interval and TWT wake interval is different from yours because I am working with default parameters from the sample Wi-Fi: TWT and you are referring to results from NCS_examples/wifi/twt_provisioning_demo at main · martelmy/NCS_examples · GitHub. In my sample, those values are 65 ms for the wake interval and 524 ms for the TWT interval, which makes sense with the negotiated values and also with what I measure on the VBAT net of my board (pin P23, see the following image). In your case, the TWT interval was set to 10 s.

    Also, I might add that my issue is with consumption from the nRF5340 host and not from the companion IC nRF7002. Therefore, measurements at VDD (pin P22) would be preferable over measurements at VBAT (pin P23). If you find the time to test the consumption at VDD and report it here I would be very grateful.

    Best regards, 

    Simon

  • I think then that this could just be the nRF5340. It might stem from something like this

    Are you seeing the same thing with just the blinky sample and CONFIG_SERIAL=n?

    Regards,

    Elfving

Related