The application's reading of the DCSR register value caused a CPU freeze. My device environment consists of a B4860 hardware chip platform running the OSE operating system, with a DCSR address space mapping type of SASE. 0xf1100000 - 0xf14fffff 0x00400000 rw-r-- cio ----g- SASE dcsr Dereferencing any address within the range 0xf1124fff to 0xf1125fff caused a CPU freeze, followed by a reset due to a watchdog timeout. This address space is 4KB in size. I'd like to know information about the chip's DCSR register. What is the function of the DCSR register? Can't its value be directly accessed and read?

デモ資料のアップロードエラー 電源管理ICの機能安全と関連システムに関する考慮事項 | NXPセミコンダクターズ　このビデオの情報はビデオのURLであり、ドキュメントのURLではありません。 Re: 演示资料上传错误 こんにちは、 ご報告いただいた問題は把握しており、影響を受けているページを特定しました。トレーニングコース「電源管理IC的功能安全及相关システム注意事项 |NXP中国語のウェブサイトにある「NXP半导体」(Functional Safety in Power Management ICs and Related System Considerations, COURSE ID: TIP-NXP-AUT-T4050)には、動画URLを指し示す誤った資料/プレゼンテーションのダウンロードリンクが表示されているようです。 担当のウェブコンテンツチームに修正を依頼しましたので、リンクが修正され次第、ご連絡いたします。 その間、このトレーニングのプレゼンテーションスライドが必要な場合は、同じコースのグローバル英語版が以下で利用可能です: https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T4050 BRs、トーマス

双核通信 S32K322 大家好， 我已经启动了一个双核项目，其中核心 0 和核心 1 都已启用。作为测试，我在每个核心上创建了一个递增变量。 将变量数据从核心 1 共享或传输到核心 0（反之亦然）的推荐方法是什么？ 非常感谢您能提供一些使用共享内存的示例或最佳实践。 微控制器：NXPS32k322 IDE：S32 设计工作室 RTD：v3 调试器：PEMicro 谢谢！ Re: Dual core communication S32K322 你好@db16122 我开始搭建双核系统，并通过计数器验证了核心 0 和核心 1 是否正在运行。但是，我的主要问题是：如何将数据从核心 1 传递到核心 0，反之亦然？您能否提供一些关于核心间数据共享的例子？ Re: Dual core communication S32K322 我建议使用跨平台通信框架（IPCF）。 https://www.nxp.com/design/design-center/software/automotive-software-and-tools/inter-platform-communication-framework-ipcf:IPCF 包含示例和培训。 Re: Dual core communication S32K322 如果给每个 M7 核心增加两个计数器呢？M7 运行后，计数器开始计数，您可以检查该值是否相同。 顺便问一下，检查每个核心状态的目的是什么？是为了功能安全原因吗？

imx8 nanoカーネルのA53コアへの5.15から6.18への移行 imx_rproc_kick こんにちは A53コアのカーネルを5.15から6.18にアップグレードしていますが、imx_rproc_kickが見つかりません。 デバッグメッセージを探してください # DMESG |grep -nE "rpmsg|virtio|remoteproc|imx-rproc|imx_rproc_kick|goodbye|new チャネル|get [0-9]」 118:[ 0.030048] IMX RPMSGドライバーが登録されています。 222:[ 1.538994] remoteproc remoteproc0: imx-rproc が利用可能です 224:[ 1.544537] RemoteProc RemoteProc0: IMX-rprocへの接続 225:[ 1.555034] rproc-virtio rproc-virtio.1.auto:割り当てられた予約メモリノードvdevbuffer@b8400000 226:[ 1.564322] virtio_rpmsg_bus virtio0: rpmSGホストがオンライン 227:[ 1.569846] rproc-virtio rproc-virtio.1.auto:登録済みVirtio0(タイプ7) 228:[ 1.576689] RemoteProc RemoteProc0: リモートプロセッサ IMX-Rproc が接続されました 327:[ 5.860600] IMX-rproc imx8mn-cm7: imx_rproc_kick: failed (1, err:-62) 敬具 ヤドゥナート・R Re: imx8 nano kernel migration for a53 core from 5.15 to 6.18 imx_rproc_kick imx_rproc_kick 6.18カーネルに欠けているわけではありません。ログにはドライバーが到達しエラーを返したことが示されています: imx-rproc imx8mn-cm7: imx_rproc_kick: 失敗しました (1、エラー:-62) err:-62 は、リモートコアへのキックがタイムアウトしたことを意味します。NXPのi.MX remoteproc/RPMsgのコンテキストでは、これはRPMsgキックパス中のタイムアウトとして説明されています。デフォルトのBSPリモート準備完了待機時間は50msですが、キャッシュがオフになっている場合やファームウェアがまだ準備できていない場合など、RPMsgの初期化が遅れるとMコアはより長い時間が必要になる場合があります。 あなたのログによると、Linux側はここまで来ています: remoteproc0: imx-rprocに接続中 rproc-virtio... 予約済みメモリノード vdevbuffer@b8400000 を割り当てました virtio_rpmsg_bus virtio0: rpmsgホストはオンラインです リモートプロセッサIMX-RproCが接続されました つまり、A53/Linux側はすでに動作中のM7に接続し、virtio RPMsgホストを作成しています。失敗は後にLinuxがvirtqueue 1に通知しようとした際に発生しますが、MU/RPMsg側が間に合わずハンドシェイクを完了しません。i.MX remoteprocキックパスは、LinuxとハードウェアのMU(リモートプロック)間のIPC割り込み信号にメールボックス/MUを使用します。 5.15 → 6.18へのアップグレードでデバッグが必要になる可能性が最も高い箇所： M7ファームウェアリソーステーブル/RPMsgメモリレイアウト M7のファームウェアリソーステーブルがLinuxのDT予約メモリ配置と一致しているか確認してください。 NXPのドキュメントによると、リソーステーブルはvirtioデバイスおよびvringエントリを定義しており、RSC_VDEV、NUM_VRINGS、VDEV0_VRING_DA_BASE、VRING_ALIGN、バッファカウントなどが含まれます。 有効なリソーステーブルが存在しない場合、NXPのLinuxユーザーガイドではリソーステーブル領域をクリアすべきと記載されています。i.MX 8M Mini/Nano/Quad LPDDR4 EVK では、文書化されたコマンドは mw 0xb80ff000 0 4 です。 デバイスツリーの予約メモリとrsc-da 6.18 DT が、M7 ファームウェアが想定するアドレスと同じアドレスに RPMsg vring/buffer/resource-table 領域を予約していることを確認してください。 ログにはLinuxが割り当てられたvdevbuffer@b8400000が表示されているので、M7ファームウェアのRPMsg-Lite/OpenAMP設定が同じvring/bufferベース領域を使っているか確認してください。 また、imx8mn-cm7ノードに、お使いのボード/ファームウェアに適したmboxes、memory-region、rsc-daの値が設定されていることを確認してください。 M7ファームウェアの準備状況 ログにはタイムアウト前のRPMsg「新しいチャネル」ラインは表示されません。これはLinuxがRPMsgホストとしてオンラインであることを示唆していますが、M7側が正しくチャネルをアナウンス・サービスしていない可能性があります。 Linuxがトラフィックを送信する前にM7アプリケーションがRPMsg-Lite/OpenAMPを初期化し、エンドポイントを有効にする前にブロックされていないことを確認してください。 新しいカーネルのRPMsgに関する前提に基づいて構築されたファームウェア NXPは、リモートRPMsgリソースが破壊された後もLinux側がM7をキックし続けた事例を記録しており、その結果imx_rproc_kick失敗(...、ええと:-62)が出ています。 SDKのピンポン風デモを使う場合は、M7ファームウェアが一定数のメッセージ後にRPMsgエンドポイントを終了または破壊するかどうかを確認してください。そのパターンはまさにこの種類の誤りを引き起こすことがあります。 推奨される次のデバッグコマンド： dmesg | grep -nE "remoteproc|rproc|rpmsg|virtio|mailbox|mu|imx-rproc|imx_rproc" ls -l /sys/class/remoteproc/remoteproc0/ cat /sys/class/remoteproc/remoteproc0/state cat /sys/class/remoteproc/remoteproc0/name また、5.15と6.18のこれらの値を比較してください。 grep -n "imx8mn-cm7" -n your-board.dts grep -n "vdevbuffer\|vdev0vring\|rsc\|rpmsg\|reserved-memory" your-board.dts まず最初に確認すべきことは、 6.18 デバイスツリーが M7 ファームウェアのリソーステーブルと RPMsg メモリ アドレスと一致しているかどうかです。Linux側は正常に接続しています。故障はMU/RPMsgのキック/アクック段階にあり、これはimx_rproc_kick機能の欠如よりもM7の準備状況、メールボックス/DTの設定、リソーステーブル/vringの不一致を示唆しています。

