nrf_wifi fails : memory allocation failure at boot and crash at config

[BrianW]

Using an nrf5340 with nrf7002 wifi, connected via SPI4. Using a shared (chip) antenna, and the COEX signals (pretty much exactly as per the dev board schema).

DTS snippets:

    // Wifi nrf7002 : SPI4 using SCK P0.08, MOSI P0.09, MISO P0.10, CS P0.11

    // BUCKEN P0.12, IRQ P0.23, COEX_GRANT P0.24, COEX_REQ P0.28, STATUS0 P0.30, STATUS1 P0.29, NRF7002_IOVDD_EN ioexp0/GPB0

    nrf_radio_coex: nrf7001-coex {

        status = "okay";

        compatible = "nordic,nrf700x-coex";

        req-gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;

        status0-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;

        grant-gpios = <&gpio0 24 (GPIO_PULL_DOWN | GPIO_ACTIVE_LOW)>;

        swctrl1-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>;

        // btrf-switch-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; No, controlled by nrf7002 directly???

    };

    nordic_wlan0: nordic_wlan0 {

        compatible = "nordic,wlan0";

        status = "okay";

    };

&spi4 {                     // Wifi nrf7002

    status = "okay";

    compatible = "nordic,nrf-spim";

    pinctrl-0 = <&spi4_default>;

    pinctrl-1 = <&spi4_sleep>;

    cs-gpios = <&gpio0 11 GPIO_ACTIVE_LOW>; /* P0.11 */

    pinctrl-names = "default", "sleep";

    nrf700x: nrf7002@0 {

        status = "okay";

        compatible = "nordic,nrf700x-spi";

        reg = <0>;

        spi-max-frequency = <33000000>;

//      sck-frequency = <24000000>;

        /* Wi-Fi Pins used */

        iovdd-ctrl-gpios = <&ioexp0 8 GPIO_ACTIVE_HIGH>;            // GPB00

        bucken-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;

        host-irq-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;

    };

};

I have configured prj.conf to have the wifi STA 'iot' operation, as per the docs:

# WIFI config
CONFIG_WIFI=y
CONFIG_WIFI_NRF700X=y

# WPA supplicant
CONFIG_WPA_SUPP=y
CONFIG_NRF700X_AP_MODE=n
CONFIG_NRF700X_P2P_MODE=n

# Networking layers
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_LOG=y
CONFIG_NET_IPV4=y
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
CONFIG_NET_DHCPV4=y

CONFIG_NET_IF_UNICAST_IPV4_ADDR_COUNT=2
CONFIG_NET_MAX_CONTEXTS=1
CONFIG_NET_CONTEXT_SYNC_RECV=y

CONFIG_NET_L2_ETHERNET=y

CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_INIT_TIMEOUT=0

CONFIG_NET_SOCKETS_POLL_MAX=1

# Memory usage
CONFIG_NET_TX_STACK_SIZE=4096
CONFIG_NET_RX_STACK_SIZE=4096

# Optimized networking settings for memory usage (STA MODE IOT DEVICES profile)
# https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/wifi/stack_configuration.html
CONFIG_NRF700X_MAX_TX_TOKENS=5
CONFIG_NRF700X_MAX_TX_AGGREGATION=1
CONFIG_NRF700X_RX_NUM_BUFS=6

CONFIG_NET_TC_TX_COUNT=1
CONFIG_NET_PKT_RX_COUNT=6
CONFIG_NET_PKT_TX_COUNT=6

CONFIG_NET_BUF_RX_COUNT=6
CONFIG_NET_BUF_TX_COUNT=12
# can take BUF_DATAT_SIZE down to 500
CONFIG_NET_BUF_DATA_SIZE=800

However, at boot time I see these logs:

[00:00:00.015,686] <inf> wifi_nrf_bus: SPIM spi@a000: freq = 33 MHz
[00:00:00.022,369] <inf> wifi_nrf_bus: SPIM spi@a000: latency = 1
[00:00:01.074,981] <err> wifi_nrf: hal_fw_patch_load: Failed to allocate memory for patch UMAC-bin: chunk 1/6, size: 8192
[00:00:01.086,639] <err> wifi_nrf: nrf_wifi_fmac_fw_load: UMAC patch load failed

