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

yangyaoguang · ‎07-29-2025

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:

Is this a known issue with firmware version 16.92.21.p84.4 (FP92)?
What is the recommended firmware and driver pairing for Linux 5.4 platforms using the moal stack?
Are there known firmware-level limitations in STA mode that may cause Tx path stall or data flow blockage?
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

yangyaoguang · ‎07-29-2025

Platform Details:

SoC: NXP i.MX6ULL (ARMv7)
Kernel: Linux 5.4.24-imx6ull
WiFi Module: NXP SD8997 (SDIO interface)
Driver Stack: moal/mlan
Firmware: sdiouart8997_combo_v4.bin
→ Version: 16.92.21.p84.4 (FP92)
Power Table: tx_power_test.bin
WiFi Mode: STA (client mode only)ps_mode=0
auto_ds=0
fw_name=nxp/sdiouart8997_combo_v4.bin
txpwrlimit_cfg=nxp/tx_power_test.bin
drv_mode=3
sta_name=wlan
cfg80211_wext=0xf
Test Setup and Procedure:
- STA (SD8997) ←→ AP (SD8997)
- Channel: 5GHz, HT40, CH161
- Environment: non-shielded
- Tool: iperf3
  - Server: iperf3 -s -p 7777
  - Client: iperf3 -c <AP IP> -t 20 -i 1 -P 10

yangyaoguang · ‎07-29-2025

Christine_Li · ‎07-29-2025

Hi, @yangyaoguang

Thanks for creating case to us.

I saw you are using an old FW which is released on Dec 14, 2023.

Would you please help to try with our latest FW and driver?

Please see below for getting latest FW and driver.

For FW:

# git clone https://github.com/NXP/imx-firmware.git -b lf-6.12.20-2.0.0

# cd imx-firmware/nxp/

For driver:

# git clone https://github.com/nxp-imx/mwifiex.git -b lf-6.12.20-2.0.0

#

If still have same problem, please let me know and provide us wifi driver load parameters, dmesg logs.

Best regards,

Christine.

yangyaoguang · ‎07-31-2025

Dear Christine,

Thank you very much for your previous response and for providing the updated firmware and driver resources.

We have now successfully upgraded to the following versions as per your recommendation:

Firmware: https://github.com/NXP/imx-firmware.git -b lf-6.12.20-2.0.0
Driver:https://github.com/nxp-imx/mwifiex.git -b lf-6.12.20-2.0.0

After applying these updates, we reran our 5GHz STA performance tests using iperf3 with 10 parallel streams (-P 10). Unfortunately, the issue still persists — multiple iperf3 threads report 0.00 bits/sec throughput for prolonged periods, as shown in the attached log. This behavior occurs even in a stable test environment with minimal retransmissions and power-saving features disabled (ps_mode=0, auto_ds=0).

This pattern suggests a possible Tx path stall or queue starvation issue, potentially at the firmware or SDIO transport layer, despite successful association and initialization.

We would greatly appreciate your kind support on the following points:

Are there any known issues in STA mode under high-concurrency traffic with the current firmware/driver version?
Is there a debug version of the firmware that enables more detailed logging or assert tracing?
Are there any available patches or kernel-side workarounds (e.g., flow control tuning, SDIO IRQ coalescing)?

We remain at your disposal to provide complete dmesg logs, module load parameters, or additional diagnostics as needed.

Thank you again for your continued assistance and support. We truly appreciate your help in resolving this issue.

Best regards,
Yaoguang

The attachment contains the full test log, including dmesg output, iperf3 throughput results, and Wi-Fi configuration details, with the driver loaded via modprobe moal mod_para=nxp/wifi_mod_para.conf.

Christine_Li

Hi， @yangyaoguang

Have you test with other AP? For example, SD8997 works in STA mode, and connects to another AP(Not using SD8997). In this way, can you still reproduce this issue?

Are there any known issues in STA mode under high-concurrency traffic with the current firmware/driver version? ==>No. As I know, until now, we do not receive other customers report this issue with the latest FW.
Is there a debug version of the firmware that enables more detailed logging or assert tracing? ==> you can add below parameter when loading Wi-Fi driver to enable more driver logs.

drvdbg = 0x20037
Are there any available patches or kernel-side workarounds (e.g., flow control tuning, SDIO IRQ coalescing)? ==>No, as we didn't receive this kind of issue on the latest FW, we do not have patches workarounds.
For throughput performance tunning, maybe this link can help you somehow: https://docs.nxp.com/bundle/RM00297/page/connectivity-features/topics/throughput_performance_tuning....

For the issue you reported, I will continue to debug and try to test locally to see whether can reproduce it.

The dmesg you provided was null, please help to provide me again. Thanks.

Best regards,

Christine.

yangyaoguang

Hi Christine,

Thank you very much for your detailed response and suggestions.

We will first try the alternative test method by switching to another AP, and review the reference materials you provided. Hopefully, this will help us better understand and address the issue.

Thanks again for your support!

Best regards,
Yaoguang

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,

Thank you for your continued support on the 5GHz STA throughput dropping to 0 Mbps issue.

During ongoing stability and repeated reconnection testing, we’ve discovered a new problem:

After multiple EAPOL timeouts, the driver triggers an in-band reset, but the firmware then fails to reload via SDIO, leaving Wi-Fi in a non-functional state until reboot.

This issue seems to occur only after repeated connection failures. It may be related to how the firmware or SDIO interface handles recovery after in-band resets.

Here is the relevant dmesg log:

[87697.429777] WiFi Reset due to EAPOL timeout cnt 5
[87697.499968] ========START IN-BAND RESET===========
[87704.130302] wlan_sdio_poll_card_status failed, tries = 10000, cs = 0xc
[87704.259872] wlan_dnld_fw fail ret=0xffffffff
[87705.481337] woal_request_fw failed
[87705.484769] Firmware Init Failed

