LX2162A USXGMIIリンクが完了しない みなさん、こんにちは。 私はSolidrun社製のLX2162A SoMを所有しています。Clearfogの開発キットを使用していますが、近いうちにカスタムキャリアに移行する予定です。 Solidrunは基本的なRCW/DCP/DPLを提供しており、その機能は確認済みです。私の場合、DPC3のDPCはSFPケージで動作し、SFP DACケーブルと様々なSFPモジュールでXFIリンクが接続されています。 RCW "rcw_2000_650_2900_3_11_0_auto" は SerDes1=3、SerDes2=11 に設定され、私は QorIQ カーネル (lf-6.6.52-2.2.0) と mc-utils (10.39.0) を使用していますが、両方に Solidrun のパッチが適用されています。U-Bootやその他のものもパッチが適用されています。すべてのパッチはここから取得されます： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 私はMaxLinear GPY245-EKV-1（および-2）開発キットを持っており、PHYをデバイスに接続するためにDACケーブル経由のUSXGMIIを必要としています。どうやらこれはごく普通のことらしい。最終的にはこのPHYチップはSerDes2=7のレーン6とレーン7に統合される予定ですが、テストのためにはClearfogのSFPケージを使用する必要があります。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 私は、dpmac3がDPC経由でこのUSXGMIIリンクを使用するように設定しようとしているだけです。 mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （MAC_LINK_TYPE_BACKPLANEも試してみました） 「restool dpmac info dpmac.3」で確認済み「DPMAC イーサネットインターフェース:DPMAC_ETH_IF_USXGMII」と表示されます。 LinuxではMaxLinearドライバーを追加し、いくつかの点を修正しました: gpy_update_interface() の修正 (LKML、Daniel Golle)。これはUSXGMIIインターフェースで-EINVALを戻す際にクラッシュphy_state_machine。 pcs-lynx.c の lynx_pcs_config_usxgmii() 関数にパッチを適用しました。mdiobus_c45_modify() を介して MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) も書き込む必要があります。この関数はこれまで MII_ADVERTISE しか書き込んでおらず、レプリケータブロック自体で AN を有効にしたことがなかったためです。このギャップは、このフォーラムの別の投稿（「LS1028A 10g-qxgmii phy 起動」）と一致しており、同じ症状（MMD31.0/Replicator）が報告されています。コントロールレジスタが0に固定され、ビット12を手動で設定した後、ANが作動しました。 こちらがDPMAC3 Linuxデバイスツリーのエントリーです: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; ここで、`gpy245_0`はMDIOノードです。PHYへのMDIOトラフィックは正常に動作しています。 lynx_pcsドライバーにリードバックを表示するプリントアウトを追加しました: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 質問： このPCSインスタンスのMDIO_MMD_VEND2レジスタへの書き込みが持続しないような場合、LX2162AファミリSoCのUSXGMIIが設定を受け入れる前に、SerDes/PCSブロックの有効化、プロトコル固有の初期化など、追加のステップが必要になるのでしょうか?プロトコル3はdpmac3上のUSXGMII向けに完全に検証済みですか、それとも主にXFI向けに設計・テストされていますか？ その他の質問： GPY245とUSXGMIIについて、私はよく理解していないのかもしれません。これをQXGMIIと呼ぶ人もいますが、LX2162Aが本当に動作するのかはわかりません。 Solidrunに問い合わせる必要があるかもしれないが、彼らのパッチはどれもLX2162Aの性能を制限するものではないようだ。 ありがとう！ Re: LX2162A USXGMII link never completes LX2162A側は、あなたが使っているパス上でUSXGMIIをサポートするドキュメントがありますが、あなたが示している症状はLinux pcs-lynxの書き込みが欠けているというより、選択したPCSインスタンスがまだUSXGMIIアプリケーションモードに入っていないか、MCファームウェアが間違った10G PCSセレクタをプログラムしているように見えます。 SerDes1プロトコル3の場合、LX2162Aリファレンスマニュアルでは4つのSerDes1レーンすべてがUSXGMII / XFIとして記載されており、最初のレーンにはUSXGMII / XFI.3と記載されています。これはClearfog SFPパス上でテストしているDPMAC3のユースケースに対応しています。将来のカスタムキャリアのターゲットとして、SerDes2プロトコル7はレーン6とレーン7をUSXGMII / XFI.13およびUSXGMII / XFI.14として記録しています。 重要な注意点は、USXGMII / XFI のエントリが自動的に「USXGMII」になるわけではないということです。リファレンス・マニュアルには、USXGMIIとXFIのレーン内のデフォルトはXFIと書かれています。モードは、プロトコル構成レジスタCであるPCCCによって選択され、そのSXGMII*_XFIビットによって0b = USXGMII、1b = XFI/SFIが選択されます。まず最初に確認すべきは、LinuxのBMCR書き込み自体ではなく、DPMAC3の特定のSXGMIIインスタンスがMC/DPC初期化後にPCCC XFIセレクトビットがクリアされているかどうかです。 この正確な故障クラスは、LinuxのPCS**ドライバ**ではなくMCファームウェアに起きている前例もあります。あるLX2162Aチケットでは、USXGMII構成でMCがPCCCの10G**インターフェースセレクタ**を間違ったクリアしている様子があり、MCのファームウェアエンジニアリングビルドバージョン10.35.101で問題が解決されました。別のチケットでは、MCの設定はMCファームウェアによって行われ、NXPはMCをバイナリとして提供していると記載されています。MC 10.39.0 を使用しているため、その特定の古い修正は適用されていないはずですが、発生している障害モードは依然として「MC が意図した PCS を USXGMII モードにしなかった」または「間違った PCS インスタンスが処理されている」というエラーと一致しています。 次に私がすること： Linuxが何かを変える前にPCCCを読んでください。 RCW + MC + DPL/DPCのロード後、LinuxのPCSドライバーが動作する前に、PCCCを読み取り、該当するSXGMII*_XFIビットが0であることを確認します。DPMAC3 / USXGMII/XFI.3 用、最初のSXGMIIセレクタを期待してください。MAC13/14のセレクタではありません。そのビットが1のままの場合、レーンは依然としてXFI/SFIであり、VEND2/USXGMII PCS書き込みはアクティブなUSXGMII PCSパスに適用されません。 MDIOアクセスが意図したPCS管理ポートに届いているか確認してください。 SXGMIIプロトコル制御レジスタにはMDIOアクセスをマッチングするためのMDEV_PORTフィールドがあり、マニュアルにはMDIOがSGMII/PCSターゲットにアクセスするまで、ソフトウェアは変更後少なくとも3プラットフォームクロックを待つ必要があると記載されています。もしMDIOアドレスデコードが間違っていると、書き込みが「永続しない」ように見えることがあります。これは異なる、またはリセット/デフォルトのPCSウィンドウを読み取っているからです。 USXGMII ANレジスタが意味を持つのは、モード選択が正しく行われた後のみであることを確認してください。 USXGMII PCS CONTROLレジスタのビット12にはAUTO_NEGOTIATION_ENABLEがあり、DEV_ABILITY / PARTNER_ABILITYはRWレジスタです。DEV_ABILITY下位ベンダーの任意の速度フィールドはゼロでなければならず、ゼロは自動交渉失敗を引き起こす可能性があります。しかし、PCCCが依然としてXFIを選択する場合、これらのBMCR/能力書き込みは本当の根本的な問題ではない。 GPY245ボードのドキュメントに明確に記載されていない限り、QXGMIIを別の必須外部プロトコルとして扱わないでください。 LX2162Aドキュメントには、PD_QXGMやRST_QXGMなどのリセット/電源停止制御ビットを含むQXGMIIプロトコルコンバータレジスタが含まれています。NXPコミュニティの資料LS1028Aでは10G_QXGMII Lynx SerDesドライバーパスも言及されています。しかし、選んでいるDPMACインターフェースLX2162Aドキュメントは依然としてUSXGMII / XFIであり、NXPのドキュメントにはLX2160クラスのデバイスがUSXGMIIをサポートし、「SXGMII」は同じ意味ではないと別途記載されています。言い換えれば、「QXGMII」という言及は、ドライバ/コミュニティの議論において、あなたが設定したUSXGMIIモードとは必ずしも異なるMAC-to-PHY契約ではなく、内部のコンバータ/ドライバの命名パスを指している可能性があります。 このClearfog SFPテストでは、DPCはシンプルなものにしてください。 MAC_LINK_TYPE_PHY enet_if = 「USXGMII」のモデルは、MDIO上で管理される外部PHYのより自然なモデルです。バックプレーン/KRスタイルのフローを意図的に使用していない限り、MAC_LINK_TYPE_BACKPLANE が PHY 側の USXGMII 設定を修正するとは期待できません。 プロトコル3が「主にXFI専用」であるとは結論付けません。リファレンス・マニュアルでは、プロトコル3をDPMAC3のSerDes1レーン用にUSXGMII / XFIとして記載しています。取得した資料から確認できないのは、「プロトコル3 + DPMAC3 + USXGMIIはGPY245で検証された」という別の検証文です。より強力な証拠に基づく主張は、ハードウェアモードは存在し、PCCCがUSXGMIIを選択しない限りデフォルトでXFIに移行すること、そしてMCファームウェアで誤った10G PCSセレクタをプログラムする前例が存在することが知られています。 具体的な読み上げ内容については、以下をご覧ください。 ADV=0xd601 BMCR=0x1a00 を書き込んだ リードバック ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 これは、PCSインスタンスがUSXGMIIで完全に有効化・選択されていないか、MDIOマネジメントウィンドウが意図したPCSインスタンスに対応していない場合に予想される結果です。Linux側の書き込みを追加する前に、まずPCCCとMCログを確認したほうがいいでしょう。 LX2162Aプロトコル3はDPMAC3上のUSXGMII / XFIについて文書化されていますが、USXGMIIはMC/PCCCがUSXGMII PCSを選択することに依存しています。VEND2/BMCR書き込みが永続化されない場合は、まずDPMAC3の正しいPCCCビットがクリアされていること、およびMDIOが正しいSXGMII PCSインスタンスをアドレス指定していることを確認してください。 Re: LX2162A USXGMII link never completes @yipingwang詳細なご回答、本当にありがとうございます！ あなたの言うことはすべて納得でき、プラットフォームについてもっと学び始めています。AN13329.pdfに記載されているアドバイスを実践し始めました。いくつかのアドレスや機能がうまくいかず(おそらくバージョンの不一致です)、少なくとも以下に示すようにMCログは入手できます: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 私はubootを介してPCCCを操作しようと試みました。関連する事項は以下のとおりです。 crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 0x1ea10b0が正しいアドレスであることを心から願っています。LX2162ARM.pdfによると、それが正しい住所である可能性はあり、ビットを解読すると次のようになります: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 正しいレジスタアドレス（PCCC）を観察すべきでしょうか？他に提供できる情報はありますか? ありがとう！ Re: LX2162A USXGMII link never completes はい。のために SerDes1 、  0x1ea10b0  正しい住所は PCCC : LX162A CCSRマップリスト SerDes 1 で  0x1EA_0000–0x1EA_FFFF  。 SerDesのメモリマップには、 プロトコル構成レジスタC / PCCC オフセットで  0x10B0  。 したがって： 0x1EA0000+0x10B0=0x1EA10B0 0 x 1 E A 0000 + 0 x 10 B 0 = 0 x 1 E A 10 B 0 あなたのUブートにはこう書かれていました: コピー => md.l 0x1ea10b0 1 01ea10b0: 88889991   予想どおりに観測している SerDes1 PCCC 登録する。 重要な注意点は命名法です。私はそれらの分野を物理的とは表現しません。 SerDesレーンA/B/C/D 現在の設定の場合。LX2162A SerDes1プロトコルテーブルでは、プロトコル  3  地図 物理レーンH / レーン0 に  USXGMII / XFI.3  、その後レーンG/レーン1から  .4  、レーンF/レーン2から  .5  、そしてレーンE/レーン3から  .6  。PCCCフィールド名など  SXGMIIA_XFI  、  SXGMIIB_XFI  などは PCS/プロトコル制御フィールドであり、必ずしも物理レーン文字と同じ命名規則ではありません。 価値  0x88889991  上位ニブルは次のようにデコードされます。 コピー PCCC = 0x88889991 ビット31:28 = 0x8 -> SXGMIIA_XFI = 1、CFG = 000 ビット 27:24 = 0x8 -> SXGMIIB_XFI = 1、CFG = 000 ビット 23:20 = 0x8 -> SXGMIIC_XFI = 1、CFG = 000 ビット 19:16 = 0x8 -> SXGMIID_XFI = 1、CFG = 000 ビット15:12 = 0x9 -> SXGMIIE_XFI = 1、CFG = 001 ビット11:8 = 0x9 -> SXGMIIF_XFI = 1、CFG = 001   重要な部分は  _XFI  少し。RMは定義する  0  として USXGMIIモード そして  1  として XFI/SFIモード これらの分野については 。つまり、あなたが読んでいる値は、関連するUSXFI/SXGMIIのPCSインスタンスが依然として XFI/SFI として選択されていることを強く示唆しています。USXGMIIとして選ばれているわけではありません。 これはあなたの症状と一致します。Linux/restoolは報告するかもしれませんが  DPMAC_ETH_IF_USXGMII  PCCCが関連する  _XFI  selectビットを  1  保持しているなら、基盤となるSerDes/PCSの選択は実質的にXFI/SFIモードのままです。RMはまた、10G-SXGMIIを有効にするにはソフトウェアが設定しなければならないと明記しています  PCCC[SGMIIa_XFI] = 0  。 あなたのMCログ抽出結果も問題なさそうです。AN13329では、MCFBAL/MCFBAHを以下のように読むように指示されています。  0x8340020  MCファームウェアベースを構築し、オフセットでログバッファ構造をダンプします。  0x01000000  ; この構造体には、マジックナンバー、ログバッファオフセット、およびログバッファ長が含まれます。 。あなたの  0x21e1000000  ダンプには予想どおりの結果が表示されます  0x4d430100  魔法とログオフセットへのポイント  0x01400000  これは、後であなたがダンプした内容と一致します。  0x21e1400000  。 次に私が撮影したいもの： PCCCの各段階におけるスナップショット コピー md.l 0x1ea10b0 1 それを捉える： リセット直後／可能であればMC起動前に、 MCブート後、 DPC/DPL適用後、 Linuxが起動した後、 DPMACのプローブ/設定が完了した後。 隣接するプロトコル設定レジスタ コピー md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9は他のSGMII構成フィールドを含み、PCCCはSXGMII/XFIセレクタレジスタ です。 USXGMIIを強制しようとしたときにどのPCCCフィールドが変わるか確認してください 実験用にU-Bootを安全に挿入できるなら、候補ビットをクリアしてすぐに読み返してみてください  _XFI  。例えば、dpmac3が最初のSXGMII/USXFI制御フィールドに対応する場合、ビット31をクリアすることが実験的な確認となる。 コピー mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 すぐに読み返せば  0x88889991  その場合、書き込みがブロック/上書きされているか、現在のブロック状態ではそのフィールドに書き込みができません。もしMCやLinuxが動くまで固定されるなら、MC/LinuxはXFI/SFIモードを復元している可能性が高いです。 RCW SerDesの完全デコード あなたは既に  SerDes1=3, SerDes2=11  ; dpmac3 レーンが利用可能であることと一致します  USXGMII / XFI.3  SerDes1プロトコル3の下で 。ただし、MCファームウェアはプロトコルセット全体に基づいてキーを生成することが多いため、エスカレーションを行う際には、完全なRCW文字列と生のRCWダンプを含めてください。 MCファームウェア + DPC/DPLアーティファクト あなたのMCは  10.39.0  、 含む： MCファームウェアバージョン、 DPCソース、 DPLソース、 ちょうど  dpmac@3  ブロック、 restool dpmac info dpmac.3  、 各ステップ後のPCCC値。 私の現在の読めたデータ: はい、  0x1ea10b0  正しいSerDes1 PCCCアドレスであり  0x88889991  関連するPCSセレクタはまだXFI/SFIモードのようです。 これは、XFIがSFPケージを介して動作し、USXGMIIが期待されるPCS構成を受け入れ/保持しないという状況と一致しています。

