[URGENT] SD8997 WiFi Module — 5GHz STA Throughput Frequently Drops to 0 Mbps During iperf3 Testing

[yangyaoguang]

Dear NXP Support Team,

I hope this message finds you well.

We are currently evaluating the performance of the NXP SD8997 WiFi module (SDIO interface) on an i.MX6ULL-based platform running Linux 5.4.24, using the official moal/mlan driver stack. The firmware in use is sdiouart8997_combo_v4.bin, version 16.92.21.p84.4 (FP92), along with the associated tx_power_test.bin power table. Firmware loads correctly, and the driver reports successful initialization without errors.

However, we are encountering a critical and reproducible issue: when operating in 5GHz STA mode, the WiFi throughput frequently drops to 0 Mbps during iperf3 testing, even in stable open-air environments. This issue significantly impacts our validation process and raises concerns about the module’s reliability in real-world deployments.

In our test setup, the SD8997 module connects as a station to a 5GHz AP (HT40, channel 161). We initiate standard iperf3 throughput tests (e.g., iperf3 -c <AP IP> -t 20 -i 1 -P 10), during which multiple threads consistently show zero throughput, despite minimal retransmissions. Disabling power save features (ps_mode=0, auto_ds=0) does not alleviate the issue. Firmware initialization and WLAN association complete successfully, and the interface transitions into the CONNECTED state normally. The problem begins only after traffic starts flowing.

This issue is currently blocking our development progress, as 5GHz STA stability is a critical requirement in our target application.

We kindly seek your urgent support on the following:

1. Is this a known issue with firmware version 16.92.21.p84.4 (FP92)?

2. What is the recommended firmware and driver pairing for Linux 5.4 platforms using the moal stack?

3. Are there known firmware-level limitations in STA mode that may cause Tx path stall or data flow blockage?

4. Is there any debug firmware, patch, or recommended workaround available to help isolate or resolve the issue?

We are happy to provide additional test data, full dmesg logs, configuration files, or conduct further diagnostic testing as needed.

Thank you very much for your time and support. We sincerely appreciate your assistance in helping us move forward.

Best regards,

Yangguang

[Christine_Li]

Hi, @yangyaoguang 

1.Can you please share the dts file to me?

To save your project info, you can sent it to my email:christine.li@nxp.com.

2.To enable the ADMA, you need add below line in dts:

dma-coherent;

3.To check whether ADMA has been enabled, you can check the dmesg(from device boot-up), dmesg | grep usdhc

mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA

Best regards,

Christine.

[yangyaoguang]

Hi Christine,

Please find below the DTS configuration for usdhc1 on our platform:

usdhc1: usdhc@2190000 {
        compatible = "fsl,imx6ul-usdhc", "fsl,imx6sx-usdhc";
        reg = <0x02190000 0x4000>;
        interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&clks IMX6UL_CLK_USDHC1>,
                 <&clks IMX6UL_CLK_USDHC1>,
                 <&clks IMX6UL_CLK_USDHC1>;
        clock-names = "ipg", "ahb", "per";
        fsl,tuning-step = <2>;
        fsl,tuning-start-tap = <20>;
        bus-width = <4>;
        status = "disabled";
};

&usdhc1 {
        compatible = "fsl,imx6ull-usdhc", "fsl,imx6sx-usdhc";
        assigned-clocks = <&clks IMX6UL_CLK_USDHC1_SEL>, <&clks IMX6UL_CLK_USDHC1>;
        assigned-clock-parents = <&clks IMX6UL_CLK_PLL2_PFD2>;
        assigned-clock-rates = <0>, <132000000>;
};

fragment@1 {
        target = <&usdhc1>;
        __overlay__ {
                pinctrl-names = "default", "state_100mhz", "state_200mhz";
                pinctrl-0 = <&pinctrl_usdhc1>;
                pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
                pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
                non-removable;
                keep-power-in-suspend;
                wakeup-source;
                fsl,sdio-interrupt-enabled;
                status = "okay";
        };
};

Please confirm if this matches the requirements for enabling ADMA on USDHC1.

Best regards,
Yangyaoguang

[yangyaoguang]

We have checked the logs, and ADMA is already enabled on our platform.
Here is the dmesg output:

root@Voice-Gateway:~# dmesg | grep ADMA
[    5.808617] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[    5.873090] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA

[Christine_Li]

Hi, @yangyaoguang 

Any updates on this case?

If you did any experiment or test related to this thread, please share me your information. So that we can keep moving forward on this thread.

Thanks.

Christine.

[yangyaoguang]

Hi Christine,

No, we were only using the Wi-Fi interface of the SD8997 during the performance test. Bluetooth was not enabled.

Best regards,
Yaoguang