アプリケーションがDCSRレジスタの値を読み取った際に、CPUがフリーズした。 私のデバイス環境は、OSEオペレーティングシステムを実行するB4860ハードウェアチッププラットフォームで構成されており、DCSRアドレス空間マッピングタイプはSASEです。 0xf1100000 - 0xf14fffff 0x00400000 rw-r-- cio ----g- SASE dcsr 0xf1124fffから0xf1125fffの範囲内のアドレスを逆参照すると、CPUがフリーズし、ウォッチドッグタイムアウトによりリセットされました。このアドレス空間のサイズは4KBです。チップのDCSRレジスタについて知りたいのですが、DCSRレジスタの機能は何ですか？その値に直接アクセスして読み取ることはできないのでしょうか？ Re: 应用程序中读取DCSR寄存器的值引发CPU停滞的问题 フリーズは、通常の読み取り可能なDCSRレジスタではなく、B4860 DCSR空間内の記録されたアクセス不能ホールにアクセスすることと一致しています。 DCSRは一つのレジスタではありません。これは、実行制御/デバッグイベント、トレース生成、イベントカウント、EPUパフォーマンスカウンタ、Nexus/トレース関連レジスタなど、デバッグ関連のハードウェアリソースに使用される4MBのメモリマップ付きデバッグ/制御/ステータスアドレス空間です。一部のDCSRリソースはデバッグや内部用途のみ使用可能であり、少なくとも1つのサポートノートではDCSR/DSCRアクセスは「内部使用のみ」と記載されており、該当する場合はDTUにはCCSRアクセスの使用を推奨しています。 マッピングについて： DCSRベース = 0xf1100000 範囲が不正です = 0xf1124fff - 0xf1125fff オフセット = 0x24fff - 0x25fff 重要な点は次のとおりです。 0xf1125000 - 0xf1125fff  ＞ DCSR オフセット 0x25000 - 0x25fff その正確なDCSRオフセット範囲はアクセス不能スロットとして記載されており、NXPのサポート証拠ではDCSR領域で0x25000~0x25fffを読み取ると「システムハングを引き起こす」とされています。推奨される解決策は、DCSR空間のMMUウィンドウを有効にする際にその範囲を除外することです。他のB4860関連の証拠も同様に、CCSR/DCSRの未マッピング・未使用・予約領域はアクセスできず、それらにアクセスするとSC3900コアやSoCが停止する可能性があると示されています。 つまり答えは次の通りです: いいえ、DCSRマップされた範囲内の任意のアドレスを直接スキャンしたり、逆参照したりしてはいけません。 アクセスすべきは、文書化された有効なDCSRオフセットのみです。 予約済み、未使用、またはアクセス不能のDCSRスロットは、バスエラーを返す代わりにCPU/SoCをハングさせることがあります。 お客様の特定の障害発生範囲は、既知の不良DCSRオフセット0x25000～0x25fffと重複しており、これがCPUフリーズ後にウォッチドッグリセットが発生する理由です。 もう一つ追加情報として、0xf1124fffは文書化された0x25000ホールの1バイト前ですが、その非揃列アドレスでの32ビットアクセスは0xf1125000に交差する可能性があります。DCSR/レジスタアクセスは、任意のバイト/ワードプロービングではなく、アラインドされた32ビットレジスタアクセスとして扱うべきです。 推奨される処理方法：特定のデバッグ リソースが必要な場合にのみ DCSR をマッピングし、読み取り/書き込みを既知の有効なオフセットに制限し、診断ダンプまたはメモリ スキャン コードから DCSR + 0x25000 から DCSR + 0x25fff を明示的にブロック/除外します。 フリーズはそのアドレス範囲で予想されます。0xf1125000–0xf1125fffはB4860 DCSRの非アクセス可能なスロット0x25000–0x25fffにマッピングされるため、DCSR空間の任意の直接読み込みは安全ではありません。

Demonstration material upload error Functional Safety and Related System Considerations for Power Management ICs | NXP Semiconductors The information in this video is the video URL, not the document URL. Re: 演示资料上传错误 Hi, The issue you reported has been noted and I have identified the affected page. The training course "电源管理IC的功能安全及相关系统注意事项 | NXP 半导体" (Functional Safety in Power Management ICs and Related System Considerations, course ID: TIP-NXP-AUT-T4050) on the NXP Chinese website does appear to have an incorrectly configured material/presentation download link, pointing to the video URL rather than the downloadable presentation file. I have flagged this to the responsible web content team for correction and will update you once the link has been fixed. In the meantime, if you require the presentation slides from this training, the global English-language version of the same course is available at: https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T4050 BRs, Tomas