[00:00:01.094,818] <err> wifi_nrf: nrf_wifi_fw_load: nrf_wifi_fmac_fw_load failed
[00:00:01.103,027] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fw_load failed
[00:00:01.113,891] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed

Note I also have configured malloc to use the system heap, and for it to occupy all remaining RAM:

CONFIG_COMMON_LIBC_MALLOC=y

CONFIG_COMMON_LIBC_MALLOC_ARENA_SIZE=-1

The heap size at boot time is 233576 bytes so no reason for a malloc to fail?

Then when I attempt to initialise the wifi I get this crash

[00:00:13.322,784] <err> os: ***** USAGE FAULT *****
[00:00:13.328,399] <err> os: Unaligned memory access
[00:00:13.334,197] <err> os: r0/a1: 0xa07eeaff r1/a2: 0x00000068 r2/a3: 0x0000005c
[00:00:13.342,834] <err> os: r3/a4: 0x20047130 r12/ip: 0x00000000 r14/lr: 0x00063dc9
[00:00:13.351,440] <err> os: xpsr: 0x61000000
[00:00:13.356,628] <err> os: Faulting instruction address (r15/pc): 0x0009bafe
[00:00:13.364,501] <err> os: >>> ZEPHYR FATAL ERROR 31: Unknown error on CPU 0
[00:00:13.372,375] <err> os: Current thread: 0x20007340 (sysworkq)
[00:00:13.379,180] <err> os: Halting system

in  nrf_wifi_osal_mem_zalloc() according to zephyr.map.

This is called somewherr from nrf_wifi_coex_config_non_pta():

    /* Configure Coexistence Hardware */

    log_info("netwifi: Configuring non-PTA registers. seperate antennas:%s  is_sr_protocol_ble: %s",separate_antennas?"YES":"NO", is_sr_protocol_ble?"YES":"NO");

    ret = nrf_wifi_coex_config_non_pta(separate_antennas, is_sr_protocol_ble);

    if (ret != 0) {

        log_warn("netwifi: Configuring non-PTA registers of CoexHardware FAIL");

        return false;

    }

Note the wifi sample projects (wifi_radio_test, wifi_shell)all run just FINE (with no error logs at boot) so the hardware is apparently good, but I haven't managed to get from them to my full app without this problem occuring...

Any ideas?

[Charlie]

Hi Brian，

Sorry for the late reply. I have been travling last week.

I did a try with the following configurations added to original NCS v2.7.0 https://docs.nordicsemi.com/bundle/ncs-2.7.0/page/nrf/samples/wifi/sta/README.html sample on nRF7002DK.

CONFIG_COMMON_LIBC_MALLOC=y

CONFIG_COMMON_LIBC_MALLOC_ARENA_SIZE=-1

CONFIG_RESET_ON_FATAL_ERROR=n

Here is the log:

