WM02C(nrf7002) scan example failed after a one attempt

Hi Team,

I'm encountering an issue when using scan and STA mode.

When I run the shell example along with my custom board, the scan works successfully the first time. However, subsequent attempts fail.

I also ran a bus test, which passed successfully.

Additionally, when I run another standalone STA example, I get the following error:
"RPU context not initialized"

Please find the logs for both scenarios attached.

00> [00:00:00.002,000] <inf> wifi_nrf_bus: SPIM spi@40003800: freq = 8 MHz
00> [00:00:00.002,000] <inf> wifi_nrf_bus: SPIM spi@40003800: latency = 0
00> *** Booting Zephyr OS build v4.2.0 ***
00> [00:00:00.303,000] <inf> net_config: Initializing network
00> [00:00:00.303,000] <inf> net_config: Waiting interface 1 (0x240012e8) to be up...
00> [00:00:00.303,000] <inf> net_config: IPv4 address: 192.168.1.99
00> [00:00:00.303,000] <inf> net_config: Running dhcpv4 client...
00> [00:00:00.303,000] <inf> sta: Starting custom_h743ig with CPU frequency: 400 MHz
00> [00:00:00.303,000] <inf> wifi_supplicant: wpa_supplicant initialized
00> [00:00:01.303,000] <inf> sta: Static IP address (overridable): 192.168.1.99/255.255.255.0 -> 192.168.1.1
00> [00:00:01.311,000] <inf> net_wifi_mgmt: Connection requested
00> [00:00:01.311,000] <inf> sta: Connection requested
00> [00:00:01.311,000] <inf> sta: ==================
00> [00:00:01.311,000] <inf> sta: State: SCANNIN
00> 
00> [00:00:04.070,000] <inf> sta: ==================
00> [00:00:04.070,000] <inf> sta: State: DISCONNECTED
00> [00:00:04.270,000] <err> wifi_nrf: nrf_wifi_wpa_supp_scan2: RPU context not initialized
00> [00:00:04.270,000] <err> wpa_supp: wpa_drv_zep_scan2: scan2 op failed
00> [00:00:04.370,000] <inf> sta: ==================
00> [00:00:04.370,000] <inf> sta: State: DISCONNECTED

Parents
  • 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:

    1. Dedicated power-enable GPIO (supply-gpios) that switches the nRF7002’s VDD rail on and off under software control.

    2. Reset or buck-enable GPIO (reset-gpios) held low until the driver is ready to bring the RPU out of reset.

    3. Wake-up GPIO (wakeup-gpios) to exit low-power mode after each operation.

    4. 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.

Reply
  • 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:

    1. Dedicated power-enable GPIO (supply-gpios) that switches the nRF7002’s VDD rail on and off under software control.

    2. Reset or buck-enable GPIO (reset-gpios) held low until the driver is ready to bring the RPU out of reset.

    3. Wake-up GPIO (wakeup-gpios) to exit low-power mode after each operation.

    4. 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.

Children
  • 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

Related