• State Not Answered
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 261 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 345982
Options

Measuring power consumption of nrf7002dk seems impossible

Tudor B.

Hello everyone,

Currently we're trying to get the full WiFi stack working on nrf7002dk. We decided to look into the power consumption of the DK board itself as a point of reference to gauge some rough estimations for our board.

I stumbled upon this guide: https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/intro.html , which pointed me towards the "nRF7002_DK_User_Guide_v1.0.0.pdf" documentation for the board. In there, on page 35, section "5.3 Using an ampere meter for current measurement", it says to disconnect the P23 jumper and add a multimeter (which should be set to uA or mA). I've done so, but all of a sudden, the basic mechanisms of WiFi completely stopped working. More exactly:

1). (startup, no jumper) when resetting the board, I get some strange initialisation issues:

>>> [00:00:00.870,513] <err> wifi_nrf_bus: RDSR failed: -16
[00:00:00.876,403] <err> wifi_nrf: zep_shim_bus_qspi_dev_add: QSPI device init failed
[00:00:00.885,040] <err> wifi_nrf: nrf_wifi_bus_qspi_dev_add: nrf_wifi_osal_bus_qspi_dev_add failed
[00:00:00.894,836] <err> wifi_nrf: nrf_wifi_bal_dev_add: Bus dev_add failed
[00:00:00.902,526] <err> wifi_nrf: nrf_wifi_sys_hal_dev_add: nrf_wifi_bal_dev_add failed
[00:00:00.911,407] <err> wifi_nrf: nrf_wifi_sys_fmac_dev_add: nrf_wifi_sys_hal_dev_add failed
[00:00:00.920,623] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed
[00:00:00.929,626] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed
[00:00:00.938,995] <dbg> net_dns_resolve: dns_resolve_init_locked: (main): [0] 8.8.8.8
[00:00:00.947,387] <dbg> net_dns_resolve: dns_resolve_init_locked: (main): [1] 8.8.4.4
[00:00:00.956,146] <dbg> net_sock: zsock_socket_internal: (main): socket: ctx=0x2000adf0, fd=3
[00:00:00.965,301] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Service WEST_TOPDIR/zephyr/subsys/net/lib/dhcpv4/dhcpv4_server.c:1535 has 1 pollable sockets
[00:00:00.981,536] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Service WEST_TOPDIR/zephyr/subsys/net/lib/dns/resolve.c:41 has 2 pollable sockets
[00:00:00.996,826] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Monitoring 3 socket entries
[00:00:01.007,873] <dbg> net_sock: zsock_socket_internal: (main): socket: ctx=0x2000aea0, fd=5
*** Booting nRF Connect SDK v3.0.0-3bfc46578e42 ***
*** Using Zephyr OS v4.0.99-a0e545cb437a ***
[00:00:01.026,611] <inf> net_config: Initializing network
[00:00:01.032,440] <inf> net_config: Waiting interface 1 (0x20009290) to be up...
[00:00:01.046,356] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:01.053,588] <inf> net_config: IPv4 address: 192.168.1.1
[00:00:01.059,875] <inf> net_config: Running dhcpv4 client...
MicroPython 9ea566c69-dirty on 2025-05-25; zephyr-nrf7002dk with nrf5340
Type "help()" for more information.

2). (startup, jumper) putting the jumper back on P23, powering off and then on the board completely (not just simply resetting it), the startup sequence looks normal:

>>> [00:00:00.373,535] <inf> wifi_nrf: Configuring SLEEP CTRL GPIO control register

[00:00:00.520,843] <dbg> net_dns_resolve: dns_resolve_init_locked: (main): [0] 8.8.8.8
[00:00:00.529,357] <dbg> net_dns_resolve: dns_resolve_init_locked: (main): [1] 8.8.4.4
[00:00:00.538,146] <dbg> net_sock: zsock_socket_internal: (main): socket: ctx=0x2000adf0, fd=3
[00:00:00.547,363] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Service WEST_TOPDIR/zephyr/subsys/net/lib/dhcpv4/dhcpv4_server.c:1535 has 1 pollable sockets
[00:00:00.563,568] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Service WEST_TOPDIR/zephyr/subsys/net/lib/dns/resolve.c:41 has 2 pollable sockets
[00:00:00.578,887] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Monitoring 3 socket entries
[00:00:00.589,935] <dbg> net_sock: zsock_socket_internal: (main): socket: ctx=0x2000aea0, fd=5
*** Booting nRF Connect SDK v3.0.0-3bfc46578e42 ***
*** Using Zephyr OS v4.0.99-a0e545cb437a ***
[00:00:00.608,703] <inf> net_config: Initializing network
[00:00:00.614,501] <inf> net_config: Waiting interface 1 (0x20009290) to be up...
[00:00:00.628,417] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:00.635,681] <inf> net_config: IPv4 address: 192.168.1.1
[00:00:00.641,967] <inf> net_config: Running dhcpv4 client...
MicroPython 9ea566c69-dirty on 2025-05-25; zephyr-nrf7002dk with nrf5340
Type "help()" for more information.