*** Booting nRF Connect SDK v2.7.0-6a541e852d54 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
[00:00:00.609,130] <inf> net_config: Initializing network
[00:00:00.609,161] <inf> net_config: Waiting interface 1 (0x20000ed8) to be up...
[00:00:00.609,313] <inf> net_config: IPv4 address: 192.168.1.99
[00:00:00.609,344] <inf> net_config: Running dhcpv4 client...
[00:00:00.610,198] <inf> sta: Starting nrf7002dk with CPU frequency: 64 MHz
[00:00:01.610,382] <inf> sta: QSPI Encryption disabled
[00:00:01.610,443] <inf> sta: Static IP address (overridable): 192.168.1.99/255.255.255.0 -> 192.168.1.1
[00:00:01.610,443] <inf> sta: Waiting for Wi-Fi to be ready
[00:00:03.150,756] <inf> wifi_mgmt_ext: Connection requested
[00:00:03.150,787] <inf> sta: Connection requested
[00:00:03.150,848] <inf> sta: ==================
[00:00:03.150,878] <inf> sta: State: SCANNING
[00:00:03.451,019] <inf> sta: ==================
[00:00:03.451,049] <inf> sta: State: SCANNING
[00:00:03.751,190] <inf> sta: ==================
[00:00:03.751,220] <inf> sta: State: SCANNING
[00:00:04.051,361] <inf> sta: ==================
[00:00:04.051,361] <inf> sta: State: SCANNING
[00:00:04.351,531] <inf> sta: ==================
[00:00:04.351,562] <inf> sta: State: SCANNING
[00:00:04.651,702] <inf> sta: ==================
[00:00:04.651,733] <inf> sta: State: SCANNING
[00:00:04.951,873] <inf> sta: ==================
[00:00:04.951,904] <inf> sta: State: SCANNING
[00:00:05.252,044] <inf> sta: ==================
[00:00:05.252,075] <inf> sta: State: SCANNING
[00:00:05.552,215] <inf> sta: ==================
[00:00:05.552,215] <inf> sta: State: SCANNING
[00:00:05.852,386] <inf> sta: ==================
[00:00:05.852,416] <inf> sta: State: SCANNING
[00:00:06.152,557] <inf> sta: ==================
[00:00:06.152,587] <inf> sta: State: SCANNING
[00:00:06.452,728] <inf> sta: ==================
[00:00:06.452,758] <inf> sta: State: SCANNING
[00:00:06.752,899] <inf> sta: ==================
[00:00:06.752,899] <inf> sta: State: SCANNING
[00:00:07.053,070] <inf> sta: ==================
[00:00:07.053,100] <inf> sta: State: AUTHENTICATING
[00:00:07.236,053] <inf> sta: Connected
[00:00:07.251,525] <inf> net_dhcpv4: Received: 192.168.50.23
[00:00:07.251,678] <inf> net_config: IPv4 address: 192.168.50.23
[00:00:07.251,678] <inf> net_config: Lease time: 86400 seconds
[00:00:07.251,739] <inf> net_config: Subnet: 255.255.255.0
[00:00:07.251,770] <inf> net_config: Router: 192.168.50.1
[00:00:07.251,892] <inf> sta: DHCP IP address: 192.168.50.23
[00:00:07.363,464] <inf> sta: ==================
[00:00:07.363,494] <inf> sta: State: COMPLETED
[00:00:07.363,525] <inf> sta: Interface Mode: STATION
[00:00:07.363,555] <inf> sta: Link Mode: WIFI 6 (802.11ax/HE)
[00:00:07.363,555] <inf> sta: SSID: WiFi6
[00:00:07.363,586] <inf> sta: BSSID: C8:7F:54:91:94:50
[00:00:07.363,616] <inf> sta: Band: 2.4GHz
[00:00:07.363,616] <inf> sta: Channel: 10
[00:00:07.363,647] <inf> sta: Security: WPA2-PSK
[00:00:07.363,677] <inf> sta: MFP: Optional
[00:00:07.363,677] <inf> sta: RSSI: -26

I see you are using different NCS version, could you have a try with NCS v2.7.0?

Best regards,

Charlie

[BrianW]

Charlie said:

I see you are using different NCS version, could you have a try with NCS v2.7.0?

Well, I'm quite wary about doing an update to 2.7.0, as I understand there are some quite major changes to the build system (use of sysbuild), also maybe changes to the hardware DTS models?

I don't want to get even further behind in the project...

Can you try the change with NCS 2.6.2? 

[BrianW]

BrianW said:

Well, I'm quite wary about doing an update to 2.7.0, as I understand there are some quite major changes to the build system (use of sysbuild), also maybe changes to the hardware DTS models?

Now I have been forced to move to v2.8 in the hope this will fix the bugs in the wifi stack, I find I was indeed right to be afraid of the change to the HWM. everything that was working is now broken.

Can you point me to a HWMv2 / 2.8.0 compatble DTS example that works? The build seems no longer to recognise my nrf7002 DTS declarations, so rejects all the prj.conf setup...

My (previously working) DTS declaration:

&spi4 {                     // Wifi nrf7002

    status = "okay";

    compatible = "nordic,nrf-spim";

    pinctrl-0 = <&spi4_default>;

    pinctrl-1 = <&spi4_sleep>;

    cs-gpios = <&gpio0 11 GPIO_ACTIVE_LOW>; /* P0.11 */

    pinctrl-names = "default", "sleep";

    nrf700x: nrf7002@0 {

        status = "okay";

        compatible = "nordic,nrf700x-spi";

        reg = <0>;

//      spi-max-frequency = <33000000>;

        spi-max-frequency = <24000000>;

//      sck-frequency = <24000000>;

        /* Wi-Fi Pins used */

        iovdd-ctrl-gpios = <&ioexp0 8 GPIO_ACTIVE_HIGH>;            // GPB00

        bucken-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;

        host-irq-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;

    };

};