Could you please confirm whether this is a known issue, and if there is any workaround or firmware update available?

Thanks again for your support.

Best regards,
Yaoguang

Christine_Li

Hi, @yangyaoguang

This is a new issue.

Could you please help to create a new case to discuss this issue?

We always recommend our customer to follow different issue with different case so that we can better track the issue root cause and solution for future reference.

And for your information, this issue is related to FW reset, it might need our internal SAE team's help for tracking root cause. In other words, it will take longer time for global communications. Please pay more patient about this.

Let's keep tracking the original dropping to 0 issue in this thread.

Thanks for your understandings!

Best regards,

Christine.

yangyaoguang

Hi Christine,

Thanks for the clarification and suggestion.

I’ve created a new case to track this in-band reset recovery issue separately, as recommended.
Here is the link:
https://community.nxp.com/t5/Other-NXP-Products/SD8997-Wi-Fi-Fails-to-Recover-After-In-Band-Reset-Tr...

We’ll continue to follow the original throughput drop issue in this thread.

Thanks again for your support.

Best regards,
Yaoguang

yangyaoguang

Hi Christine,

We are still conducting ongoing tests on the SD8997 WiFi Module — 5 GHz STA throughput frequently dropping to 0 Mbps during iperf3 testing.
So far, we have:

Updated the driver and firmware
Tuned the SDIO max frequency in the DTS

These changes appear to help — the probability of throughput dropping to 0 Mbps has decreased. We’ll keep testing and share more data as we collect it.

Best regards,

Yaoguang

Christine_Li

Hi, @yangyaoguang

Thanks for your feedback.

Sure, let's keep touching on this case. If anything need from my side, please do not hesitate to let me know.

Thanks for your efforts.

Best regards,

Christine.

yangyaoguang

Hi Christine,

Thanks for your support. I’ll keep you posted if we find any other issues.

Best regards,

Yaoguang

Christine_Li

Hi, @yangyaoguang

How is your test?

Anything else I can do for this case?

Best regards,

Christine.

Christine_Li

Hi, @yangyaoguang

How is your test?

Anything else I can do for this case?

Best regards,

Christine.

yangyaoguang

Hi Christine,

Thanks for the follow-up.

We’ve tried adjusting the maximum SDIO interface clock frequency for the Wi-Fi module. Specifically, we reduced it from 100–200 MHz down to 50 MHz. After this change, we observed that:

The probability of Wi-Fi throughput dropping to 0 Mbps appears to have decreased.
However, the overall Wi-Fi performance also slightly dropped, likely due to the reduced SDIO bandwidth.

We’d like to check if you have any further suggestions for tuning or improving stability without significantly reducing throughput.

Looking forward to your guidance.

Best regards,

Yaoguang

Christine_Li

Hi, @yangyaoguang

1.If you keep the maximum SDIO interface clock frequency for the Wi-Fi module to 100MHz, whether can meet you requirement?

I noticed that when you reduced it to 50MHz, the overall Wi-Fi performance also slightly dropped.

2.And also, you have changed to other AP(not 88W8997) right?

3.Which module are you using? AW-CM276MA-SUR from AzureWave?

I don't have SD-UART module of 88W8997 on my hand, otherwise, I can try to test locally with I.MX6ULL-EVK.

Best regards,

Christine.

yangyaoguang

Hi Christine,

On our i.MX6ULL platform, keeping the SDIO clock at 100 MHz tends to trigger throughput drops to 0 Mbps more frequently during long-term iperf3 tests.

In fact, during parallel testing on our another product line using the i.MX8 platform, running at 100 MHz SDIO clock also led to CMD53 errors after 3–5 hours of continuous stress. Only reducing the clock to 50 MHz resulted in stable operation, though with slightly lower throughput.

5.4.70-imx8mp

The issue seems to involve both the Wi-Fi driver and the SDIO clock speed. Do you have any further insights or suggestions?

Best regards,
Yangyaoguang

Christine_Li

Hi, @yangyaoguang

1.When the iperf 5G throughput drops to 0Mbps, does the connection between AP and STA is still there? Or disconnected?

I seen below info in logs, but I am not sure the disconnection is triggered automatically or you trigger it manually.

=======

[41972.636502] wlan: Received disassociation request on wlan0, reason: 3
[41972.677171] wlan: REASON: (Deauth) Sending STA is leaving (or has left) IBSS or ESS
[41972.716536] Already disconnected

========

2. Please have a try with below para in wifi_mod_para.conf, to disable power saving mode and auto deep sleep mode.

ps_mode=2

auto_ds=2

3. If on your host side, there is any power saving related configurations, please also turn it off.

4. I checked our internal case, other customer meet this kind of issue when their SDIO is using DMA mode, if changing to ADMA mode, it will be ok. You can also check this point.

Best regards,

Christine.

yangyaoguang

Hi Christine,

Regarding your first point:
We can confirm that there was no manual intervention during the entire test.
From the logs, it seems like the Wi-Fi connection is automatically disconnecting and reconnecting.
(Our product is designed to trigger a reconnect if an abnormal disconnection is detected.)
If it’s just a short-term reconnection, this may be acceptable from our product perspective.

For point 2 and 3, we have already conducted experiments by disabling power saving mode and auto deep sleep mode on both the device and the host, but unfortunately it didn’t have a significant impact.

For point 4, we would like to know how to configure SDIO to switch from DMA mode to ADMA mode.
We’d like to try this approach to see if it improves the stability.

As a temporary solution, we have reduced the SDIO speed to 50 MHz and updated the driver to address the current issue.

Best regards,
Yang Yaoguang

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