WM02C(nrf7002) scan example failed after a one attempt

RE: WM02C(nrf7002) scan example failed after a one attempt

dev_nxp — Fri, 19 Sep 2025 11:03:30 GMT

Apologies for the confusion — the issue was on my end. Setting CONFIG_HEAP_MEM_POOL_SIZE correctly resolved it.

RE: WM02C(nrf7002) scan example failed after a one attempt

Simonr — Tue, 19 Aug 2025 07:12:03 GMT

Sorry about the late reply, but Susheel is currently out of office. Can you share some more details on when you see these UMAC timeouts? If you enable debugging I think you'll be able to see more detailed information on what exactly is failing here.

Best regards,

Simon

RE: WM02C(nrf7002) scan example failed after a one attempt

dev_nxp — Mon, 11 Aug 2025 05:39:06 GMT

Hi, sorry for the delay, and thank you for the suggestion. You were right—it was a power-up issue because the RPU was in sleep mode. However, I'm occasionally seeing a UMAC timeout error. How can I resolve this?

[00:00:08.043,000] <inf> wifi_nrf_bus: SPIM spi@40394000: freq = 8 MHz
[00:00:08.043,000] <inf> wifi_nrf_bus: SPIM spi@40394000: latency = 0
[00:00:08.168,000] <inf> wifi_nrf: Management buffer offload enabled

[00:00:23.168,000] <err> wifi_nrf: nrf_wifi_sys_fmac_fw_init: UMAC init timed out
[00:00:23.169,000] <err> wifi_nrf: nrf_wifi_sys_fmac_dev_init: nrf_wifi_sys_fmac_fw_init failed
[00:00:23.169,000] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_sys_fmac_dev_init failed
[00:00:23.169,000] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed
*** Booting Zephyr OS build v4.2.0 ***
[00:00:23.169,000] <inf> wifi_supplicant: wpa_supplicant initialized
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:23.171,000] <err> wifi_nrf: nrf_wifi_wpa_supp_set_key: rpu_ctx_zep is NULL
[00:00:23.171,000] <err> wpa_supp: _wpa_drv_zep_set_key: set_key op failed
[00:00:28.169,000] <inf> MAIN: Connecting to SSID: galaxyTab

RE: WM02C(nrf7002) scan example failed after a one attempt

Susheel Nuguru — Tue, 05 Aug 2025 07:37:19 GMT

the scan failures are not probably due to our sample code but to how the Wi-Fi chip is powered and clocked on your custom PCB. On your board, the nRF7002 is only ever kept awake and clocked long enough for the very first scan. As soon as that finishes, the RPU (Radio Processing Unit) falls back into low-power/reset and never gets re-enabled, hence the “RPU context not initialized” error on every subsequent attempt.

On our DK, Nordic’s DTS wiring does three key things that keep the chip alive across scans:

Dedicated power-enable GPIO (supply-gpios) that switches the nRF7002’s VDD rail on and off under software control.
Reset or buck-enable GPIO (reset-gpios) held low until the driver is ready to bring the RPU out of reset.
Wake-up GPIO (wakeup-gpios) to exit low-power mode after each operation.
24 MHz SPI clock (spi-max-frequency = <24000000>), matching the DK’s QSPI speed.

Your board was only using an 8 MHz SPI clock and didn’t have the power- and wake-control lines defined, so after the first scan the radio simply went to sleep. The fix is to mirror the DK’s &spi { wifi: .. } node in your device tree, updating the GPIO numbers for your layout:

&spi1 {
    status = "okay";
    wifi: wifi@0 {
        compatible = "nordic,nrf7002-spi";
        reg = <0>;
        spi-max-frequency = <24000000>;
        spi-hold-cs;
        supply-gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
        reset-gpios  = <&gpio0 11 GPIO_ACTIVE_LOW>;
        wakeup-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
        status = "okay";
    };
};

Once you rebuild with those three control lines wired up and the SPI bus running at 24 MHz, You should see the scan example succeed every time. If that does not work, then I will need to ask some assistance from my colleague to look into this.