NXP SR040のピーク消費電力 こんにちは、SR040の最大消費電力はどれくらいですか？Tx/Rx/アイドルの内訳を教えてもらえますか? Re: NXP SR040 Peak Power Consumption こんにちは、 あなたの調子が良いといいのですが。ご不便をおかけして申し訳ありませんが、この製品の情報はNDA(秘密保持契約)に基づいており、公開されていません。 チップについての詳細は、代理店ネットワークで利用可能な当社の代理店のいずれかにお問い合わせください。NXPですか?または、このデバイスを手に入れるのを手伝った直接の連絡先がいれば、ぜひ連絡してください。 もし当社のUWB製品に関する情報をお探しの方やこのテクノロジに興味がある方は、パートナー(Trimension UWB Partners)のこれらの開発キットとモジュールをご確認いただくことをお勧めします。 これらのキットやモジュールに興味がある場合は、直接彼らに相談してプロセスやサポートを受けられるかを知る必要があります。なぜなら、このテクノロジのサポートは彼らを通じて行われるからです。 ドキュメントとソフトウェアは対応するUWBモジュールパートナーによって配布されます。モジュールを選択すると、パートナーのページに案内され、データシート、アプリケーションノート、必要なイネーブルメントにアクセスできます よろしくお願いいたします。 リカルド

imx8 nano 内核迁移（适用于 a53 核心），从 5.15 版本迁移到 6.18 版本 imx_rproc_kick 你好 我正在将 A53 核心的内核从 5.15 升级到 6.18，但是我发现缺少 imx_rproc_kick。 请查看调试信息 # dmesg | grep -nE "rpmsg|virtio|remoteproc|imx-rproc|imx_rproc_kick|goodbye|new 频道|获取[0-9]" 118:[ 0.030048] imx rpmsg 驱动程序已注册。 222:[ 1.538994] remoteproc remoteproc0: imx-rproc 可用 224:[ 1.544537] remoteproc remoteproc0：正在连接到 imx-rproc 225:[ 1.555034] rproc-virtio rproc-virtio.1.auto:已分配保留内存节点 vdevbuffer@b8400000 226:[ 1.564322] virtio_rpmsg_bus virtio0: rpmsg 主机已联机 227:[ 1.569846] rproc-virtio rproc-virtio.1.auto:已注册 virtio0（类型 7） 228:[ 1.576689] remoteproc remoteproc0: 远程处理器 imx-rproc 已连接 327:[ 5.860600] imx-rproc imx8mn-cm7: imx_rproc_kick: 失败 (1, 错误:-62) 问候 亚杜纳特·R Re: imx8 nano kernel migration for a53 core from 5.15 to 6.18 imx_rproc_kick 你的 6.18 内核中并没有缺少 imx_rproc_kick 函数——你的日志显示驱动程序已经执行到该函数，但返回了错误： imx-rproc imx8mn-cm7：imx_rproc_kick：失败（1，错误代码：-62） 错误代码 -62 表示向远程核心发送的指令超时。在 NXP 的 i.MX remoteproc/RPMsg 上下文中，这被描述为 RPMsg 启动路径期间的超时；默认的 BSP 远程就绪等待时间为 50 毫秒，如果 RPMsg 初始化延迟，例如当缓存关闭或固件尚未准备就绪时，M 内核可能需要更长时间。 从你的日志来看，Linux 端执行到了这一步： remoteproc0：正在连接到 imx-rproc rproc-virtio... 已分配预留内存节点 vdevbuffer@b8400000 virtio_rpmsg_bus virtio0：rpmsg 主机已联机 远程处理器 imx-rproc 已连接 因此，A53/Linux 端连接到已经运行的 M7，并创建 virtio RPMsg 主机。故障发生在 Linux 尝试通知 virtqueue 1 时，但 MU/RPMsg 端未能及时完成握手。i.MX remoteproc kick 路径使用邮箱/MU 在 Linux remoteproc 和硬件 MU 之间进行 IPC 中断信号传递。 5.15 → 6.18 升级过程中最可能需要调试的区域： M7固件资源表/RPMSg内存布局 验证 M7 固件资源表是否仍然与 Linux DT 保留内存布局匹配。 NXP 文档显示资源表定义了 virtio 设备和 vring 条目，包括 RSC_VDEV、NUM_VRINGS、VDEV0_VRING_DA_BASE、VRING_ALIGN 和缓冲区计数。 如果映像没有有效的资源表，NXP 的 Linux 用户指南指出应该清除资源表区域；对于 i.MX 8M Mini/Nano/Quad LPDDR4 EVK，记录的命令是 mw 0xb80ff000 0 4。 设备树保留内存和 rsc-da 检查 6.18 DT 是否仍然在 M7 固件预期的相同地址保留 RPMsg vring/buffer/resource-table 区域。 您的日志显示 Linux 分配了 vdevbuffer@b8400000，因此请确认 M7 固件的 RPMsg-Lite/OpenAMP 配置使用相同的 vring/buffer 基础区域。 另外，请确认 imx8mn-cm7 节点具有适用于您的板/固件的正确 mboxes、memory-region 和 rsc-da 值。 M7固件准备情况 日志中未显示超时前 RPMsg “新通道” 行。这表明 Linux 作为 RPMsg 主机在线，但 M7 端可能没有正确地通告/服务该通道。 确保 M7 应用程序在 Linux 发送流量之前初始化 RPMsg-Lite/OpenAMP，并且在启用端点之前没有被阻止。 为新内核的 RPMsg 假设而构建的固件 NXP 记录了一些案例，在这些案例中，即使远程 RPMsg 资源已被销毁，Linux 端仍然继续踢 M7，导致 imx_rproc_kick: failed (..., err:-62)。 如果您使用的是 SDK 乒乓式演示，请确认 M7 固件是否会在发送固定数量的消息后退出/销毁 RPMsg 端点。这种模式可能会触发此类错误。 建议的后续调试命令： dmesg | grep -nE "remoteproc|rproc|rpmsg|virtio|mailbox|mu|imx-rproc|imx_rproc" ls -l /sys/class/remoteproc/remoteproc0/ cat /sys/class/remoteproc/remoteproc0/state cat /sys/class/remoteproc/remoteproc0/name 另外，请比较 5.15 和 6.18 之间的这些差异： grep -n "imx8mn-cm7" -n your-board.dts grep -n "vdevbuffer|vdev0vring|rsc|rpmsg|reserved-memory" your-board.dts 我首先要检查的主要事项是6.18 设备树是否仍然与 M7 固件的资源表和 RPMsg 内存地址匹配。您的 Linux 端已成功连接；失败发生在 MU/RPMsg kick/ack 阶段，这更多地指向 M7 就绪、邮箱/DT 配置或资源表/虚拟环不匹配，而不是 imx_rproc_kick 函数缺失。