The build fails due to :

warning: WIFI_NRF70 (defined at drivers/wifi/nrfwifi/Kconfig.nrfwifi:8) was assigned the value 'y'
but got the value 'n'. Check these unsatisfied dependencies: (DT_HAS_NORDIC_NRF7002_SPI_ENABLED ||
DT_HAS_NORDIC_NRF7002_QSPI_ENABLED || DT_HAS_NORDIC_NRF7001_SPI_ENABLED ||
DT_HAS_NORDIC_NRF7001_QSPI_ENABLED || DT_HAS_NORDIC_NRF7000_SPI_ENABLED ||
DT_HAS_NORDIC_NRF7000_QSPI_ENABLED) (=n). See
docs.zephyrproject.org/.../kconfig.html and/or look up WIFI_NRF70 in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

The 'see' reference is deeply unhelpful about what DT_HAS_NORDIC_NRF7002_SPI_ENABLED is actually looking for so I don't know how to fix it?

Is there a migration guide for moving nrf700X config/setup to 2.8?

[Charlie]

Did you refer to the nRF7002DK dts file changes between NCS2.6.2 and NCS2.80 to modify you custom board dts files?

C:\ncs\v2.8.0\zephyr\boards\nordic\nrf7002dk> git fetch --tags

C:\ncs\v2.8.0\zephyr\boards\nordic\nrf7002dk> git diff  v3.5.99-ncs1-2 v3.7.99-ncs1 . >nrf7002dk_dts_change_ncs262_to_ncs280.patch

Or you can try to generate a new custom board DTS using nRF Connect for VS Code Extentsion under NCS 2.8.0.

Best regards,

Charlie

[BrianW]

Charlie said:

Did you refer to the nRF7002DK dts file changes between NCS2.6.2 and NCS2.80 to modify you custom board dts files?

I looked at the latest version and attempted to apply the changes I saw. Same for the 'wifi/sta' example to understand the changes for all the CONFIG_ keys.

The wifi part now at least gets past the DTC/KConfig.... can't tell if it works as I'm stuck with the flash no longer being seen as supported....( Trouble migrating from NCS 2.6 to 2.8 )

It's really not giving me great happiness about either Zephyr or Nordic : I really don't see why you couldn't keep the old keys valid as well, or at least provide a simple corrospondance table to help the poor idiots who have to deal with this...

[Charlie]

Hi Brian,

I’m sorry to hear that you’re struggling with the migration process. I understand how frustrating it can be when significant changes impact your workflow.

This isn’t the first time I’ve heard concerns like yours, but I’ve also encountered many developers who appreciate the continuous evolution of the SDK, with bug fixes and new features being added. Making NCS/Zephyr simpler to use is an ongoing journey for us.

From my personal experience, when updating my application across several SDK versions, I often find it helpful to start fresh by using the latest sample in the new SDK as a baseline, then gradually incorporating my existing application logic. This approach can save time debugging compatibility issues while offering a chance to review and improve your existing code. Of course, this is just my personal preference, and I hope it might be helpful for you too.

We’re here to support you as long as you need assistance.

Wishing you a Merry Christmas and a Happy New Year! Let’s continue working together in the new year.

Best regards,

Charlie 

[BrianW]

Charlie said:

From my personal experience, when updating my application across several SDK versions, I often find it helpful to start fresh by using the latest sample in the new SDK as a baseline,

Yes, normally I would be happy with this, but my application uses pretty much every feature of the nrf5340, so the question of which sample to start with is tricky.... It took a while to get all the features to properly work together on 2.6 (memory size is particular issue when pulling in the networking stuff!)....

Charlie said:

many developers who appreciate the continuous evolution of the SDK, with bug fixes and new features being added

Sure, but I'm not appreciating the removal of config keys without real documentation about what replaces them. It's very frustrating to have the config process spiut out another 'blah blah key is set but not set: why not look up the doc' and the doc is auto generated from the KConfig comment, but without any context...

Charlie said:

Wishing you a Merry Christmas and a Happy New Year! Let’s continue working together in the new year.

Merry Christmas and best wishjes for 2025 also!  The work will continue anyway - got to delivery our device to customers in Feb!