[LPC55S69] Zephyr MCUboot 通过 UART 进行设备固件更新时，在 LPC55S69 上使用 MCUmgr 时无法正常工作 您好，我正在尝试让 Zephyr 的 MCUboot 在 LPC55XpressoS69 上使用 0 号核心运行。我正在 Zephyr 中运行简单的 Blinky 示例应用程序。 应用程序运行正常，没有任何错误。 但是，我一直尝试使用 mcumgr 通过 UART 发送设备固件更新 (DFU)，但由于某种原因，我甚至无法在 mcumgr 和我的设备之间建立连接。我一直收到“NMP超时”的错误提示。 为了方便理解，我的目录结构如下所示： | __boards |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__ main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf 我的prj.conf文件内容如下：   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y 我的sysbuild.conf文件内容如下：   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y 我的mcuboot.conf文件内容如下：   CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   我的 MCUboot.overlay 文件看起来像这样 /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 最后，我的 lpcxpresso55s69_lpc55s69_cpu0.overlay 文件看起来像这样 / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 当我运行以下 MCUmgr 命令时，会收到 NMP 超时错误，如下所示： > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout 所以 mcumgr 肯定知道端口可用（否则它会拒绝访问），但它一直超时。 我非常确定这是配置选项错误。我多次尝试更改配置选项，但似乎都无法解决问题。我几乎可以肯定，我漏掉了一些对这个功能正常运行至关重要的配置选项。 我已经尽可能地查阅了所有相关的应用笔记和用户手册。这些方法似乎都无法帮助我解决我的具体问题：在运行 Zephyr 应用程序的 LPC55Sxx 芯片上使用 Zephyr MCUboot 进行 DFU。 任何帮助都将不胜感激，不过最好是有人能在自己的板子上测试一下，例如：LPCXpresso55S69 并确认它们可以使用任何简单的程序执行 UART DFU。 LPC55S6x LPC55S69-EVK LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 嗨@Harry_Zhang ， 你的方法确实有效。事实上，我能够将命令简化到仅仅只保留一个部分。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" 这个方法也奏效了。非常感谢您重现我的问题，感激不尽。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 你好@ZQ2 我能够在 LPCXpresso55S69 板上重现并验证该设置。 1.关键在于，在此配置中，MCUmgr 必须与 MCUboot 一起使用。该应用程序链接到 slot0（而不是闪存基地址），因此单独构建和烧录 smp_svr 应用程序将无法正常工作。MCUboot 是启动应用程序并将控制权移交给应用程序所必需的。 2. 我在文件 /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards 中添加了覆盖文件 lpcxpresso55s69_lpc55s69_cpu0.overlay。 &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. 使用以下命令构建项目： west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. 建成之后。您可以使用命令 grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts Harry_Zhang_2-1786007232854.png 5. 和西闪光 6. Harry_Zhang_0-1786007007588.png 7. Harry_Zhang_1-1786007044209.png 这证实了 UART 传输、SMP 服务器、MCUmgr 和 MCUboot 集成均正常工作。 BR 哈里 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 嗨@Harry_Zhang ， 巧合的是，就在我昨天发布这个问题之后，我正好在使用 Zephyr 的smp_svr示例。 我遇到的问题也完全一样。 我按照 Zephyr 文档中的示例进行了操作，链接如下。 我创建了一个示例项目，然后成功构建了代码，并按照文档说明，使用以下命令启用了Raw UART（串行） smp_svr 选项的配置： west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" 然后我成功地刷入了代码。 尽管如此： C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout 我甚至尝试将调试探针从 Link2 改为 JLink，之后调试探针就连接到了 COM16。为了以防万一，我还使用 JLink Commander 禁用了所有大容量存储设备功能。 然后我尝试刷机并运行： > west flash -r jlink 但再次出现这种情况： C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" 错误：NMP 超时 我究竟漏掉了什么？我猜这跟配置有关？如果是这样，我很好奇为什么 Zephyr 官方提供的smp_svr示例与 LPC55S69 不兼容，需要进行修改。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S 你好@ZQ2 由于 mcumgr echo 已经返回 NMP 超时，我认为您可以在调试 MCUboot DFU 流程之前验证 MCUmgr UART 通信。 您可以确认以下内容： flexcomm0 是连接到 LPCXpresso55S69 板上 COM11 的 UART。 应用程序运行正常（未停留在MCUboot串行恢复模式）。 没有控制台、shell 或日志输出与 MCUmgr 共享同一个 UART。 为了快速验证，我建议从 Zephyr 的smp_svr示例开始。 首先验证以下命令是否有效： mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR 哈里