当另一个端口失去连接时，端口上的 T1040 mEMAC TX_FIFO_OVFL 会发出警报。 我正在调试 T1040 上的以太网问题，该交换机使用 1G mEMAC RGMII 接口。当另一个端口失去物理连接（例如，电缆断开）时，我发现以太网端口上出现丢包现象。当两个端口都以高数据速率运行时，这种情况似乎最常发生。 当出现问题时，我看到正常端口的中断事件寄存器（`IEVENT`）中设置了`TX_FIFO_OVFL`位。 我目前的解释是，当一个正在发送数据的 mEMAC 失去物理链路时，FMan/mEMAC 发送路径中的某些东西会暂时阻止另一个 mEMAC 足够快地耗尽其 TX FIFO。正常端口最终会报告 `IEVENT[TX_FIFO_OVFL]`，导致帧丢失。然而，我尚未确定导致这种行为的共享资源或机制。 我的问题是： * 这是已知的 T1040 / FMan v3 / mEMAC 芯片问题还是勘误？ * 1G mEMAC 端口之间是否存在共享资源，导致一个端口在传输时出现载波丢失，从而暂时影响另一个端口的 TX FIFO？ * 当 PHY 失去链路时，是否有必要的顺序，例如停止 QMI 出队、禁用 BMI TX 端口、禁用 mEMAC TX/RX 或重置 mEMAC？ * 是否有任何 mEMAC 或 FMan 状态寄存器可以在溢出发生之前检测到导致 `TX_FIFO_OVFL` 的情况？ * 是否有建议的 FMan/mEMAC 或 PHY 配置更改可以防止在这种情况下出现 `TX_FIFO_OVFL`？ 谢谢！ Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 你好， 目前尚无公开记录的 T1040/FMan v3 硅勘误表，专门描述由对等端口链路丢失触发的健康端口上的 TX_FIFO_OVFL 。T1040 芯片勘误表文档受 NDA 控制，未公开索引，但尚未发现 T1040 mEMAC 存在此类跨端口 TX FIFO 溢出勘误。 您观察到的行为很可能是共享的 FMan BMI 资源中的架构交互，而不是芯片缺陷。   此致 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 您好， 四个共享的 BMI 资源是 TNUM（任务）、DMA 通道、FIFO（MURAM）和流水线深度。由于您的 FIFO 大小、流水线深度 ( DPDE ) 和 FIFO 低阈值 ( FLCL ) 的更改没有产生任何改进，因此 DMA 通道层很可能是瓶颈，而不是 MURAM 分配。 T1040 FMan 具有固定的 DMA 通道池，该通道池在所有活动的 TX 端口之间共享。每个端口的发送路径为： CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire     当您的停滞端口失去链路并且您清除 COMMAND_CONFIG[TX_EN] 时，mEMAC 会停止向线路发送数据，但任何已在流水线中间的帧（特别是 BMI TX 端口已发出 DMA 读取事务 (DDR → MURAM TX FIFO) 的帧）不会立即完成。DMA 读取可能已经将数据移入 TX FIFO，而 FMan DMA 引擎现在正在等待“DMA 完成/EBD（外部缓冲区描述符）释放”确认，这取决于正在使用 FIFO 的 MAC。当 TX_EN=0 ，MAC 不进行消费，因此 DMA 事务保持打开状态。 停滞端口上的那些未关闭的 DMA 事务占用共享的 DMA 通道槽位。在高负载下，健康端口的 BMI TX 路径无法获得足够的 DMA 通道槽位来从 DDR 快速获取数据，从而无法保持其 TX FIFO 的供应 → TX FIFO 短暂为空 → 然后回填速度比 MAC 的耗尽速度更快 → TX_FIFO_OVFL 。 此致 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 谢谢。您能否确定是哪种共享的 BMI 资源或仲裁机制导致了这种行为？ 我测试了FMBM_PFS[IFSZ]、FMBM_TFP[DPDE]和FMBM_TFP[FLCL]的更改，但没有看到有意义的变化。当 IF_STATUS[RGLINK] 变为低电平时，我也会立即停止入队并禁用 mEMAC TX，但健康的端口仍然可能会丢包。 是否有已记录或推荐的配置方法可以将端口与这种交互隔离？此外，是否有计数器、状态寄存器或调试机制可以显示哪个 BMI 资源正在耗尽、阻塞或以其他方式阻止健康的 mEMAC 清空其 TX FIFO？ Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link 谢谢你的解释。我检查了 1G TX 端口的 FMBM_PP 配置。它们均配置为默认值： MXT = 3：最多 4 个并发任务 MXD = 2：最多 3 个未完成的 DMA 请求 我还尝试调整了每个端口的资源限制。我调整了DMA请求和并发任务数的设置。这并没有对 TX FIFO 溢出产生明显的改善。 鉴于默认配置下 1G TX 端口只能有 3 个未完成的 DMA 请求，我不确定一个停滞的 1G 端口如何能消耗足够的共享 DMA 资源，从而对另一个端口产生重大影响。 是否存在一个与 84 项 FMan v3 DMA 命令队列分开的较小的共享 DMA 通道/资源池？或者少量停滞的 DMA 事务是否会导致队头阻塞，或者阻止其他端口的 DMA 事务继续进行？ 另外，是否有 DMA 状态/调试寄存器或计数器可以用来确认链路断开端口的未完成 DMA 事务在此情况下是否仍然保持打开状态？

Linux 6.+ の ls104x 上バージョン NXPはLS104Xチップ向けにLinux 6.0以上の上位バージョンを公式に提供しているのでしょうか?ダウンロードリンクを教えてもらえますか? Re: ls104x higher version of Linux 6.+ 以下のリンクをご参照ください。 https://github.com/nxp-qoriq/yocto-sdk ブランチ バージョン 斜鼻 YP 6.0-lf-6.18.20 ウィンラッター YP 5.3-lf-6.18.2 ウォルナスカー YP 5.2-lf-6.12.49 スタイヘッド YP 5.1-lf-6.12.3 スカースギャップ YP 5.0-lf-6.6.52 ナンビルド YP 4.3-lf-6.6.3 ミックルドア YP 4.2–lf-6.1.55 ラングデール YP 4.1–lf-6.1.1

