Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
MC33774 デイジーチェーン デュアルループ接続 こんにちは。 現在、MC33665AとMC33774を使用してダブルチェーンループバック構造を形成するAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1はそれぞれMADD0とMADD1として構成されており、すべてのコマンドは現在MADD0経由で送信されています。PORT0とDC1の間だけをデイジーチェーン接続すると、通信は正常です。しかし、PORT1とDC2の間にもデイジーチェーン接続すると、33774が応答フレームで応答できないことがわかりました。これはなぜでしょうか?33665のPORT構成が正しいこと、および33774のSYS_TPL_CFG.RESPCFGが00 SAMEモードに設定されていることは確認済みです。 現在、私はMC33665AとMC33774を組み合わせたデュアルリングループ構成のAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1をそれぞれMADD0とMADD1として設定し、現在すべてのコマンドはMADD0経由で送信されています。 PORT0とDC1の間だけをデイジーチェーン接続した場合、通信は正常に動作します。しかし、PORT1とDC2の間にデイジーチェーン接続も行った後、MC33774にリクエストを送信しても応答しなくなりました。 なぜこのようなことが起こるのでしょうか? MC33665 PORT の設定を読み返して確認したところ、正しいことが分かりました。また、MC33774 で SYS_TPL_CFG.RESPCFG = 00 (SAME モード) を設定しました。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは。 1. MADD=1の位置からDADDの割り当てを反転させる必要があるかどうかを知りたいです。 2. 現在のSYS_PORT0_CFG構成は、TIMEOUT=0、CADD=1、MADD=0、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1です。 SYS_PORT1_CFG は、TIMEOUT=0、CADD=1、MADD=1、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1 で構成されています。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨によると、2つのMC33665A TPLポートがループバックリングとしてコネクテッドである場合、あなたが見ている挙動を引き起こすいくつかの設定要件があります。 ループバック構成の場合: デバイスアドレス(DADD)は、リングの一方の側からは昇順で、ループバック側からは逆順で割り当てることをお勧めします(あなたの画像にはそれが確認できません)。 2つのポートがループバックとしてコネクテッドされている場合、重複データがMC33665バッファに入るのを防ぐために、どちらか一方のポートはSYS_PORTx_CFG[RX] = 0であるべきです。 さらに、いずれかのポートのSYS_PORTx_CFG[ALLCHAINS]が0である必要があります。両方のループバックポートがALLCHAINSコマンドを受け入れている場合、文書にはこれが信号の競合や通信エラーを引き起こす可能性があると記載されています。 SYS_PORT0_CFGとSYS_PORT1_CFG(特にEN、RX、ALLCHAINS、MADD、CADD)の価値観を共有していただけますか?それは、ループバックポートがAN13910の推奨事項に従って構成されているかどうかを判断するのに役立ちます。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨事項によると、ループバックトポロジでは、DADDの割り当てはMADD=1側から逆にする必要があります。 さらに、現在の設定では、両方のポートでRX=1およびALLCHAINS=1となっています。ループバック接続の場合、重複ルーティングや通信の競合を避けるため、いずれかのポートでRXとALLCHAINSを無効にすることをお勧めします。 RX=0、ALLCHAINS=0のポート(例えばPORT1)を設定して、MC33774が応答フレームを返し始めるか確認していただけますか?
查看全文
调试 Flash 脚本覆盖“保护内部闪存区域”设置 您好, 我们目前正在测试FRDM-S32K344上从App1到App2的应用程序跳转。 我们的应用程序布局如下: 应用程序1起始地址: 0x00400000 应用程序2起始地址: 0x00500000 为了进行调试,我们使用了启用闪存保护的独立调试配置。 调试App1时,内存保护范围配置如下: 0x00500000 到 0x005FFFFF(用于保护 App2) 调试App2时,内存保护范围配置如下: 0x00400000 到 0x004FFFFF(用于保护 App1) 然而,在通过调试配置进行编程时,我们发现即使已经配置了内存保护范围,受保护的闪存区域仍然会被擦除。 请问有人能解释一下以下问题吗? Flash Programmer 在擦除/编程操作期间是否应遵守配置的内存保护范围? 是否需要进行任何额外的配置来防止受保护的闪存区域被擦除? 有没有人成功地使用内存保护功能,在 FRDM-S32K344 上只编写一个应用程序的同时,保留另一个应用程序? 日志文件和 LD 文件已附上,供您参考。 我们正在使用板上 PE 调试器 任何指导或建议都将不胜感激。 谢谢! Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好@Avinpat123 我在相同版本的 S32 Design Studio 中进行了快速测试,以确保它能够正常工作。我使用了相同的设置——一个应用程序被强制使用 0x40_0000 地址,而 0x50_0000 地址区域配置为保留;第二个应用程序被强制使用 0x50_0000 地址,而 0x40_0000 地址区域配置为保留: 以下日志显示此配置已被应用: 而且我可以看到内存中的内容确实被保留了下来,所以它运行正常。 我从你的截图中看到你配置了地址范围,但是“保留此范围”复选框没有启用。问题不就出在这里吗? 此致, Lukas Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好 @lukaszadrapa 谢谢回复,是的,正如您所说,复选框确实是问题所在,现在一切正常了。
查看全文
MBDTにおけるCANバス処理 FlexCAN0の設定には、NXPのS32K344用MBDTを使用しています。CANメッセージ処理のどの部分がNXPのブロックやツールボックスで管理され、何がアプリケーションで処理されるべきかを理解したいです。 仲裁やバッファの処理はドライバやツールボックスで管理されていますか?例:最初に0x18FEF111を送信すると、0x18FEEF00はバス上に表示されません。しかし、0x18FEEF00を先に送信すると、両方とも送信されます。両方を同時に送信すると、どちらか一方のみが表示されます。 SO、複数のフレームを同時に送信する際、各メッセージIDに専用のTxハードウェアオブジェクトを割り当てる必要がありますか? MBDTやSDKsはメッセージの優先順位付けを処理し、ACKが届かない場合に自動的に再試行しますか? 優先度の高いIDが失敗した場合(例えば、ACKが返ってこなかった場合)、他のメッセージもブロックされますか?これをどのように検知し、復旧すればよいのでしょうか? ブロックやメッセージの喪失を避けるために、モデル内でバッファの割り当てや送信タイミングを手動で管理する必要がありますか? MBDTで複数のTxメッセージIDを設定する最適な方法は何ですか?動的バッファを使用する場合。 社内で何が処理されるのか、アプリケーションで何が処理されるのかを明確にしてください。 サンプル・モデル Re: CAN Bus Handling in MBDT こんにちは、 @SorinIBancila さん、 利用可能なHTHハードウェアオブジェクトの数よりも多くのフレームを送信する必要がある状況に遭遇しました。CanIf送信バッファリング実装はS32CTでは活用できないため、この問題に対してsimulinkベースのバッファソリューションをおすすめしてもらえますか? ありがとうございます。 サンデシュ Re: CAN Bus Handling in MBDT こんにちは、 32 CANのハードウェアオブジェクト数は制限ではありません。MCUによってはさらに制限を上げることも可能です。CANオブジェクトカウントの上限を変更できますが、数字を大きくするとS32CTがエラーを出します。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT 理解した!SO、32以上のメッセージを送信する必要がある場合、追加のTx Hardware Objectを作成するべきでしょうか?また、S32CTを使ったS32K3で単一のCANトランシーバまたはコントローラの下で設定できるハードウェアオブジェクトの最大数はどれくらいですか? 制限内に収まるように、大規模なメッセージセットに対してHOH(階層型ヘッダー)を構成する最適な方法を理解したいと考えています。 Re: CAN Bus Handling in MBDT こんにちは、 一度に何件のメッセージを送信する必要があると思いますか? S32K358 HVBMSリファレンスデザインで以下のシナリオをテストしました: 単一の送信ハードウェアオブジェクトを使い、Can Hw Objectカウント を32に設定します(バッファ内に最大32メッセージを許可するため)。 Simulinkでは、調停プロセスを検証するために、メッセージバッファに32個のメッセージを格納し、バッファにメッセージが格納されるにつれて優先度を上げました。 結果: 予想通り、メッセージバッファが完全に満たされていないため、最初に送信されるメッセージは優先度が低くなります。6番目のメッセージあたりでバッファが埋められ、CANの優先度の高いメッセージが最初に送信されるのがわかります。 単一のトランシーバを使いたい場合、すべてのメッセージを同時に送信することは実際には不可能です。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT こんにちは、ソリンさん。 ご意見ありがとうございます! 動的バッファを使用する場合に、MBDTで複数の送信メッセージIDを設定する最適な方法を明確にしたいと思いました。私の場合、コントローラはJ1939ベースのCANセットアップでEVアプリケーションに使われており、数百のサイクリックメッセージが関わっています。 S32CTでメッセージごとに個別のハードウェアオブジェクトを作成する方法は、拡張性にも実用性にも欠けるように思われる。単一のTxハードウェアオブジェクトを使って複数のメッセージを動的に処理し、1つのCANインターフェースを通じて同時に送信したいと考えています。 このユースケースで推奨されるセットアップやベストプラクティスについて教えていただけませんか?また、MBDTで使われる設定設定や関連関数の仕組みを理解するために参照しなければならないドキュメントもぜひ教えてください。 Re: CAN Bus Handling in MBDT こんにちは、 まず最初に、S32K3xx用のMBDTはS32K3 RTDをベースに構築されていることを指摘しておきたいと思います。ペリフェラルの設定はS32設定ツールで行い、必要な設定に完全な柔軟性を持たせます。つまり、NXPのMBDT S32K3xxで機能がサポートされているかどうかを確認するには、ペリフェラル(S32K3 RTDで使用されている)のソースコードとS32設定ツールの利用可能な設定を確認できます。 ツールボックスには、FlexCANペリフェラルの実装がこちらにあります: {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 注記!S32K3 RTDの名称は、使用するMBDT S32K3のバージョンによって異なる場合があります。 ご質問への回答は私の経験に基づくものであり、必ずしも完全に正確とは限りません。 1 & 2 & 5:ツールボックスは仲裁を扱っていませんが、SDKでこのマターに関してどんなオプションがあるのかはよくわかりません。あなたの例では、別のCanHardwareObjectを作成してそれを使って 2 番目のメッセージを送信していますが、この方法は管理が難しいかもしれません。2つ目の解決策は、バッファにより多くのメッセージを入れるためにCan Hw Object Countを作成することです。 3:S32K3 用の MBDT はメッセージの優先順位付けを処理しません。私の知る限り、FlexCANコントローラの役割は、ACKが受信されるまでメッセージを再送信しつつ、バッファ内でメッセージをブロックすることです。 4. メッセージが送信されたかどうかを検出する方法の1つは、ハードウェア割り込みコールバックで割り込みCanIf_TxConfirmationを使用して、メッセージが送信されたことをマークすることです。指定されたPDUに対して割り込みが発生しない場合、メッセージは送信されなかったことを意味します。さらに、CANバスオフの条件を満たすとトリガーされる別の割り込み(CAN_ControllerBusOff)が利用可能です。S32設定ツールには、バスオフ状態から自動的に復旧するオプションがあります。 ご質問があれば、遠慮なくご返信ください。 よろしくお願いします、 ソリン・バンシラ
查看全文
定制 S32G399A 板:双向均无帧交叉选择开关面向 RGMII 总线 板:基于 S32G399A 的定制模块,源自 S32G-VNP-RDB3。PFE_MAC1 通过 RGMII (PE_02–PE_13) 连接到 NXP SJA1110A 交换机端口 2,配置为 DSA CPU 端口(树内 sja1105 驱动程序,内核 6.x BSP43.0)。 拓扑结构: - PFE_MAC0:通过 SerDes1 通道 1 的 SGMII,模式 1 - PFE_MAC1:RGMII 到 SJA1110A 端口 2(DSA CPU 端口)——即所讨论的端口 - PFE_MAC2:通过 SerDes0 通道 1 进行 SGMII 传输 S32G MAC地址配置如下: +---------+--------------+------------------+ | | 第 0 道 | 第 1 道 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完整的 U-启动 硬件配置: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii 端口 2(交换机侧)的 DTS: port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1(MAC 端)的 DTS: &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) 链路状态 — 已确认已启动,并且在 Linux/驱动程序级别配置正确: 启动时 dmesg: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed 实时 DTB 确认内核与源 DTS 匹配: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip 输出: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link 所有SJA1110 DSA从端口均已正确枚举。这证实了 sja1105 DSA 驱动程序已成功绑定。 将 pfe1 作为 CPU 端口/DSA 主设备,并解析静态配置,未出现错误。 时钟树: TX 和 RX RGMII 时钟均已启用并连接到正确的使用者: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id 因此,pfe1 状态为 UP、LOWER_UP,已正确绑定到 SJA1110 作为 DSA 主设备,并以 RGMII 模式运行。 两个时钟都已启用——这排除了 pfe1 宕机、未绑定或配置错误的可能性。 Linux/驱动程序级别。目前尚不清楚的具体问题是,帧是否真的会跨越 PFE_MAC1 和 SJA1110 端口 2 之间的物理 RGMII 引脚。 问题: 尽管总线两侧的所有设备都已独立启动,但 PFE_MAC1 和 SJA1110 端口 2 之间的 RGMII 总线似乎没有任何流量双向通过: 测试 1 — S32G -> 切换方向 设置: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 测试 2 — 切换 -> S32G 方向 设置伙伴板是一个独立的基于 SJA1105 交换机的板。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] 端口 9 接收到 9 个实际帧;交换矩阵将全部 9 个帧转发到端口 2——但是 pfe1处未收到任何信息。 因此,SJA1110 自身的交换矩阵计数器显示所有 9 个帧都已成功从端口 9 转发到端口 2 的出口。 但是,在本次测试中,S32G 上运行 tcpdump -i pfe1 -e -nn 命令显示没有收到任何数据。 因此,S32G 端的 DSA/软件层认为它正在发送(情况 1)。交换机的内部结构认为它正在向 CPU 端口发送数据(情况 2)。双方都无法确认对方是否真的通过物理 RGMII 总线收到了任何信息。与这条总线相邻的每一层都是独立运行的;这条总线本身在任何方向上都没有确认的成功穿越记录。 目前已排除的可能性: - pfeng_mode / hwconfig (xpcs_mode) — 已确认正确;EMAC1 模式为 RGMII (0x9),而非 SGMII(之前由于 SerDes1 上的 xpcs_mode=both 强制 PFE_MAC1 的 XPCS 为 SGMII,因此错误地配置为 SGMII;已更正为 xpcs_mode=0,因为 PFE_MAC0 单独只需要 XPCS0)。 - PFE_MAC1 TX/RX 时钟使能 — 已在 clk_summary 中确认以正确的频率 (125MHz) 使能 - DSA 标记和 CPU 端口绑定——已确认工作正常(端口网络设备存在,帧在 DSA 标头中被标记了正确的目标端口) - SJA1110 内部交换矩阵/转发 — 已确认在另外两个端口(9 和 2)之间使用真实外部流量正常工作 - BASE-T1 链路伙伴 — 已确认将真实帧传递到交换机(端口 9 n_rxfrm 从真实的线路流量中递增) 尚未排除的可能性/悬而未决的问题: - 在 MAC 端和交换机端均无内部延迟(rx/tx-internal-delay-ps=0,使用纯“rgmii”而非“rgmii-id”)的情况下,1000 Mbps RGMII 是否兼容,且不考虑板载走线长度带来的延迟——尚未尝试将链路速率强制降至 100 Mbps 进行时序裕量测试。 1. 在 1000 Mbps RGMII 模式下,两端的 rx/tx-internal-delay-ps=0 是否预期可以工作,或者除非 PCB 明确考虑了延迟补偿,否则这种组合通常需要延迟补偿吗? 2. 我是否遗漏了其他配置? 如有需要,我很乐意提供完整的寄存器转储文件。在用逻辑分析仪探测 PE_02-13 总线之前,请提供一些建议(由于电路板布局的限制,探针的访问受到限制,因此目前不太方便)。 谢谢。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z @db16122,我把原理图的相关部分附在这里。连接流程如下: 我们使用s32g3_pfe_mac1_connections.png中所示的 S32G3 芯片上的 PE_02 到 PE_13 作为 PFE_MAC1。它们连接到板对板连接器(如图Board_to_board_connector.png所示),该连接器将这些信号路由到具有开关的另一块板。交换机连接如图SJA1110_A.png和SJA1110_B.png 所示。 所以连接方式是:PE_xx 引脚 -> 板连接器 -> 开关 (SJA1110) 如有任何疑问,请随时联系我。我也提交了一份支持工单( #00990408 ),内容与上述相同。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好, pcentauri92 感谢您的回复。 请提供与您的 ETH 相关的原理图,特别是 PFE_MCA1 和 SJA1110 部分的原理图。 您可以创建内部支持系统案例。@Joey ,请在信息描述中提供您的原理图信息。请访问此网站: https://support.nxp.com BR 乔伊 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z , 谢谢你的回复。 这里提到的模块是一个定制设计,它使用了 S32G399A 芯片和 NXP SJA1110A 以太网交换机。我们以 S32G-VNP-RDB3 开发平台为基础进行设计,但对基础设计做了一些改动。使用 RGMII 的 PFE_MAC1 就是其中一项更改。 我还附上了 dts 文件覆盖,其中我们更改了 PFE_MAC1 模式和引脚复用。 PFE_MAC1 模式配置: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 引脚复用: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 如果您还需要其他信息,请告诉我。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 是否有关于PFE_MAC1和SJA1110端口2之间RGMII总线的硬件原理图可以分享? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好, pcentauri92 感谢您提供的详细信息 据我了解,当您在开发板上使用 PFE_MAC1 RGMAII 和 SJA1110A 的端口 2 时,通信似乎存在问题。是这样吗? S32G-VNP-RDB3 的默认配置是 PFE_MAC0/1 以 SGMII 模式运行并连接到 SJA1110。在你的开发板上,为什么考虑使用 RGMII 模式?建议修改相应的软件配置。 BR 乔伊
查看全文
カスタムS32G399Aボード:スイッチ面RGMIIバスをクロスフレームなしでいずれの方向にも接続しません 基板: S32G-VNP-RDB3をベースにしたカスタムS32G399Aモジュール。PFE_MAC1 RGMII(PE_02–PE_13)を介してNXPのSJA1110Aスイッチポート2にコネクテッド、DSA CPUポートとして設定されていました(in-tree sja1105ドライバ、カーネル6.x BSP43.0)。 トポロジー: - PFE_MAC0: SerDes1 レーン 1 経由の SGMII、モード 1 - PFE_MAC1: RGMII から SJA1110A ポート 2 (DSA CPU ポート) — 問題のポート - PFE_MAC2: SerDes0レーン1経由のSGMII S32G MACは以下のように構成されています。 +---------+--------------+------------------+ | | レーン0 | レーン1 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完全なU-Bootハードウェア構成: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii port@2用DTS(スイッチ側): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1 (MAC側) の DTS: &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1(pfe1)リンク状態 — Linux/ドライバーレベルで確認・正しく設定: 起動時のdmesg: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTBは、カーネルがソースDTSと一致することを確認します。 # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a の出力: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link SJA1110 DSAスレーブポートはすべて正しく列挙されました。これにより、sja1105のDSAドライバが正常にバインドされていることが確認されました pfe1をCPUポート/DSAマスターとして設定し、静的設定を誤りなく解析しました。 クロックツリー: TXおよびRXのRGMIIクロックが両方とも有効で、正しいコンシューマーに接続されています。 # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id SO pfe1はUP、LOWER_UP、DSAマスターとして正しくSJA1110バインドされ、RGMIIモードで動作しています 両方のクロックが有効になっている場合 — これによりPFE1がダウン、アンバウンド、または誤った設定で Linux/ドライバレベル。未解決の問題は、フレームが実際に PFE_MAC1とSJA1110ポート2間の物理的なRGMIIピン。 問題: PFE_MAC1とSJA1110ポート2間のRGMIIバスでは、バスの両側の機器がすべて独立して稼働しているにもかかわらず、どちらの方向にもトラフィックが流れていないようです。 テスト1 — S32G ->スイッチ方向 セットアップ: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 テスト2 — スイッチ-> S32G方向 セットアップパートナーボードは別のスイッチベースのSJA1105ボードです。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] ポート9は9つの実際のフレームを受信しました。ファブリックは9つすべてをポート2に転送しましたが、 pfe1には何も届きませんでした。 SO、SJA1110自身のファブリックカウンターでは、ポート9からポート2の出口へ9フレームすべてが正常に転送されたことが示されています。 しかし、このテスト中にS32Gでtcpdump -i pfe1 -e -nnを実行すると、何も受信されなかったことが示されます。 つまり、S32G側のDSA/ソフトウェア層は送信していると認識しています(CASE 1)。スイッチの内部ファブリックはCPUポートに向かって送信していると認識しています(CASE 2)。どちらの側も、相手側が物理的なRGMIIバスを介して実際に何かを受信したという確証は得ていない。このバスに隣接する各層は個別に機能します。バス自体は、どちらの方向にも正常に通過したことが確認されていません。 これまでに除外されたこと: - pfeng_mode / hwconfig (xpcs_mode) — 正確であることが確認されています。EMAC1モードはRGMII(0x9)であり、SGMIIではありません(以前はSerDes1でxpcs_mode=両方がPFE_MAC1のXPCSSをSGMIIに強制的に入ったためSGMIIとして誤って設定されていました。PFE_MAC0単独でXPCS0が必要なため、xpcs_mode=0に修正します) - PFE_MAC1 TX/RXクロックのイネーブルメント — clk_summaryで正しいレート(125MHz)で有効化が確認されています - DSAタグ付けおよびCPUポートバインディング — 動作確認済み(netdevのポートが存在し、フレームにDSAヘッダーで正しい宛先ポートがタグ付けされる) - SJA1110内部ファブリック/転送 — 実際の外部トラフィックを用いて他の2つのポート(9と2)間で動作が確認されました - BASE-T1リンクパートナー — 実際のフレームをスイッチに渡すことを確認しました(ポート9 n_rxfrm実際のワイヤートラフィックからのインクリメント) まだ排除されていないこと/未解決の疑問: - MAC側とスイッチ側の両方で内部遅延ゼロ(rx/tx-internal-delay-ps=0、単に「rgmii」ではなく「rgmii-id」)の1000 Mbps RGMIIがボードトレース長による遅延なしに互換性があるかどうか — タイミングマージンテストとしてリンクを100 Mbpsに強制的に落とす試みはまだしていません 1. 1000 Mbps RGMII において、両端で rx/tx-internal-delay-ps=0 は正常に動作すると想定されますか?それとも、PCB が明示的に遅延を考慮していない限り、この組み合わせでは通常、遅延補償が必要になりますか? 2. 他に何か設定漏れはありますか? 必要であれば、完全なレジスタダンプを提供いたします。PE_02-13バスをロジックアナライザで探査する前に、何かアドバイスをいただけるとありがたいです(基板レイアウトのためプローブへのアクセスが限られているため、現状はあまり便利ではありません)。 ありがとう。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん、@db16122 さん。回路図の関連部分をここに添付します。接続の流れは以下のとおりです。 PFE_MAC1には、s32g3_pfe_mac1_connections.pngに示されているS32G3チップ上のPE_02からPE_13を使用します。基板間コネクタ( Board_to_board_connectorに示されています)。png)を使い、これらの信号をスイッチを持つ別のボードにルーティングします。スイッチ接続は SJA1110_Aで示されています。png および SJA1110_B.png。 接続はPE_xxピン - >基板コネクタ - >スイッチ(SJA1110) ご質問があればお知らせください。同じ詳細でサポートチケット( #00990408)も提出しました。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 ご返信よろしくお願いします。 貴社のETHに関する回路図、特にPFE_MCA1およびSJA1110セクションの回路図をご提供ください。 内部サポートシステムのケースを作成することもできます。情報の説明欄に、 @Joey さん、回路図の情報を提供してください。こちらのウェブサイトを参照してください: https://support.nxp.com BR ジョーイ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん。 ご回答ありがとうございます。 ここで扱っているモジュールは、S32G399AチップとNXP SJA1110Aイーサネットスイッチを組み合わせたカスタム設計です。このデザインはS32G-VNP-RDB3の開発プラットフォームを基にしましたが、ベースデザインからかなりの変更を加えました。RGMIIを使用するPFE_MAC1は、そうした変更点の1つです。 また、PFE_MAC1モードとピン多重化を変更するdtsファイルのオーバーライドも添付します。 PFE_MAC1モードの設定: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1ピンマルチプレクサ: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 他に何か情報が必要な場合はお知らせください。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction PFE_MAC1とSJA1110ポート2間のRGMIIバスに関するハードウェア側の回路図を共有していただけませんか? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 詳細な情報を提供していただきありがとうございます。 私の理解では、開発ボード上でRGMAIIとポート2を使うPFE_MAC1通信に問題があるようですSJA1110A。それは正しいですか? S32G-VNP-RDB3のデフォルト構成は、PFE_MAC0/1がSGMIIモードで動作し、SJA1110にコネクテッドです。開発ボードでRGMIIモードを使うことを考えたのはなぜですか?対応するソフトウェア構成を変更することが推奨されます。 BR ジョーイ
查看全文
MC33774 Daisy Chain Dual Loop Connection HI. 我当前使用MC33665A+MC33774的AFE采样系统组成双链回环的结构,配置MC33665A的PORT0和PORT1分别为MADD0和MADD1,当前发送所有指令均由MADD0发送。当我只连接PORT0到DC1之间的菊花链时,我的通讯都是正常的,但是当我把PORT1和DC2之间的菊花链也连接后,我再去请求33774发现33774无法回复响应帧,这是为什么?我回读确认过33665的PORT端口配置没有错误,并且将33774中的SYS_TPL_CFG.RESPCFG设置为00 SAME模式。 I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1.我想知道从MADD=1的位置反向分配DADD是必须的吗? 2.我当前的SYS_PORT0_CFG配置为TIMEOUT=0,CADD=1,MADD=0,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 SYS_PORT1_CFG配置为TIMEOUT=0,CADD=1,MADD=1,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 Re: MC33774 Daisy Chain Dual Loop Connection 你好, 根据 AN13910 TPL 环回建议,当两个 MC33665A TPL 端口连接成环回环时,存在一些配置要求,可能会导致您看到的行为。 对于环回配置: 我们建议从环的一侧按升序分配设备地址 (DADD),从环回侧按相反的顺序分配设备地址 (DADD)(我在你的图片中没有看到这一点)。 如果两个端口连接为环回,则其中一个端口应设置 SYS_PORTx_CFG[RX] = 0,以避免重复数据进入 MC33665 缓冲区。 此外,其中一个端口的 SYS_PORTx_CFG[ALLCHAINS] 应为 0。文档指出,如果两个环回端口都接受 ALLCHAINS 命令,则可能导致信号冲突和通信错误。 请问能否提供 SYS_PORT0_CFG 和 SYS_PORT1_CFG 的值(特别是 EN、RX、ALLCHAINS、MADD 和 CADD)?这将有助于确定环回端口是否按照 AN13910 建议进行配置。 Re: MC33774 Daisy Chain Dual Loop Connection 你好, 根据 AN13910 TPL 环回建议,在环回拓扑中,DADD 分配应与 MADD=1 侧相反。 此外,您当前的配置在两个端口上都设置了 RX=1 和 ALLCHAINS=1。对于环回连接,我们建议禁用其中一个端口上的 RX 和 ALLCHAINS,以避免重复路由和通信冲突。 请尝试将一个端口的 RX=0 和 ALLCHAINS=0 配置为(例如,PORT1),并验证 MC33774 是否开始返回响应帧?
查看全文
「内部フラッシュメモリ領域」設定を上書きするDebug Flashスクリプト こんにちは、 現在、FRDM-S32K344上でApp1からApp2へのアプリケーションジャンプをテスト中です。 私たちのアプリケーションレイアウトは以下の通りです: アプリ1の開始アドレス: 0x00400000 アプリ2の開始アドレス: 0x00500000 デバッグには、フラッシュメモリ保護を有効にした個別のデバッグ構成を使用しています。 App1のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00500000~0x005FFFFF(App2を保護するため) App2のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00400000~0x004FFFFF(App1を保護するため) しかし、デバッグ構成によるプログラミング中に、メモリ保護範囲が設定されているにもかかわらず、保護対象のフラッシュ領域が消去されていることが確認されました。 どなたか次の点をCANしてもらえますか? フラッシュプログラマは、消去/書き込み操作中に、設定されたメモリ保護範囲を尊重することが求められますか? 保護されたフラッシュ領域が消去されないようにするために、追加の設定が必要ですか? FRDM-S32K344上で1つのアプリケーションだけをプログラムしながら、メモリ保護を使って別のアプリケーションを保存することに成功した方はいらっしゃいますか? ログファイルとLDファイルを参考資料として添付しました。 私たちは搭載のPEデバッガを使用しています 何かご助言やご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings こんにちは、@Avinpat123さん 同じバージョンのS32 Design Studioで動作しているか素早くテストしました。私も同じ設定を使いました。1つのアプリケーションは0x50_0000領域が保持されるように設定されている間に強制的に0x40_0000し、もう1つのアプリケーションは0x50_0000を強制され、0x40_0000領域は保存されるように設定されています: この設定が考慮されていることを示すログを以下に示します。 メモリを見ると、内容が本当に保存されているのがわかり、SO、期待通りに動作します。 スクリーンショットを確認したところ、アドレス範囲は設定されているようですが、「この範囲を保持する」チェックボックスが有効になっていません。問題はそこではないでしょうか? よろしくお願いいたします。 ルーカス Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings こんにちは、@lukaszadrapa ご返信ありがとうございます。おっしゃる通り、チェックボックスが問題でした。今は正常に動作しています。
查看全文
MC33774 Daisy Chain Dual Loop Connection HI. I'm currently using an AFE sampling system with MC33665A and MC33774 to form a double-chain loopback structure. The MC33665A's PORT0 and PORT1 are configured as MADD0 and MADD1 respectively, and all commands are currently sent via MADD0. When I only connect the daisy chain between PORT0 and DC1, my communication is normal. However, when I also connect the daisy chain between PORT1 and DC2, I find that the 33774 cannot reply with a response frame. Why is this? I have confirmed that the PORT configuration of the 33665 is correct and that SYS_TPL_CFG.RESPCFG in the 33774 is set to 00 SAME mode. I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1. I want to know if it is necessary to reverse the allocation of DADD from the position where MADD=1? 2. My current SYS_PORT0_CFG configuration is TIMEOUT=0, CADD=1, MADD=0, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 SYS_PORT1_CFG is configured with TIMEOUT=0, CADD=1, MADD=1, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 Re: MC33774 Daisy Chain Dual Loop Connection Hello, According to the AN13910 TPL Loopback Recommendation, when two MC33665A TPL ports are connected as a loopback ring, there are several configuration requirements that may cause the behavior you are seeing. For a loopback configuration: We recommend assigning device addresses (DADD) in ascending order from one side of the ring and in reverse order from the loopback side (I do not see this in your image). If two ports are connected as loopback, one of the ports should have SYS_PORTx_CFG[RX] = 0 to avoid duplicate data entering the MC33665 buffer. In addition, one of the ports should have SYS_PORTx_CFG[ALLCHAINS] = 0. If both loopback ports accept ALLCHAINS commands, document states that this can cause signal conflicts and communication errors. Could you please share the values of SYS_PORT0_CFG and SYS_PORT1_CFG (especially EN, RX, ALLCHAINS, MADD, and CADD)? That would help determine whether the loopback ports are configured according to the AN13910 recommendations. Re: MC33774 Daisy Chain Dual Loop Connection Hello, According to AN13910 TPL Loopback Recommendation, the DADD assignment should be reversed from the MADD=1 side in a loopback topology. In addition, your current configuration has RX=1 and ALLCHAINS=1 on both ports. For a loopback connection, we recommend disabling RX and ALLCHAINS on one of the ports to avoid duplicate routing and communication conflicts.  Could you please try configuring one port with RX=0 and ALLCHAINS=0 (for example, PORT1) and verify whether the MC33774 starts returning response frames?
查看全文
S32K3 ADC 使用外部通道 你好。恩智浦团队 如何使用S32K3 ADC的外部通道 . Re: S32K3 ADC Use of external channels 嗨@VaneB 我还有后续问题。 如果我的设计没有多路复用器,但我只想使用例如 ADC1_X[0] 连接传感器 1,ADC1_X[1] 连接传感器 2,ADC1_X[2] 连接传感器 3,我可以将 MA 引脚重复使用于其他用途吗,例如用作 GPIO 输出引脚来驱动 LED? 我的设计基于s32k344 Re: S32K3 ADC Use of external channels NPX团队,您好! 关于这个话题,请问是否可以实现如下图所示的SCH? 非常感谢您的支持。 Re: S32K3 ADC Use of external channels @VaneB 非常感谢您的帮助。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 每个 ADC 提供 3 个外部解码信号 (MA),用于从外部模拟多路复用器的 8 个通道中选择 1 个通道,最多可以有 4 个这样的多路复用器来连接 32 个外部通道,这意味着这 4 个多路复用器共享相同的 MA 信号。 ADC 根据当前选择的转换通道,自动设置 MA 来控制这些外部模拟多路复用器。根据掩码寄存器位,对相应的“X”引脚进行采样,并将结果存储在“MA”和“X”组合的匹配位置中。 由于我们的开发板上没有设计外部模拟多路复用器,因此没有实现这样的示例。 Re: S32K3 ADC Use of external channels 你好。VaneB 根据您的提示,我找不到在RTD中使用外部通道ADC的例子。如果你有相应的日常安排,希望你能发给我。非常感谢。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 您可以在 RTD 中找到一些可能对您有用的 ADC 实现示例。 BR VaneB
查看全文
S32K3 ADC Use of external channels Hello.  NXP Team How to use the external channel of S32K3 ADC . Re: S32K3 ADC Use of external channels Hi @VaneB I have a followup to this. If my design DOES NOT have a MUX but I want to use only for example ADC1_X[0] to sensor1, ADC1_X[1] to sensor2 and ADC1_X[2] sensor 3, can i reuse the MA pins for other purpose like GPIO output pins to drive an LED? My design is based on s32k344 Re: S32K3 ADC Use of external channels Hi NPX Team,  Related with this topic, may you please confirm if  is it possible to implement a SCH like the following diagram? Many thanks for your support. Re: S32K3 ADC Use of external channels @VaneB  Thank you very much for your help. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  Each ADC provides 3 external decode signals (MA) to be used to select 1 channel out of 8 in the external analog multiplexers, and there can be maximum 4 of such multiplexers to connect 32 external channels, it means that these 4 multiplexers sharing the same MA signals. The ADC automatically sets the MA to control these external analog multiplexers, based on the current channel selected for conversion. Depending on the Mask Register bits, the corresponding “X” pin is sampled, and the result is stored in the matching location for the “MA” & “X” combination. Since no external analog multiplexers have been designed on our development board, such an example has not been implemented. Re: S32K3 ADC Use of external channels hello.VaneB According to your prompt, I can't find an example of using external channel ADC in RTD. If you have a corresponding routine, I hope you can send it to me. Thank you very much. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  You can find examples of ADC implementation that may be useful to you in the RTD. B.R. VaneB
查看全文
PN7220 Android 16 Porting to i.MX95 FRDM EVK Board Introduction Many customers are using PN7220 + Android 16 recently. In this document, I will show you how to porting the PN7220 to Android 16. I use the i.MX95 FRDM board as a reference target board. NOTE :  All the modifications are just for reference. They are NOT a NXP official patches for the newer release of AOSP porting. So the modifications may not be the best solution. Customer please base on their needs to modify the AOSP source code. This is not for production. Customer still need to perform full testing after the porting.  Hardware boards: i.MX95 FRDM Board (FRDM i.MX 95 Development Board | NXP Semiconductors) PN7220 EVK -- PNEV7220BP1 (PNEV7220BP1 Development Board for PN7220 NFC Controller | NXP Semiconductors) There is a 40pins connector on both PN7220 EVK and i.MX95 FRDM board. So PN7220 + i.MX95 FRDM connecting together is like this: Build the Android BSP for i.MX95 FRDM board: The i.MX Android BSP that I used is Android 16.0.0_1.4.0 (L6.12.49_2.2.0 BSP). It could be downloaded from here: Android OS for i.MX Applications Processors | NXP Semiconductors 1. Download the "Documentation" and the "Install Source Package".  2. Follow the steps in Android User's Guide to build the Android BSP for "evk_95" first.  $ export MY_ANDROID=`pwd` $ source build/envsetup.sh $ lunch evk_95-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt According to the android_build/.repo/manifests/aosp-android-16.0.0_1.4.0.xml, you will see the AOSP version is android-16.0.0_r4. According to the PN7220 Android 16 porting guide (PN7160/PN7220 – Android 16 porting guide), the patches is for AOSP release android-16.0.0_r2. So fortunately, the AOSP release version between them is not big different.  Now, we start the porting: 1. Kernel Driver To establish connection with the PN7220, the Android stack uses the nxpnfc kernel driver.  You could download the driver from github below: nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev · nxp-nfc-infra/nfcandroid_platform_drivers · GitHub The command is : git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev There is driver for Kernel 6.6 and 6.12. So, please download the correct one for your porting. For example, the kernel in i.MX Android BSP Android 16.0.0_1.4.0 is 6.12. So I will use the 6.12 driver for my porting. In your porting, make sure the PATH in Makefile and Kconfig files are setting properly.  For example in my porting: android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7220$ tree . ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig └── Makefile 0 directories, 7 files For simplifying everything, we will only add a support for I2C and not SPI. Replace drivers/nfc/pn7220/Makefile default code with following code (for easier understanding) nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o The contents of drivers/nfc/Makefile. Add the PN7220 like below: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7220/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o The contents of drivers/nfc/Kconfig. Add the PN7220 like below: source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" source "drivers/nfc/pn7220/Kconfig" endmenu 2. Adding the "nxpnfc" to the i.MX95 FRDM board device tree file android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts We need to check the connection between two boards and then to decide which pins to use in the device tree file. Here is the 40 pins connector on the PN7220: Here is the 40 pins connector on the i.MX95 FRDM board. According to the 40 pins connection between PN7220 EVK and the i.MX95 FRDM board, I decided to use the I2C6 and the GPIO2_20, GPIO2_21 and GPIO2_26. So, in the imx95-15x15-frdm.dts, I added: &lpi2c6 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpi2c6>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio2 26 0>; nxp,nxpnfc-ven = <&gpio2 21 0>; nxp,nxpnfc-mode_sw = <&gpio2 20 0>; }; }; And the IOMUX settings in the imx95-15x15-frdm.dts. pinctrl_nfc: nfcgrp { fsl,pins = < IMX95_PAD_GPIO_IO26__GPIO2_IO_BIT26 0x39e // IRQ IMX95_PAD_GPIO_IO21__GPIO2_IO_BIT21 0x39e // VEN IMX95_PAD_GPIO_IO20__GPIO2_IO_BIT20 0x39e // MODE_SW >; }; pinctrl_lpi2c6: lpi2c6grp { fsl,pins = < IMX95_PAD_GPIO_IO02__LPI2C6_SDA 0x40000b9e IMX95_PAD_GPIO_IO03__LPI2C6_SCL 0x40000b9e >; }; 3. Modify the imx95_gki.fragment File:  android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx95_gki.fragment Add the "CONFIG_NXP_NFC_I2C=m" into the imx95_gki.fragment 4. Add the settings in your corresponding board configuration files in Android - Go to the android_build/device/nxp/imx9/evk_95/  - Modify the BoardConfig.mk. # Add KVM support BOARD_BOOTCONFIG += androidboot.hypervisor.vm.supported=true + # ---- selinux permissive ---- + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive # -------@block_sepolicy------- BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx9/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc \ + vendor/nxp/emvco/sepolicy +include vendor/nxp/nfc/BoardConfigNfc.mk  - Add the "nxpnfc_i2c.ko" to the ShareBoardConfig.mk. Make sure the path and the filename are correct. ifeq ($(LOADABLE_KERNEL_MODULE),true) IMX_ANDROID_FIRST_STAGE_MODULES += \ $(KERNEL_OUT)/drivers/hwmon/hwmon.ko \ $(KERNEL_OUT)/drivers/hwmon/scmi-hwmon.ko \ .... .... .... $(KERNEL_OUT)/drivers/soc/imx/soc-imx9.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-adp5585.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-pca953x.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-vf610.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko .... .... BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/media/i2c/ap1302.ko \ $(KERNEL_OUT)/drivers/media/i2c/ox03c10.ko \ $(KERNEL_OUT)/drivers/media/i2c/max96717_lib.ko \ .... .... $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc-vf.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc4.ko \ $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/hwmon/pwm-fan.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko - Add the INxpNfc and INxpEmvco to the device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.ele 1 ISecureEnclave default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default  - Add the following to the evk_95.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc2-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx - Add the nxpnfc_i2c in init.rc exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep - Add nxpnfc to ueventd.nxp.rc /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc 5. Apply the NXP AOSP patches I write a script to download the patches from the github. The script file and the android_build folder is on the same directory. Run the AOSP_adaptation.sh.  AOSP_adaptation.sh # nfcandroid_nfc_modules git clone "https://github.com/nxp-nfc-infra/nfcandroid_modules_nfc.git" cd nfcandroid_modules_nfc git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/packages/modules/Nfc cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_16_comm_infra_dev mkdir ../android_build/packages/modules/Nfc/framework cp -rf * ../android_build/packages/modules/Nfc/framework cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_16_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_16_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. Apply a patch. $ cd android_build/system/logging $ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch Add TDA Test support: # Clone repositories for test applications and TDA support # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_16_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_16_comm_infra_dev cp -rf nfc_tda/ ../android_build/packages/modules/Nfc/libnfc-nci/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/ cd .. 6. Put changes into hardwatre/interfaces/compatibility_matrices  File: hardware/interfaces/compatibility_matrices/compatibility_matrix.202504.xml android.hardware.audio.effect 1-3 IFactory default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default nxp.hardware.ele 1 ISecureEnclave default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default android.hardware.authsecret 1 IAuthSecret default 7. Add the firmware $ git clone https://github.com/NXP/nfc-NXPNFCC_FW.git $ cp -r nfc-NXPNFCC_FW/InfraFW/pn7220/64-bit-2.5/pn7220_64bits.so android_build/vendor/nxp/pn7220/firmware/lib64/libpn72xx_fw.so 8. Add the NXPAndroidDTA $git clone https://github.com/NXPNFCProject/NXPAndroidDTA.git $cd NXPAndroidDTA $git checkout br_ar_new_dta_arch cp -r NXPAndroidDTA android_build/vendor/nxp/ 9. Some fixes before build: $ cd android_build $ mv hardware/nxp/nfc/snxxx/Android.bp hardware/nxp/nfc/snxxx/_Android.bp $ mv hardware/nxp/nfc/snxxx/halimpl/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl/power-tracker/_Android.bp $ mv hardware/nxp/secure_element/snxxx/aidl/Android.bp hardware/nxp/secure_element/snxxx/aidl/_Android.bp $ cd hardware/nxp/nfc $ rm pn8x -rf Now, build the Android BSP again. Use "mm" to build the Android source code. After fixed all the errors of the AOSP build, use "imx-make.sh" to build the whole i.MX Android image.  When building the Android, there may have some errors during the build. I listed some errors and the workaround below for your reference. Error: error: packages/modules/Nfc/tests/cts/tests/Android.bp:20:1: "CtsNfcTestCases" depends on undefined module "CtsAppTestStubsShared". Workaround : Comment out "CtsAppTestStubsShared" in packages/modules/Nfc/tests/cts/tests/Android.bp Error: error: hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp:17:1: "power_tracker_v2" depends on undefined module "nfc_nci_nxp_snxxx_headers_v2". Workaround: mv hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/_Android.bp Error: error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/NfcNci/nci/jni:libnfc-nci-jni-tests which is not visible to this module You may need to add "//platform_testing" to its visibility error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/libnfc-nci/tests:libnfc-nci-tests which is not visible to this module You may need to add "//platform_testing" to its visibility Workaround: nano packages/modules/Nfc/NfcNci/nci/jni/Android.bp In cc_test {     name: "libnfc-nci-jni-tests", .. ..     visibility: [         "//platform_testing:__subpackages__",     ], Same in packages/modules/Nfc/libnfc-nci/tests/Android.bp Error: FAILED: out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system-stubs.srcjar out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_annotations.zip out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_api.txt out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_removed.txt out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:52: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.emulateNfcTechnologyATag(boolean,byte,byte,byte,byte[],byte,byte[]) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:64: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.overwriteRoutingTable(int,int,int,int,int) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:77: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_INTERNAL [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:78: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_NFC_NOT_ENABLED [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:79: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_OK [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:120: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.Callback.onRoutingChangeCompleted() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:160: error: Binary breaking change: Removed method android.nfc.RoutingStatus.getDefaultFelicaRoute() [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Comment out the lines 52,64,77,78,79,120,160 in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest Error: out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:77: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isExitFramesSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:80: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeEnabled() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:81: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:91: error: Binary breaking change: Removed method android.nfc.NfcAdapter.setPowerSavingMode(boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:196: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:197: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopPatternFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:202: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceScreenOnRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:203: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceUnlockRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:214: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceScreenOnForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:215: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceUnlockForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:248: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.NfcEventCallback.onOffHostAidSelected(String,String) [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Same as the previous workaround. Comment out the lines (line number shown in error) in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest. Error: FAILED: out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw out/host/linux-x86/bin/checkpolicy -C -M -L -c 30 -o out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw out/soong/.intermediates/system/sepolicy/vendor_sepolicy.conf/android_common/evk_95/vendor_sepolicy.conf && out/host/linux-x86/bin/build_sepolicy filter_out -f out/soong/.intermediates/system/sepolicy/reqd_policy_mask.cil/android_common/reqd_policy_mask.cil -t out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw # hash of input list: 7a5f97fdfa590e2ec5a2c6b745c65293680d0202c9b5869c1425905c209b9bf1 vendor/nxp/emvco/sepolicy/service.te:1:ERROR 'Duplicate declaration of type' at token ';' on line 21764: type hal_emvco_service, hal_service_type, service_manager_type; #line 1 "vendor/nxp/emvco/sepolicy/service.te" checkpolicy:  error(s) encountered while parsing configuration 11:50:27 ninja failed with: exit status 1 Workaround: nano vendor/nxp/emvco/sepolicy/hwservice.te Change the hal_emvco_service to hal_emvco_hwservice like this: type hal_emvco_hwservice, hwservice_manager_type; nano vendor/nxp/emvco/sepolicy/hwservice_contexts vendor.nxp.emvco::INxpEmvco                             u:object_r:hal_emvco_hwservice:s0 nano vendor/nxp/emvco/sepolicy/hal_emvco_default.te + allow hal_emvco_default hal_emvco_hwservice:hwservice_manager { add find }; Error: FAILED: out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp if [ $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) = $(tail -1 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash') ]; then touch out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp; else cat 'system/tools/aidl/build/message_check_integrity.txt' && exit 1; fi ############################################################################### # ERROR: Modification detected of stable AIDL API file                        # ############################################################################### Above AIDL file(s) has changed, resulting in a different hash. Hash values may be checked at runtime to verify interface stability. If a device is shipped with this change by ignoring this message, it has a high risk of breaking later when a module using the interface is updated, e.g., Mainline modules. Workaround: echo $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) d9e99a62ff5ebed44083a79577ec7ed32d264775 Then,  nano hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash replace the value to d9e99a62ff5ebed44083a79577ec7ed32d264775 A runtime error: Problem: You will find the following failed about the permission in the log. java.lang.IllegalStateException: Signature|privileged permissions not in privileged permission allowlist: {com.android.nfc (/apex/com.android.nfcservices/priv-app/[email protected]😞 android.permission.OBSERVE_ROLE_HOLDERS} Workaround: Add :                 To the file : out/target/product/evk_95/system/etc/permissions/privapp-permissions-platform.xml 10. Download the image to the target board: - We use the tool UUU to download the image to the i.MX boards. Download the UUU from here : Releases · nxp-imx/mfgtools - Download the Android 16 BSP i.MX95 EVK demo image from the Android i.MX BSP web page first. There are UUU script and necessary image files already in the demo image package.  - Put the UUU executable file into the demo image folder. uuu_imx_android_flash.bat is the script also in the same folder. - After your Android BSP building is completed and succeed, copy the images to the demo image folder. The image files are located in android_build/out/target/product/evk_95/. - Switch the boot mode to "Download" mode on the i.MX95 FRDM board. - Run the UUU script to download the images to the FRDM board. uuu_imx_android_flash.bat -f imx95 -a -e -u 15x15-frdm -d 15x15-frdm Run the "TagInfo" on the board: - Download the TagInfo apk file from the NXP TagInfo App web page . - Use the "adb install" command to install the TagInfo to the FRDM board. C:\>adb install com.nxp.taginfo-6.2.0-play-release-protected.apk * daemon not running; starting now at tcp:5037 * daemon started successfully Performing Streamed Install Success After TagInfo installed, the TagInfo icon will be available on the GUI. Run the TagInfo, and then put a card on the board. The information of the card will be show on the TagInfo App. Reference: PN7160/PN7220 – Android 16 porting guide PN7220 NFC Frontend IC with Integrated Power Management | NXP Semiconductors Android OS for i.MX Applications Processors | NXP Semiconductors nxp-nfc-infra · GitHub
查看全文
Safety recommended Compiler setting violation Compiler settings, Assembler setting and the linker setting, recommended by the MCAL SIP provided by the NXP, is not following the safety compiler settings recommended by the Wind River. Need to have a discussion on the settings and check how to align with Wind River compilers safety recommendations. MCAL SIP package Info: -  ->SW32K3_S32M27x_RTD_R21-11_7.0.1_QLP02  ->SW32K3_RTD_R21-11_7.0.1_P05_D2604  ->SW32K3_SAF_1.0.6_D2512  ->SCST_M7_S32K3_RFP_1.0.7 Re: Safety recommended Compiler setting violation Hello, In case you need direct talk to application team please reach out to your assigned NXP representative FAE/Sales, they can setup direct support channel. In case you have any questions do not hesitate to ask. Best regards, Peter
查看全文
JLinkデバッグ認証 皆さん、こんにちは。 私はMCXN947(frdm_mcxn947ボード)を基にしたプロジェクトを進めており、クライアントにテストのために送る前にデバッグ認証と署名済みファームウェア検証を設定する必要がありますが、2つの点について非常に迷っています。 デバッグ認証は「現場内」のCASEに限定されているのでしょうか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? すでにこの問題に取り組んだ方が、今後の進め方について教えていただけるとありがたいです。なぜなら、私は言及されている AN14162だけで、それ以外のドキュメントはあまり見かけません MCX N セキュリティ(EdgeLock | セキュアブート | OTP) Re: JLink Debug Authentication こんにちは、 @raimbowgeddon さん。 1. デバッグ認証は「インフィールド」ケースに限定されるのか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない ->>いいえ、デバッグ認証は「ファイル内」ケースだけのものではありません。開発中にテストCAN。CMPA側で設定してください。OTP側ではありません。 2. デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? ->>はい。デバッグ認証が有効になった後は、通常は通常、以前のように通常のJ-Linkセッションを開始することはできません。まずデバッグ認証チャレンジ-レスポンスフローを実行し、その後デバッガを接続します。 MCXN947上でデバッグ認証の設定と使用手順を示す動画があります。アクセスCANかはわかりませんが: https://www.bilibili.com/video/BV13EhAzdEzV/?spm_id_from=333.1387.homepage.video_card.click よろしくお願いします。 BR アリス Re: JLink Debug Authentication こんにちは、 @Alice_Yang さん。 返信が遅れて申し訳ありません。他の緊急の仕事に追われていました。あなたがリンクしてくれた動画の手順通りにやってみたら、うまくいったようです!ツールからデバイスのロックを解除し、その後デバッガーで接続するという手順を見落としていました。画像を別の画像で上書きしようとしましたが、CFPAリージョンが書き込まれていないという警告は出ていますが、デバッグ認証ステップを行ってもフラッシュ消去はできないようです。これは普通のことですか?これはつまり、今後は取締役会が恒久的に安全になるということでしょうか?今、ボードを工場出荷時の設定に戻す方法はないのでしょうか? ご助力本当にありがとうございます FS
查看全文
MiFARE Plus APDU 您好, 我正在开发一个 Windows/Linux 应用程序,该应用程序使用 `winscard`/`pcsc-lite` 库和 HID Global OMNIKEY 5122 读卡器将数据编码到 MIFARE 卡上。我已经成功实现了对经典卡和Ultralight卡的支持,现在我需要添加对Plus卡的支持。 来自 `MF1P(H)x2.pdf`根据公开文档(见下方链接),我知道该卡支持许多原生命令,例如 `GetVersion` 和 `WritePerso`,而且,如果我对第 8.2.3 节的理解正确的话,这些命令可以封装在 APDU 中。那将是理想的,因为我就是这样处理其他卡的:我构建并发送 APDU。 我的问题如下: 1. 哪些文档描述了 MIFARE Plus 的本地命令及其参数?我需要这些信息才能正确地编写这些命令。 2. 据我了解,MIFARE Plus 需要基于 AES 的身份验证和加密才能向卡发送命令。哪份文件对此有详细描述? 3. 是否有关于如何在 APDU 中封装本地命令的文档? 4. `MF1P(H)x2.pdf` 包含许多链接,或者看起来像链接的文本,但它们是不可点击的。例如:`CommitReaderID`、`WritePerso`、`CommitPerso` 和 `虚拟卡架构`。我如何才能获取这些文件?是否有办法确定每个链接指向哪个文档? 我签署了保密协议,并获得了访问我的 NXP 帐户安全部分的一些文件的权限,但这些文件都没有回答我的问题。 https://www.nxp.com/docs/en/data-sheet/MF1P(H)x2.pdf Re: MiFARE Plus APDUs 你好@Codringher 希望你一切都好。 支持 MIFARE Plus EV2 的资源受 NDA 保护,必须通过安全访问权限申请,请按照此页面上的说明进行操作:安全访问权限 | NXP 半导体 。另外,我建议您查看NXP 半导体的“安全访问权限常见问题解答” 。 请查收您的收件箱,我刚刚给您发送了一条社区私信。 问候, 爱德华多。
查看全文
Some questions about developing LPC Microcontrollers on MCUXpresso IDE Hi everyone,     I'm currently working on development with the NXP LPC1778FET180 chip, and I want to use the 'MCUXpresso' IDE. But during this process: 1. I found that in NXP's official 'SDK Builder,' I can't find the SDK for LPC1778FET180, whereas 'MCUXpresso' shows that it supports this chip. So how can I get the SDK for this chip? 2. If this chip doesn't have a corresponding SDK, I've already generated a bare-metal project through 'MCUXpresso,' but it seems that graphical pin configuration isn't supported. No .mex file is being generated. Is it that this chip doesn't support graphical pin configuration, or am I doing something wrong?                                                                                                                                     Best wishes Re: Some questions about developing LPC Microcontrollers on MCUXpresso IDE Hello Leo_wong, I am also struggling to find the SDK. My target MCU is LPC1518JBD64. I have download MCUXpresso ide in VScode and now look for SDK for LPC1518. It you get to figure this out just let me also know how to get the SDK to start coding for LPC1518. Re: Some questions about developing LPC Microcontrollers on MCUXpresso IDE Hi @leo_wong  LPC1778FET180 is an older LPC17xx device and is not supported by the modern MCUXpresso SDK Builder. You can import it from file system. The absence of a .mex file and graphical Pins/Clocks configuration is expected. These MCUXpresso Config Tools features are primarily available for devices that have MCUXpresso SDK support. LPC1778 projects generally require manual pin and clock configuration or the use of LPCOpen APIs. BR Harry
查看全文
MIMXRT1061 无法从外部 或非 闪存启动 你好 我有一个基于 MIMXRT1061DVL6B 的定制板,带有一个外部 或非 闪存 (W25Q128JVSSIQ)。我使用 Zephyr 和 VS Code 作为开发环境,目前遇到了设备启动困难的问题。 我怀疑这个问题与这篇文章中讨论的问题类似: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/i-MX-RT1060-Boot-using-FlexSPI/mp/1242678 具体来说,我认为这可能与链接器脚本配置和启用 `XIP_EXTERNAL_FLASH` 有关。 我不太明白的是,在基于 Zephyr 的设置和独立组网 (SA) MCUXpresso/NXP SDK 风格的项目中,修改链接器设置并启用 `XIP_EXTERNAL_FLASH` 的正确方法是什么。 作为一项实验,我通过手动修改 `MIMXRT1062xxxxx_flexspi_nor.ld` 文件,成功地让 MCU 执行了一些操作。链接器文件并将 `.text` 部分的位置更改为: ``` 。文本{}> m_data AT > m_text ``` 但是,我不想依赖这种手动修改,因为存在多个 `MIMXRT1062xxxxx_flexspi_nor.ld` 文件。项目中包含多个文件,我不确定链接器实际使用的是哪个文件。 我希望能够获得以下正确流程的指导: 1. 配置 MIMXRT1061 从外部 或非 闪存执行 XIP。 2. 启用所需的 `XIP_EXTERNAL_FLASH` 设置。 3. 在基于 Zephyr 的项目中正确修改或覆盖链接器脚本。 4. 了解非 Zephyr 项目的等效配置。 非常感谢您能就推荐方法提供任何指导。 问候, 朱奈德 启动 ROM | 启动配置 | 闪存 Re: MIMXRT1061 unable to boot from external NOR flash 你好@jahmed9 , 为了更好地为您提供帮助,请您提供以下信息? -你的设计中DQS引脚是连接着的,还是浮空的? -闪存设备是否连接到FlexSPI端口A? -你是否根据你的闪光灯设备修改过FCB?如果可以的话,请您使用修改后的 SDK 运行 flash_component_nor_flexspi 示例程序? 这可以通过确认读取、写入和擦除操作是否成功完成来帮助验证与闪存设备的基本通信。该测试还有助于验证硬件连接。 如果您尚未修改 FCB, FlexSPI 启动指南第 18 章将详细介绍 FCB 的构造方式。如有任何疑问,请随时告诉我。 BR 哈比卜
查看全文
MCUxpressoでのSIMマクロの有効化 私は、元々はKDEを使って構築され、後にmcuexpressoを使って修正された古いプロジェクトを引き継いでいます。 最新バージョンのIDEをダウンロードし、FRDM_K64Fボード用のSDK2.11.0を使って新しいC/C++プロジェクトを作成しました。 古いプロジェクトにはもう必要のないものがたくさん含まれていたので、そこからコードをコピーして、新しいプロジェクトをゼロから構築しようとしています。 最初に貼り付けたコードはポートの初期化コードでした。 問題は、コンパイル時にすべてのハードウェア参照で「未定義」エラーが発生することです。 ./source/Frere_2016.c:52:1: エラー: 'SIM_SCGC5' が宣言されていません (この関数での最初の使用) 52 | SIM_SCGC5 |= SIM_SCGC5_PORTA_MASK; // ポートAクロックゲートCを有効にする SDKを解凍しても変わりはありません。 元のソースコードには、私がコピーしていない何らかの割り当てが含まれていたようですが、それは新しいプロジェクトで以下のようにカバーされるべきでしょう。 #include #include "board.h" #include「ペリフェラル」 #include "pin_mux.h" #include "clock_config.h" #include "fsl_debug_console.h" #include "MK64F12.h" を追加してみましたが、効果はありませんでした。 どんなご支援でも大変ありがたいです! よろしくお願いします。 ナイジェル SO始めました Re: SIM Macro activation in MCUxpresso こんにちは@ve3id コンパイルエラーが起こる理由は以下の通りです  SIM_SCGC5  は古いKinetisレジスタ記号です。FRDM-K64F用のMCUXpresso SDK 2.xで使用すべきです  SIM->SCGC5  同様に、他のハードウェアレジスタ参照も次のように変換します  PERIPHERAL->REGISTER  構文。 あなたの特定の行については、 SIM_SCGC5 |= SIM_SCGC5_PORTA_MASK ; に SIM->SCGC5 |= SIM_SCGC5_PORTA_MASK; よろしくお願いします。 BR アリス Re: SIM Macro activation in MCUxpresso アリスさん、本当にありがとうございました。あなたはSOとても知識豊富で、簡単に見せてしまうのですね! これでプロジェクトにCAN取りかかる 🙂 乾杯 ナイジェル
查看全文
MIMXRT1061は外部NORフラッシュから起動できません こんにちは 私は、外部NORフラッシュ(W25Q128JVSSIQ)を搭載したMIMXRT1061DVL6Bをベースにしたカスタムボードを持っています。私は開発環境としてVS Codeを使い、Zephyrを使っていますが、現在デバイスの起動に苦労しています。 この問題は、こちらの投稿で議論されている問題と似ているのではないかと考えています。 https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/i-MX-RT1060-Boot-using-FlexSPI/mp/1242678 具体的には、リンカースクリプトの設定と`XIP_EXTERNAL_FLASH`の有効化に関連している可能性があると考えています。 私が完全には理解していないのは、ZephyrベースのセットアップとスタンドアロンのMCUXpresso/NXP SDKスタイルプロジェクトの両方で、リンカー設定を正しく変更し「XIP_EXTERNAL_FLASH」を有効にする方法です。 実験として、手動で「MIMXRT1062xxxxx_flexspi_nor.ld」を修正することでMCUから多少の活動を得ることができましたリンカーファイルと`.text`セクションの配置の変更: 「`」 。文章{}> m_data AT > m_text 「`」 しかし、`MIMXRT1062xxxxx_flexspi_nor.ld` が複数存在するため、この手動修正に頼りたくありません。プロジェクト内のファイルのうち、どれがリンカーによって実際に使用されているのか分かりません。 以下の手順について正しい方法をご教示いただければ幸いです。 1. MIMXRT1061の外部NORフラッシュからXIP実行を設定します。 2. 必要な`XIP_EXTERNAL_FLASH`設定を有効にします。 3. Zephyrベースのプロジェクトでリンカースクリプトを適切に修正またはオーバーライドすること。 4. 非Zephyrプロジェクトにおける同等の構成を理解すること。 推奨されるアプローチについてご助言いただければ大変ありがたいです。 よろしくお願いいたします。 ジュナイド ブートROM|ブート|フラッシュ Re: MIMXRT1061 unable to boot from external NOR flash こんにちは、 @jahmed9 さん。 よりサポートするために、次の情報を教えていただけますか? -DQSピンはコネクテッドですか、それともデザイン中に浮かんでいる状態ですか? -フラッシュデバイスはFlexSPIポートAにコネクテッドですか? フラッシュデバイスに合わせてFCBを変更しましたか?もしそうなら、SDKの中のflash_component_nor_flexspiその例をあなたの修正を加えて実行してもらえますか? これにより、読み書き・消去操作が成功したかどうかを確認し、フラッシュデバイスとの基本的な通信を検証できます。このテストは、ハードウェア接続の検証にも役立ちます。 FCBを改造していない場合は、 FlexSPIブートガイドの第18章にFCBの構造に関する詳細な説明が記載されています。ご質問があれば、遠慮なくお尋ねください。 BR ハビブ
查看全文
セーフティ推奨コンパイラ設定違反 NXPが提供するMCAL SIPで推奨されるコンパイラ設定、アセンブラ設定、リンカー設定は、Wind Riverが推奨するセーフティコンパイラの設定に従っていません。 設定について話し合い、Wind Riverコンパイラのセーフティ推奨事項にどう合致するかを確認する必要があります。 MCAL SIPパッケージ情報: - ->SW32K3_S32M27x_RTD_R21-11_7.0.1_QLP02 ->SW32K3_RTD_R21-11_7.0.1_P05_D2604 ->SW32K3_SAF_1.0.6_D2512 ->SCST_M7_S32K3_RFP_1.0.7 Re: Safety recommended Compiler setting violation こんにちは、 アプリケーションチームに直接連絡が必要な場合は、担当のNXP担当者FAE/営業担当者に連絡してください。直接サポートチャネルを設定できます。 ご質問があれば、遠慮なくお尋ねください。 よろしくお願いします、 ピーター
查看全文
RT1180 VDDA_ADC_1P8 源 您好, 在 RT1180 参考手册中,VDDA_ADC_1P8 源与图 70 中的不同。电源架构(§19.3.2)和图 90。电源系统概述(§24.3.2.1):它分别连接到VDD_AON_ANA或DCDC_1P8。 哪个信息源更可取? 此致 雷米 Re: RT1180 VDDA_ADC_1P8 source 嗨@rémi , 根据硬件设计指南,建议避免使用内部 DCDC/低压差线性稳压器(LDO) 输出作为 ADC 参考,而应使用更精确的外部电压参考。 如果您更倾向于使用内部参考值,我推荐 VDD_AON_ANA。或者,您可以使用外部参考作为 VREF,EVK 实现了这两种选项。 此致, 巴勃罗 Re: RT1180 VDDA_ADC_1P8 source 嗨@Pablo_Ramos , 感谢您的反馈。 抱歉,我把密码名称写错了,应该是: 在 RT1180 参考手册中, VDDA_1P8_IN源与图 70 中的源不同。电源架构(§19.3.2)和图 90。电源系统概述(§24.3.2.1):它分别连接到VDD_AON_ANA或DCDC_1P8。 哪个信息源更可取? 此致 雷米 Re: RT1180 VDDA_ADC_1P8 source 嗨@rémi , 对于 VDDA_1P8_IN,我建议参考 EVK 设计原理图,该原理图使用 VDD_AON_ANA 或外部参考电源为 VDDA_1P8_IN 供电。 此致, 巴勃罗 Re: RT1180 VDDA_ADC_1P8 source 嗨@Pablo_Ramos , 感谢您的反馈。 硬件设计指南或其他 NXP 文档中是否有任何技术解释,说明使用VDD_AON_ANA 或外部参考电源为 VDDA_1P8_IN 供电而不是使用 DCDC_1P8 是合理的? 此致 雷米 Re: RT1180 VDDA_ADC_1P8 source 嗨@rémi , 两个连接都正确。然而,硬件设计指南中提到,有关图 1 中未描述的电源域的详细信息,请参阅相关文档。电源控制图,请参考 MIMXRT1180-EVK 设计原理图。 在 EVK 原理图中,VDDA_1P8_IN 与 VDDA_ADC_1P8 由同一电源供电,因此可以选择使用外部参考或 VDD_AON_ANA。这就是我之前提出建议的依据。 此致 巴勃罗
查看全文