[LPC55S69]Zephyr MCUboot for Device Firmware Update over UART が MCUmgr で動作しないLPC55S69 こんにちは、Core 0を使ってLPC55XpressoS69でZephyrのMCUbootを動かそうとしています。私はZephyrでシンプルなBlinkyサンプルアプリケーションを使っています。 エラーもなくアプリケーションは問題なく動いています。 しかし、mcumgrを使ってUART経由でデバイスファームウェアアップデート(DFU)を送信しようとしているのですが、なぜかmcumgrとデバイス間の接続すら確立できません。「NMPタイムアウト」が繰り返し発生します。 参考までに、私のディレクトリ構造は以下のようになっています。 | __ボード |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__ main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf 私のprj.confファイルは以下のようになっています。   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y 私のsysbuild.confは以下のとおりです。   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y 私のmcuboot.confは次のようになっています。   CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   私のmcuboot.overlayは次のようになっています。 /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; そして最後に、私のlpCXpresso55s69_lpc55s69_cpu0.overlayは次のようになります。 / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 以下の MCUmgr コマンドを実行すると、以下に示すように NMP タイムアウトが発生します。 > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout つまり、mcumgrはポートが利用可能であることを確実に認識しています(そうでなければアクセスを拒否します)が、タイムアウトが続いています。 これは設定オプションのエラーだと思います。設定オプションを何度も変更してみましたが、どれもうまくいきません。おそらく、この機能を動作させるために不可欠な設定オプションがどこかに抜けているのだと思います。 できるだけ多くのアプリケーションノートやユーザーマニュアルを調べました。私のケースにはどれも役に立たないようです。例えば、Zephyrアプリケーションを動かすLPC55Sxxチップ上のDFU MCUbootを使う場合です。 どんな助けでもありがたいですが、誰かが自分のボードで試すのが一番良いかもしれません。LPCXpresso55S69を送り、どんな簡単なプログラムでもUART DFUを実行できるか確認してください。 LPC55S6x LPC55S69-EVK LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @ZQ2さん LPCXpresso55S69ボード上で、この設定を再現し、検証することができました。 1.重要な点は、この構成ではMCUmgrをMCUbootと併用する必要があるということです。アプリケーションはslot0にリンクされている(フラッシュベースアドレスではありません)ため、smp_svrアプリケーションを単独でビルディングしてフラッシュするだけでは正しく動作しません。起動と制御をアプリケーションに引き渡すにはMCUbootが必要です。 2. /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boardsのオーバーレイファイルlpcxpresso55s69_lpc55s69_cpu0.overlayを追加します。 &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. 以下のコマンドを使用してプロジェクトをビルドしました。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. それを建てた後。コマンドを使うことができます grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts Harry_Zhang_2-1786007232854.png 5. そして西の閃光 6. Harry_Zhang_0-1786007007588.png 7. Harry_Zhang_1-1786007044209.png これは、UARTトランスポート、SMPサーバー、MCUmgr、およびMCUbootの統合がすべて正しく動作していることを確認するものです。 BR ハリー Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @Harry_Zhang さん。 あなたの解決策は確かに効果があります。実際、私はコマンドを単に west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" これも効果があった。私の問題を再現していただき、本当にありがとうございます。大変感謝しています。 Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @ZQ2さん mcumgr echoはすでにNMPタイムアウトを返しているので、MCUbootのDFUフローをデバッグする前にMCUmgr UART通信を検証できると思います。 以下のことを確認できます: flexcomm0はLPCXpresso55S69ボード上のCOM11に接続されたUARTです。 アプリケーションは通常通り動作しており(MCUbootのシリアルリカバリーモードにとどまっていません)。 コンソール、シェル、ログ出力のいずれも、MCUmgrが使用するUARTを共有していません。 簡単な検証として、Zephyrの smp_svr サンプルから始めることをお勧めします まず、以下のコマンドが正しく動作することを確認してください。 mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR ハリー Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S こんにちは、 @Harry_Zhang さん。 偶然にも、昨日この質問を投稿した直後にZephyrのsmp_svr サンプルを使っていました。 私も全く同じ問題に直面しています。 以下の リンクにあるZephyrのサンプルドキュメントに従って確認しました。 サンプル用のプロジェクトを作成し、ドキュメントに記載されている以下のコマンドを使用して、 Raw UART (serial) smp_svr オプションの設定を有効にして、コードを正常にビルドしました。 west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" そして、コードの書き込みに成功しました。 それにもかかわらず： C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout デバッガープローブをLink2からJLinkに変更してみたところ、デバッグプローブがCOM16に接続されるようになりました。念のため、JLinkコマンドーを使ってマスストレージデバイスの機能も無効にしました。 次に、フラッシュして実行してみました。 > west flash -r jlink しかし、またしても： C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" エラー:NMPタイムアウト 一体何を見落としているのでしょうか?設定に関係があるのでしょうか？もしそうなら、なぜZephyrの公式サンプルがLPC55S69 smp_svrと互換性がなく、改造が必要なのか疑問です。