ls104x 更高版本的 Linux 6.+ NXP 官方是否为 LS104X 芯片提供了更高版本的 Linux 6.0 或更高版本？能否提供下载链接？ Re: ls104x higher version of Linux 6.+ 请参考以下链接。 https://github.com/nxp-qoriq/yocto-sdk 分支 版本 蚁鼻 YP 6.0-lf-6.18.20 惠尼拉特 YP 5.3-lf-6.18.2 瓦尔纳斯卡 YP 5.2-lf-6.12.49 斯泰黑德 YP 5.1-lf-6.12.3 疤痕裂缝 YP 5.0-lf-6.6.52 南比尔德 YP 4.3-lf-6.6.3 米克尔多尔 YP 4.2–lf-6.1.55 朗代尔 YP 4.1–lf-6.1.1

T1040 mEMAC TX_FIFO_OVFL は、別のポートがリンクを失ったときにポートで動作します。 私は1G mEMAC RGMIIインターフェースを使ってT1040のイーサネット問題をデバッグしています。別のポートが物理的なリンクを切った場合(例えばケーブルが切断されている場合)、イーサネットポートでパケットロスが発生しています。これは、両方のポートが高速データ転送速度で動作している場合に最も頻繁に発生するようです。 問題が発生すると、健康なポートの割り込みイベントレジスタ(「IEVENT」)に「TX_FIFO_OVFL」ビットが設定されているのが見えます。 私の現在の解釈では、アクティブに送信中のmEMACが物理的なリンクを失うと、FMan/mEMAC送信経路の何らかの要因によって、別のmEMACがTX FIFOを十分に速く使い切ることが一時的に妨げられる、ということだ。正常なポートは最終的に`IEVENT[TX_FIFO_OVFL]`を報告し、フレームが失われます。しかし、この行動を引き起こす共通のリソースやメカニズムはまだ特定していません。 私の質問は以下のとおりです。 * これは既知のT1040 / FMan v3 / mEMACシリコンの問題ですか、それともエラタムですか? * 1G mEMACポート間で共有リソースがあり、送信中に一方のポートでキャリアが失われ、別のポートの送信FIFOに一時的に影響が出る可能性があるか? * PHYがリンクを失った場合、QMIデキューの停止、BMI TXポートの無効化、mEMAC TX/RXの無効化、mEMACのリセットなど、必要なシーケンスはありますか? * オーバーフローが発生する前に「TX_FIFO_OVFL」状態を検出できるmEMACやFManステータスレジスタはありますか? * この状況で「TX_FIFO_OVFL」を防ぐために推奨されるFMan/mEMACやPHYの設定変更はありますか? よろしくお願いします。 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link こんにちは、 T1040/FMan v3のシリコンエラッタで、ピアポートのリンク喪失によって正常なポートで TX_FIFO_OVFL トリガーされることを具体的に説明したものは、公式には文書化されていません。T1040チップの正誤表はNDA（秘密保持契約）によって管理されており、一般には公開されていませんが、T1040 mEMACに関して、そのようなクロスポートTX FIFOオーバーフローの正誤表は確認されていません。 観察されている現象は、シリコンの欠陥というよりも、共有されているFMan BMIリソース内のアーキテクチャ上の相互作用によるものである可能性が最も高いです。   よろしくお願いします。 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link こんにちは、 共有される4つのBMIリソースは、TNUM(タスク)、DMAチャネル、FIFO(MURAM)、パイプライン深度です。FIFOサイズ、パイプライン深度( DPDE )、FIFOの低閾値( FLCL )の変更で改善が見られなかったため、DMAチャネル層が最もボトルネックであり、MURAM割り当てではありません。 T1040 FManは、すべてのアクティブなTXポートで共有される固定されたDMAチャネルプールを持っています。各ポートのTXパスは以下のとおりです。 CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire     停止したポートがリンクを失い、 COMMAND_CONFIG[TX_EN] クリアすると、mEMAC はワイヤへの送信を停止しますが、既にパイプラインの途中にあるフレーム、特に BMI TX ポートが既に DMA 読み取りトランザクション (DDR → MURAM TX FIFO) を発行しているフレームは、すぐには完了しません。DMA読み取りによって既にデータがTX FIFOに移動されている可能性があり、FMan DMAエンジンは現在、FIFOを消費するMACに依存する「DMA完了/EBD（外部バッファ記述子）解放」確認応答を待っています。 TX_EN=0 ではMACが消費されないため、DMAトランザクションは開かれたままになります。 停止したポートで開いているDMAトランザクションは、共有DMAチャネルスロットを保持します。高負荷時には、健康なポートのBMI TXパスが十分なDMAチャネルスロットを獲得できず、DDRからデータを迅速に取得できず、TX FI→FOが一時的に空になり→その後MACのドレインレート→ TX_FIFO_OVFL よりも速く戻ってしまいます。 よろしくお願いします。 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link ありがとう。この行動を引き起こすと予想される共有のBMIリソースや仲裁メカニズムを特定しますか? FMBM_PFS[IFSZ]、FMBM_TFP[DPDE]、およびFMBM_TFP[FLCL]への変更をテストしましたが、意味のある変化は見られませんでした。また、IF_STATUS[RGLINK]が低下したらエンキューをやめ、mEMAC TXをすぐに無効にしていますが、健康なポートでもパケットが失われることがあります。 この相互作用からポートを分離するための、文書化された、または推奨される構成はありますか？また、どのBMIリソースが枯渇したり、ブロックされたり、健康なmEMACがTX FIFOを消耗させないようにしているかを示すカウンター、ステータスレジスタ、デバッグ機構はありますか? Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link ご説明ありがとうございます。1G TXポートのFMBM_PP設定を確認しました。これらはデフォルト値で設定されています。 MXT = 3:最大4つの同時処理タスク MXD = 2:最大3件の未処理DMA要求 ポートごとのリソース制限についても実験してみました。DMA要求や同時処理タスクの設定を増減しました。これはTX FIFOオーバーフローに関して目立った改善をもたらさなかった。 デフォルト設定では1GのTXポートは未処理のDMA要求が3件しか持てないため、1つの停止した1Gポートが他のポートに大きな影響を与えるほどの共有DMAリソースを消費する理由がよくわかりません。 84エントリのFMan v3 DMAコマンドキューとは別に、より小さな共有DMAチャネル/リソースプールが存在するのでしょうか?それとも、少数のDMAトランザクションが停止することでヘッドオブラインブロッキングや他のポートからのDMAトランザクションの進行を妨げることがあるのでしょうか? また、リンクダウンポートからの未処理のDMAトランザクションがこの状態でも実際に開いていることを確認するためのDMAステータス/デバッグレジスタやカウンターはありますか?

