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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

7,482 Views
yangyaoguang
Contributor III

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

0 Kudos
Reply
32 Replies

1,610 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

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

To save your project info, you can sent it to my email:[email protected].

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.

0 Kudos
Reply

1,605 Views
yangyaoguang
Contributor III

 

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

Tags (1)
0 Kudos
Reply

1,604 Views
yangyaoguang
Contributor III

 

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

 

Tags (1)
0 Kudos
Reply

1,592 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

Thanks for your info.

Yes, from your logs, I think ADMA already enabled on your board.

And I will escalated this issue to our internal team to ask help.

 

Best regards,

Christine.

0 Kudos
Reply

1,553 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

Please help to provide below info:

  1.  Please help provide complete DTS file.
  2. Use latest available release and help get the sniffer traces if issue is observed.
  3. Also please help get the in-sync dmesg log. Do not use any drvdbg.
  4. What is the ext. AP used? Can we get the ext. AP model/FW version details?
  5. Is issue observed on Channel-161 only? Can you check the issue scenario on other channels (36 or 40, etc) ?

Best regards,

Christine.

0 Kudos
Reply

1,519 Views
yangyaoguang
Contributor III

Hi Christine,

Thanks for your support.

After internal discussion and evaluation, we decided to adopt the following measures to address the issue:

  • Updated to the latest available Wi-Fi driver, and

  • Reduced the SDIO bus speed to 50MHz.

With these changes in place, the issue is no longer observed in our environment.
Currently, no further testing is planned beyond this scope.

Best regards,
YangYaoguang

Tags (1)
0 Kudos
Reply

1,513 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

Thanks for letting me know your plan.

So, Can we close this ticket for now?

And please do not hesitate to create new case to us if you need our help.

Best regards,

Christine.

0 Kudos
Reply

1,502 Views
yangyaoguang
Contributor III

Hi Christine,

Yes, we can close this ticket as the issue has been resolved.
Noted, and thank you for the support.

Best regards,
YangYaoguang

Tags (1)
0 Kudos
Reply

1,548 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

Any updates on our requested info?

 

Best regards,

Christine.

0 Kudos
Reply

1,527 Views
Christine_Li
NXP TechSupport
NXP TechSupport

Hi, @yangyaoguang 

Any updates on our requested info?

Please help to provide the requested info, so that we can help to resolve this issue ASAP.

Thanks.

 

Best regards,

Christine.

0 Kudos
Reply

2,202 Views
Christine_Li
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply

2,285 Views
yangyaoguang
Contributor III

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

0 Kudos
Reply