请问有人可以帮我找到S32K3的功能安全手册吗？ 大家好，我正在寻找NXP S32K3 MCU系列的**功能安全**手册。请问有人能帮我找到它或者提供访问方式吗？ Re: Could someone please help me find the Safety Manual for the S32K3? HI 你已经和恩智浦签署保密协议了吗？如果您不确定公司是否与恩智浦半导体签署了保密协议，请告诉我公司的全名或地址。 如果您已经持有有效的保密协议，请参考此文档注册安全文件帐户。 获得安全文件访问权限后，您可以点击 S32K3 产品页面 文档部分的“安全”按钮 ，下载 功能安全手册 。 Safety Manual S32K3.png 此致敬礼， Robin

どなたかS32K3のセーフティマニュアルを探すのを手伝ってもらえますか? 皆さんこんにちは、NXP S32K3 MCUファミリのセーフティマニュアルを探しています。どなたか見つける手助けやアクセス方法の情報を教えていただけませんか? Re: Could someone please help me find the Safety Manual for the S32K3? ハイ NXP社とは既に秘密保持契約（NDA）を締結済みですか？もし会社がNXPとNDAを結んでいるか確信が持てない場合は、会社のフルネームか住所を教えてください。 既に有効な秘密保持契約（NDA）をお持ちの場合は、この文書を参照してセキュアファイルアカウントを登録してください。 Secure Fileへのアクセスができたら、 S32K3製品ページの ドキュメントセクションで 「Secure 」をクリックして セーフティマニュアル をダウンロードできます。 Safety Manual S32K3.png よろしくお願いいたします ロビン

Kinetis 和 LPC 的调试接口有什么建议？ 我目前主要从事 Kinetis 系列芯片的开发工作，未来可能还会开发一些 LPC 芯片。我抽屉里装满了 P&E Micro 的调试接口，其中最常用的是 Cyclone ACP。 我有时会发现自己从 600 美元的 Cyclone 换成了 20 美元的 LPC-Link2，因为 Cyclone 与 MCUXpresso 存在很多奇怪的问题。说实话，LPC-Link2 基本能满足我的需求，只是速度有点慢。 我应该考虑使用Segger接口吗？请问有人可以推荐一款可靠、速度适中、在 MCUXpresso（最好也能在 CodeWarrior 11）中支持良好的接口吗？这款接口不会经常导致程序崩溃，也不会无法停止正在运行的目标。如果能支持追踪功能就更好了。 谢谢您！ Re: Debug interface recommendations for Kinetis and LPC? 嗨@richard37 感谢您的帖子！ 您不妨考虑一下 SEGGER J-Link。它与 MCUXpresso 一起使用时支持 Kinetis 和 LPC 设备，并且 CodeWarrior 11 也原生支持它。 如果您需要一种可以在开发环境和设备系列中使用的调试探针，那么它是一个很好的选择。

KinetisとLPC用のデバッグインターフェースのおすすめはありますか? 私は主にKinetisシリーズで開発をしており、近い将来LPCのパーツもいくつか手がけるかもしれません。P&E Microのデバッグインターフェースが引き出しいっぱいにあり、よく使っているCyclone ACPも含まれています。 時々、600ドルのCycloneから20ドルのLPC-Link2に切り替えることがあります。なぜなら、CycloneはMCUXpressoに多くの奇妙な問題があるからです。正直なところ、LPC-Link2は私の必要な機能のほとんどを満たしてくれるのですが、少し動作が遅いのが難点です。 Seggerインターフェースを検討しるべきでしょうか?MCUXpresso(そしてできればCodeWarrior 11でも)で十分にサポートされ、クラッシュや走行中のターゲットを止められない信頼性が高く、そこそこ高速なインターフェースを誰かおすすめできませんか?トレースサポートがあれば助かります。 よろしくお願いします！ Re: Debug interface recommendations for Kinetis and LPC? こんにちは、@richard37さん 投稿ありがとうございます！ SEGGER J-Linkを検討してみるのも良いかもしれません。MCUXpressoと組み合わせて使用した場合、KinetisとLPCの両方に対応しており、CodeWarrior 11でもネイティブサポートされています。 これにより、開発環境やデバイスファミリーの両方で使えるデバッグプローブが必要な場合に良い代替手段となります。

MCUXpresso SDK 最新版本 - 推荐的闪存数据存储方案 大家好，   我正在评估最新版本的 MCUXpresso SDK，并使用 NXP MCU。       对于将小型配置参数（设备设置、校准值、计数器等）保存到内部闪存中，目前推荐的方法是什么？     具体来说：   1. 使用专用闪存存储区还是 EEPROM 仿真（在支持的情况下）更好？   2. 频繁执行闪存写入操作时，是否存在性能或可靠性方面的考虑因素？ 3. NXP 是否有任何示例项目来展示参数存储和损耗均衡的最佳实践？ 4. 是否有推荐的用于管理持久配置数据的 SDK 库？ 我已经查阅了现有的 SDK 文档，但我希望能够获得关于新项目推荐实施方法的指导。   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage 你好@Manjuanth ， 我看到您已将此帖子发布在 S32K 的产品论坛上，但是 S32K 的 MCU 与 MCUXpresso 不兼容，请改用S32 Design Studio 。请问您使用的是哪款恩智浦MCU？ 此致， 朱利安

MCUXpresso SDK 最新バージョン - フラッシュデータストレージの推奨アプローチ チームの皆さん、こんにちは。   私は最新バージョンのMCUXpresso SDKを評価しており、NXP MCUを使って作業しています。       小さな設定パラメータ(デバイス設定、キャリブレーション値、カウンターなど)を内部フラッシュメモリに保存する場合、現在推奨されている方法は何でしょうか?     具体的には：   1. 専用のフラッシュストレージ領域を使用するのと、EEPROMエミュレーション（サポートされている場合）を使用するのとでは、どちらが良いでしょうか？   2. フラッシュメモリへの書き込み操作を頻繁に行う場合、パフォーマンスや信頼性に関して考慮すべき点はありますか？ 3. NXPは、パラメータの保存とウェアレベリングに関するベストプラクティスを示すサンプルプロジェクトを提供していますか？ 4. 永続的な設定データを管理するために推奨されるSDKライブラリはありますか? 利用可能なSDKドキュメントは確認しましたが、新規プロジェクトでの推奨実装アプローチについての指針をいただけるとありがたいです。   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage こんにちは、 @Manjuanth さん。 S32Kの製品フォーラムに投稿されているのを見ましたが、S32KのMCUはMCUXpressoと互換性がなく、代わりに S32 Design Studioを使っています。どのNXPのMCUを使っているか教えてもらえますか? よろしくお願いします、 ジュリアン