OX05B1S GMSL2 相机，配备 MAX96717/MAX96724，搭载于 i.MX95 上 您好，NXP团队： 我们正在测试运行 Linux 的 i.MX95 19x19 EVK 上的 OX05B1S GMSL2 相机。 设置： OX05B1S 相机 - MAX96717 - GMSL2 - MX95MBDESER01 MAX96724 - i.MX95 MX95MBDES10001 套件附带的 OX03C10 摄像头与相同的解串器板配合使用，并且可以使用 cam -l 命令查看。 但是，cam -l 并未列出配备 MAX96717 的 OX05B1S 相机。 BSP包含ox05b1s.ko，max96724.ko，max96717_lib.ko，以及 OX05B1S DTB 文件。 OX05B1S DTB 似乎描述了直接的 MIPI 连接，而 OX03C10 DTB 包含 MAX96724 拓扑结构。 NXP是否为这种配置提供参考设备树配置？ OX05B1S - MAX96717 - MAX96724 - i.MX95 如果不行，请问要将这款 OX05B1S GMSL2 相机与 MX95MBDESER01 板配合使用，需要进行哪些更改？ 谢谢！ 此致， 塔伦 Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 谢谢你的解释。我们了解到，目前的 电路板支持包 正式支持通过直接 MIPI-CSI 接口实现的 OX05B1S，而 MAX96717/MAX96724 SerDes 支持则用于 OX03C10。 我们使用 OX05B1S 相机模块，该模块通过 MAX96724 解串器连接到 i.MX95，并带有 MAX96717 串行器。GMSL2 链路锁定成功，MAX96717 可通过远程 I2C 通道访问。 目前 电路板支持包 是否不支持 OX05B1S + MAX96717 + MAX96724，这意味着需要自定义驱动程序/设备树集成？或者是否有针对这种组合的参考实现或补丁？ Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 当前 电路板支持包 支持使用 MIPI_CSI miniSAS 连接器直接连接 i.MX95 板的 OX05B1S 传感器。Omnivision OX03C10 传感器可通过以下供应商提供的串行器/解串器解决方案在 i.MX 95 上获得支持： • Analog Devices：MAX96717/MAX96724 • 德州仪器：DS0UB953/DS0UV960 更多详细信息，请参阅第 6.1.3 章。相机参考手册 https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 是的，请参考驱动程序 MX95mbcam.c如果使用 OX03C10 驱动程序，并且需要更换摄像头，则必须完全更换该驱动程序。 https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/media/i2c/mx95mbcam.c

设备（型号为 MK22FN1M0VLQ12）工作一段时间后出现复位循环 嗨，大家好， 我有一个运行在 MK22FN1M0VLQ12 上的设备。 问题是，运行一段时间后，它在启动时会陷入重置循环。 起初我以为是闪存损坏的问题（该应用程序将日志保存在闪存中）。我采用了乒乓球式策略来解决这个问题。 但有些设备退回来时也存在类似问题。我尝试调试其中一个设备，但没有设置任何断点，它总是在 ASerialLDD2_Init 或 IntFlashLdd1_Erase 处停止，这两个函数都是由处理器专家生成的。我用内存转储功能检查了其他设备，发现内存确实损坏了，所以我就修复了闪存的使用方式。 另一点需要注意的是，有时这种情况会在几个月后发生，有时则会在一年后发生。另外，我还有一些设备已经安装了一年半以上，目前运行正常。 另外，我尝试使用 usbdm 对该设备进行内存转储，并尝试读取相同的地址，有时读取正常，有时返回 ARM 事务错误。 有人遇到过类似的情况吗？ Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time 谢谢你的回复 我会调查一下，因为这个问题发生的时间恰好与内存读取命令的时间重合。虽然有一个引脚在不应该置为高电平的时候置为高电平。该引脚初始化为低电平输出。 也就是说，在调试过程中，有没有什么原因可以解释为什么它会在这些函数处暂停？在读取命令之前，ASerialLDD2_Init() 仅在 PE_low_level_init() 中被调用。 我正在使用PE Micro多链路进行调试。 Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time 谢谢你的回复 我会调查一下，因为这个问题发生的时间恰好与内存读取命令的时间重合。虽然有一个引脚在不应该置为高电平的时候置为高电平。该引脚初始化为低电平输出。 也就是说，在调试过程中，有没有什么原因可以解释为什么它会在这些函数处暂停？在读取命令之前，ASerialLDD2_Init() 仅在 PE_low_level_init() 中被调用。 我正在使用PE Micro多链路进行调试。 Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time 你好@Rigolon ， 感谢你的帖子。 我认为这更像是 Flash 操作相关的故障或 Flash 内容损坏问题，而不是 ASerialLDD2_Init 或 IntFlashLdd1_Erase 本身的问题。RM 指出，如果 MCU 在受到活动的 Flash 命令操作时读取 FTFE 资源，则会设置 FSTAT[RDCOLERR]，并且无法保证读取的数据。 您可以参考AN4835 ，其中也提到：“擦除或编程命令的中断会导致闪存内容损坏。中断可能包括RESET、断电或与处理器上运行的代码发生冲突。这与以下观察结果相符：读取同一地址有时会成功，有时会返回 ARM 事务错误：如果 Flash 区域损坏或处于不确定状态，读取它可能会触发总线故障；在类似情况下，擦除受影响的扇区，或在必要时进行批量擦除，用于恢复 Flash 阵列。请参阅“已解决：查找内部 Flash MK22FX512VLH12 的损坏 - NXP 社区”了解更多详情。 希望对您有所帮助。 BR 塞莱斯特 Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time 失败率如何？如果失败率高于 50%，请提供错误日志以便进一步分析。 同时，您的应用程序是否需要频繁地对内部闪存进行编程和擦除？ Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time 你好@Rigolon ， 感谢您提供的更多细节。如果调试器在没有断点的情况下在 ASerialLDD2_Init 或 IntFlashLdd1_Erase 处停止，则强烈表明发生了故障（例如 HardFault 或 BusFault），而不是表示执行实际上正常到达了这些函数。一个可能的原因是 Flash 的向量表区域损坏，如果故障处理向量损坏，MCU 可能会跳转到错误的地址，而该地址恰好落在 PE 生成的函数附近。 您可以查看 HFSR、CFSR、BFAR 和 MMFAR 寄存器。 您还可以参考“如何在 ARM Cortex-M MCU 上调试 HardFault | 中断”中的方法，来验证它是否确实是 HardFault。 希望对您有所帮助。 BR 塞莱斯特