Although a few error messages aren't really problematic, the bothersome thing is that WiFi scanning and connection stops working:

1). (WiFi scan, no jumper)

>>> import network
>>>
>>> wlan = network.WLAN(network.STA_IF)  # Wi-Fi client
Starting nrf7002dk with CPU frequency: 64 MHz
[00:00:14.482,391] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.490,600] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:14.498,199] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.506,408] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:14.514,038] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.522,247] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:14.529,846] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.538,085] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:14.545,684] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.553,894] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:14.561,523] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:14.569,732] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:15.480,346] <err> wifi_nrf: nrf_wifi_if_stop_zep: rpu_ctx_zep is NULL
[00:00:15.488,128] <inf> wifi_supplicant: Network interface 1 (0x20009290) down
[00:00:15.499,053] <err> os: ***** SECURE FAULT *****
[00:00:15.504,791] <err> os:   Address: 0x0
[00:00:15.509,674] <err> os:   Attribution unit violation
[00:00:15.515,808] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000000
[00:00:15.524,566] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0003decd
[00:00:15.533,294] <err> os:  xpsr:  0x61000000
[00:00:15.538,574] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x0003844f  s[ 2]:  0x00000000  s[ 3]:  0x40015000
[00:00:15.549,072] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x0007bd77  s[ 6]:  0x00000000  s[ 7]:  0xffffffff
[00:00:15.559,570] <err> os: s[ 8]:  0xffffffff  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00038639
[00:00:15.570,068] <err> os: s[12]:  0x00000000  s[13]:  0x0003858d  s[14]:  0x000c5508  s[15]:  0x00000020
[00:00:15.580,535] <err> os: fpscr:  0x00000020
[00:00:15.585,784] <err> os: Faulting instruction address (r15/pc): 0x0006e716
[00:00:15.593,750] <err> os: >>> ZEPHYR FATAL ERROR 41: Unknown error on CPU 0
[00:00:15.601,715] <err> os: Current thread: 0x20009f80 (unknown)
[00:00:15.608,551] <err> os: Halting system

2). (WiFi scan, jumper) 