MRF300AN 27MHz 参考设计 TVS 和电源时序 您好，NXP团队，关于MRF300AN-27MHz参考设计有两个问题：问题1：我可以在漏极和地之间连接一个110V TVS进行保护吗？Vds 为 133V。这是个好选择吗？Q2：正确的开机顺序是什么？栅极偏置先于漏极，还是漏极偏置先于栅极？另外，射频驱动应该缓慢增加功率还是可以直接施加全功率？谢谢。 Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence 你好， 一般而言，TVS 反向截止电压应选择高于最大正常工作漏极电压，以防止正常工作期间发生意外导通，同时还能提供对异常瞬态事件的保护。 关于上电顺序，漏极电源可以在栅极偏置之前施加，反之亦然。在稳定且经过适当调整的电路中，这两种方法都是可以接受的。 此外，建议逐步增加射频驱动功率，而不是突然施加全功率驱动，因为这有助于确保更平稳的启动，并减少设备在运行条件下的压力。 希望这能帮到你！

MRF300AN 27MHzリファレンス設計TVSとパワーシーケンス こんにちは、NXPチームの皆さん。MRF300AN-27MHzのリファレンスデザインについて2つ質問があります。Q1:110V TVSをドレインからアースにかけて保護してもいいですか?Vdsは133Vです。これは良い選択でしょうか？Q2: 正確な電源オンシーケンスは何ですか?ゲートバイアスをドレインの前に置くべきか、ドレインバイアスをゲートの前に置くべきか？また、RFドライブはゆっくりと増やすべきでしょうか、それともフルドライブを直接適用してもいいのでしょうか?ありがとう。 Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence こんにちは、 一般的に、TVSの逆スタンドオフ電圧は通常動作中の最大動作ドレイン電圧より高い位置に選択し、正常運転中の意図しない導電を防ぎつつ、異常な過渡現象からの保護も提供します。 電源アップシーケンスに関しては、ドレイン電源をゲートバイアスの前に、またはその逆に適用することができます。どちらの方法も、安定していて適切に調整された回路であれば許容範囲内である。 さらに、RFドライブを急激にフルドライブするのではなく、徐々にパワーアップさせることが推奨されており、これにより起動がスムーズになり、動作時のデバイスへの負荷も軽減されます。 お役に立てば幸いです！