NXP SR040 峰值功耗 您好，SR040的峰值功耗是多少？能否提供一下发送/接收/空闲时间的详细数据？ Re: NXP SR040 Peak Power Consumption 你好， 希望你一切都好。很抱歉给您带来不便，但由于该产品的信息受保密协议（NDA）约束，因此不对外公开。 如需了解有关该芯片的更多信息，请联系我们代理商网络|NXP中的一位代理商。或者，如果您有任何直接联系人曾帮助您获得此设备，请与他们联系。 如果您正在寻找有关我们 UWB 产品的信息，或者您对这项技术感兴趣，我建议您查看我们合作伙伴（ Trimension UWB 合作伙伴）提供的这些开发套件和模块。 如果您对这些套件/模块感兴趣，您需要直接与他们联系，了解流程以及他们能够提供的支持，因为这项技术的支持途径是通过他们。 文档和软件由相应的UWB模块合作伙伴分发。选择模块后，您将被引导至我们合作伙伴的页面，您可以在该页面访问数据表、应用笔记和所需的启用信息。 此致， 里卡多

エラーが発生した際にS32K322レジスタを表示できません NXPテクノロジーチームの皆さん、こんにちは。 私のプロジェクトの現在のソフトウェアバージョンは、一定時間実行すると不具合が起きます。しかし、レジスタを表示しようとすると表示できず、シミュレーションも切断されています。ラウトバッハ氏のスクリーンショットを以下に添付します。 チップ用の3.3Vおよび1.5V電源はすべて正常で、異常な波形は見られないことを確認済みです。 私の状況は、以前の投稿（https://community.nxp.com/t5/S32K/S32K3-core-power-down-error-amp-running-bus-error/m-p/1853122）と似ているようです。 この問題のトラブルシューティングや解決方法を教えていただけませんか?RTDのバージョンはSW32K3_S32M27x_RTD_4.4_4.0.0_P24_D2405で、EB Tresos AUTOSARに設置されています。 Johnson97_0-1786334605174.jpeg

发生错误时，S32K322 无法查看寄存器 恩智浦科技团队，您好！ 我的项目当前软件版本运行一段时间后会出现故障。但是，当我尝试查看寄存器时，却无法查看，并且仿真已断开连接。劳特巴赫的截图附在下面。 我已经检查过芯片的 3.3V 和 1.5V 电源，它们都正常，没有出现异常波形。 我的情况似乎与之前的帖子类似。@https://community.nxp.com/t5/S32K/S32K3-core-power-down-error-amp-running-bus-error/m-p/1853122 请问如何排查并解决这个问题？RTD 版本为 SW32K3_S32M27x_RTD_4.4_4.0.0_P24_D2405，位于 EB Tresos AUTOSAR 中。 Johnson97_0-1786334605174.jpeg

S32DS K116 コンパイルの問題 こんにちは、NXPのエンジニアさん！ MCSPTE1AK116 は初めてです。MCSPTE1AK116-SW、S32K11x_AMMCLIB_RTM_1_1_45_BIN、S32DS-IDE-ARM_2.2.2_D2312、および FMASTERSW32 をインストールしました。MCSPTE1AK116_PMSM_FOC_1Sh サンプルプロジェクトを S32DS にインポートしてコンパイルしました。その後、.srec ファイルをドライブ E に直接コピーし、電源を入れ直した後、FreeMaster を使用して接続して実行しました。通信は正常に行われ、指定された速度で動作しましたが、数秒後に停止し、PDB0 エラーが報告されました。SW ディレクトリから元の .srec ファイルをドライブ E に直接コピーすると、正常に動作しました。コンパイル設定に何か問題があるのでしょうか？ Re: S32DS K116编译问题 こんにちは、ロビンさん。 我安装了S32 Design Studio (S32DS) for ARM 2.2 UP1和UP2 也安装了S32K1xx 3.0.3用のS32ソフトウェア開発キット(SDK) 図のように、我下了老的S32K11X_AMMCLIB_RTM_1_1_37_BIN、また不行、 我找不到S32K11X_AMMCLIB_RTM_1_1_29_BIN下載链接，你能出版一个给我试そして、私たちの 3 つの工程は、PMSM_FOC_1Sh 工程のみが不稼働と判断され、さらに 2 つの工程は問題がないと判断されました。 7a6c7c4ef61e9213d789cace0810a496.png7a6c7c4ef61e9213d789cace0810a496.png7a6c7c4ef61e9213d789cace0810a496.png7a6c7c4ef61e9213d789cace0810a496.png7a6c7c4ef61e9213d789cace0810a496.png7a6c7c4ef61e9213d789cace0810a496.png   Re: S32DS K116编译问题 こんにちは 元のフォルダにあるテストファイル（.srec）は正常に動作するが、コンパイル済みのファイル（.srec）でエラーが発生する場合は、コンパイル済みのファイルも実行できるはずです。 したがって、 S32K11x 用の Automotive Math and Motor Control Library Setの古いバージョンをダウンロードすることをお勧めします。たとえば、 MCSPTE1AK116-SWのインストール手順で説明されているバージョンS32K11X_AMMCLIB_RTM_1_1_29_BIN などです。 S32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.png MCSPTE1AK116_ReleaseNotes.txt ファイルには、このプロジェクトが以下のバージョンに基づいて開発されたことが示されています。 開発キットアプリケーションは、以下のIDE、ドライバ、ツールを使用して構築およびテストされました。 ===================================================================================== - ARM 2.2 用 S32 Design Studio (S32DS) - S32K1xx 用 S32 ソフトウェア開発キット (SDK) 3.0.3 - FreeMASTER 3.1.4.5 S32K1 SDKのバージョン3.0.3がインストールされていることを確認してください。 よろしくお願いします、 ロビン 回复： S32DS K116编译问题 これは奇妙な問題です。付属のBLDC_6StepsとPMSM_FOC_2Shプロジェクトを使ってプロジェクトを直接ダウンロードすることはできますし、コンパイル後にダウンロードすることもできます。ただ、コンパイル後にダウンロードできないのです。 Re: S32DS K116编译问题 こんにちは、ロビンさん 理由は分かりませんが、すべての.srecファイルが実行できません...あなたのプログラムを試すことができません。 評価委員会を通過する方法を教えていただけますか？ 今月、S32K116EVBを購入しました。外観を確認するにはどうすれば良いでしょうか？ Re: S32DS K116编译问题 こんにちは 1. 他のバージョンを削除し、S32K11x_AMMCLIB_v1.1.29のみをインストールしました。 2. 現在、テスト用のハードウェアプラットフォームが手元にないため、S32K11x_AMMCLIB_v1.1.29 をベースにしたバージョンを添付しました。コンパイル済みの.SRECファイルをテスト用に提供しました。（プライベートメッセージで送信済みです。） 3. 正常に動作する場合は、お客様のアカウント用にソフトウェアチームにS32K11x_AMMCLIB_v1.1.29をリクエストします。バージョンソフトウェア。 4. ハードウェアの違いも確認する必要があるかもしれません。お使いのS32K116EVBはS32K116EVB2Q048でしょうか？S32K116EVB-Q048という以前のバージョンもありました。 Re: S32DS K116编译问题 以下はS32K116EVB-Q048という旧バージョンで、モーターキットには対応していません。最も顕著な違いは、ソケット（J5）が1列少ないことです。 S32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.png 以下はS32K116EVB2Q048のスクリーンショットです。 S32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.png まずキットを取り外し、S32K116EVBのみをテストすることをお勧めします。また、 P&E Recovery Utilityツールを使用してCPUを停止し、新しいプログラムをダウンロードすることをお勧めします。 Re: S32DS K116编译问题 故障波形を更新します。 TimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpeg Re: S32DS K116编译问题 .srecファイルをダウンロードできるものの、モーター制御プログラムの実行に問題がある場合は、P&Eは必要ありません。リカバリユーティリティ。このツールは、新しいプログラムをダウンロードできない場合に使用します。 確認のため、FreeMasterのインターフェースに表示されている過電流エラーメッセージのスクリーンショットを提供していただけますでしょうか？ 公式サンプルプログラムに含まれる.srecファイルはすべて正常に動作しますが、3つの公式プロジェクトを再コンパイルした後、モーターの動作に問題が発生しているのですね？私が提供した、S32K11x_AMMCLIB_v1.1.29をベースにコンパイルした.srecファイルを試してみましたか？ Re: S32DS K116编译问题 こんにちは、ロビンさん 先日、他のことで忙しかったんです。私の型番はS32K116EVB2Q048です。 以前は、ダウンロードした公式サンプル.srecファイルはすべて正常に動作していました。しかし、今回ダウンロードした3つの公式プロジェクトはすべてモーターの動作に問題が発生しています。具体的には、ダウンロードと通信は問題なく行われるのですが、速度を設定してモーターを起動すると、2回ビープ音が鳴り、その後過電流エラーが発生します。この場合、CPUを停止させるためにP&E Recovery Utilityツールをダウンロードし、新しいプログラムをダウンロードする必要があるのでしょうか？ Re: S32DS K116编译问题 J9、J10、J11は位置12にあり、これはPMSMの位置である。 TimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpeg Re: S32DS K116编译问题 こんにちは、ロビンさん 現在、私がコンパイルした.srecファイルであろうと公式のサンプルであろうと、モーター起動時に2回のビープ音が鳴った後に過電流エラーが報告されます。 以下に故障インターフェースを示し、外部デバイスによって検出された始動電流も以下に示します。 TimLIANG_0-1787020428889.pngTimLIANG_0-1787020428889.png TimLIANG_1-1787020447511.pngTimLIANG_1-1787020447511.png

