2406818_ja-JP

はい

IW416の長期安定した運用設計について

NXPチームの皆様、こんにちは。

当社では、NXP IW416チップセットを搭載したu-blox MAYA-W1モジュールを使用しています。

環境
ハードウェア
ホストプラットフォーム:Rock3A
Wi-Fiモジュール:u-blox M2-MAYA-W1(NXP IW416ベース)
u-bloxが提供する評価用ハードウェア
SDIOホストインターフェース
ソフトウェア
Linuxカーネル:6.6.23
NetworkManager: 1.30.6
wpa_supplicant: 2.10
iw: 5.9

Wi-Fiドライバー/ファームウェア
ドライバー:MM6X16542.p8-(FP92)
ファームウェア: 16.92.21.p155.1

Wi-Fi設定
cntry_txpwr=1
cfg80211_wext=0xf
cal_data_cfg=なし
drv_dbg=0xFFFFFFFF

edmac オフ
その他の設定はすべてデフォルトです

ホスト・インターフェース：

SDIO（Wi-Fi専用、Bluetoothは使用しません。）

テスト条件

このデバイスは非常に弱い信号条件下でAPに接続された状態で連続的に動作します。

RSSIは通常次のようになります。

-80 dBm～-85 dBm

アクセスポイントが通信範囲の限界付近に位置しているため、接続が不安定で、再接続やスキャン動作が断続的に発生することが予想されます。

問題の説明

約10日間連続稼働すると、Wi-Fiインターフェース(mlan uap wfd)が消えます。

故障発生時：

FW_IN_BAND_RESETがトリガーされます
ファームウェアのリロード開始
ファームウェアのダウンロードが失敗します
mlan0および関連するインターフェースは消失します

ログには、次のようなエラーが含まれています。

FW_IN_BAND_RESET
...
wlan_dnld_fw 失敗 ret=0xffffffff

インバンドリセットシーケンスを実行しても、問題は自動的に回復しません。

質問

これはIW416ファームウェア16.92.21.p155.1の既知の問題ですか？

RSSIが弱い状態（-80～-85 dBm）
スキャン/再接続アクティビティの繰り返し
長時間運転
FW_IN_BAND_RESET
wlan_dnld_fw 失敗 ret=0xffffffff

システム設計の観点から、IW416を組み込み、長期的な安定した運用を必要とする製品に対して、NXPからの推奨される復旧戦略は何でしょうか?

システム設計者は、現場運用中に時折ファームウェア復旧イベントが発生すると想定し、それに応じてより高レベルの復旧メカニズムを実装すべきでしょうか?（PDn後またはRESET後のファームウェアのリロードなど）

添付：

dmesgログ
FW_IN_BAND_RESET 周辺の障害ログ

追加情報
mlan0の消失は、熱の問題やWi-Fiモジュールへの電力供給不足が原因であることを理解しています。

これらの可能性を排除するため、試験中に以下の対策が講じられた。

基板は外部ファンを使用して積極的に冷却された。
基板の温度は約30℃に維持された。
最大出力60Wの専用USB Type-C電源が使用されました。
試験中、電力供給の不安定性を示す兆候は一切見られなかった。

したがって、熱や電力に関する問題が今回の故障の主な原因である可能性は低いと考えられる。

よろしくお願いいたします。

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

こんにちは、 @developer123

最新リリースで試すのを手伝ってもらえますか:

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

最新のタグを選択してください：lf-6.18.20_2.0.0

FWを取得するには：

GitHub - nxp-imx/imx-firmware · GitHub

ドライバーを獲得するには:

GitHub - nxp-imx/mwifiex: WiFi拡張機能 · GitHub

よろしくお願いいたします。

Christine。

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

こんにちは、 @developer123

詳細なフォローアップと設計哲学の質問を明確に述べてくださりありがとうございます。これは確かに生産システムにとって重要な考慮事項です。

ご質問に直接お答えします。

はい、NXPが長期的な現場運用に推奨する設計哲学は、システム設計の一部としてホスト側の復旧メカニズムを実装することです。

また、IW416はリリースノートに記載されているように 、致命的なエラーに対する自動フォールカバリをサポートしています 。

Wi-Fiファームウェアの自動復旧理論をより深く理解するために、以下を参照することをお勧めします。

Wi-Fiファームウェアの自動復旧

報告された問題に戻りますが、最新のドライバ+FWの組み合わせで試してみてください。もしまだ再現できる場合は、dmesgログ、FWダンプ、ドライバーダンプを含む完全なログの提供に協力してください。

完全なログを取得するには、以下を実行してください。

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

よろしくお願いいたします。

Christine。

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

おすすめしていただきありがとうございます。

最新のドライバとファームウェアのリリースを評価します。

しかし、我々の主な疑問は、この特定の問題が新しいファームウェアバージョンで修正されたかどうかではありません。

実際の製品開発では、ソフトウェアのバージョンは製品リリース前のどこかで凍結されなければなりません。新しいファームウェアリリースが既知の問題を解決することはありますが、製品ライフサイクル全体を通じてすべてのファームウェアアップデートを継続的に追跡・展開することは一般的に現実的ではありません。

また、ファームウェアは時間とともに継続的に改良されており、新しいリリースで特定の問題が解決されることもありますが、将来的に追加の例外的な問題が発見される可能性もあります。

長期的に信頼性の高い現場運用を必要とする製品において、時折のファームウェア復旧イベントを通常のシステム設計の前提として考慮すべきでしょうか?

私たちはNXPのデザイン哲学を理解しようとしています。

よろしくお願いいたします。