wifi_nrf fails to load: Boot_sig check failed, LMAC ROM boot check failed etc.

Hello,

Today was a very strange day - somehow I was able to incapacitate the WiFi functionality on the two 7002 DK boards, rev A and B! Funny that basic things seem to work just fine (eg hw_id sample) and wifi shell sample seems to load and start, too, with ability to run different commands, but the actual wifi_nrf driver is inaccessible. Several posts report similar problems, and most of them suggest setting CONFIG_NRF700X_REV_A=y in prj.conf - it didn't work for rev A board, and obviously (?) for rev B it's not needed at all. The issue happened while I was using v2.5.0 SDK, but reverting it back to v2.4.2 and v2.2.0 did not change anything.

Below is the full log from wifi/shell sample, SDK v2.2.0. Could you please help me understand what happened with my boards? Is it possible to recover them, reflash the nrf7002 companion IC?

Thank you for taking the time to investigate!

-Vigen

[00:00:00.430,145] <inf> wifi_nrf: QSPI freq = 24 MHz
[00:00:00.430,175] <inf> wifi_nrf: QSPI latency = 1
[00:00:01.041,625] <inf> wifi_nrf: wifi_nrf_fmac_fw_load: LMAC patches loaded

uart:~$ *** Booting Zephyr OS build v3.2.99-ncs1 ***
Starting nrf7002dk_nrf5340_cpuapp with CPU frequency: 128 MHz

[00:00:11.173,858] <err> wifi_nrf: wifi_nrf_hal_fw_chk_boot: Boot_sig check failed for RPU(0), Expected: 0x5A5A5A5A, Actual: 0x0
[00:00:11.173,919] <err> wifi_nrf: wifi_nrf_fmac_fw_load: LMAC ROM boot check failed
[00:00:11.173,950] <err> wifi_nrf: wifi_nrf_fmac_dev_add_zep: wifi_nrf_fmac_fw_load failed
[00:00:11.173,980] <err> wifi_nrf: wifi_nrf_drv_main_zep: wifi_nrf_fmac_dev_add_zep failed
[00:00:11.174,194] <err> wifi_nrf: wifi_nrf_if_init: vif_ctx_zep is NULL
[00:00:11.178,741] <inf> net_config: Initializing network
[00:00:11.178,802] <inf> net_config: IPv4 address: 192.165.100.150
[00:00:11.178,833] <inf> net_config: Running dhcpv4 client...
[00:00:11.184,814] <inf> wpa_supp: start_wpa_supplicant: 192 Starting wpa_supplicant thread with debug level: 3
[00:00:11.184,906] <inf> wpa_supp: Successfully initialized wpa_supplicant
[00:00:11.184,967] <inf> wpa_supp: iface_cb: iface wlan0 ifindex 1 00:00:00:00:00:00
[00:00:11.184,997] <inf> wpa_supp: Using interface wlan0
[00:00:11.185,028] <inf> wpa_supp: Initializing interface 0: wlan0
[00:00:11.185,089] <err> wpa_supp: wpa_drv_zep_init: Interface wlan0 not found
[00:00:11.185,119] <err> wpa_supp: wlan0: Failed to initialize driver interface
[00:00:11.185,180] <inf> wpa_supp: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
[00:00:11.185,302] <inf> wpa_supp: wpa_supplicant_main: exitcode -1
[00:00:11.279,754] <inf> net_config: IPv6 address: 2001:db8::1

  • Tried the OTP memory programming described in this post. Although I've never updated the MAC address in runtime, it was worth a shot. The result was disappointing agian - the OTP was not accessible. Below is the output from radio_test app:

    [00:00:27.393,066] <err> wifi_nrf: hal_rpu_ps_wake: RPU is not ready for more than 1 sec,reg_val = 0x0 rpu_ps_state_mask = 0x6
    [00:00:27.393,157] <err> wifi_nrf: rpu_mem_read_ram: RPU wake failed
    [00:00:27.393,341] <err> wifi_nrf: wifi_nrf_hal_otp_info_get: OTP info get failed
    [00:00:27.393,371] <err> wifi_nrf: wifi_nrf_fmac_rf_params_get: Fetching of RPU OTP information failed
    

  • Hello Vigen, 

    wifi shell sample seems to load and start, too, with ability to run different commands, but the actual wifi_nrf driver is inaccessible.

    And you've confirmed that they did previously work too? Before the thing that somehow happened.

    Vigen said:
    Tried the OTP memory programming described in this post.

    Did you remember powering it off and on (from hardware)? I've seen others having an issue because they've forgotten this.

    Several posts report similar problems, and most of them suggest setting CONFIG_NRF700X_REV_A=y in prj.conf - it didn't work for rev A board, and obviously (?) for rev B it's not needed at all.

    I believe there is only a need for this config in NCS 2.2, but it seems to mentioned here that you can set it to revision B by setting CONFIG_NRF700X_REV_A=n.  I guess you can try that, in case it gets enabled by default.

    This issue is a bit new to me, but I do see a few cases on DevZone that seems similar. One was solved by a getting a stable power supply, I guess your powering the DK from a USB cable? Have you tried changing it, in case there is anything wrong with it? 

    Are the switches in the right positions, and no solder bridges cut?

    Regards,

    Elfving 

  • Elfving, I've tried your suggestion with the USB cable replacement - just replacing the cable on J2 did not help. But then I added an external power supply via J3, and somehow the Rev B board (v1.0.2) was recovered right away (just flashed the wifi/shell app).

    Funny enough, I couldn't recover the Rev A board (v0.7.2) flashing v2.2.0 with CONFIG_NRF700X_REV_A enabled or disabled, v2.4.2 and v2.5.0. The symptom is still the same - the wifi_nrf driver fails to load. Could it be that there's a J3 power supply difference between Rev A and B boards?

  • Happy new year, and sorry about the wait. The holiday periods are a busy time for us.

    That sounds very odd to me. If so I would suspect that a cable in J2 should also do the trick. Did you try different cables as well as different USB ports?

    I am not sure if I understand. What do you mean by recovered here? That it was possible to flash them without issue?

    Vigen said:
    Could it be that there's a J3 power supply difference between Rev A and B boards?

    Could be, though I think it is just using a different version of the nRF7 chip. 

    Regards,

    Elfving

Related