S32K358 SEMA42 demo Hello! I need to use the Gate register in the SEMA42 module to write to its GTFSM field. I need to enable SEMA42 operations in mcal to ensure that the GTFSM field can be written to and read from correctly during use. Could you please provide a demo of inter-core communication using SEMA42? Thank you! Re: S32K358 SEMA42 demo Hi @liyongfeng, To use SEMA42, you need to configure XRDC first. By default, only one domain is active — domain 0. If you want a core to lock a gate, for example, under domain 1 (GTFSM = 0010b, meaning domain 1 holds the lock), you must enable domain 1 in XRDC. XRDC is configured via the RM RTD MCAL driver. So either use the MCAL RM driver, or enable the relevant XRDC configuration in your custom code. For a reference, see the RTD example: Rm_Example_All_S32K358. It demonstrates how to configure both XRDC and SEMA42. danielmartynek_0-1786518348453.png Regards, Daniel

i.MX95基板上にMAX96717/MAX96724を搭載したOX05B1S GMSL2カメラ こんにちは、NXP チームの皆様、 Linuxを動かすi.MX95 19x19 EVKでOX05B1S GMSL2カメラをテストしています。 設定： OX05B1S カメラ - MAX96717 - GMSL2 - MX95MBDESER01 MAX96724 - i.MX95 MX95MBDES10001キットに付属のOX03C10カメラは、同じデシリアライザボードで動作し、cam -lコマンドで確認できます。 しかし、MAX96717を搭載したOX05B1Sカメラはcam -lコマンドではリストに表示されません。 BSPにはox05b1s.koが含まれています。max96724.ko、max96717_lib.ko、およびOX05B1S DTBファイル。 OX05B1S DTBは直接MIPI接続について記述しているようで、一方OX03C10 DTBにはMAX96724トポロジーが含まれている。 NXPはこの構成に対応したリファレンスデバイスツリー構成を提供していますか？ OX05B1S - MAX96717 - MAX96724 - i.MX95 もしなければ、このOX05B1S GMSL2カメラをMX95MBDESER01ボードで使うにはどんな変更が必要か教えていただけますか? よろしくお願いします。 よろしくお願いします、 タルン Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 ご説明いただきありがとうございます。現在のBSPは公式には直接MIPI-CSIインターフェースを通じてOX05B1Sをサポートしており、OX03C10にはMAX96717/MAX96724 SerDesサポートが提供されていると理解しています。 OX05B1SカメラモジュールとMAX96717シリアライザーをMAX96724デシリアライザー経由でi.MX95に接続しています。GMSL2リンクは正常にロックされ、MAX96717はリモートI2Cチャネルを通じてアクセス可能です。 OX05B1S + MAX96717 + MAX96724は現在BSPでサポートされていないため、カスタムドライバー/デバイスツリー統合が必要になるのでしょうか?あるいは、この組み合わせに対応するリファレンス実装やパッチは存在しますか？ Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 現在のBSPは、miniSASコネクタMIPI_CSI IMX95ボードを直接接続するためのOX05B1Sをサポートしています。Omnivision OX03C10 センサは、以下のベンダーのシリアライザー/デシリアライザーソリューションを用いて i.MX 95でサポートされています。 • アナログ・デバイセズ:MAX96717/MAX96724 • テキサス・インスツルメンツ:DS0UB953/DS0UV960 詳細については、第6.1.3章を参照してください。カメラのリファレンス・マニュアル https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 はい、ドライバーのmx95mbcam.cを参照してくださいカメラをOX03C10使うので、もしカメラを変えたいなら、このドライバーを完全に変えるべきです。 https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/media/i2c/mx95mbcam.c