>>> import network
>>>
>>> wlan = network.WLAN(network.STA_IF)  # Wi-Fi client
Starting nrf7002dk with CPU frequency: 64 MHz
>>> wlan.scan()
Scan requested
Num  | SSID                             (len) | Chan | RSSI | Security | BSSID
1    | TP-Link_7474                     12    | 4    | -52  | WPA2-PSK | 40:ED:00:CD:74:73
2    |                                  0     | 4    | -53  | WPA2-PSK | 62:ED:00:CD:74:73
3    | TP-Link_7474                     12    | 44   | -60  | WPA2-PSK | 40:ED:00:CD:74:72
4    |                                  0     | 44   | -61  | WPA2-PSK | 62:ED:00:CD:74:72
5    | NIA                              3     | 7    | -67  | WPA2-PSK | 7C:F1:7E:78:C7:0F
6    | AG                               2     | 11   | -72  | WPA2-PSK | 04:95:E6:FF:42:02
7    | TP-Link_10E4                     12    | 8    | -74  | WPA2-PSK | 7A:A4:B7:09:10:E4
8    | TP-Link_337C                     12    | 3    | -75  | WPA2-PSK | 82:5A:B0:BA:33:7C
9    |                                  30    | 3    | -76  | WPA2-PSK | 82:5A:B0:BA:33:7D
10   |                                  30    | 8    | -77  | WPA2-PSK | 7A:A4:B7:09:10:E5
11   | DIGI-4TYa                        9     | 11   | -78  | WPA2-PSK | AC:CC:36:55:68:E1
12   | NIA                              3     | 48   | -83  | WPA2-PSK | 7C:F1:7E:78:C7:11
13   | TP-Link_10E4_5G                  15    | 36   | -90  | WPA2-PSK | 72:A4:B7:09:10:E3
Scan request done
Found 13 networks.
Network ID: TP-Link_7474 & Network MAC: 40:ED:00:CD:74:73
Network ID:  & Network MAC: 62:ED:00:CD:74:73
Network ID: TP-Link_7474 & Network MAC: 40:ED:00:CD:74:72
Network ID:  & Network MAC: 62:ED:00:CD:74:72
Network ID: NIA & Network MAC: 7C:F1:7E:78:C7:0F
Network ID: AG & Network MAC: 04:95:E6:FF:42:02
Network ID: TP-Link_10E4 & Network MAC: 7A:A4:B7:09:10:E4
Network ID: TP-Link_337C & Network MAC: 82:5A:B0:BA:33:7C
Network ID:  & Network MAC: 82:5A:B0:BA:33:7D
Network ID:  & Network MAC: 7A:A4:B7:09:10:E5
Network ID: DIGI-4TYa & Network MAC: AC:CC:36:55:68:E1
Network ID: NIA & Network MAC: 7C:F1:7E:78:C7:11
Network ID: TP-Link_10E4_5G & Network MAC: 72:A4:B7:09:10:E3
MAC: F4:CE:36:00:1C:F4
[(b'TP-Link_7474', b'40:ED:00:CD:74:73\x00', 4, -52, 1, False), (b'', b'62:ED:00:CD:74:73\x00', 4, -53, 1, False), (b'TP-Link_7474', b'40:ED:00:CD:74:72\x00', 44, -60, 1, False), (b'', b'62:ED:00:CD:74:7]
>>>

As far as I can interpret it, it seems that the nrf5340 can't communicate with the nrf7002. The weird part is that the multimeter set to mA (or uA) measurement should behave like a jumper, but whatever reason, it doesn't. Could anyone provide some insight on this matter?

Also: is there a table/ spreadsheet/ documentation/ something that can be used to roughly estimate power consumption based on active features and active time?

Edit: I found the table that describes theoretical power consumptions: Technical Documentation. The only thing that remains is the suspicious behaviour of the nrf7002 chip when removing the P23 jumper and adding a multimeter.

Parents
  • 0

    So you have followed the steps here: https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/prepare_board.html and here https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/hw_measure_ampmeter.html .


    So everything works as expected with the jumper in place but when you connected the amperemeter then you have issues. I would suspect the amperemeter\measurement tool or its connection here firstly. Make sure that it works as expected. 

    We do also have a more info on example use case here: https://academy.nordicsemi.com/courses/wi-fi-fundamentals/lessons/lesson-6-wifi-fundamentals/topic/lesson-6-exercise-1-2/ , and for a more accurate for your use case here we have this: https://github.com/too1/mqtt_over_wifi_nrf7002DK?tab=readme-ov-file#chapter-4---enable-the-wi-fi-6-target-wake-time-twt-feature-in-the-code-to-evaulate-power-consumption 

    Here is an image of the setup used, using ampere mode: 

    NB: Note that the ground connection from the measuring device is not directly connected to the DK here, this is not recommended as this would be an issue if both devices did not share the same ground plane through USB as it is in this case. 


    Also make sure that you have not accidently switched some of the other switches on the DK. 

    Regards,
    Jonathan

  • 0 in reply to JONATHAN LL

    Hello Jonathan,

    Please excuse my extremely late reply, but I was working on another more urgent task. Here is a video that showcases the issue in detail. I've checked the first two links that you've sent and to the best of my knowledge, I've followed them correctly.

    Video:

    I don't really understand your "NB: note" since I've followed the instructions from the second link precisely and there it says that both probes from the multimeter are connected to the two pins that are freed up by the removal of the jumper.

  • 0 in reply to Tudor B.

    Hello again Jonathan,

    My superior got me a PPK II and I tried doing the same connection as presented in that exercise that you linked. Same error and behaviour as when I tried using my multimeter: once that jumper is off, the nrf7002 chip is dead/ doesn't wanna communicate.

    But an interesting find is:

    https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/nRF5340_nRF7002_measure_current.html

    Based on that guide, I decided to follow the route of using just the first PPK II from the guide and try measuring just the nrf5340. Thankfully that works like a charm and can do measurements on the main chip.

  • 0 in reply to Tudor B.

    Finally found a way to do the measurement:

    The trick was to make the connection EXACTLY as can be seen in the picture below (notice the jumper left half on and the GND on the ground from the "2x PPKII both chips measurement" example and do a few resets:

    Is there a way of measuring TOTAL power draw without using 2x PPKII?

    Edit: the strange connection that I mentioned is completely unnecessary. What actually mattered is that the "Enable Power output" toggle in the Power Profiler app was made active prior to resetting/ turning on the board.

    The only question that remains is the one about using a single PPKII to measure the total power draw (if possible).

Reply
  • 0 in reply to Tudor B.

    Finally found a way to do the measurement:

    The trick was to make the connection EXACTLY as can be seen in the picture below (notice the jumper left half on and the GND on the ground from the "2x PPKII both chips measurement" example and do a few resets:

    Is there a way of measuring TOTAL power draw without using 2x PPKII?

    Edit: the strange connection that I mentioned is completely unnecessary. What actually mattered is that the "Enable Power output" toggle in the Power Profiler app was made active prior to resetting/ turning on the board.

    The only question that remains is the one about using a single PPKII to measure the total power draw (if possible).

Children
No Data
Related
Terms of service