2406818_en-US

是

Regarding the design for long-term stable operation of the IW416

Hello NXP Team,

We are using the u-blox MAYA-W1 module based on the NXP IW416 chipset.

Environment
Hardware
Host platform: Rock3A
Wi-Fi module: u-blox M2-MAYA-W1 (NXP IW416 based)
Evaluation hardware provided by u-blox
SDIO host interface
Software
Linux Kernel: 6.6.23
NetworkManager: 1.30.6
wpa_supplicant: 2.10
iw: 5.9

Wi-Fi Driver / Firmware
Driver: MM6X16542.p8-(FP92)
Firmware: 16.92.21.p155.1

Wi-Fi Configuration
cntry_txpwr=1
cfg80211_wext=0xf
cal_data_cfg=none
drv_dbg=0xFFFFFFFF

edmac off
All other settings are default

Host Interface:

SDIO(Wi-Fi only; Bluetooth not used.)

Test Condition

The device is operated continuously while connected to an AP under very weak signal conditions.

RSSI is typically:

-80 dBm to -85 dBm

The connection is unstable and reconnect/scanning activities are expected to occur intermittently because the AP is located near the limit of the communication range.

Issue Description

After approximately 10 days of continuous operation, the Wi-Fi interface(mlan uap wfd) disappears.

At the time of failure:

FW_IN_BAND_RESET is triggered
Firmware reload starts
Firmware download fails
mlan0 and related interfaces disappear

The log contains errors similar to:

FW_IN_BAND_RESET
...
wlan_dnld_fw fail ret=0xffffffff

The issue does not recover automatically after the In-Band Reset sequence.

Questions

Is this a known issue for IW416 firmware 16.92.21.p155.1?

weak RSSI conditions (-80 to -85 dBm)
repeated scan/reconnect activity
long duration operation
FW_IN_BAND_RESET
wlan_dnld_fw fail ret=0xffffffff

From a system design perspective, for products incorporating the IW416 and requiring long-term stable operation, what is the recommended recovery strategy from NXP?

Should system designers assume that occasional firmware recovery events may occur during field operation and implement higher-level recovery mechanisms accordingly? (such as FW reloading after PDn or RESET)

Attached:

dmesg log
failure logs around FW_IN_BAND_RESET

Additional Information
We understand that disappearance of mlan0 can sometimes be caused by thermal issues or insufficient power supplied to the Wi-Fi module.

To eliminate these possibilities, the following countermeasures were applied during the test:

The board was actively cooled using an external fan.
Board temperature was maintained at approximately 30°C.
A dedicated USB Type-C power supply with a maximum output of 60 W was used.
No signs of power instability were observed during the test.

Therefore, thermal and power related issues are considered unlikely to be the primary cause of this failure.

Best regards

Re: Regarding the design for long-term stable operation of the IW416

Hi, @developer123

Can you please help to try with our latest release:

SD-WLAN-UART-BT-IW416-LNX_6_18_20-IMX8-16.92.21.p160-16.92.21.p160-MM6X16543.p18-GPL

Choose the latest tag: lf-6.18.20_2.0.0

To get FW:

GitHub - nxp-imx/imx-firmware · GitHub

To get driver:

GitHub - nxp-imx/mwifiex: WiFi extensions · GitHub

Best regards,

Christine.

Re: Regarding the design for long-term stable operation of the IW416

Hi， @developer123

Thank you for the detailed follow-up and for clearly articulating the design philosophy question — this is indeed an important consideration for production systems.

To address your question directly:

Yes, NXP's recommended design philosophy for long-term field operation is to implement a host-side recovery mechanism as part of the system design.

And also IW416 does support Auto FW recovery on fatal error as mentioned in our release note.

To better understand our Wi-Fi firmware automatic recovery theory, I recommend you to refer to below:

Wi-Fi Firmware Automatic Recovery

And back to the reported issue, hope you can have a try with the latest Driver + FW combinations. If still reproduce, please help to provide the full logs, including dmesg logs, FW dump and driver dumps.

To get full logs, please:

1. load driver with drvdbg=0xa0037
issue happened
logs will automatically save in this directory printed like below:
========================================
[ 4221.173141] Create directory /data/dump_4220 error, try create dir in /var
[ 4221.173147] Wakeup device...
[ 4221.173231] Create directory /var/dump_4220 successfully
[ 4221.173232] Directory name is /var/dump_4220
[ 4221.173233] === START DRIVER INFO DUMP===
[ 4221.173289] DRV dump data in /var/dump_4220/file_drv_info
[ 4221.173306] Wakeup device...
[ 4221.173889] SDIO Func0 (0x0-0x9): 43 03 06 00 07 00 00 02 03 00 
[ 4221.175173] SDIO Func1 (0x4-0xb): 00 00 00 00 ff ff ff ff 
[ 4221.175879] SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 
[ 4221.176284] SDIO Func1 (0xc0-0xca): dc fe 96 00 31 11 00 37 37 02 20 
[ 4221.177301] |
[ 4221.275861] SDIO Func1 (0xc0-0xca): dc fe a1 00 3b 00 00 37 37 02 20 
[ 4221.276501] Drv info total bytes = 263150 (0x403ee)
[ 4221.276503] === DRIVER INFO DUMP END===Wakeup device...
[ 4221.276555] ==== DEBUG MODE OUTPUT START: 4220.878602 ===
====================================================
If the dump is not auto-generated at "/var" or "/data" it can be collected manually using below "cat /proc/mwlan/adapter0/fw_dump > file_fw_dump" command.

2. If you check it doesn't print the directory in dmesg logs,
3.please get it in below way: 
- echo debug_dump > /proc/mwlan/adapter0/config 
- Wait for some time (1 or 2 min)
- cat /proc/mwlan/adapter0/fw_dump > file_fw_dump
drv_dump:
cat /proc/mwlan/adapter0/drv_dump > file_drv_dump

Best regards,

Christine.

Re: Regarding the design for long-term stable operation of the IW416

Thank you for the recommendation.

We will evaluate the latest driver and firmware release.

However, our primary question is not whether this specific issue has been fixed in a newer firmware version.

In practical product development, software versions must be frozen at some point before product release. While newer firmware releases may resolve known issues, it is generally not feasible to continuously follow and deploy every firmware update throughout the entire product lifecycle.

We also understand that firmware is continuously improved over time, and while a newer release may address a particular issue, additional corner-case issues may still be discovered in the future.

For products that require long-term reliable field operation, should occasional firmware recovery events be considered as part of the normal system design assumptions?

We are trying to understand NXP's design philosophy.

Best regards.

Re: Regarding the design for long-term stable operation of the IW416

Hi, @developer123

Sure.

Please take your time. And once need any further support, please do not hesitate to let me know.

Best regards,

Christine.

Re: Regarding the design for long-term stable operation of the IW416

Thank you for your reply.

There is a significant amount of investigation required, and reproducing the issue takes time.

The investigation into the new forward testing will take some time, but I will contact you again once the results are available.

Best regards.