Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
FRDM-MCXW72:AN14889 灵敏度测试 你好, 我正在按照 AN14889 中的步骤运行灵敏度测试 FRDM-MCXW72 ,但未成功 我使用以下序列在通道 0 (2402 MHz) 上运行测试。 你能帮忙查一下吗? 连接测试接口快捷方式 ------------------------------------------ -按 [t] 进行 Tx 操作 -按 [r] 进行 Rx 操作 -按 [z] 键可增加模式(GENFSK、BLE)和速率 -按 [x] 键降低模式(GENFSK、BLE)和速率 -按 [c] 键可在固定白化和单通道白化之间切换(仅适用于 BLE) 按 [q] 键向上切换频道 按 [w] 键向下切换频道 -按[a]键启动 按 [s] 键掉电 按 [n] 键增加有效载荷 按 [m] 键减少有效载荷 -按 [d] 键增加晶振调整值 -按 [f] 键可降低晶振调整值 这些按键可以在应用程序的各个角落用于更改 测试参数 ______________________________ __ | | | Select the Test to perform | |__ ______________________________| -按[1]连续测试 -按[2]进行丢包率测试 -按[3]进行范围测试 -按 [4] 调整 RTC 晶振 -按[5]调整PLL分子偏移 -按 [!] RESET MCU 模式 RX,速率 BLE 1Mbps,Whiten Chan,信道 42,功率 8,有效载荷 6,XtalTrim 10> -------------------------------------------------------------- [t] 发射 [z] 模式/速率+ [c] 固定/通道 wit。[q] Ch+ [a] Pw+ [r] 接收 [x] 模式/速率- [w] 通道- [s] 功率- [n] Pyld+ [d] XtalTrim+ [m] Pyld- [f] XtalTrim- -------------------------------------------------------------- ____________________ __ | | | PER Rx Test Menu | |__ ____________________| -按[空格键]开始/停止接收数据包 -按下任意按钮即可停止接收数据包 -按 [p] 上一菜单 模式 RX,速率 BLE 1Mbps,Whiten Chan,信道 42,功率 8,有效载荷 6,XtalTrim 10> PER 测试处方运行 PER 测试处方已停止 PER期间平均RSSI:0 dBm 已接收 0 个数据包(已发送 0 个数据包) 按 [ENTER] 键返回 Per Rx 测试菜单 我使用 BLE 测试仪发送标准 BLE 测试数据包,但板没有收到任何数据包。 该应用笔记没有对灵敏度测试做出任何设置。 另一方面,如果我使用 hci_bb 应用程序和标准 HCI 命令,则当测试仪发送 HCI_LE_RECEIVER_TEST 或 HCI_LE_ENHANCED_RECEIVER_TEST 时,板会随机卡在所有 PHY 上,导致无法运行测试。 发射器测试指令运行正常。 您能给我一些建议吗? 我使用的是 SDK_26_06_00_FRDM-MCXW72。 谢谢, 马可 开发板
View full article
RTD 7.0.0 で生成された設定ファイル名の問題 こんにちは、チームの皆さん、 機能群名SEHS2を付けましたが、この名前は生成されたファイル名に現れ、RTD 7.0.0とDS 3.6.4を使用しています。 以前の6.0.0ではそうではありませんでした。
View full article
s32k312でのセルフテスト NXPチームの皆様、こんにちは。 私はS32K312 SAR ADCを使用しており、ADCの自己テスト機能、特にアルゴリズムS、アルゴリズムC、およびRTD自己テストAPIについてより詳しく理解したいと考えています。 S32K3のリファレンスマニュアルや利用可能なドキュメントは確認しましたが、これらの自己テストアルゴリズム中にADCハードウェア内で実際に何が起きているのかを理解したいです。 1. アルゴリズムS – 供給自己テスト ドキュメントによると、アルゴリズムSは3つのステップで構成されており、バンドギャップ/基準/供給電圧などの内部ADC関連電圧をチェックするようです。 各アルゴリズムSステップで内部で何が起こっているのか、もう少し詳しく説明していただけますか? 例: S0、S1、S2の間、SAR ADCに接続されている内部信号は何ですか? 各ステップで測定される供給/参照物質はどれですか? ADCは、通常のADC変換で使用されるのと同じSAR変換パスを使用してこれらのテストを実行しますか? アルゴリズムSの実行中に、サンプリングコンデンサ/CDACも関与しますか? Self-Test アナログ Watchdogの閾値と比べて具体的に何が比較されるのでしょうか? 期待値/閾値は、工場出荷時の校正情報に基づいて算出されたものですか? 信号経路全体を理解したいです。 内部テスト電圧→サンプリングネットワーク→SAR/CDAC→コンパレータ→変換結果→自己テスト監視犬比較 2. アルゴリズムC – 容量性自己診断 私は特にアルゴリズムCを理解することに興味があります。 ドキュメントには、アルゴリズムCが複数のステップ(C0–C11)を持ち、容量性の自己テストを行うと記載されています。 これらのステップでADCハードウェアが実際に何をしているのか説明していただけますか? 私の現在の理解では、SAR ADCには容量性DAC/CDACが内蔵されており、アルゴリズムCは内部的にさまざまなコンデンサの組み合わせを動作させることで、サンプリング/変換コンデンサネットワークのエラーを検出します。 この理解は正しいでしょうか? より具体的に言うと: C0、C1、C2…C11の間で何が変わっているのでしょうか? 個々のコンデンサや2進加重コンデンサのグループがスイッチング・テストされているのでしょうか? アルゴリズムCの際に外部アナログ入力が使われるのか、それともテストは完全に内部で行われるのか? コンデンサネットワークにはどのような電圧/電荷が印加されますか? アルゴリズムCの各ステップで返されるADCの結果は、物理的に何を表していますか? ドキュメントには、以前にキャリブレーションされた値と比較して「オフセット/誤差」があると記載されています。この校正済み基準値はどこに保存されていますか? 期待される結果はどのように決定されるのですか? 理想的なアルゴリズムCの結果がほぼゼロになると期待されるのはなぜですか? アルゴリズムCはどのようなハードウェア障害を検出できるのでしょうか?例えば: コンデンサの不一致、 コンデンサのオープン/ショート、 スイッチの故障、 漏れ、 比較器エラー、 電荷再分配エラー。 可能であれば、サンプリングコンデンサ/CDAC、コンパレータ、SARロジックがアルゴリズムCにどのように関与しているか、簡略化された内部ブロックレベルの説明を教えていただけますか? 3. 通常変換とアルゴリズムCの違い 通常のADC変換の場合、その動作はおおよそ次のようになると理解しています。 入力サンプリング → サンプリング/CDACネットワークに蓄積された電荷 → SAR逐次近似 → 変換結果 アルゴリズムCの実行中、通常の外部入力サンプリングフェーズは、内部で生成されるコンデンサテスト条件に置き換えられますか? 言い換えれば、アルゴリズムCは主に外部ADCチャネルを測定するのではなく、アナログSAR変換経路自体をテストしているのでしょうか? 4. RTDセルフテストAPI 私はS32K3のRTD ADCドライバーを使っており、RTDセルフテストAPIが呼び出されたときに正確に何が起こるのかも知りたいです。例えば: Adc_Sar_Ip_SelfTest() この関数が実行する内部ソフトウェアのシーケンスについて説明していただけますか? これらの操作のうち、どれが実際にRTD APIによって行われ、どの操作がアプリケーションによって設定されるのか、明確に教えていただけますか? 私が特に知りたいのは以下の点です。 APIが自己テストを開始した後、アルゴリズムSとアルゴリズムCが1つのハードウェアシーケンスとして自動的に実行されるかどうか。 RTD API自体が結果を評価するのか、ADCハードウェアのアナログウォッチドッグが実際のPASS/FAIL比較を行うのか。 RTD関数からの戻り値/ステータスのうち、自己診断テストの失敗を示すものはどれですか。 5. 自己テストアナログ監視犬閾値 自己テストのアナログ監視ドッグ閾値がどのように決定されるのかも説明していただけますか? 上限値/下限値は以下のとおりです。 NXPが推奨する固定値、 デバイス固有の工場出荷時校正値、 Tresos/RTD構成によって生成されました。 あるいは、アプリケーション開発者が手動で設定しなければならない値は? アルゴリズムCに関して具体的に、C0~C11の各ステップにおける許容される正負の誤差範囲はどのように決定されるのでしょうか? 6. セルフテストのタイミング 最後に、自己診断テスト全体の実施時期について教えていただきたいです。 アルゴリズムSが3ステップ、アルゴリズムCが12ステップの場合: S0 → S1 → S2 → C0 → C1 → ... → C11 各ステップは内部的に以下のような完全なADC演算を実行しますか? 事前サンプリング+サンプリング+SAR変換+評価/ウォッチドッグ比較? もしそうなら、以下の予想実行時間を計算するためのドキュメントや数式はありますか? アルゴリズムS、 アルゴリズムC、 そして、S+Cの完全な自己診断テストは? 私の主な目標は、RTD関数を呼び出す方法だけでなく、S32K312 SAR ADCのセルフテストのハードウェア動作を理解することです。 可能であれば、S32K3専用のアプリケーションノート、詳細なADC自己テストドキュメント、またはRTDのソースやドキュメントでこれらのシーケンスを説明していただければ教えてください。 よろしくお願いします。 Re: Selftest in s32k312 こんにちは、 S32K3のリファレンスマニュアルや利用可能なドキュメントは確認しましたが、これらの自己テストアルゴリズム中にADCハードウェア内で実際に何が起きているのかを理解したいです。 そのために、詳細を説明したアプリケーションノートをSTで作成しました。テスト結果は、S32KがMPC56xxデバイスからモジュールを引き継いだのと同じです。 あなたの質問のほとんどはそこに回答されていますが、一般には公開されていません。もし NXP.com で1つ上がったらチケットで共有できます 自己診断テストの仕組みを詳細に説明するつもりはありません。 基本的な答えは次のとおりです。 S0、S1、S2の間、SAR ADCに接続されている内部信号は何ですか? ADC内部バンドギャップ電圧(S0 - step0)-(Vbandgap / Vref) ADC電源電圧(S1 - ステップ1)-(VDDA / Vbandgap) ADC基準電圧(S2 - ステップ2) – (Vref' / Vref) C0、C1、C2…C11の間で何が変わっているのでしょうか? 容量性自己テストアルゴリズムCは、11(または可変)のテスト変換(ステップ)のシーケンスを含み、 サンプリングコンデンサ/容量性DACを構成する容量性素子。このアルゴリズムは次のようになります。 サンプリングコンデンサマトリックスの欠陥を強調するために設計されています。各ステップは2つの要素を考慮します サンプリングコンデンサマトリックスの。各ステップでは、事前サンプリング、サンプリング、および 評価段階が実行されます。 よろしくお願いいたします。 ピーター
View full article
RTD 7.0.0 生成的配置文件名称问题 各位团队成员,大家好! 我已将功能组命名为 SEHS2,该名称出现在生成的文件名中,我正在使用 RTD 7.0.0 和 DS 3.6.4。 此前在 6.0.0 版本中并非如此。
View full article
分かりにくいデータシートNAFE33352 良い一日、 私の任務は、将来的にNAFE33352を使用する可能性を考慮して、その特性を評価し、テストすることですが、以下のデータシートに記載されている情報の一部が理解しにくく、見つけるのに苦労しています。https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf これまで、最も重要な機能にざっと目を通しただけで、以下のような問題点/疑問点がいくつか浮かびました(順不同)。 a) 7.6.3HV入力: シングルエンドアナログ測定の場合、データシートにはLVMUXを次のように構成すると書かれています: HV入力ポジティブ:AI1P、Isense HV入力ポジティブ:AI1N、Vsense 表12にはその構成が見つかりません。少し空想的に考えれば、最初のものは00010/bで、VsenseがVSNSだと仮定すると考えられます。しかし、2番目の組み合わせは存在しないようだ。たとえ存在したとしても、3つのSENSEピンをGNDに結びつければいいのでしょうか? AI1PとAI1NをGNDと比べて、他にどのように測定できますか?私のアプリケーションにはシングルエンドチャネルが2つ必要です。 b) 7.6.6低電圧多重化器へのアナログ入力(LV_MUX) 表12、VCMとは何ですか?図1に示すMUXのCOM入力は?COMは、差動PGAのコモンモード出力レベルのことですか?COMをシングルエンドの測定基準として使えますか? c) 5 ブロック図 なぜ1つのマルチプレクサに2つのLS入力があるのですか?また、それは何を意味するのですか?DACとVSENSEのAMPの出力はどのようにコネクテッドできますか? d) 7.5.8電圧源の極性切り替え(交流励起) VIEX_CHOPに何が起こったのですか?このセクションでは2回しか言及されていませんが、どこにあるのか、どのレジスタに設定すればよいのかは一切説明されていません。 e) 7.14 CMD_MM、マルチチャネルマルチリーディングコマンド それぞれのレジスタはどう設定すればいいですか?どのチャンネルから選べますか?このチップは2チャネルADCだけ搭載していないのでしょうか?このセクションで言及されているCH_CONFIGxレジスターはどこで見つけられますか? また、表20にはDATA0...最大8チャネルのDATA7についても記載されていますが、これ以上の情報はありません。これは何を意味するのでしょうか?表12の組み合わせはチャネルと見なされますか? 私が探している情報がデータシートのどこかにある可能性もありますが、たとえそうであっても、隠し方が多かったり、異なる用語や略語が使われているため、さらに混乱し、見つけにくくなります。 このICを使いたいなら、できるだけ早く評価ボードを注文する必要がありますが、未解決の疑問が多く、チップでできることが可能かどうかも分からないのでできません。要するに、アナログ入力が1つ、アナログ入力チャネルが2つ独立しています。 近いうちにご連絡いただけることを楽しみにしています。よろしくお願いします、 ルーカス SPI
View full article
Confusing datasheet NAFE33352 Good day, my task is to characterize and test the NAFE33352 for potential later use, but have difficulty following or locating some information in the following datasheet. https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf Until now, after just glancing over the most important functionalities, I have the following problems/questions in no specific order: a) 7.6.3 HV Input: For single-ended analog measurements the datasheet says to configure the LVMUX like this: HV input positive: AI1P, Isense HV input positive: AI1N, Vsense I can't find those configurations in Table 12. With a bit of fantasy, the first could be 00010/b, assuming Vsense is VSNS. But the second combination doesn't seem to exist. Even if they existed, do I just have to tie the three SENSE pins down to GND? How else can I measure AI1P and AI1N vs GND? I need two single-ended channels for my application. b) 7.6.6 Analog inputs to low-voltage multiplexer (LV_MUX) Table 12, what is VCM? The COM input of the MUX seen in Figure 1? Is the COM the common mode output level for the differential PGAs? Can I use COM as reference for my single-ended measurements? c) 5 Block diagram Why are there 2 LS inputs per MUX and what do the mean? How can the outputs of the AMPs of DAC and VSENSE be connected together? d) 7.5.8 Voltage sources polarity switching (AC excitation) What happened to VIEX_CHOP? It's only mentioned twice in this section but never where to find it and in which register to set it. e) 7.14 CMD_MM, multichannel multireading command How do I configure the respective registers, which channels can I choose from? Does this chip not only have a 2-channel ADC? Where can I find the CH_CONFIGx registers that are mentioned in the section? Also Table 20 mentions DATA0...DATA7 for up to 8 channels but no more information what this means? Are the combinations of Table 12 considered channels? It may be that some information I'm looking for is somewhere in the datasheet, but even if that is the case, it is well hidden or a different terminology/abbreviation is used, which makes it even more confusing and hard to find. If I want to use this IC, I would need to order an eval-board as soon as possible, but I can't with so many open questions and not knowing if it's even possible to do what I try to do with the chip. In a nutshell, one analog input and 2 independent analog input channels. Hoping to hear from you soon. Best regards, Lukas SPI
View full article
NAFE33352 数据手册令人困惑 再会, 我的任务是表征和测试 NAFE33352,以便将来可能使用,但在以下数据表中,我很难理解或找到某些信息。https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf 到目前为止,在粗略浏览了最重要的功能之后,我还有以下问题/疑问,排名不分先后: a) 7.6.3高压输入: 对于单端模拟测量,数据手册中指出 LVMUX 的配置方式如下: 高压输入正极:AI1P、Isense 高压输入正极:AI1N、Vsense 我在表 12 中找不到这些配置。稍加想象,第一个可能是 00010/b,假设 Vsense 是 VSNS。但第二种组合似乎并不存在。即使它们存在,我是否只需要将三个感知引脚接地即可? 除了以上方法,我还能如何测量 AI1P 和 AI1N 与 GND 的关系?我的应用需要两个单端通道。 b) 7.6.6低压多路复用器 (LV_MUX) 的模拟输入 表 12,VCM 是什么?图 1 中所示的 MUX 的 COM 输入是什么?COM 是差分 PGA 的共模输出电平吗?我可以将 COM 用作单端测量的参考吗? c) 5 方框图 为什么每个多路复用器有 2 个 LS 输入,它们分别代表什么?如何将 DAC 和 VSENSE 的 AMP 输出端连接在一起? d) 7.5.8电压源极性切换(交流激励) VIEX_CHOP 发生了什么事?本节中只提到了两次,但从未说明在哪里可以找到它,以及应该在哪个寄存器中设置它。 e) 7.14 CMD_MM,多通道多读命令 我该如何配置各个寄存器?我可以从中选择哪些通道?这款芯片不仅有双通道ADC吗?我可以在哪里找到本节中提到的 CH_CONFIGx 寄存器? 表 20 中提到了 DATA0...DATA7,最多可表示 8 个通道,但没有提供更多信息说明其含义?表 12 中的组合是否被视为通道? 或许我要找的信息就在数据手册的某个地方,但即使是这样,它也隐藏得很深,或者使用了不同的术语/缩写,这使得查找起来更加令人困惑和困难。 如果我想使用这款集成电路,我需要尽快订购一块评估板,但由于还有太多疑问,而且我也不知道是否能够用这款芯片实现我想要的功能,所以我无法订购。简而言之,就是一个模拟输入和两个独立的模拟输入通道。 希望能尽快收到您的回复。此致, 卢卡斯 SPI
View full article
i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12.23 Title: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12.23 Hello NXP Team, I am debugging WiFi initialization on the following setup: Board: NXP i.MX95 19x19 EVK WiFi module: u-blox JODY-W263-00B Android build: AOSP 15 (Android property verification pending) Running kernel: 6.12.23-android16-5-maybe-dirty-4k Exact NXP Android BSP release/tag: not yet confirmed WiFi driver: mlan/moal (MWLAN) Selected firmware: sduart8987_combo.bin SDIO device: mmc2:0001:1 Running kernel information: The SDIO device is detected, and the driver reports “FW download over”. However, the firmware does not become active within the timeout, and the WiFi SDIO probe fails. Relevant boo$ adb shell uname -a Linux localhost 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT Thu Jan 1 00:00:00 UTC 1970 aarch64 Toybox t logs: [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully After unloading and reloading the driver, I also observed: [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 I found this related community discussion: https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 The discussion concerns 88W8801 on Nvidia AGX Orin, so it is a different module/platform. The author reported improvement after removing no-sd and changing bus-width from 4 to 1, followed by successful operation with the original configuration. I have not yet tested these changes on my board. Could you please help clarify: Is sduart8987_combo.bin the correct firmware for JODY-W263-00B? Which firmware release and mlan/moal driver revision are recommended for this Android/kernel combination? What are the recommended SDIO device-tree settings for this module on the i.MX95 19x19 EVK, particularly bus width, maximum frequency, pinctrl, power supplies, reset GPIO, and power-sequence delays? Would testing bus-width = <1> or a lower SDIO clock help diagnose this timeout? Is removing no-sd relevant or recommended for this platform? What could cause the firmware activation timeout after the driver reports firmware download completion? Does downloaded 0 after driver reload indicate that a full module power cycle or hardware reset is needed before retrying? Are there known issues or required patches for this board/module/kernel combination? Which additional debug settings, SDIO register dumps, or logs should I collect to distinguish firmware/driver compatibility issues from SDIO communication or power/reset sequencing issues? I can provide the full boot log, relevant device-tree nodes, wifi_mod_para.conf, and exact BSP/driver revisions once confirmed. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hello NXP Team, We have collected further diagnostic evidence for the firmware activation timeout on i.MX95 19x19 EVK with JODY-W263-00B. Hardware mode verification Both register reads succeed: WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection The masked strap indicates SD-UART mode according to our driver source, consistent with the configured firmware name. Download-loop exit confirmed WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! The requested-length registers remain zero throughout 100 polling attempts, causing the download loop to exit. Firmware binary inspection Using the source’s 16-byte FWHeader layout and command-length rules, offline parsing identifies a CMD4 record at offset 619140, ending at 619156—exactly matching the download counter. The source defines CMD4 as FW_HAS_LAST_BLOCK. There are 9044 bytes after this record. We have not established their purpose or confirmed that these parsing rules fully describe the SDIO bootloader format. We therefore do not consider the counter difference alone proof of an incomplete download. Additional details: MOAL/MLAN version: 537.p9 Embedded firmware string: w8987o-V0, RF878X, FP92, 16.92.21.p151.4 Firmware size: 628200 bytes SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 Actual 1-bit SDIO operation was previously verified at 50 MHz, with the same timeout. The latest diagnostic test runs at 4-bit, 50 MHz. Expected firmware READY status is 0xfedc; observed status remains 0xf005. No Wi-Fi network interface is created. Exact NXP BSP release/tag is still being confirmed. Could you please clarify: Is stopping at the CMD4 boundary, offset 619156, expected for this specific image? What is the purpose of the remaining 9044 bytes? What does 0xf005 indicate during SD8987 firmware activation? Is firmware containing version string 16.92.21.p151.4 supported with driver 537.p9 for JODY-W263-00B? Which BSP and firmware/driver package should we use? Which module power/reset timing, supply and reference-clock checks are recommended for this failure? Which additional registers or diagnostics would distinguish a firmware startup failure from a communication or hardware initialization issue? The firmware binary remains unchanged. Our source modifications add diagnostic logging, and full boot logs and source diffs are available. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 One important clarification about the failure stage: The processor detects the SD8987 Wi-Fi device over SDIO, and the firmware download routine reports “FW download over”. However, during the subsequent activation check, the driver expects SDIO_FIRMWARE_READY = 0xfedc, while the reported status is 0xf005. Firmware initialization and the SDIO probe therefore fail, and no Wi-Fi network interface is created. This remains unchanged after verifying actual 1-bit SDIO operation at 50 MHz. Could you please explain what 0xf005 indicates for SD8987 at this stage and which additional register values or logs would help identify why the firmware does not reach READY status? Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hello NXP Team, Following up on my original report, we have completed additional checks and a controlled SDIO bus-width experiment. Wi-Fi initialization still fails at the firmware activation stage. 1. Confirmed device and software details Board/module: i.MX95 19x19 EVK with JODY-W263-00B Android fingerprint: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys Kernel: 6.12.23-android16-5-maybe-dirty-4k Exact NXP BSP release/tag: still being confirmed SDIO device: mmc2:0001:1 SDIO ID: 02DF:9149, mapped to SD8987 in the driver source Host controller: USDHC3, mmc@428b0000 Both moal and mlan report version 537.p9 MOAL srcversion: 358C14898F4DDF4EB40AB03 Source repository revisions: nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad imx-firmware: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b Both commits have the subject “MA-23689-1 [Android-15]WCS Q2 release patch integrate”. Mapping these source revisions to the installed module build is still being verified. 2. Firmware identity verified The selected firmware is /vendor/firmware/sduart8987_combo.bin, size 628200 bytes. The source copy and installed board copy have the same SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 This confirms that the copies match; firmware compatibility with the module still needs confirmation. 3. Actual 1-bit SDIO test completed Initially, the live Device Tree reported bus-width = <1>, but /sys/kernel/debug/mmc2/ios still showed 4-bit operation. In our source, mmc_of_parse() does not clear an existing 4-bit capability for bus-width = <1>, while generic SDHCI setup adds MMC_CAP_4_BIT_DATA unless SDHCI_QUIRK_FORCE_1_BIT_DATA is set. We therefore added a diagnostic block in sdhci-esdhc-imx.c, immediately after the mmc_of_parse() error check: { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } After rebuilding and deploying the modified kernel and DT configuration, we verified: Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) However, the same failure remained: Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 No Wi-Fi network interface appears. The configured maximum frequency is 100 MHz, but actual operation remained at 50 MHz. We have therefore not completed a lower-clock test. Also, no-sd was absent from the reviewed USDHC3 configuration, so no removal was performed. 4. WLAN-only firmware reload test We temporarily bind-mounted sd8987_wlan.bin over the configured firmware path and reloaded MOAL. The driver read the alternative file size, but reported: firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! Because this was a reload after an earlier failed initialization, we consider the result inconclusive. It does not establish WLAN-only firmware compatibility or successful transfer. A reboot removed the temporary bind mount, and the original 628200-byte combo firmware was verified again. 5. Current investigation We are preparing diagnostic logging in moal_sdio_mmc.c to capture: Raw chip magic and host strap register values. Return status of both register reads. Masked magic and strap values. The source defines CHIP_MAGIC_VALUE = 0x24 and CARD_TYPE_SD_UART = 0. The existing boot log did not expose these values. This logging change has not yet been deployed. The exact meaning of firmwarestat=0xf005 and the repeated 9044-byte difference between firmware size and download counter remain unresolved. We are not treating the completion message as proof that firmware is active. Could you please advise on the following? Is this firmware/driver package appropriate for JODY-W263-00B on this BSP/kernel? How can we identify the exact firmware release from the binary or package? Is downloaded 619156 for a 628200-byte combo image expected for this firmware format, or does it indicate premature termination? What does firmware status 0xf005 mean for SD8987 during initialization? Is the diagnostic host-driver change above appropriate for enforcing a 1-bit test, or is there a preferred BSP mechanism? Which registers/logging should we collect to verify strap-based firmware selection, and does an explicit fw_name override that selection? What power/reset sequence is required before retrying after this failure? Would you recommend a lower-clock test or another targeted experiment next? We can provide the full boot logs, DT/overlay changes, host-driver diff, and wifi_mod_para.conf. Thank you.
View full article
RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi, We are implementing WPA2-Enterprise / IEEE 802.1X on an RW612-based product using Zephyr 4.3 and Hostap/wpa_supplicant. Initial authentication works correctly with both PEAP/MSCHAPv2 and EAP-TLS. EAP-TLS also works with a PSA/ELS-backed non-exportable private key. We see a problem specifically during Wi-Fi in-place reauthentication. Observed sequence: RADIUS Access-Accept → EAP success → 4-way handshake → AP retransmits Message 3 → Wi-Fi link is lost → device reconnects and authenticates successfully again Our current evidence suggests a possible ordering issue between transmission of the final EAPOL-Key response and installation of the new PTK. The PTK update appears able to proceed while the final EAPOL frame may still be queued for transmission. We tried to find a supported mechanism to guarantee: final EAPOL-Key frame transmission completed BEFORE new PTK installation However, we could not find an EAPOL TX-completion callback, TX queue drain/fence, or equivalent API in the RW612 Wi-Fi driver/firmware path. As a diagnostic experiment only, adding a 100 ms delay before PTK installation allowed several PEAP and EAP-TLS reauthentication attempts to complete without interruption. We do not consider a fixed delay to be a production solution. Could you please clarify: - Is there a supported API to know when an EAPOL data frame has actually been transmitted by the firmware? - Is there a TX queue flush/drain or key-install fence that should be used before updating PTK? - Is this a known limitation or known issue in the RW612 Wi-Fi driver/firmware? - Is there a newer driver or Wi-Fi firmware version that addresses this? Tested versions: RW612 driver: v1.3.r52.z_up.p11 Wi-Fi firmware: 18.99.6.p47 We can provide detailed traces and a vendor issue package if needed. Thanks. RW612 
View full article
RT1170 支持 QSPI Flash (MX25L51245G) 您好, RT1170 是否支持 MX25L51245G QSPI 闪存? 是否需要修改配置文件“evkmimxrt1170_flexspi_nor_config.c”才能与该芯片兼容? 如果是这样,该如何修改?应该修改哪些参数? 感谢您的支持! 顺祝商祺! 世界青年大会 Re: RT1170 support QSPI Flash (MX25L51245G ) 你好@jeremyzhou 我们使用 MX25L51245G 外置闪存和 RT1176,并实现了如下所示的配置。它在 XIP 模式下运行完美,但我也想得到您的验证。 但是,当在“链接应用程序模式”下运行多核应用程序时,系统会发生硬故障。具体来说,由于从 FlexCAN MCR 寄存器读取的值,它触发信号一个断言。 下面附上一些截图和我的查找表供您参考,引用。 M7 闪存初始化(RAM): M4 闪存初始化(RAM): 多核(RAM)的硬故障: 以下是为支持软件在 RAM 和 XIP(就地执行)模式下无缝运行而设计的查找表配置:   #define FLASH_DUMMY_CYCLES 0x08 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG , .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc= kFlexSPIReadSampleClk_LoopbackFromDqsPad , .csHoldTime = 3u, .csSetupTime = 3u, .controllerMiscOption = 0x10, .deviceType = kFlexSpiDeviceType_SerialNOR , .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz , // kFlexSpiSerialClk_120MHz​​ .sflashA1Size = 64u * 1024u * 1024u, //64MB //她的acilista QE = 1. ROM 一次 WREN'i ( seq 3) kendisi gonderir , sonra 4*12' yi 0x40 ile calistirir . //NXP RT1170 EVK'daki configCmd kalibinin aynisi .configCmdEnable = 1u, .configModeType[0] = kDeviceConfigCmdType_Generic, .configCmdSeqs[0] = {.seqNum = 1u, .seqId = 12u, .reserved = 0u}, //1 个序列calistir : 4*12 // asagiyi 0x20 yapinca calismadi Dogrudan内存hatasinda patladi main'e gelmeden .configCmdArgs[0] = 0x40u, //WRITE_SDR'nin gonderecegi 字节: SR = 0x40 .lookupTable = { [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x6C, RADDR_SDR, FLEXSPI_1PAD, 0x20), //6Ch QREAD4B: komut ve 4 字节地址tek hattan (1-1-4) [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), //8 虚拟bekle , 数据 4 hattan [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), //状态寄存器0x05'den okuyacam (WIP = bit0) [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), //写入en ettim // asagidakini yoruma alinca gercekten silmedi [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4 字节地址alarak 4 kb扇区silecem [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20), //64 kb块silecem (app'de kullanmiyoruz ) [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4 字节 1 页yazacam [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // datayi gonder ve bitir (WEL'i flash 程序bitince kendisi temizler ) [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC7, STOP, FLEXSPI_1PAD, 0x0), //转flashi silecem (app'de kullanmiyoruz ) [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x01, WRITE_SDR, FLEXSPI_1PAD, 0x01), //WRSR + tam 1 字节 (configCmdArgs[0]): sadece SR yazilir , CR'ye dokunmaz // seq 6/7 bos : ROM API 暂停/恢复kullanmiyor }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 0x1, .blockSize = 64u * 1024u, .isUniformBlockSize = true, }; Re: RT1170 support QSPI Flash (MX25L51245G ) 你好, 感谢您对恩智浦半导体产品的关注,并感谢您给我们提供服务的机会。 1) RT1170 是否支持 MX25L51245G 作为 QSPI 闪存? - 是的。 2)是否需要修改配置文件“evkmimxrt1170_flexspi_nor_config.c”以适配此芯片? 是的,请参考以下代码。 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64u * 1024u * 1024u, .lookupTable = { // Read LUTs FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 256u * 1024u, .isUniformBlockSize = false, }; 祝你有美好的一天, 信息通信技术 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
View full article
RW612 WPA2-Enterprise再認証 – PTKインストール前のEAPOL TX完了 こんにちは、 Zephyr 4.3とHostap/wpa_supplicantを使用したRW612ベースの製品上でWPA2-Enterprise / IEEE 802.1Xを実装しています。 初期認証はPEAP/MSCHAPv2およびEAP-TLSの両方で正しく動作します。EAP-TLSは、PSA/ELSで保護された非エクスポート型の秘密鍵でも動作します。 特にWi-Fiのインプレース再認証時に問題が発生することが確認されています。 観測されたシーケンス: RADIUS アクセス-受け入れ → EAPの成功 → 4ウェイハンドシェイク → APがメッセージ3を再送信します → Wi-Fi接続が途絶えました →デバイスは再接続し、再び認証に成功します 現在の証拠は、最終的なEAPOL-Key応答の送信と新しいPTKの設置の間に順序の問題の可能性を示唆しています。 PTKの更新処理は、最終的なEAPOLフレームが送信待ちの状態であっても、続行できるようです。 私たちは、以下のことを保証するサポートされたメカニズムを見つけようとしました。 最終的なEAPOLキーフレーム送信が完了しました 前に 新しいPTKのインストール しかし、RW612のWi-Fiドライバ/ファームウェアパス内でEAPOL TX完了コールバック、TXキュードレイン/フェンス、または同等のAPIは見つかりませんでした。 診断実験としてのみ、PTKのインストール前に100ミリ秒の遅延を追加することで、PEAPおよびEAP-TLSの再認証試行が複数回、中断なく完了することができました。固定遅延は、生産上の解決策とは考えていません。 もう少し詳しく教えていただけますか: ファームウェアによってEAPOLデータフレームが実際に送信されたかどうかを知るための、サポートされているAPIはありますか? - PTKを更新する前に使うべきテキストラキューのフラッシュ/ドレインやキーインストールフェンスはありますか? - これはRW612のWi-Fiドライバ/ファームウェアにおける既知の制限や既知の問題ですか? - この問題に対応する新しいドライバやWi-Fiファームウェアはありますか? テスト済みバージョン: RW612ドライバ:v1.3.r52.z_up.p11 Wi-Fiファームウェア:18.99.6.p47 必要に応じて詳細なトレースやベンダー発行パッケージをご提供いたします。 ありがとう。RW612
View full article
i.MX95 19x19 EVK with JODY-W263-00B:Android 15 / Linux 6.12.23でのWiFiファームウェアの有効化タイムアウト タイトル:i.MX95 19x19 EVK with JODY-W263-00B:Android 15 / Linux 6.12.23におけるWiFiファームウェアの有効化タイムアウト NXPチームの皆様、こんにちは。 以下の構成でWiFiの初期化に関するデバッグを行っています。 ボード: NXP i.MX95 19x19 EVK WiFiモジュール:u-blox JODY-W263-00B Androidビルド:AOSP 15(Androidプロパティ認証待ち) 実行中のカーネル: 6.12.23-android16-5-maybe-dirty-4k 正確なNXPのAndroid BSPリリース/タグ:まだ確定していません WiFiドライバ:mlan/moal(MWLAN) 選択されたファームウェア: sduart8987_combo.bin SDIOデバイス: mmc2:0001:1 カーネル情報の実行: SDIOデバイスが検出され、ドライバが「FWダウンロードオーバー」と表示します。しかし、ファームウェアはタイムアウト時間内にアクティブにならず、WiFi SDIOプローブが失敗します。 Relevant boo$ adb shell uname -a Linux localhost 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT 1970年1月1日木曜日 00:00:00 UTC aarch64 Toybox tログ: [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully ドライバをアンロードして再ロードした後、次のことも観察しました: [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 関連するコミュニティの議論を見つけました。 https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 議論はNvidia AGX Orin上の88W8801に関するもので、異なるモジュール/プラットフォームです。著者はノーSDを除去しバス幅を4から1に変更し、元の構成で正常に動作した結果改善を報告しています。これらの変更を自分のボードでまだテストしていません。 もう少し詳しく教えていただけますか: Is sduart8987_combo.bin JODY-W263-00Bの正しいファームウェアですか?このAndroid/カーネルの組み合わせには、どのファームウェアリリースとMLAN/MOALドライバのリビジョンが推奨されますか? i.MX95 19x19 EVK 上のこのモジュールについて、推奨される SDIO デバイスツリー設定は何ですか?特に、バス幅、最大周波数、pinctrl、電源、リセット GPIO、および電源シーケンス遅延について教えてください。 バス幅=<1> やSDIOクロックを低くすることで、このタイムアウトの診断に役立つ でしょうか?このプラットフォームにおいて、 無SD の除去は 重要または推奨されますか? ドライバがファームウェアのダウンロード完了を報告した後、ファームウェアのアクティベーションタイムアウトが発生する原因は何でしょうか?ドライバ再ロード後にダウンロード0になるということは、再試行前にモジュールの完全な電源サイクルやハードウェアリセットが必要だということを示しているのでしょうか? このボード/モジュール/カーネルの組み合わせに関して、既知の問題や必要なパッチはありますか? ファームウェアやドライバの互換性問題とSDIO通信や電源・リセットシーケンスの問題を区別するために、どの追加のデバッグ設定、SDIOレジスタダンプ、ログを集めるべきでしょうか? 確認され次第、完全なブートログ、関連するデバイスツリーノード、wifi_mod_para.conf、そして正確なBSP/ドライバのリビジョンも提供できます。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 NXPチームの皆様、こんにちは。 JODY-W263-00Bを搭載したi.MX95 19x19 EVKにおけるファームウェアのアクティベーションタイムアウトに関する、さらなる診断証拠を収集しました。 ハードウェアモード検証 両方のレジスタ読み取りが成功しました。 WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection マスクされたストラップは、ドライバーソースによるとSD-UARTモードを示しており、設定されたファームウェア名と一致しています。 ダウンロードループからの脱出が確認されました WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 要求された長さのレジスタが100回のポーリング試行中ずっとゼロのままであるため、ダウンロードループが終了します。 ファームウェアバイナリ検査 ソースの 16 バイトのFWHeaderレイアウトとコマンド長ルールを使用してオフライン解析を行うと、オフセット 619140 から 619156 で終了する CMD4 レコードが特定され、ダウンロードカウンタと完全に一致します。ソースでは、CMD4 をFW_HAS_LAST_BLOCKとして定義しています。 このレコードの後に9044バイトの空きがあります。これらの解析ルールの目的はまだ明らかにされておらず、また、これらのルールがSDIOブートローダーのフォーマットを完全に記述しているかどうかも確認されていません。したがって、カウンターの差額だけでは、ダウンロードが不完全であったことの証明とはみなしません。 その他詳細: MOAL/MLAN バージョン: 537.p9 組み込みファームウェア文字列: w8987o-V0、RF878X、FP92、16.92.21.p151.4 ファームウェアサイズ:628200バイト SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 実際の1ビットSDIO動作は、以前に50MHzで同じタイムアウト値で検証済みである。 最新の診断テストは、4ビット、50MHzで実行されます。 期待されるファームウェアのREADYステータスは0xfedcですが、観測されたステータスは0xf005のままです。 Wi-Fiネットワークインターフェースは作成されません。 NXP BSPの正確なリリース/タグは現在確認中です。 もう少し詳しく教えていただけますか: この特定の画像において、CMD4境界(オフセット619156)で停止することは想定されている動作でしょうか?残りの9044バイトの目的は何ですか? SD8987ファームウェアのアクティベーション中に、 0xf005は何を示していますか? バージョン文字列16.92.21.p151.4を含むファームウェアは、JODY-W263-00Bのドライバ537.p9でサポートされていますか?どのBSPとファームウェア/ドライバーパッケージを使うべきでしょうか? この不具合に対して推奨されるモジュール電源/リセットタイミング、電源供給、および基準クロックのチェック項目はどれですか? ファームウェアの起動失敗と、通信またはハードウェアの初期化の問題を区別するために、他にどのようなレジスタや診断情報を使用すればよいでしょうか? ファームウェアのバイナリファイルは変更されていません。ソースコードの変更により診断ログ機能が追加され、完全なブートログとソースコードの差分が利用可能になりました。 よろしくお願いします。 Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 失敗段階に関する重要な補足事項: プロセッサはSDIO経由でSD8987のWi-Fiデバイスを検出し、ファームウェアダウンロードルーチンでは「FW download over」と報告されます。しかし、その後のアクティベーションチェックでは、ドライバはSDIO_FIRMWARE_READY = 0xfedcを期待し、報告された状態は0xf005とされています。 そのため、ファームウェアの初期化とSDIOプローブが失敗し、Wi-Fiネットワークインターフェースは作成されません。50MHzでの実際の1ビットSDIO動作を確認した後も、この結果は変わりません。 この段階でSD8987 0xf005が何を示しているのか、またファームウェアがREADYステータスに到達しない理由を特定するのに役立つ追加のレジスタ値やログについて説明していただけますか? Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 NXPチームの皆様、こんにちは。 前回の報告に続き、追加の検証と、制御されたSDIOバス幅実験を完了しました。Wi-Fiの初期化は、ファームウェアの有効化段階で依然として失敗します。 1. 確認されたデバイスおよびソフトウェアの詳細 ボード/モジュール: i.MX95 19x19 EVK (JODY-W263-00B搭載) Android fingerprint: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys カーネル: 6.12.23-android16-5-maybe-dirty-4k NXP BSPの正確なリリース/タグ:現在確認中 SDIOデバイス: mmc2:0001:1 SDIO ID: 02DF:9149、ドライバーソースではSD8987にマッピングされています ホストコントローラー:USDHC3、 mmc@428b0000 moalとmlanはどちらもバージョン537.p9を報告している。 MOAL ソースバージョン: 358C14898F4DDF4EB40AB03 ソースリポジトリのリビジョン: nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad imx ファームウェア: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 両方のコミットの件名は「MA-23689-1 [Android-15]WCS Q2 release patch integrate」となっています。これらのソースコードのリビジョンをインストール済みのモジュールビルドにマッピングする作業は、現在も検証中です。 2. ファームウェアの識別情報を確認しました 選択されたファームウェアは/vendor/firmware/sduart8987_combo.binで、サイズは628200 バイトです。 ソースコピーとインストール済みボードコピーのSHA-256ハッシュ値は同じです。 db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 これにより、コピーが一致していることが確認されました。ただし、モジュールとのファームウェアの互換性については、まだ確認が必要です。 3. 実際の1ビットSDIOテストが完了しました 当初、ライブデバイスツリーはbus-width = <1>と報告していましたが、 /sys/kernel/debug/mmc2/iosでは依然として 4 ビット動作が表示されていました。 ソースコードでは、 mmc_of_parse() は バス幅 = の既存の 4 ビット機能をクリアしませんが <1>、汎用 SDHCI 設定では、 SDHCI_QUIRK_FORCE_1_BIT_DATA が設定されてい ない限り、 MMC_CAP_4_BIT_DATA が追加されます 。 そこで、 sdhci-esdhc-imx.cのmmc_of_parse()エラーチェックの直後に診断ブロックを追加しました。 { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } 変更したカーネルとDT構成を再構築およびデプロイした後、以下のことを確認しました。 Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) しかし、同じ失敗が続いた。 Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 Wi-Fiネットワークインターフェースは一切表示されません。 設定された最大周波数は100 MHzですが、実際の動作は50 MHzのままです。したがって、低クロックのテストは完了していません。また、 レビューしたUSDHC3構成にはSDが含まれていなかったため、削除は行われませんでした。 4. WLAN専用ファームウェアのリロードテスト 設定済みのファームウェアパスに一時的にsd8987_wlan.binをバインドマウントし、MOALを再読み込みました。ドライバーは代替ファイルサイズを読み取りましたが、次のように報告しました: firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! これは以前の初期化失敗後の再読み込みであったため、結果は決定的なものではないと判断します。これは、WLAN専用ファームウェアの互換性や正常な転送を保証するものではありません。 再起動により一時的なバインドマウントが解除され、元の628200バイトのコンボファームウェアが再度検証されました。 5. 現在の調査 moal_sdio_mmc.cで診断ログを準備し、以下の情報をキャプチャします。 生のチップマジックとホストストラップレジスタの値。 両方のレジスタ読み取りの戻りステータス。 仮面魔法とストラップの価値。 ソースコードでは、 CHIP_MAGIC_VALUE = 0x24 、 CARD_TYPE_SD_UART = 0と定義されています。既存のブートログではこれらの値は公開されていませんでした。このログ記録の変更はまだ展開されていません。 firmwarestat=0xf005 の正確な意味 、およびファームウェアサイズとダウンロードカウンタの 差が9044バイト 繰り返される現象 については、未解決のままです。完了メッセージをファームウェアがアクティブであることの証明とはみなしていません。 以下の点についてアドバイスいただけますか? このファームウェア/ドライバーパッケージは、このBSP/カーネル上のJODY-W263-00Bに適していますか?バイナリやパッケージから正確なファームウェアリリースをどうやって特定できますか? 628200バイトのコンボイメージに対して619156バイトがダウンロードされたのは、このファームウェア形式では想定されるサイズなのでしょうか、それとも予期せぬ終了を示しているのでしょうか? SD8987の初期化中にファームウェアステータス0xf005が表示されるのはどういう意味ですか? 上記の診断ホスト・ドライバの変更は1ビットテストを強制するのに適切でしょうか、それとも推奨されるBSPメカニズムがありますか? ストラップベースのファームウェア選択を検証するために、どのレジスタ/ログを収集すべきでしょうか?また、明示的なfw_nameを指定すると、その選択は上書きされますか? この障害発生後、再試行する前に必要な電源投入/リセット手順は何ですか?次に推奨する実験は、クロック周波数を低く設定するテストでしょうか、それとも別の対象を絞った実験でしょうか? 完全なブートログ、DT/オーバーレイの変更、ホストドライバーの違い、wifi_mod_para.confも提供可能です。 よろしくお願いします。
View full article
RT1170 support QSPI Flash (MX25L51245G ) Hi, Can RT1170 support MX25L51245G for QSPI flash? Do it need to modify the configuration file “evkmimxrt1170_flexspi_nor_config.c” to meet this chip? If so, how to modify it? Which parameters should be modified? Thanks for your support! Best regards, WJC Re: RT1170 support QSPI Flash (MX25L51245G ) Hello @jeremyzhou  We are using the MX25L51245G external flash and RT1176 and have implemented the configuration shown below. It works flawlessly in XIP mode, but I would like to get a validation from you as well. However, when running a multicore application in "Link application mode", the system hits a hardfault. Specifically, it triggers an assert due to the value read from the FlexCAN MCR register. I am attaching some screenshots and my lookup table below for your reference. M7 flash init(RAM): M4 flash init(RAM): hardfault for multicore(RAM): Here is the lookup table configuration designed to support the software running seamlessly in both RAM and XIP (Execute-in-Place) modes:   #define FLASH_DUMMY_CYCLES 0x08 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, .controllerMiscOption = 0x10, .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz, //okuma hatasi olursa kFlexSpiSerialClk_120MHz .sflashA1Size = 64u * 1024u * 1024u, //64MB //Her acilista QE = 1. ROM once WREN'i (seq 3) kendisi gonderir, sonra 4*12'yi 0x40 ile calistirir. //NXP RT1170 EVK'daki configCmd kalibinin aynisi .configCmdEnable = 1u, .configModeType[0] = kDeviceConfigCmdType_Generic, .configCmdSeqs[0] = {.seqNum = 1u, .seqId = 12u, .reserved = 0u}, //1 tane sequence calistir: 4*12 //asagiyi 0x20 yapinca calismadi dogrudan memory hatasinda patladi main'e gelmeden .configCmdArgs[0] = 0x40u, //WRITE_SDR'nin gonderecegi byte: SR = 0x40 .lookupTable = { [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x6C, RADDR_SDR, FLEXSPI_1PAD, 0x20),//6Ch QREAD4B: komut ve 4 byte adres tek hattan (1-1-4) [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04),//8 dummy bekle, data 4 hattan [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04),//status regini 0x05'den okuyacam (WIP = bit0) [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0),//write en ettim //asagidakini yoruma alinca gercekten silmedi [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20),//4 byte adress alarak 4 kb sector silecem [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20),//64 kb block silecem(app'de kullanmiyoruz) [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20),//4 byte 1 page yazacam [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0),//datayi gonder ve bitir (WEL'i flash program bitince kendisi temizler) [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC7, STOP, FLEXSPI_1PAD, 0x0),//tum flashi silecem(app'de kullanmiyoruz) [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x01, WRITE_SDR, FLEXSPI_1PAD, 0x01),//WRSR + tam 1 byte (configCmdArgs[0]): sadece SR yazilir, CR'ye dokunmaz //seq 6/7 bos: ROM API suspend/resume kullanmiyor }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 0x1, .blockSize = 64u * 1024u, .isUniformBlockSize = true, }; Re: RT1170 support QSPI Flash (MX25L51245G ) Hi, Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you. 1) Can RT1170 support MX25L51245G for QSPI flash? -- Yes. 2) Do it need to modify the configuration file “evkmimxrt1170_flexspi_nor_config.c” to meet this chip? -- Yes, please refer to the below code. const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64u * 1024u * 1024u, .lookupTable = { // Read LUTs FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 256u * 1024u, .isUniformBlockSize = false, }; Have a great day, TIC ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
View full article
i.MX95 19x19 EVK 搭配 JODY-W263-00B:在 Android 15 / Linux 6.12.23 系统上 WiFi 固件激活超时 标题:i.MX95 19x19 EVK with JODY-W263-00B:Android 15 / Linux 6.12.23 上的 WiFi 固件激活超时 您好,NXP团队, 我正在调试以下配置下的 WiFi 初始化: 板:NXP i.MX95 19x19 EVK WiFi模块:u-blox JODY-W263-00B Android 版本:AOSP 15(Android 属性验证待定) 运行内核:6.12.23-android16-5-maybe-dirty-4k NXP Android 电路板支持包的具体版本/标签:尚未确认 WiFi 驱动程序:mlan/moal (MWLAN) 选定的固件:sduart8987_combo.bin SDIO 设备:mmc2:0001:1 运行内核信息: 检测到 SDIO 设备,驱动程序报告“固件下载完成”。但是,固件在超时时间内没有激活,WiFi SDIO 探测失败。 相关命令:adb shell uname -a Linux 本地主机 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT Thu Jan 1 00:00:00 UTC 1970 aarch64 Toybox t 日志: [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully 卸载并重新加载驱动程序后,我还观察到: [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 我找到了这个相关的社区讨论: https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 讨论的是基于 Nvidia AGX Orin 的 88W8801 芯片,因此它属于不同的模块/平台。作者报告称,移除no-sd配置并将总线宽度从 4 改为 1 后,性能有所提升,之后恢复到原始配置后运行正常。我尚未在我的主板上测试这些更改。 请问您能否帮忙澄清一下: sduart8987_combo.bin是JODY-W263-00B 的正确固件吗?对于这种 Android/内核组合,推荐使用哪个固件版本和 mlan/moal 驱动程序版本? 对于 i.MX95 19x19 EVK 上的此模块,推荐的 SDIO 设备树设置是什么?特别是总线宽度、最大频率、引脚控制、电源、RESET GPIO 和电源时序延迟? 测试 总线宽度是否等于 1<1> 或降低 SDIO 时钟频率有助于诊断此超时问题吗?移除 no-sd 参数 对于此平台是否相关或推荐? 驱动程序报告固件下载完成后,固件激活超时可能是什么原因造成的?下载次数为0是否意味着在重试之前需要对模块进行完全断电重启或硬件RESET? 针对这种板/模块/内核组合,是否存在已知问题或需要打补丁? 为了区分固件/驱动程序兼容性问题与 SDIO 通信或电源/RESET时序问题,我应该收集哪些额外的调试设置、SDIO 寄存器转储或日志? 确认后,我可以提供完整的启动日志、相关的设备树节点、 wifi_mod_para.conf以及确切的 电路板支持包/驱动程序版本。 谢谢! Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 您好,NXP团队, 我们已经收集了关于 i.MX95 19x19 EVK(JODY-W263-00B)固件激活超时的进一步诊断证据。 硬件模式验证 两次寄存器读取均成功: WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection 根据我们的驱动程序来源,带掩码的表带表示 SD-UART 模式,这与配置的固件名称一致。 下载循环退出已确认 WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 在 100 次轮询尝试中,请求长度寄存器始终为零,导致下载循环退出。 固件二进制检查 利用源文件的 16 字节FWHeader布局和命令长度规则,离线解析在偏移量 619140 处识别出一条 CMD4 记录,该记录在 619156 处结束——与下载计数器完全匹配。源文件将 CMD4 定义为FW_HAS_LAST_BLOCK 。 此记录之后还有 9044 个字节。我们尚未确定其用途,也未确认这些解析规则是否完全描述了 SDIO 引导加载程序格式。因此,我们并不认为仅凭反差就能证明下载不完整。 其他详情: MOAL/MLAN 版本: 537.p9 嵌入式固件字符串: w8987o-V0、RF878X、FP92、16.92.21.p151.4 固件大小:628200 字节 安全散列算法(SHA)-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 之前已验证过 50 MHz 下的实际 1 位 SDIO 操作,超时时间相同。 最新的诊断测试以 4 位、50 MHz 的频率运行。 预期固件 READY 状态为0xfedc ;观察到的状态仍为0xf005 。 未创建 Wi-Fi 网络接口。 NXP 电路板支持包的具体版本/标签仍在确认中。 请问您能否澄清一下: 对于这张特定的图像,在 CMD4 边界(偏移量 619156)处停止是否符合预期?剩余的 9044 字节有什么用途? SD8987固件激活过程中, 0xf005表示什么? 固件版本号为16.92.21.p151.4的固件是否支持 JODY-W263-00B 的驱动程序537.p9 ?我们应该使用哪个 电路板支持包 和固件/驱动程序软件包? 针对此故障,建议检查哪些模块的电源/RESET时序、供电和参考时钟? 哪些额外的寄存器或诊断信息可以区分固件启动失败与通信或硬件初始化问题? 固件二进制文件保持不变。我们的源代码修改增加了诊断日志记录,并且提供了完整的启动日志和源代码差异。 谢谢! Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 关于失败阶段,有一点需要特别说明: 处理器通过 SDIO 检测到 SD8987 Wi-Fi 设备,固件下载例程报告“固件下载完成”。但是,在随后的激活检查期间,驱动程序期望SDIO_FIRMWARE_READY = 0xfedc ,而报告的状态为0xf005 。 因此,固件初始化和 SDIO 探测失败,并且没有创建 Wi-Fi 网络接口。在验证了 50 MHz 下实际的 1 位 SDIO 操作后,结果仍然不变。 请问在此阶段, 0xf005对于 SD8987 代表什么?还有哪些寄存器值或日志可以帮助确定固件为何无法达到 READY 状态? Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 您好,NXP团队, 继我最初的报告之后,我们完成了额外的检查和受控 SDIO 总线宽度实验。Wi-Fi 初始化在固件激活阶段仍然失败。 1. 已确认的设备和软件详情 板/模块:i.MX95 19x19 EVK,带 JODY-W263-00B Android 指纹: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys 内核: 6.12.23-android16-5-maybe-dirty-4k NXP 电路板支持包的具体发布版本/标签:仍在确认中 SDIO 设备: mmc2:0001:1 SDIO ID: 02DF:9149 ,在驱动程序源中映射到 SD8987 主机控制器:USDHC3, mmc@428b0000 moal和mlan都报告了版本537.p9 MOAL 源版本: 358C14898F4DDF4EB40AB03 源代码库修订: nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad IMX 固件: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b 这两个提交的主题都是“MA-23689-1 [Android-15]WCS Q2 版本补丁集成”。目前仍在验证这些源代码版本与已安装模块构建的映射关系。 2. 固件身份验证已验证 选定的固件为/vendor/firmware/sduart8987_combo.bin ,大小为628200 字节。 源拷贝和已安装板拷贝具有相同的 SHA-256 值: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 这证实了副本匹配;固件与模块的兼容性仍需确认。 3. 实际 1 位 SDIO 测试完成 最初,实时设备树报告总线宽度 = <1> ,但/sys/kernel/debug/mmc2/ios仍然显示 4 位操作。 在我们的源代码中, mmc_of_parse()不会清除总线宽度 = <1>的现有 4 位功能,而通用的 SDHCI 设置会添加MMC_CAP_4_BIT_DATA,除非设置了SDHCI_QUIRK_FORCE_1_BIT_DATA 。 因此,我们在sdhci-esdhc-imx.c中,紧接在mmc_of_parse()错误检查之后,添加了一个诊断块: { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } 在重新构建并部署修改后的内核和 DT 配置后,我们验证了以下几点: Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) 然而,同样的问题依然存在: Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 未显示Wi-Fi网络接口。 配置的最大频率为 100 MHz,但实际运行频率保持在 50 MHz。因此,我们没有进行低频测试。此外,所审查的 USDHC3 配置中缺少no-sd 选项,因此未执行移除操作。 4. 仅支持 WLAN 的固件重载测试 我们临时将sd8987_wlan.bin挂载到配置的固件路径,并重新加载了 MOAL。驱动程序读取了备用文件大小,但报告如下: firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! 由于这是在之前初始化失败后重新加载,因此我们认为结果不确定。它无法确定仅 WLAN 固件的兼容性或传输是否成功。 重启后,临时绑定挂载被移除,原始的 628200 字节组合固件再次得到验证。 5. 当前调查 我们正在moal_sdio_mmc.c中准备诊断日志记录,以捕获: 原始芯片信息和主机链路寄存器值。 两次寄存器读取的返回状态。 面具魔法和表带价值。 源文件定义了CHIP_MAGIC_VALUE = 0x24和CARD_TYPE_SD_UART = 0。现有的启动日志并未记录这些值。此日志记录更改尚未部署。 firmwarestat=0xf005的确切含义以及固件大小与下载计数器之间反复出现的9044 字节差异仍然未得到解决。我们不将完成消息视为固件已激活的证据。 请问您能否就以下问题提供建议? 此固件/驱动程序代码包,软件包是否适用于此 BSP/内核上的 JODY-W263-00B?如何从二进制或软件包中确定具体的固件版本? 对于这种固件格式,下载 619156个文件(对应 628200 字节的组合映像)是否正常,还是表示下载提前终止? SD8987 在初始化期间固件状态0xf005代表什么含义? 上述诊断主机驱动程序更改是否适合强制执行 1 位测试,或者是否有更推荐的 电路板支持包 机制? 我们应该收集哪些寄存器/日志来验证基于表带的固件选择,显式fw_name是否会覆盖该选择? 此次故障后,重试前需要执行怎样的电源/RESET顺序?您建议接下来进行低时钟频率测试还是进行其他针对性实验? 我们可以提供完整的启动日志、DT/overlay 更改、主机驱动程序差异和wifi_mod_para.conf 。 谢谢!
View full article
RW612 WPA2-Enterprise 重新认证 – EAPOL TX 在 PTK 安装之前完成 您好, 我们正在使用 Zephyr 4.3 和 Hostap/wpa_supplicant 在基于 RW612 的产品上实现 WPA2-Enterprise / IEEE 802.1X。 初始认证对 PEAP/MSCHAPv2 和 EAP-TLS 均有效。EAP-TLS 也适用于 PSA/ELS 支持的不可导出私钥。 我们发现,在 Wi-Fi 原地重新认证过程中存在问题。 观察到的序列: RADIUS 访问接受 → EAP成功 → 四方握手 → AP 重传消息 3 → Wi-Fi 连接丢失 → 设备重新连接并再次成功验证 我们目前的证据表明,最终 EAPOL-Key 响应的传输和新 PTK 的安装之间可能存在顺序问题。 PTK 更新似乎可以继续进行,而最终的 EAPOL 帧可能仍在排队等待传输。 我们尝试寻找一种受支持的机制来保证: EAPOL-Key帧最终传输完成 前 新安装的PTK 但是,我们在 RW612 Wi-Fi 驱动程序/固件路径中找不到 EAPOL TX 完成回调、TX 队列清空/隔离或等效 API。 仅作为诊断实验,在 PTK 安装之前添加 100 毫秒的延迟,使得多次 PEAP 和 EAP-TLS 重新认证尝试得以顺利完成,而不会中断。我们不认为固定延迟是一种可行的生产解决方案。 请问您能否澄清一下: - 是否有支持的 API 可以知道固件何时实际发送了 EAPOL 数据帧? - 在更新 PTK 之前,是否应该使用 TX 队列冲洗/排空或密钥安装围栏? - 这是 RW612 Wi-Fi 驱动程序/固件中已知的限制或已知问题吗? - 是否有更新的驱动程序或 Wi-Fi 固件版本可以解决这个问题? 测试版本: RW612驱动程序:v1.3.r52.z_up.p11 Wi-Fi固件版本:18.99.6.p47 如有需要,我们可以提供详细的追踪记录和供应商问题包。 谢谢。RW612
View full article
Initial PWM output value with eFlexPWM Hi, Working with eFlexPWM of MCXA132, I want to modify the initial value for PWM23. For that I do next steps: 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1     SM1CTRL2[FORCE] = 1    (note that SM1CTRL2[FORCE_SEL] is 000) 3. MCTRL[RUN] = 010 But first PWM cycle always starts with output at level 0. Where can be the problem? Thanks in advance MCXA
View full article
eFlexPWM 的初始 PWM 输出值 你好, 在使用 MCXA132 的 eFlexPWM 时,我想修改 PWM23 的初始值。 为此,我将采取以下步骤: 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1 SM1CTRL2[FORCE] = 1(注意 SM1CTRL2[FORCE_SEL] 为 000) 3. MCTRL[RUN] = 010 但第一个 PWM 周期总是从输出电平 0 开始。 问题出在哪里? 提前致谢 MCXA
View full article
RT1170はQSPIフラッシュ(MX25L51245G)をサポートしています こんにちは、 RT1170はQSPIフラッシュのMX25L51245Gをサポートしていますか? このチップに対応するために、設定ファイル「evkmimxrt1170_flexspi_nor_config.c」を変更する必要がありますか? もしSOなら、どうやって修正すればいいのでしょうか?どのパラメータを変更すべきでしょうか? ごサポートありがとうございます! よろしくお願いいたします。 世界ジュニア会議 Re: RT1170 support QSPI Flash (MX25L51245G ) こんにちは、 @jeremyzhou 弊社では、MX25L51245G外部フラッシュメモリとRT1176を使用しており、以下の構成を実装しています。XIPモードでは問題なく動作しますが、念のため貴社からも確認をいただきたいです。 しかし、「リンクアプリケーションモード」でマルチコアアプリケーションを実行すると、システムはハードフォールトに遭遇します。具体的には、FlexCAN MCRレジスタから読み取った値によってアサートがトリガーされます。 参考までに、スクリーンショットとルックアップテーブルを以下に添付します。 M7フラッシュ初期化(RAM): M4フラッシュ初期化(RAM): マルチコア(RAM)のハードフォルト: こちらはRAMモードとXIP(Execute-in-Place)モードの両方でシームレスに動作するソフトウェアをサポートするために設計されたルックアップテーブルの構成です:   #define FLASH_DUMMY_CYCLES 0x08 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG 、 .version = FLEXSPI_CFG_BLK_VERSION、 .readSampleClksrc= kFlexSPIReadSampleClk_LoopbackFromDqsPad 、 .csHoldTime = 3u、 .csSetupTime = 3u、 .controllerMiscOption = 0x10、 .deviceType = kFlexSpiDeviceType_SerialNOR 、 .sflashPadType = kSerialFlash_4Pads、 .serialClkFreq = kFlexSpiSerialClk_133MHz , //オクマハタシオルルサkFlexSpiSerialClk_120MHz .sflashA1Size = 64u * 1024u * 1024u, //64MB //彼女のアシリスタQE = 1. ROM 1 回 WREN'i ( seq 3) kendisi gonderir 、 sonra 4*12' yi 0x40 ile calistirr 。 //NXP RT1170 EVK'daki configCmd kalibin aynisi .configCmdEnable = 1u、 .configModeType[0] = kDeviceConfigCmdType_Generic、 .configCmdSeqs[0] = {.seqNum = 1u, .seqId = 12u, .reserved = 0u}, //1 taneシーケンスcalistir : 4*12 // asagiyi 0x20ヤピンカカリスマディドグルダンメモリハタシンダパトラディメインエゲルメデン .configCmdArgs[0] = 0x40u, //WRITE_SDR'nin gonderecegi byte: SR = 0x40 .lookupTable = { [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x6C, RADDR_SDR, FLEXSPI_1PAD, 0x20), //6Ch QREAD4B: komut ve 4 byte adres tek hattan (1-1-4) [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), //8 ダミーベール、データ 4ハットン [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), //ステータスregini 0x05'den okuyacam (WIP = bit0) [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), //書き込み完了 //アサギダキニヨルマアリンカゲルツェクテンシルメディ [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4 バイトアドレスalarak 4 kbセクターsilecem [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20)、 //64 kbブロック サイセム(アプリ デkullanmiyoruz ) [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4バイト1ページyazacam [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // datayi gonder ve bitir (WEL'i フラッシュ プログラム ビットインスkendisi temizler ) [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC7, STOP, FLEXSPI_1PAD, 0x0), // tum flashi silecem (app'de kullanmiyoruz ) [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x01, WRITE_SDR, FLEXSPI_1PAD, 0x01), //WRSR + tam 1 バイト (configCmdArgs[0]): sacece SR yazilir , CR'ye dokunmaz // seq 6/7 bos : ROM API サスペンド/レジュームkullanmiyor }、 }、 .pageSize = 256u、 .sectorSize = 4u * 1024u、 .ipcmdSerialClkFreq = 0x1、 .blockSize = 64u * 1024u、 .isUniformBlockSize = true、 }; Re: RT1170 support QSPI Flash (MX25L51245G ) こんにちは、 NXP Semiconductors製品へのご関心と、皆様にお仕えできる機会をいただき、ありがとうございます。 1) RT1170はQSPIフラッシュのMX25L51245Gをサポートしていますか? ――はい。 2) このチップに合わせて設定ファイル「evkmimxrt1170_flexspi_nor_config.c」を変更する必要がありますか? はい、下記のコードをご参照ください。 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64u * 1024u * 1024u, .lookupTable = { // Read LUTs FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 256u * 1024u, .isUniformBlockSize = false, }; 良い一日をお過ごしください。 TIC ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------
View full article
eFlexPWMを使用した初期PWM出力値 こんにちは、 MCXA132のeFlexPWMを使用して、PWM23の初期値を変更したいと考えています。 そのため、私は以下の手順を実行します。 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1 SM1CTRL2[力] = 1(SM1CTRL2[FORCE_SEL]は000であることに注意) 3. MCTRL[RUN] = 010 しかし最初のPWMサイクルは常に出力レベル0から始まります。 問題はどこにあるのでしょうか? よろしくお願いします MCXA
View full article
S32K3X8EVB-Q289 Boundary Scan test based on Lauterbach μTrace and Trace32. 1. Abstract/Introduction Boundary scan is a method for testing interconnects (wire lines) on printed circuit boards or sub-blocks inside an integrated circuit (IC). Boundary scan is also widely used as a debugging method to watch integrated circuit pin states, measure voltage, or analyze sub-blocks inside an integrated circuit. The Joint Test Action Group (JTAG) developed a specification for boundary scan testing that was standardized in 1990 as the IEEE Std. 1149.1-1990. In 1994, a supplement that contains a description of the boundary scan description language (BSDL) was added which describes the boundary-scan logic content of IEEE Std 1149.1 compliant devices. Since then, this standard has been adopted by electronic device companies all over the world. Boundary scan is now mostly synonymous with JTAG. This test is based on existing application notes for LPC55(S)xx, i.MX RT and MCXA (See references). The procedure follows how to do both a BYPASS, IDCODE and SAMPLE test, as well as an EXTEST. Following boundary scan instructions are defined in the IEEE standard: BYPASS (mandatory): TDI is connected to TDO via a single shift register. IDCODE (optional): Reads the device identification register. SAMPLE (mandatory): Takes a snapshot of the normal operation of the IC. EXTEST (mandatory): Apply preloaded data of the boundary scan register to the ports. 2. Hardware platform Lauterbach: LA-3505 POWER-DEBUG-PRO S32K3: S32K3X8EVB-Q289 There are no hardware modifications needed for connecting JTAG interface, as the S32K3 family includes the standard Arm debug port, supporting both the JTAG and SWD interfaces. S32K3XX derivatives can directly use the JTAG interface. Ensure S32K3X8EVB-Q289's jumpers are set as in the Quick Start Guide for S32K3X8EVB Board: Default Jumper settings.Default Jumper settings. Ensure a valid connection between the EVB's JTAG ARM 20-pin Standard Port (On board: J365), and the Debug Cable for Lauterbach interface. 3. Software platform This test uses Lauterbach's TRACE32 Software Package. Download the TRACE32_202509.7z to the computer and install it: Because the installation package is relatively large, you can install software components according to the target processor to save hard disk space. You can find installed driver at C:\T32\bin\windows64\drivers. 4. BSDL file validation using Lauterbach JTAG debugger. Confirm that Lauterbach probe is detected in 'Device Manager': Device Manager Trace32 device enumeration.Device Manager Trace32 device enumeration. Note: Lauterbach debugger used is LA-3500, with Probe LA-3000 + LA-7844A Debug License. Related information can be found on the Lauterbach's page. Open TRACE32 Arm interface: Type in the following commands: SYStem.Down BSDL.RESet BSDL.ParkState Select-DR-Scan BSDL.state  BSDL.state window should now appear. Select 'FILE' and load BSDL from S32K3 HW Design Package. S32K3X8EVB-Q289 should use S32K358_bga289_customer_1995E01D.bsdl. BSDL.state window.BSDL.state window.  After loading the file, type the following command: BSDL.SOFTRESET​ Switch to the Check tab of the BSDL.state window. Click BYPASSall and IDCODEall button to see if both results pass. Both should change from 'No result' to 'Test PASS': BYPASS and IDCODE check.BYPASS and IDCODE check. BYPASS: PASS means the bypass scan completed correctly for all configured devices. This indicates that the JTAG chain connectivity, chain order/length, and basic BSDL configuration are probably correct. IDCODE: PASS means the received device ID matches the expected BSDL description. This is evidence that the correct device and BSDL file are being used, but it still does not validate the boundary-register pin definitions. Next, click the SAMPLEall button, 'No result' should become Test done. Double-click the entity name, and the BSDL.SET window will pop-up: BYPASS and IDCODE check, BSDL.SET window appears.BYPASS and IDCODE check, BSDL.SET window appears. SAMPLE: PASS indicates that the pin can be observed through the boundary-scan cell, the BSDL input/observe mapping is likely correct, and that the captured value corresponds to the actual pad level. In the BSDL.SET window, uncheck Intern option to filter out the internal registers. The remaining contents are the sampled value on each signal pins. Use a multimeter to measure voltage of at least three signal pins and see if the logic state matches the sampled value. BSDL.SET window, SAMPLE check.BSDL.SET window, SAMPLE check. Next, in the Instructions field, click EXTEST and in the DR mode field, choose Set Write. Then switch to the BSDL.state window and check SetAndRun and TwoStepDR. BSDL.SET & BSDL.STATE windows EXTEST set up.BSDL.SET & BSDL.STATE windows EXTEST set up. Switch back to BSDL.SET window, click 'ENABLE' in Init BSR to enable output of corresponding signal pins, and click the buttons in “Reg.” column to toggle their output logic state 0 or 1. Use a multimeter to measure if the logic state really toggles on those signal pins. At least three signal pins need to be verified. BSDL.SET window enable and toggle signal levelBSDL.SET window enable and toggle signal level Note: PTG29/30/31 (User LED indicators Red/Green/Blue) for simplicity reasons, however, as a diagnostic recommendation, use an unloaded or lightly loaded pad if possible. 5. Conclusion This procedure provides a practical method for validating the S32K3X8EVB JTAG boundary-scan chain using TRACE32 and the appropriate S32K358 BSDL file. BYPASSall and IDCODEall verify JTAG-chain connectivity and device identification, SAMPLEall confirms pin-state observation, and EXTEST verifies pin control through the boundary-scan register. While these checks confirm basic boundary-scan operation, additional pin-level testing is recommended to validate board connectivity and application-specific signals. Any reset observed during EXTEST should be investigated before concluding a BSDL-related issue. The final report should capture the BSDL file used, JTAG-chain results, validated pins, measured logic levels, and any reset behavior observed during EXTEST. 6. References How to Perform Boundary Scan for LPC55(S)xx based on μTrace AN12919: Introduction to Boundary Scan of i.MX RT Series – Application Note How To Perform Boundary Scan On MCXA Series Using μTrace And Trace32 Boundary Scan User's Guide S32K3 Auto General-Purpose MCUs | NXP Semiconductors Software Download | Lauterbach TRACE32
View full article