i.MX8MP: SAI3オーディオを有効にしてM7を実行すると、SErrorとページフォルトが発生します。 NXP公式チームの皆様、こんにちは。 i.MX 8M Plus プラットフォームを使用し、 Linux A53 と FreeRTOS M7 を実行する システムを開発しています 。M7 を実行中に SAI3 オーディオインターフェースをLinuxに割り当てようとしたところ、カーネルクラッシュ（SError/ページフォルト）が発生しました。 1. ソフトウェアのバージョンと環境： カーネルバージョン: Linux 5.10.72 U-Bootバージョン: U-Boot 2021.04 M7 SDK: i.MX8MP 用 MCUXpresso SDK (rpmsg_lite_str_echo_rtos) 公式記事を参照してください: NXPナレッジベース: remoteprocを使用してM7ファームウェアを実行中にSAI3をテストする 2. システム構成：   <1> M7ファームウェア（m7.bin）はシステムパーティションに保存され、...U-Bootステージは、bootaux 0x007e0000コマンドを使用して直接起動されます。 <2> Cortex-A53 Linux側では、SAI3 + I2C3 + SDMA3バスに搭載された物理サウンドカードチップ（SGTL5000）を使用します。 <3> Cortex-M7は、GPIO2_IO09ピンでデータを取得し、高周波サンプリング割り込みをトリガーし、RPMsg仮想シリアルポート（/dev/ttyRPMSG30）を介してコア間でA53 Linuxとやり取りする役割を担っています。 3．発生した問題： サウンドカードのリソースがA53に調整されていない場合、/dev/ttyRPMSG30デバイスの動作は正常です。 現在、A53サウンドカードが必要です。公式記事「<リモートプロシージャコールでM7ファームウェアを実行中にSAI3をテストする>」に従って、以下の調整を行いましたが、カーネルの起動時に問題が発生します。変更点は以下のとおりです。 <1> カーネルのDTS設定が復元され、サウンドカードの設定が添付ファイル に示すようにA53に変更されました。 <2> u-boot dts: A53 にサウンドカードのリソースを割り当てます。例: <3> ATF、 SAI3、sdma3、i2c3をA53に割り当て、 imx8mp_bl31_setup.cを修正します。例： <4>M7 SDK: 添付の および に示されているように、AUDIO の変更に関連する BOARD_BootClockRUN および BOARD_RdcInit 関数に関するコメント。 4. カーネルのdmesgクラッシュログ： 以下のログに示すように、カーネル起動中にシステムがフリーズします。 [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none 問題点をご確認いただき、解決に役立つ関連文書や修正点がないかご検討ください。ご提案やご回答をお待ちしております。よろしくお願いいたします。 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled 解決しました。M7側のオーディオ設定を完全に無効にする必要がありました。

i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled Hello NXP official team: We are developing a system using the i.MX 8M Plus platform, running Linux A53 and FreeRTOS M7 . While attempting to allocate the SAI3 audio interface to Linux while running M7, we encountered a kernel crash (SError/page fault). 1. Software version and environment: Kernel version: Linux 5.10.72 U-Boot version: U-Boot 2021.04 M7 SDK: MCUXpresso SDK for i.MX8MP (rpmsg_lite_str_echo_rtos) Refer to the official article: NXP Knowledge Base: Test SAI3 while running M7 firmware with remoteproc 2. System configuration:   <1> The M7 firmware (m7.bin) is stored in the system partition and...The U-Boot stage is started directly using the command bootaux 0x007e0000. <2> On the Cortex-A53 Linux side, we use a physical sound card chip (SGTL5000) mounted on the SAI3 + I2C3 + SDMA3 bus. <3> The Cortex-M7 is responsible for acquiring data on the GPIO2_IO09 pin and triggering a high-frequency sampling interrupt, and interacting with the A53 Linux across cores via the RPMsg virtual serial port (/dev/ttyRPMSG30). 3. Problems encountered: If the sound card resources are not adjusted to A53, the operation of the /dev/ttyRPMSG30 device is normal; Currently, an A53 sound card is required. Following the official post < Test SAI3 while running M7 firmware with remoteproc >, the following adjustments were made, but kernel booting will cause issues. The changes are as follows: <1> The kernel DTS configuration has been restored, and the sound card configuration has been changed to A53, as shown in the attached <2> u-boot dts: Allocates sound card resources to the A53, such as <3> ATF, assign SAI3, sdma3, and i2c3 to A53, modify imx8mp_bl31_setup.c, such as: <4> M7 SDK: Comments on the BOARD_BootClockRUN and BOARD_RdcInit functions related to AUDIO changes, as shown in the attached and . 4. Kernel dmesg crash log: The system freezes during boot into the kernel, as shown in the following log: [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none Please take a look at the problem and see if there are any relevant documents or modifications that can resolve it. Looking forward to your suggestions and replies! Thank you! 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled Resolved; the audio configuration on the M7 side needs to be completely disabled.

S32 IDE開発環境のRTDプラグインをインストールできません。 S32Z280プロセッサ用のソフトウェアを開発するには、S32 IDE開発環境にS32ZE RTDプラグインをインストールする必要があります。しかし、図1に示すように、この環境ではインストールが失敗します。NXPのWebサイトからダウンロードしようとしても、ライセンスが必要なためダウンロードできません。ライセンスの取得方法についてご教示ください。よろしくお願いいたします。 Re: S32 IDE开发环境RTD插件无法安装 どういたしまして。ご質問があればいつでもお気軽にご連絡ください！ Re: S32 IDE开发环境RTD插件无法安装 最初のリンクではアカウントログインが必要で、ログイン後もインストールパッケージのダウンロードパスが表示されませんでした。2番目のリンクからは「カーパッケージマネージャー」にアクセスしてインストールパッケージを正常にダウンロードできました。ありがとうございました。 Re: S32 IDE开发环境RTD插件无法安装 こんにちは、 Flynn_T 1. このリンクからダウンロードできますか？最新のRTDバージョンは2.0.1 QLP01のはずです。ご指摘のバージョン1.1.45はリストにありません。また、2.0.1 QLP01 RTDにはS32DS IDEバージョン3.6.1が必要です。 設計：製品情報：車載用ソフトウェア - S32Z/E - リアルタイムドライバ（RTD） Joey_z_0-1786528248987.png 2. このリンクからダウンロードできるかどうか確認することもできます。 自動車パッケージマネージャー | NXPセミコンダクターズ BR ジョーイ Re: S32 IDE开发环境RTD插件无法安装 こんにちは、BRジョーイ S32 IDE バージョン 3.6.10 を使用しています。必要な RTD バージョンは 1.1.45 です。NXP の公式サイトで S32Z/E RTD プラグインのダウンロードリンクが見つかりませんでした。ダウンロードリンクを提供していただけますでしょうか。 宜しくお願いします Flynn_T Re: S32 IDE开发环境RTD插件无法安装 こんにちは、 Flynn_T 使用しているS32 IDEのバージョンは何ですか？使用しているRTDのバージョンは何ですか？ IDEにS32Z/E RTDプラグインをロードする場合、通常はライセンスは必要ありません。 BR ジョーイ

The S32 IDE development environment RTD plugin cannot be installed. To develop software for the S32Z280 processor, you need to install the S32ZE RTD plugin in the S32 IDE development environment. However, installation fails in the environment, as shown in Figure 1. It cannot be downloaded from the NXP website, which requires a license. Please provide information on how to obtain the license. Thank you. Re: S32 IDE开发环境RTD插件无法安装 You're welcome. Feel free to contact me anytime if you have any questions! Re: S32 IDE开发环境RTD插件无法安装 The first link required account login, and the download path for the installation package was not displayed after logging in. The second link allowed me to successfully download the installation package after accessing the "Car Package Manager," thank you. Re: S32 IDE开发环境RTD插件无法安装 Hi, Flynn_T 1. Can you download it from this link? The latest RTD version should be 2.0.1 QLP01; version 1.1.45, which you mentioned, is not listed. Also note that the 2.0.1 QLP01 RTD requires S32DS IDE version 3.6.1. Design: Product Information: Automotive SW - S32Z/E - Real Time Drivers (RTD) Joey_z_0-1786528248987.png 2. You can also check this link to see if you can download it. Automotive Package Manager | NXP Semiconductors BR Joey Re: S32 IDE开发环境RTD插件无法安装 Hi, BR Joey I'm using S32 IDE version 3.6.10. The required RTD version is 1.1.45. I couldn't find a download link for the S32Z/E RTD plugin on the NXP official website. Please provide a download link. Best Regard Flynn_T Re: S32 IDE开发环境RTD插件无法安装 Hi, Flynn_T What version of S32 IDE are you using? What version of RTD are you using? Loading the S32Z/E RTD plugin in the IDE generally does not require a license. BR Joey

WS2812接口与LPC5514JBD64E NXP社区的各位好， 我正在使用基于 LPC5514JBD64E 的控制器，需要将 WS2812/WS2812B LED 环与 MCU 连接。 我正在研究 LPC5514JBD64E 数据手册和我的控制器原理图，但我对 LPC55xx 系列还不熟悉，需要一些指导。 我想知道： 1. LPC5514JBD64E 的哪个 GPIO 引脚应该用于 WS2812 数据（DIN）信号？ 2. 由于 LPC5514JBD64E 使用 3.3V 逻辑，而 WS2812 由 5V 供电，那么 MCU 和 WS2812 之间推荐的硬件连接是什么？ 3. 是否建议在 MCU GPIO 和 WS2812 DIN 之间使用 74AHCT125？ 4. 应使用哪种外设或方法来生成 WS2812 协议所需的精确时序？ 5. 是否有使用 LPC5514JBD64E 控制 WS2812 或 NeoPixel LED 的官方 NXP SDK 示例、驱动程序或示例代码？ 6.如果没有 WS2812 的具体示例，您能否提供或指出一个基本的、可运行的示例代码，使 WS2812 LED 或 LED 环闪烁或改变颜色？ 7. 对于这款MCU，推荐的开发环境和编程/调试流程是什么？ 我眼下的目标是使用 LPC5514JBD64E 使 WS2812 LED 环闪烁并显示不同的颜色。 我希望能够得到关于正确的GPIO、硬件连接、外设和示例代码方面的指导。 谢谢！ LPC55xx Re: WS2812 interface With LPC5514JBD64E 请问能否提供一下这个项目的代码？ Re: WS2812 interface With LPC5514JBD64E 嗨@Kishore02 1. WS2812 协议需要一个精确定时的单线数字输出信号。因此，DIN 信号最好由定时器/PWM 外设生成，而不是通过软件位操作生成。 对于 LPC551x 设备，一个实用的解决方案是使用 SCTimer 输出。 具体引脚取决于您的硬件设计和引脚复用配置。任何可以配置为 SCTimer 输出的引脚都可以使用。 例如，LPC55S16 SDK 提供了 sctimer_pwm_with_dutycycle_change 示例，该示例使用了： SCT0_OUT2 (J12-12 on LPCXpresso55S16 board) 2. 由于 LPC5514 工作在 3.3 V 逻辑电平，而 WS2812 通常由 5 V 供电，因此建议进行电平转换以提高信号完整性并确保可靠运行。 3. 是的。 74AHCT125 是连接 3.3 V MCU 和 5 V WS2812 设备的常用推荐解决方案。 4. 对于 LPC551x 设备，首选方法是： SCTimer（推荐） 生成一个 800 kHz 的波形。 动态更新每个传输比特的PWM占空比。 与 SDK 示例类似： sctimer_pwm_with_dutycycle_change 5.目前，我还没有发现专门针对 LPC5514 的 WS2812 或 NeoPixel LED 的官方 MCUXpresso SDK 示例。 不过，SDK 提供了几个 SCTimer PWM 示例，可以作为起点。 尤其： sctimer_pwm sctimer_pwm_with_dutycycle_change 虽然我没有找到适用于 LPC5514 SDK 的 WS2812 专用示例，但我之前使用 SCTimer + eDMA 方案在 FRDM-MCXN947 板上实现了可靠的 WS2812 控制。 6.我建议从以下方面开始： lpcxpresso55s16_sctimer_pwm_with_dutycycle_change 7. 推荐的开发环境是： MCUXpresso IDE MCUXpresso SDK LPC-Link2 或 MCU-Link 调试器 板载 CMSIS-DAP 调试器（如果评估板上有） 希望这对您有所帮助。 BR 哈里

WS2812とのインターフェースLPC5514JBD64E こんにちは、NXPコミュニティの皆さん、 私はLPC5514JBD64Eベースのコントローラーを使っていて、WS2812/WS2812B LEDリングをMCUとインターフェースする必要があります。 LPC5514JBD64Eのデータシートとコントローラ回路図を勉強していますが、LPC55xxファミリは初心者で、アドバイスが必要です。 知りたいのは以下の点です。 1. LPC5514JBD64EのどのGPIOピンをWS2812のデータ（DIN）信号に使用すればよいですか？ 2. LPC5514JBD64Eは3.3Vロジックを使用し、WS2812は5Vで電源供給されるため、MCUとWS2812の間に推奨されるハードウェア接続は何でしょうか? 3. MCU GPIOとWS2812 DINの間で74AHCT125が推奨されるか? 4. WS2812プロトコルで求められる正確なタイミングを生成するためには、どのペリフェラルまたは方法を使うべきか? 5. WS2812やNeoPixel LEDをこのLPC5514JBD64Eで制御するための公式のNXP SDK例、ドライバー、またはサンプルコードはありますか? 6.もしWS2812特有の例がなければ、WS2812のLEDやLEDリングが点滅したり色を変えたりする基本的な動作例コードを教えてもらえますか? 7. このMCUに推奨される開発環境およびプログラミング・デバッグ手順は何ですか? 私の当面の目標は、LPC5514JBD64Eを使用してWS2812 LEDリングを点滅させ、異なる色を表示させることです。 正しいGPIO、ハードウェア接続、ペリフェラル、そして例コードについてのアドバイスをいただけるとありがたいです。 ご回答をお待ちしています。 LPC55xx Re: WS2812 interface With LPC5514JBD64E このプロジェクトのコードを教えていただけますか? Re: WS2812 interface With LPC5514JBD64E こんにちは、 @Kishore02さん 1. WS2812プロトコルでは、正確なタイミングで出力される単線デジタル信号が必要です。したがって、DIN信号はソフトウェアのビットバンギングではなく、タイマーやPWMペリフェラルによって生成されるべきです。 LPC551xデバイスの場合、実用的な解決策の一つはSCTimer出力を使用することです。 正確なピンはハードウェア設計やピンマルチマックス構成によって異なります。SCTimer出力として設定可能なピンなら、どんなものでも使用可能です。 例えば、LPC55S16 SDKはsctimer_pwm_with_dutycycle_change例を提供しており、以下を使用します: SCT0_OUT2 (J12-12 on LPCXpresso55S16 board) 2. LPC5514は3.3Vロジックで動作し、WS2812は通常5Vで駆動されるため、信号の完全性を向上させ、信頼性の高い動作を確保するためにレベルシフトが推奨されます。 3. はい。 74AHCT125は、3.3V MCUと5V WS2812デバイスを接続する際に一般的に推奨されるソリューションです。 4. LPC551xデバイスの場合、推奨されるアプローチは次のとおりです。 SCTimer（推奨） 800kHzの波形を生成する。 送信ビットごとにPWMデューティサイクルを動的に更新します。 SDKの例に似ています: sctimer_pwm_with_dutycycle_change 現時点では、LPC5514向けにWS2812やNeoPixel LEDを特化した公式のMCUXpresso SDK例は知りません。5.At しかし、SDKには出発点として使えるいくつかのSCTimer PWM例も提供されています。 特に： sctimer_pwm sctimer_pwm_with_dutycycle_change LPC5514 SDK専用のWS2812例はまだ見つかっていませんが、以前はSCTimer + eDMAソリューションを使ってFRDM-MCXN947ボード上で信頼性の高いWS2812制御を実現しました。 6.まずは以下から始めることをお勧めします。 lpcxpresso55s16_sctimer_pwm_with_dutycycle_change 7. 推奨される開発環境は以下のとおりです。 MCUXpresso IDE MCUXpresso SDK LPC-Link2またはMCU-Linkデバッガ オンボードCMSIS-DAPデバッガ(評価ボードに搭載されている場合) これがあなたのお役に立てば幸いです。 BR ハリー

i.MX8M Plus HiFi4 DSP（Zephyr）：SDMA 循环发送回调触发一次后停止 在运行 Zephyr 的 i.MX8MP HiFi4 DSP 上，我正在使用 Zephyr nxp,dai-sai (SAI3) 和 nxp,sdma (SDMA3) 驱动程序以循环模式启动硬件端点播放路径。开始播放时，SDMA 通道完成回调恰好触发一次，然后不会再发生 SDMA 中断。我想请教一下，为什么循环 SDMA 传输不会持续产生周期性中断？ 硬件/启动 - 板：i.MX8MP EVK，DTS：imx8mp-evk-dsp.dts - DSP核心：HiFi4（Cadence Xtensa），目标板为imx8mp_evk/mimx8ml8/adsp - 编解码器：WM8960 - 外设：SAI3、SDMA3 建筑和版本细节： - 架构概述： https://audioreach.github.io/platform/nxp.html#architecture-overview - 版本详情： - Yocto： https://audioreach.github.io/platform/nxp.html#step-1-create-a-yocto-image - Linux（控制/主机）：Yocto（scarthgap）、linux-imx。 - 仓库清单：imx-6.6.52-2.2.0.xml - Zephyr DSP 镜像： https://audioreach.github.io/platform/nxp.html#step-2-create-a-zephyr-image - Zephyr (v4.2.0)， AudioReach Engine信号处理框架，运行于 HiFi4 上。 我正在建造的东西 DSP 映像中的一个自定义硬件端点（接收器）模块，其功能如下： 1.通过 Zephyr DAI API 配置 SAI3。 2.建立从 动态随机存取存储器 (DRAM) 环到 SAI TX FIFO 的循环 SDMA 传输（2 个缓冲区描述符，MEMORY_TO_PERIPHERAL）。 3.使用 SDMA 完成回调来通知信号处理框架重新填充环。 音频格式 - 48 kHz，16 位，单声道音频流；SAI 线 = 16 位 × 2 个插槽（WM8960 的立体声 I2S 帧），BCLK = 1.536兆赫兹。 - DMA 周期 = 192 字节（48 帧 × 2 字节 × 2 个时隙），2 个描述符，384 字节环 已启用相关 Kconfig（DSP 映像）。 CONFIG_DAI=y CONFIG_DMA=y CONFIG_DAI_NXP_SAI=y CONFIG_DMA_NXP_SDMA=y CONFIG_SAI_HAS_MCLK_CONFIG_OPTION=y CONFIG_CLOCK_CONTROL_FIXED_RATE_CLOCK=y 设备树叠加（DSP 应用）： 链接： app/boards/imx8mp_evk_mimx8ml8_adsp.overlay mclk1：mclk { 状态 = "正常"; }; &sdma3 { 状态 = "正常"; }; &sai3 { rx-fifo-watermark = <65>; tx-fifo-watermark = <65>; 先进先出深度 = <128>; rx-sync-mode = <1>; 状态 = "正常"; }; &micfil { 状态 = "正常"; }; 使用的DAI/DMA配置（DSP） - dai_config: type=DAI_IMX_SAI, dai_index=3, format= DAI_PROTO_I2S (SAI 从设备), rate=48000, channels=2, word_size=16. - SAI 定制：mclk_rate=12288000，fsync_rate=48000，bclk_rate=1536000，tdm_slots=2，tx_slots=rx_slots=0x3，tdm_slot_width=16。 - DMA（struct dma_config）：channel_direction=MEMORY_TO_PERIPHERAL，source_data_size=4，dest_data_size=4，source_burst_length=4，cyclic=1，block_count=2，dma_slot 来自 SAI 握手，dma_callback 设置。两个 dma_block_config BD 指向 dma_src_addr[0/192] 源代码参考： endpoint/capi/src/capi_nxp_device_utils.c 应用程序处理器： - DTS：imx8mp-evk-dsp.dts https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx8mp-evk-dsp.dts - 使用虚拟 DAI 和虚拟平台枚举带有 wm8960 编解码器的 PCM 设备。 附件： - DSP 日志（sdma，sai） - 修改了 imx8mp-evk-dsp.dts 我很乐意提供其他任何细节。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 多媒体 Re: i.MX8M Plus HiFi4 DSP (Zephyr): SDMA cyclic TX callback fires once then stops 在恩智浦技术支持有机会查看此问题之前，我只想指出： 开始播放时，SDMA 通道完成回调函数会触发一次。 此中断发生在 SDMA 脚本完成运行通道 0（用于加载固件）之后，因此没有实际的传输发生。我会开始检查SAI配置和时钟。看起来没有SDMA请求。

i.MX8M Plus HiFi4 DSP(Zephyr):SDMAのサイクリックTXコールバックが一度だけ発生し、その後停止します Zephyrを動かすi.MX8MP HiFi4 DSPでは、Zephyr nxp、dai-sai(SAI3)、nxp、sdma(SDMA3)ドライバーをサイクリックモードでハードウェアエンドポイント再生パスを起動しています。再生開始時には、SDMAチャネル完了コールバックが正確に一度だけ発生し、その後はSDMA割り込みが発生しません。周期的なSDMA転送が定期的な割り込みを生成し続けない理由を特定するのにご協力をお願いします。   ハードウェア/起動 - ボード:i.MX8MP EVK、DTS: IMX8MP-EVK-DSP.DTS  - DSPコア:HiFi4(Cadence Xtensa)、ボードターゲットはimx8mp_evk/mimx8ml8/adsp - コーデック:WM8960 - ペリフェラル:SAI3、SDMA3 建築および建設の詳細： - アーキテクチャ概要： https://audioreach.github.io/platform/nxp.html#architecture-overview - ビルドの詳細: - ヨクト: https://audioreach.github.io/platform/nxp.html#step-1-create-a-yocto-image      - Linux(コントロール/ホスト):Yocto(scarthgap)、linux-imx。      - 回収マニフェスト:imx-6.6.52-2.2.0.xml - ゼファーDSP画像: https://audioreach.github.io/platform/nxp.html#step-2-create-a-zephyr-image - Zephyr(v4.2.0)、HiFi4上で動作する AudioReach Engine信号処理フレームワーク。   私が作っているもの DSPイメージ内のカスタムハードウェアエンドポイント(シンク)モジュールで、以下のようなものを用いています。 1.Zephyr DAI APIを通じてSAI3を設定できます。 2.DRAMリングからSAI TX FIFOへの周期的なSDMA転送（2つのバッファ記述子、MEMORY_TO_PERIPHERAL）を設定します。 3.SDMAの完了コールバックを使って信号プロセッシングフレームワークにリングの再充填を指示します。   オーディオ format   - 48 kHz, 16-bit, mono stream; SAI wire = 16-bit × 2 slots (stereo I2S frame for WM8960), BCLK = 1.536 MHz。 - DMA周期 = 192バイト (48フレーム × 2バイト × 2スロット)、2ディスクリプタ、384バイトリング   関連するKconfig(DSPイメージ)有効化 CONFIG_DAI=y CONFIG_DMA=y CONFIG_DAI_NXP_SAI=y CONFIG_DMA_NXP_SDMA=y CONFIG_SAI_HAS_MCLK_CONFIG_OPTION=y CONFIG_CLOCK_CONTROL_FIXED_RATE_CLOCK=y   デバイスツリーオーバーレイ(DSPアプリ): リンク:app/boards/imx8mp_evk_mimx8ml8_adsp.overlay  mclk1: mclk { ステータス = "正常"; }; &sdma3 { ステータス = "正常"; }; &sai3 { rx-fifo-watermark = <65>; tx-fifo-watermark = <65>; fifo-depth = <128>; rx-sync-mode = <1>; ステータス = "正常"; }; &micfil { ステータス = "正常"; };   使用されたDAI / DMA設定(DSP) - dai_config:type=DAI_IMX_SAI、 dai_index=3、format=DAI_PROTO_I2S(SAIスレーブ)、レート=48000、チャネル=2、word_size=16。  - SAI 特注: mclk_rate=12288000、fsync_rate=48000、bclk_rate=1536000、tdm_slots=2、tx_slots=rx_slots=0x3、tdm_slot_width=16。 - DMA (struct dma_config): channel_direction=MEMORY_TO_PERIPHERAL、source_data_size=4、dest_data_size=4、source_burst_length=4、cyclic=1、block_count=2、dma_slot は SAI ハンドシェイクから取得、dma_callback が設定されています。2 つの dma_block_config BD が dma_src_addr[0/192] を指しています ソースコード参照: endpoint/capi/src/capi_nxp_device_utils.c 申請処理担当者: - DTS: imx8mp-evk-dsp.dts https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx8mp-evk-dsp.dts - ダミーDAIおよびダミープラットフォームを備えたwm8960コーデックのPCMデバイスを列挙。 添付資料: - DSPログ(SDMA、SAI) - 修正されたimx8mp-evk-dsp.dts その他の詳細情報も喜んでご提供いたします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano マルチメディア Re: i.MX8M Plus HiFi4 DSP (Zephyr): SDMA cyclic TX callback fires once then stops NXPのサポートがこの件を確認するまでは、ひとつ指摘しておきたいことがあります: > 再生開始時に、SDMAチャネル完了コールバックはちょうど一度だけ発生します この割り込みはSDMAスクリプトがチャネル0(ファイアワースロードに使われる)を実行し終えた後に発生し、実際の転送は行われていません。まずはSAIの設定とクロックを確認することから始めます。SDMAリクエストがないようです。

MR-CANHUBK344 IEEE1722 车载以太网示例 – 需要适用于 S32DS 3.5/3.6.7 的工作项目 您好， 我正在使用 MR-CANHUBK344，想使用其 100BASE-T1 车载以太网接口。 我的首要目标是在修改汽车以太网示例以适应我的应用之前，先在电路板上运行该示例。 我下载了官方的 MR_CANHUBK3_IEEE1722 示例。这看起来很合适，因为它演示了 MR-CANHUBK344、100BASE-T1、TJA1103、GMAC、IEEE 1722 ACF-CAN、CAN/CAN-FD 到以太网的转换以及 FreeRTOS。 但是，我遇到了工具链/版本兼容性问题。 我可用的环境有： S32 设计工作室 3.5 和 S32K3 RTD 3.0.0 S32 设计工作室 3.6.7 和 S32K3 RTD 7.0.1 当我导入原始的 MR_CANHUBK3_IEEE1722 项目时，可以看到源文件，但是当我尝试打开 .mex 文件时却无法打开。配置时出现以下错误： 处理器 S32K344，PlatformSDK_S32K3_2022_03 版本不受当前版本工具的支持。 例如，FreeRTOS_Toggle_Led_Example_S32K344.mex 无法打开，因为它需要 PlatformSDK_S32K3_2022_03。 我了解到最初的 MR_CANHUBK3_IEEE1722 演示程序是使用较旧的 S32DS/RTD 环境开发的。 我还尝试安装了 S32 Design Studio 3.4，并下载了 SW32K3_S32DS_3.4.3_D2112.zip。但是，我目前无法激活 S32DS 3.4，因为我的 NXP 帐户没有显示 v3.4 许可证授权。 请问您能否帮我解决以下其中一个问题？ 是否有适用于 S32DS 3.5 和 RTD 3.0.0 的 MR-CANHUBK344 IEEE1722 项目？ 是否有适用于 S32DS 3.6.x 的 MR-CANHUBK344 汽车以太网示例（已更新）还有更新的即饮版吗？ 目前，我只需要一个简单的汽车以太网演示，其中两个 MR-CANHUBK344 板建立 100BASE-T1 链路，并使用 S32K344 GMAC 和 TJA1103 发送/接收基本以太网帧。 现阶段我不需要 SOME/IP、TSN 或复杂的 TCP/IP 应用程序。 如果 MR_CANHUBK3_IEEE1722 有可用的 S32DS 3.5 移植版、更新的项目或迁移指南，请分享。 或者，如果您能帮我激活许可证就太好了。我点击了下载链接，但没有收到 3.4 版本的电子邮件。不过我收到了一封关于3.6版本的邮件。 谢谢！ Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 谢谢！ Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 你好@Aaditya773 ， 最初的 MR_CANHUBK3_IEEE1722 演示程序是为较旧的 S32DS / RTD 环境发布的，因此 .mex 文件也存在问题。与较新的 S32DS 3.5 / 3.6.x 版本不兼容版本号是预期的。我无法确认是否有适用于 S32DS 3.5 或 S32DS 3.6.x 的官方发布的 IEEE1722 ACF-CAN 演示程序的迁移版本。/ RTD 7.0.1。 对于您当前的目标是首先启动 100BASE-T1 以太网接口，我建议您从较新的以太网示例入手，而不是直接迁移旧的 IEEE1722 项目。 NXP 社区上有一个 MR-CANHUBK344 lwIP 示例：示例 S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600 。本示例基于 lwip_FreeRTOS_s32K344，适用于 MR-CANHUBK344 板，演示了如何 ping lwIP 协议栈。 然而，此示例是基于 RTD 6.0.0 的版本编写的。设置。因此，对于 RTD 7.0.1，我主要会将其用作参考，而不是直接导入的项目。更简洁的方法是，从已安装的 TCP/IP 协议栈附带的当前 lwip_FreeRTOS_s32k344 示例开始，然后根据社区示例调整 MR-CANHUBK344 的特定部分，主要是 GMAC / MII 端口映射、引脚配置、时钟、中断和 TJA1103 相关设置。 作为另一参考，您还可以使用软件包 SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip 中的 S32K344_gptp_ds 示例。 我已使用以下软件配置进行了快速检查： SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip 在对 S32 配置工具配置进行一些小的修改后，可以在此环境中构建 S32K344_gptp_ds 示例。 请注意，这不是原始 IEEE1722 ACF-CAN 演示的直接移植。对于使用较新的软件环境在 MR-CANHUBK344 上启动基本的 100BASE-T1 以太网而言，这是一种相当实用的方法。 为了使讨论更容易理解，也为了对其他用户有所帮助，让我们把这个帖子集中在 MR-CANHUBK344 以太网 / 100BASE-T1 启动主题上。如果您需要其他方面的帮助，请另开一个社区帖子。   顺祝商祺！ 帕维尔