PFE 无法在 A53 中作为奴隶初始化 你好，我希望 PFE Slave 在我的自定义板上的 A53 内核上运行。 但驱动程序启动过程并不成功。 M7 使用 HIF0 作为主设备，A53 使用 HIF3。 内核日志如下 [ 10.511555] pfeng-slave 46000000.pfe_slave：PFEng 以太网驱动程序正在加载 ... [ 10.511561] pfeng-slave 46000000.pfe_slave：版本：1.8.0 [ 10.511567] pfeng-slave 46000000.pfe_slave：驱动程序提交哈希值：M4_DRIVER_COMMIT_HASH [ 10.511573] pfeng-slave 46000000.pfe_slave：支持多实例：SLAVE/mdetect=on [ 10.511579] pfeng-slave 46000000.pfe_slave：编译：10.2.1 20201103 [ 10.511849] pfeng-slave 46000000.pfe_slave：等待 PFE 控制器启动 ... [ 10.511875] pfeng-slave 46000000.pfe_slave：检测到 PFE 控制器启动 [ 10.511881] pfeng-slave 46000000.pfe_slave：Cbus addr 0x46000000 size 0x1000000 [ 10.511892] pfeng-slave 46000000.pfe_slave：IHC 通道：3 [ 10.511899] pfeng-slave 46000000.pfe_slave：主 IHC 通道：0 [ 10.511913] pfeng-slave 46000000.pfe_slave：netif name: pfe0sl [ 10.511921] pfeng-slave 46000000.pfe_slave：DT mac 地址：00:04:9f:be:ff:00 [ 10.511932] pfeng-slave 46000000.pfe_slave：netif(pfe0sl) linked phyif：0 [ 10.511938] pfeng-slave 46000000.pfe_slave：netif (pfe0sl) 模式：std [10.512765] pfeng-slave 46000000.pfe_slave：netif(pfe0sl) HIFs: count 1 map 08 [ 10.512788] pfeng-slave 46000000.pfe_slave：HIF 通道屏蔽：0x0008 [ 10.512915] pfeng-slave 46000000.pfe_slave：分配了保留内存节点 pfebufs@83600000 [ 10.512944] pfeng-slave 46000000.pfe_slave：PFE CBUS p0x00000000396a8862 映射 @ v0xffffffc00c000000 [ 10.512962] pfeng-slave 46000000.pfe_slave：Wait for Master UP ... [ 10.512968] pfeng-slave 46000000.pfe_slave：Detected Master UP [ 10.512986] pfeng-slave 46000000.pfe_slave：HIF3 处于清洁状态 [ 10.513181] pfeng-slave 46000000.pfe_slave：HIF0 未配置，跳过 [ 10.513188] pfeng-slave 46000000.pfe_slave：HIF1 未配置，跳过 [ 10.513193] pfeng-slave 46000000.pfe_slave：HIF2 未配置，跳过 [ 10.513517] pfeng-slave 46000000.pfe_slave：已启用 HIF3 [ 10.513529] pfeng-slave 46000000.pfe_slave：HIF3 启动 [ 10.513536] pfeng-slave 46000000.pfe_slave：IDEX-slave @ master-interface 6 [ 10.513547] pfeng-slave 46000000.pfe_slave：IHC 客户端已注册 [ 11.528401] pfeng-slave 46000000.pfe_slave：IDEX 请求 0 超时，重传 10 次 [ 11.528413] pfeng-slave 46000000.pfe_slave：RPC 传输失败： 110 [ 11.528420] pfeng-slave 46000000.pfe_slave：IDEX：RESET 请求不成功 [110] [11.528427] pfeng-slave 46000000.pfe_slave：IDEX: 已使用 v1（传统）协议 [ 11.528433] pfeng-slave 46000000.pfe_slave：已在 HIF3 上安装 IDEX RPC [ 11.528477] pfeng-slave 46000000.pfe_slavepfe0sl (未初始化)：Subscribe to HIF3 [ 11.528490] pfeng-slave 46000000.pfe_slave：MDIO 总线 0 已禁用：在 DT [11.528497] 中找不到 pfeng-slave 46000000.pfe_slave：MDIO 总线 1 已禁用：在 DT [11.528502] 中找不到 pfeng-slave 46000000.pfe_slave：MDIO 总线 2 已禁用：在 DT [11.528502] 中找不到 pfeng-slave 46000000.pfe_slavepfe0sl (未初始化)：Host LLTX disabled [ 12.528776] pfeng-slave 46000000.pfe_slave：IDEX 请求 1 超时，重传 10 次 [ 12.528786] pfeng-slave 46000000.pfe_slave：RPC 传输失败： 110 [ 12.528793] pfeng-slave 46000000.pfe_slave：IDEX：RESET请求不成功 [110] [12.528804] pfeng-slave 46000000.pfe_slave：ERR：(DRIVER) 事件 1 - 驱动程序运行时出错：[pfe_phy_if_slave.c:66]无法锁定接口 DB: 110 [ 13.529070] pfeng-slave 46000000.pfe_slave：IDEX 请求 2 超时，重传 10 次 [ 13.529086] pfeng-slave 46000000.pfe_slave：RPC 传输失败： 110 [ 13.529093] pfeng-slave 46000000.pfe_slave：IDEX：RESET 请求不成功 [110] [13.529104] pfeng-slave 46000000.pfe_slave：ERR：(DRIVER) 事件 1 - 驱动程序运行时出错：[pfe_phy_if_slave.c:568]PFE_PLATFORM_RPC_PFE_PHY_IF_ENABLE 失败: 110 [ 14.529351] pfeng-slave 46000000.pfe_slave：IDEX 请求 3 超时，重传 10 次 [ 14.529364] pfeng-slave 46000000.pfe_slave：RPC 传输失败： 110 [ 14.529370] pfeng-slave 46000000.pfe_slave：IDEX：RESET 请求不成功 [110] [14.529380] pfeng-slave 46000000.pfe_slave：ERR：(DRIVER) 事件 1 - 驱动程序运行时出错：[pfe_phy_if_slave.c:79]无法解锁接口 DB： 110 [ 14.529396] pfeng-slave 46000000.pfe_slavepfe0sl （未初始化）：ERR: (DRIVER) event 1 - Driver runtime error：[pfeng-netif.c:1130] 驱动程序运行时出错。无法启用 HIF3 金贵宾 Re: PFE can not be initialized in A53 as slaver 你好，@TimSamus、 这是一个相当老的帖子，因此我们用来跟踪状态的工具不再跟踪它。如果您愿意，可以创建一个新的帖子，详细说明您的问题，我或我团队中的某个人会帮助您。 谢谢  Re: PFE can not be initialized in A53 as slaver 你好，我也遇到了类似的问题："在 arRxBdWbRing 中，desc_ens 总是"1" "。您能分享一下您是如何解决这个问题的吗？ Re: PFE can not be initialized in A53 as slaver 你好，@tommychen1986、 我进一步研究了 PFE 与 M7 和 A53 的主从配置，找到了以下文档： S32G_PFE_Master_Slave_Simple_Demo_V2_2023_5_23_Eng.pdf 以及 PFE_S32G_A53_LNX_UserManual.pdf，您可以在 BSP43 的下载页面找到： 我在其中发现了以下内容： 在简单演示的第 8 页第 3.4 节中，描述了 M7 所需的配置，请查看链接中的整个章节，因为有好几页都有描述。 在《LNX 用户手册》第 12 页，您可以看到编译 pfeng 所需的选项： 这是从属配置的版本命令的示例： make KERNEL_src=/home/bsp-43/build_s32g399ardb3/tmp/work-shared/s32g399ardb3/kernel-source KERNELDIR=/home//bsp-43/build_s32g399ardb3/tmp/work-shared/s32g399ardb3/kernel-source MDIR=/home/bsp-43/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/pfe-slave/1.0.0-r0/git/sw/linux-pfeng -C /home/bsp-43/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/pfe-slave/1.0.0-r0/git/sw/linux-pfeng V=1 drv-build PFE_CFG_MULTI_INSTANCE_SUPPORT=1 PFE_CFG_PFE_MASTER=0 这可能取决于你使用的是手动编译还是 Yocto 构建，如果你使用的是最后一个，请查看 BSP43 用户手册： 请考虑这个简单的演示使用了相当旧的 BSP (电路板支持包) 版本，并且某些选项可能已被弃用或更改。不过，就我在日志中看到的情况而言，我现在的结论是，这是 M7 配置的问题。 还请检查 MCAL PFE 驱动程序附带的 MasterProject_RDB2，将其与我从您的截图中看到的选项进行比较，我发现了一些不同之处。首先尝试在 M7 中使用您的 Linux 配置运行示例，以检查 M7 上的配置是否能解决初始化问题，这样做也很有价值。 如果这些配置有用，请告诉我。 Re: PFE can not be initialized in A53 as slaver 你好alejandro_e、 我使用了 HIF3，但还是得到了同样的错误信息。 Re: PFE can not be initialized in A53 as slaver 你好，@tommychen1986、 你能用 " nxp 进行测试吗，pfeng-ihc-channel = ; "，这是使用默认的 Linux 设备树配置并使用 HIF3 作为 M7 AUTOSAR 应用程序中的通用接口？正如我在过去的留言中所建议的那样？如果是这样，你能分享测试结果吗？ 谢谢您！ Re: PFE can not be initialized in A53 as slaver 你好，@tommychen1986、 请帮我完成这两项测试： 1 - 执行此命令并共享输出结果： root@s32g399ardb3:~# find /lib/modules/$(uname -r) -name '*.ko' | grep "pfe" /lib/modules/6.6.52-rt43-g1a29a32be610/kernel/drivers/net/ethernet/nxp/pfe/pfeng-slave.ko /lib/modules/6.6.52-rt43-g1a29a32be610/kernel/drivers/net/ethernet/nxp/pfe/pfeng.ko root@s32g399ardb3:~# 2- 使用 HIF3 代替 HIF0 作为公共接口： 如果行为有所改变，请告诉我。 谢谢！ Re: PFE can not be initialized in A53 as slaver 你好，Alejandro_e、 我的配置如下。 M7 A53 Re: PFE can not be initialized in A53 as slaver 你好，@tommychen1986、 非常感谢你提供的信息。能否分享一下您在 M7 内核的 PFE 中应用的配置截图？我假设你会使用 M7 作为 PFE 的主设备，在这种配置中，A53 将等待 M7 对 PFE 进行初始化。 另外，你能分享一下你在电路板支持包方面所做的配置吗？这是将 A53 配置为从属设备。 非常感谢。 Re: PFE can not be initialized in A53 as slaver 你好 alejandro_e、 抱歉最近才回复。 我的答复如下 您使用的是 S32G2 还是 S32G3？ --------------S32G274A 您使用的是定制主板还是 RDB/EVB 恩智浦主板？ ------------------自定义板 您正在使用的 BSP (电路板支持包) 版本 --------------BSP43 您正在使用的 Linux 内核 -------------- 内核版本是 5.15.167 启动类型（QSPI、eMMC、SD 或串行） --------------ATF in Qspi Flash、kernel and rootfs in emmc 热电阻版本 --------------4.0.1（已注释"Mcu_GetSharedIpSetting" " Mcu_SetSharedIpSetting" " Mcu_TriggerHardwareUpdate" 在 M7 PFE 驱动程序的 hal.h 中调用函数 ）。 您使用的是 M7 操作系统，还是裸机项目？ -------------- autosar OS PFE FW 版本 --------------1.10.0 PFE M7 驱动程序版本 --------------1.5.0 您使用的 pfeng 内核模块的日志版本是 1.8.0，对吗？ --------------pfeng 版本为 1.8.0 您过去是否成功使用过 PFE 驱动程序中已有的主从示例（适用于 Linux 和 M7）？ --------------No，我只使用 PFE 驱动程序，因为我的母机是 A53。这是我第一次使用 "主从 "功能。 Re: PFE can not be initialized in A53 as slaver 你好，@tommychen1986、 为了更好地了解您的设置情况，请您提供以下信息： 您使用的是 S32G2 还是 S32G3？ 您使用的是定制主板还是 RDB/EVB 恩智浦主板？ 您正在使用的 BSP (电路板支持包) 版本 您正在使用的 Linux 内核 启动类型（QSPI、eMMC、SD 或串行） 热电阻版本 您使用的是 M7 操作系统，还是裸机项目？ PFE FW 版本 PFE M7 驱动程序版本 您使用的 pfeng 内核模块的日志版本是 1.8.0，对吗？ 您过去是否成功使用过 PFE 驱动程序中已有的主从示例（适用于 Linux 和 M7）？ 提前感谢您提供的信息。 Re: PFE can not be initialized in A53 as slaver HI 调试完成后，我发现 A53 发送的 IDEX RESET 命令已被 M7 收到，而且 M7 也向 A53 发送了回复。但是，A53 没有收到这个 ack。（没有msg in ihc_rx_fifo)

PFEはA53でスレーブとして初期化できません こんにちは。カスタムボード上のA53コアでPFEスレーブを動作させたいのですが。 しかし、ドライバの初期化プロセスは成功しませんでした。 M7はHIF0をマスターとして使用し、A53はHIF3を使用します。 カーネルログは以下のとおりです。 [ 10.511555] pfeng-slave 46000000.pfe_slave:PFEngイーサネットドライバをロードしています... [ 10.511561] pfeng-slave 46000000.pfe_slave:バージョン: 1.8.0 [ 10.511567] pfeng-slave 46000000.pfe_slave:ドライバコミットハッシュ: M4_DRIVER_COMMIT_HASH [ 10.511573] pfeng-slave 46000000.pfe_slave:マルチインスタンスサポート: SLAVE/mdetect=on [ 10.511579] pfeng-slave 46000000.pfe_slave:作成者: 10.2.1 20201103 [ 10.511849] pfeng-slave 46000000.pfe_slave:PFEコントローラーが起動するまで待機します... [ 10.511875] pfeng-slave 46000000.pfe_slave:PFEコントローラーがUP状態を検出しました [ 10.511881] pfeng-slave 46000000.pfe_slave:Cbusアドレス 0x46000000 サイズ 0x1000000 [ 10.511892] pfeng-slave 46000000.pfe_slave:IHCチャネル：3 [ 10.511899] pfeng-slave 46000000.pfe_slave:マスターIHCチャネル：0 [ 10.511913] pfeng-slave 46000000.pfe_slave:ネットイフ名: pfe0sl [ 10.511921] pfeng-slave 46000000.pfe_slave:DT MACアドレス: 00:04:9f:be:ff:00 [ 10.511932] pfeng-slave 46000000.pfe_slave:netif(pfe0sl) リンクされたphyif: 0 [ 10.511938] pfeng-slave 46000000.pfe_slave:netif(pfe0sl) モード: std [ 10.512765] pfeng-slave 46000000.pfe_slave:netif(pfe0sl) HIFs: カウント 1 マップ 08 [ 10.512788] pfeng-slave 46000000.pfe_slave:HIFチャネルマスク: 0x0008 [ 10.512915] pfeng-slave 46000000.pfe_slave: 割り当てられた予約済みメモリノード pfebufs@83600000 [ 10.512944] pfeng-slave 46000000.pfe_slave:PFE CBUS p0x00000000396a8862 は v0xffffffc00c000000 にマッピングされています [ 10.512962] pfeng-slave 46000000.pfe_slave:マスターアップをお待ちください... [ 10.512968] pfeng-slave 46000000.pfe_slave:マスターUPを検出しました [ 10.512986] pfeng-slave 46000000.pfe_slave:HIF3はクリーンな状態です [ 10.513181] pfeng-slave 46000000.pfe_slave:HIF0が設定されていないため、スキップしました。 [ 10.513188] pfeng-slave 46000000.pfe_slave:HIF1が設定されていないため、スキップします。 [ 10.513193] pfeng-slave 46000000.pfe_slave:HIF2が設定されていないため、スキップします。 [ 10.513517] pfeng-slave 46000000.pfe_slave:HIF3が有効 [ 10.513529] pfeng-slave 46000000.pfe_slave:HIF3が始まった [ 10.513536] pfeng-slave 46000000.pfe_slave:IDEXスレーブ @ マスターインターフェース 6 [ 10.513547] pfeng-slave 46000000.pfe_slave:IHCクライアント登録済み [ 11.528401] pfeng-slave 46000000.pfe_slave:IDEXリクエスト0がタイムアウトしました。10回再送信しました。 [ 11.528413] pfeng-slave 46000000.pfe_slave:RPCトランスポートが失敗しました: 110 [ 11.528420] pfeng-slave 46000000.pfe_slave:IDEX: リセット要求が成功しませんでした [110] [ 11.528427] pfeng-slave 46000000.pfe_slave:IDEX: v1（レガシー）プロトコルを使用 [ 11.528433] pfeng-slave 46000000.pfe_slave:HIF3にIDEX RPCがインストールされました [ 11.528477] pfeng-slave 46000000.pfe_slavepfe0sl (未初期化): HIF3 を購読する [ 11.528490] pfeng-slave 46000000.pfe_slave:MDIOバス0が無効です: DTで見つかりません [ 11.528497] pfeng-slave 46000000.pfe_slave:MDIOバス1が無効になっています: DTで見つかりません [ 11.528502] pfeng-slave 46000000.pfe_slave:MDIOバス2が無効になっています: DTで見つかりません [ 11.528502] pfeng-slave 46000000.pfe_slavepfe0sl (未初期化): ホストLLTXが無効になっています [ 12.528776] pfeng-slave 46000000.pfe_slave:IDEXリクエスト1がタイムアウトしました。10回再送信しました。 [ 12.528786] pfeng-slave 46000000.pfe_slave:RPCトランスポートが失敗しました: 110 [ 12.528793] pfeng-slave 46000000.pfe_slave:IDEX: リセット要求が成功しませんでした [110] [ 12.528804] pfeng-slave 46000000.pfe_slave:エラー: (ドライバー) イベント 1 - ドライバー実行時エラー: [pfe_phy_if_slave.c:66]インターフェースDBをロックできません: 110 [ 13.529070] pfeng-slave 46000000.pfe_slave:IDEXリクエスト2がタイムアウトしました。10回再送信しました。 [ 13.529086] pfeng-slave 46000000.pfe_slave:RPCトランスポートが失敗しました: 110 [ 13.529093] pfeng-slave 46000000.pfe_slave:IDEX: リセット要求が成功しませんでした [110] [ 13.529104] pfeng-slave 46000000.pfe_slave:エラー: (ドライバ) イベント情報 1 - ドライバ実行時エラー: [pfe_phy_if_slave.c:568]PFE_PLATFORM_RPC_PFE_PHY_IF_ENABLE が失敗しました: 110 [ 14.529351] pfeng-slave 46000000.pfe_slave:IDEXリクエスト3がタイムアウトしました。10回再送信しました。 [ 14.529364] pfeng-slave 46000000.pfe_slave:RPCトランスポートが失敗しました: 110 [ 14.529370] pfeng-slave 46000000.pfe_slave:IDEX: リセット要求が成功しませんでした [110] [ 14.529380] pfeng-slave 46000000.pfe_slave:エラー: (ドライバ) イベント 1 - ドライバ実行時エラー: [pfe_phy_if_slave.c:79]インターフェースDBのロックを解除できません: 110 [ 14.529396] pfeng-slave 46000000.pfe_slavepfe0sl (未初期化): エラー: (ドライバ) イベント 1 - ドライバ実行時エラー: [pfeng-netif.c:1130]HIF3を有効にできません ゴールドVIP Re: PFE can not be initialized in A53 as slaver こんにちは、 @TimSamus さん。 これはかなり古い投稿なので、ステータスを追跡するために使用しているツールでは、もはやこの投稿を追跡していません。よろしければ、問題の詳細をすべて記載した新しい投稿を作成していただければ、私か私のチームの誰かがお手伝いいたします。 よろしくお願いします。 Re: PFE can not be initialized in A53 as slaver こんにちは、私も同様の問題に遭遇しました。「arRxBdWbRing では desc_ens が常に "1" になります」。どのように解決されたのか教えていただけますか？ Re: PFE can not be initialized in A53 as slaver こんにちは、 @tommychen1986 さん。 M7とA53を使用したマスタースレーブ構成でのPFEについてさらに調査したところ、以下のドキュメントが見つかりました。 S32G_PFE_Master_Slave_Simple_Demo_V2_2023_5_23_Eng.pdf また、BSP43のダウンロードページにあるPFE_S32G_A53_LNX_UserManual.pdfもダウンロードできます。 それらの中で、私は以下のことを発見しました。 簡易デモの8ページ、セクション3.4にM7に必要な設定が記載されています。複数ページにわたって説明されているため、リンク先のセクション全体をご確認ください。 LNXユーザーマニュアルの12ページには、pfengをコンパイルするために必要なオプションが記載されています。 これはスレーブ構成のビルドコマンドの例です。 make KERNEL_src=/home/bsp-43/build_s32g399ardb3/tmp/work-shared/s32g399ardb3/kernel-source KERNELDIR=/home//bsp-43/build_s32g399ardb3/tmp/work-shared/s32g399ardb3/kernel-source MDIR=/home/bsp-43/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/pfe-slave/1.0.0-r0/git/sw/linux-pfeng -C /home/bsp-43/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/pfe-slave/1.0.0-r0/git/sw/linux-pfeng V=1 drv-build PFE_CFG_MULTI_INSTANCE_SUPPORT=1 PFE_CFG_PFE_MASTER=0 これは、手動ビルドを使用しているか、Yoctoビルドを使用しているかによって異なります。後者を使用している場合は、BSP43ユーザーマニュアルを確認してください。 このシンプルなデモではかなり古いBSPバージョンを使用しているため、一部のオプションが非推奨になったり変更されたりしている可能性があることにご注意ください。しかし、ログを見る限り、現時点での私の結論は、M7の設定に問題があるということです。 MCAL PFEドライバに付属しているMasterProject_RDB2も確認し、あなたのスクリーンショットから確認できるオプションと比較してみたところ、いくつか違いが見つかりました。また、まずはM7上でLinux構成を使ってサンプルを実行し、その構成で初期化の問題が解決するかどうかを確認することも有益でしょう。 この設定が役に立ったかどうか教えてください。 Re: PFE can not be initialized in A53 as slaver こんにちは、 alejandro_eさん、 HIF3を使用してみましたが、それでも同じエラーメッセージが表示されます。 Re: PFE can not be initialized in A53 as slaver こんにちは、 @tommychen1986 さん。 以前のメッセージで提案したように、デフォルトのLinuxデバイスツリー構成で、M7 AUTOSARアプリケーションの共通インターフェースにHIF3を使用して、「nxp,pfeng-ihc-channel = ;」でテストできましたか？もしできたのであれば、テスト結果を共有していただけますか？ よろしくお願いします！ Re: PFE can not be initialized in A53 as slaver こんにちは、 @tommychen1986 さん。 この2つのテストについてご協力をお願いします。 1 - このコマンドを実行し、その出力を共有してください。 root@s32g399ardb3:~# find /lib/modules/$(uname -r) -name '*.ko' | grep "pfe" /lib/modules/6.6.52-rt43-g1a29a32be610/kernel/drivers/net/ethernet/nxp/pfe/pfeng-slave.ko /lib/modules/6.6.52-rt43-g1a29a32be610/kernel/drivers/net/ethernet/nxp/pfe/pfeng.ko root@s32g399ardb3:~# 2. 共通インターフェースにはHIF0ではなくHIF3を使用する。 動作に変化があった場合はお知らせください。 よろしくお願いします。 Re: PFE can not be initialized in A53 as slaver こんにちは、 alejandro_eさん、 私の設定は以下のとおりです。 M7 A53 Re: PFE can not be initialized in A53 as slaver こんにちは、 @tommychen1986 さん。 情報提供ありがとうございました。M7コアのPFEに適用している設定のスクリーンショットを共有していただけますか？M7をPFEのマスターデバイスとして使用することを想定しています。この構成では、A53はM7によるPFEの初期化を待機します。 また、BSP側で行った設定を共有していただけますか？具体的には、A53をスレーブとして設定するための設定です。 よろしくお願いします。 Re: PFE can not be initialized in A53 as slaver こんにちは、alejandro_eさん。 返信が遅くなって申し訳ありません。 私の回答は以下のとおりです。 S32G2とS32G3のどちらを使用していますか？ --------------S32G274A カスタムボードを使用していますか、それともNXPのRDB/EVBボードを使用していますか？ -------------- カスタムボード 使用しているBSPのバージョン --------------BSP43 使用しているLinuxカーネル カーネルバージョンは5.15.167です ブートタイプ（QSPI、eMMC、SDカード、またはシリアル） --------------ATFはQspi Flashに、カーネルとrootfsはemmcに格納 RTDバージョン --------------4.0.1（M7 PFEドライバのhal.hファイル内の「Mcu_GetSharedIpSetting」「Mcu_SetSharedIpSetting」「Mcu_TriggerHardwareUpdate」関数呼び出しをコメントアウト） 使用しているM7 OS、またはベアメタルプロジェクトの場合は -------------- AUTOSAR OS PFE FWバージョン --------------1.10.0 PFE M7ドライバーバージョン --------------1.5.0 ログから判断すると、使用しているpfengカーネルモジュールはバージョン1.8.0となっていますが、これは正しいでしょうか？ --------------pfengのバージョンは1.8.0です 過去に、PFEドライバ（Linux版とM7版の両方）に既に含まれているマスタースレーブ構成のサンプルを正常に使用できた経験はありますか？ --------------いいえ、私は PFE ドライバーを A53 のマスターとしてのみ使用しています。マスタースレーブとして使うのは今回が初めてです。 Re: PFE can not be initialized in A53 as slaver こんにちは、 @tommychen1986 さん。 お客様のシステム構成をより正確に把握するために、以下の情報をご提供いただけますでしょうか。 S32G2とS32G3のどちらを使用していますか？ カスタムボードを使用していますか、それともNXPのRDB/EVBボードを使用していますか？ 使用しているBSPのバージョン 使用しているLinuxカーネル ブートタイプ（QSPI、eMMC、SDカード、またはシリアル） RTDバージョン 使用しているM7 OS、またはベアメタルプロジェクトの場合は PFE FWバージョン PFE M7ドライバーバージョン ログから判断すると、使用しているpfengカーネルモジュールはバージョン1.8.0となっていますが、これは正しいでしょうか？ 過去に、PFEドライバ（Linux版とM7版の両方）に既に含まれているマスタースレーブ構成のサンプルを正常に使用できた経験はありますか？ 情報提供ありがとうございます。 Re: PFE can not be initialized in A53 as slaver ハイ デバッグの結果、A53 から送信された IDEX RESET コマンドが M7 に受信され、M7 も A53 に ack を送信していることがわかりました。しかし、A53 はこの ack を受信していません。(いいえ)ihc_rx_fifo 内のメッセージ)

i.MX8QXPでサイドバンドECCを使用し、40ビット幅の8ビットDDR3Lチップを5個搭載する。 私は、サイドバンドECCをサポートするi.MX8QXPプロセッサを使用しています。8ビットのDDR3L DRAMチップを5個使用し、ビット結合（連結）によってそれらを組み合わせ、合計40ビットのメモリ幅を形成することを検討しています。 私の質問は次のとおりです。 この40ビット構成（8ビットチップ×5）でサイドバンドECC機能は正しく動作しますか？それとも、このSoCのデータ幅、チップ数、またはサイドバンドECCの実装に関して何らかの制限がありますか？ 何かアドバイスや関連ドキュメントをご紹介いただければ大変ありがたいです。 よろしくお願いします。 Re: Using sideband ECC on i.MX8QXP with 5× 8-bit DDR3L chips in 40‑bit width ご返信ありがとうございます。サイドバンドECCには、合計40ビット（データ32ビット＋ECC8ビット）のDRAM幅が必要であることを理解しています。 私が提案する実装方法は、5つの8ビットDDR3Lチップ（16ビットチップ2つと8ビットチップ1つではなく）を使用し、ビットスプライシングによってそれらを結合して40ビットバスを形成することです（32ビットデータ用に4つのチップ、8ビットECC用に1つのチップ）。 私の質問は、サイドバンドECCが有効になっている場合、この5チップ×8ビット構成はi.MX8QXP DDRコントローラでサポートされているかどうかです。 添付の文書は既に確認しましたが、ハードウェアの実装に関する詳細については明確に記載されていませんでした。 Re: Using sideband ECC on i.MX8QXP with 5× 8-bit DDR3L chips in 40‑bit width こんにちは@yuyang12 サイドバンド ECC は 40 ビット (32 + 😎 i.MX 8QuadXPlus/8DualXPlus（DDR3L搭載）。 サイドバンドECCが有効になっている場合、ECC用に別のデータバスが使用されます。実際のDRAMデータ幅は、 現在の「DRAM_DATA_WIDTH」。有効にすると、DDR PHY インターフェース (DFI) のデータ幅が拡張され、追加の ECC に対応します。 バイト。1 ECCレーンごとに1 ECCバイトが追加されます。 詳細については、添付ファイルをご参照ください。 BR Re: Using sideband ECC on i.MX8QXP with 5× 8-bit DDR3L chips in 40‑bit width こんにちは@yuyang12 サイドバンドECCが有効になっている場合、i.MX8QXP DDRコントローラがサポートする5チップ×8ビット構成はサポートされません。 BR

i.MX95 max96724 2台のカメラの起動に関する問題 カメラを1台接続した場合は正常に起動しますが、同じモジュールのカメラを2台接続すると、すべてのカメラの起動に失敗します。 ログ情報: パイプラインを再生中に設定します... 新しい時計: GstSystemClock [0:00:31.239670305][973] INFO カメラ camera.cpp:1215ストリームの設定: (0) 1920x1536-YUYV/未設定 [0:00:31.250185346][972] エラー V4L2 v4l2_videodevice.cpp:1991/dev/video0[15:cap]: ストリーミングの開始に失敗しました: パイプが壊れています エラー: 要素 /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0 から: カメラの起動に失敗しました: パイプが壊れています 追加のデバッグ情報: ../src/gstreamer/gstlibcamerasrc.cpp(871): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: カメラ開始()エラーコード-32で失敗しました。 実行は0:00:00.012442958で終了しました。 パイプラインをNULLに設定中... パイプラインを解放する... Re: i.MX95 max96724 2 cameras bringup issue 2台のmax9295aカメラを同じMAX96724に接続した場合、フレーム同期モードのみが動作し、MAX96724での複数カメラ使用時にはフリーランモードは動作しません。 実際、MAX96724のデバッグにおける主な負荷は、カメラ（MAX9295a）とMAX96724間の設定にあるため、お客様はMaximからのサポートが必要になるかもしれません。Linuxが動作するためには、まずMAX96724のLOCKビットがエラーなく設定されていることを確認する必要があります。その後で初めて、MAX96724はMIPIビデオフレームをiMX95に出力できるようになります。 Re: i.MX95 max96724 2 cameras bringup issue max9295aを搭載したカメラはフリーランで動作し、フレーム同期は不要です。 cam -l、media-ctl、gst のログ情報： root@imx95evk:~# cam -l [0:01:54.016285137][1058] 警告 IPAManager ipa_manager.cpp:148'/media/jeffin/dev-work/nxp/codeaurora/libcamera/install/lib/libcamera/ipa' に IPA ファイルが見つかりませんでした。 [0:01:54.016504762][1058] INFO カメラ camera_manager.cpp:330libcamera v0.0.0+6194-lf-6.12.49-2.2.0-dirty (2026-04-24T21:03:02CST) [0:01:54.061756845][1059] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 8-0062': 静的プロパティにセンサー遅延が見つかりませんでした。未検証のデフォルト値を前提としています。 [0:01:54.061982970][1059] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x00980911の遅延要求ですが、デバイス/dev/v4l-subdev12によってコントロールが公開されていません。 [0:01:54.062069678][1059] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x009e0903の遅延要求ですが、デバイス/dev/v4l-subdev12によってコントロールが公開されていません。 [0:01:54.068941887][1059] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 9-0062': 静的プロパティにセンサ遅延が見つかりませんでした。未検証のデフォルト値を前提としています。 [0:01:54.069094470][1059] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x00980911の遅延要求ですが、デバイス/dev/v4l-subdev13によってコントロールが公開されていません。 [0:01:54.069152970][1059] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x009e0903の遅延要求ですが、デバイス/dev/v4l-subdev13によってコントロールが公開されていません。 [0:01:54.073940928][1059] INFO カメラ camera_manager.cpp:220パイプラインハンドラ simple にカメラ '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62' を追加します [0:01:54.074970262][1059] INFO カメラ camera_manager.cpp:220パイプラインハンドラ simple にカメラ '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62' を追加します 利用可能なカメラ： 1: 'mx95wecam' (/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62) 2: 'mx95wecam' (/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62) root@imx95evk:~# media-ctl -d /dev/media0 -p メディアコントローラーAPIバージョン6.12.49 メディアデバイス情報 ------------------------ ドライバー mxc-isi モデルFSLキャプチャメディアデバイス シリアル バス情報プラットフォーム:4ad50000.isi ハードウェアリビジョン 0x0 ドライバーバージョン 6.12.49 デバイストポロジー - エンティティ 1: クロスバー (パッド 13 個、リンク 10 個、ルート 8 個) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev0 ルート: 2/0 → 5/0 [アクティブ] 2/0 → 6/0 [アクティブ] 2/0 → 7/0 [アクティブ] 2/0 → 8/0 [アクティブ] 2/0 → 9/0 [アクティブ] 2/0 → 10/0 [アクティブ] 2/0 → 11/0 [アクティブ] 2/0 → 12/0 [アクティブ] pad0: シンク、接続必須 pad1: シンク、接続必須 pad2: シンク、接続必須 [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "4ac10000.syscon:formatter@20":1[有効、変更不可] pad3: シンク、接続必須 pad4: シンク、接続必須 <- "mxc_isi.output":0[有効、変更不可] pad5: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0[有効、変更不可] pad6: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.1":0[有効、変更不可] pad7: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.2":0[有効、変更不可] pad8: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.3":0[有効、変更不可] pad9: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.4":0[有効、変更不可] pad10: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.5":0[有効、変更不可] pad11: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.6":0[有効、変更不可] pad12: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.7":0[有効、変更不可] - エンティティ 15: mxc_isi.0（パッド2個、リンク2個、ルート0個） タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev1 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":5 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.0.capture":0 [有効、不変] - エンティティ 18: mxc_isi.0.capture (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video0 pad0: シンク <- "mxc_isi.0":1[有効、変更不可] - エンティティ 26: mxc_isi.1 (パッド 2 個、リンク 2 個、ルート 0 個) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev2 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":6 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.1.capture":0[有効、変更不可] - エンティティ 29: mxc_isi.1.capture（パッド1枚、リンク1つ） タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video1 pad0: シンク <- "mxc_isi.1":1[有効、変更不可] - エンティティ 37: mxc_isi.2（パッド2個、リンク2個、ルート0個） タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev3 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":7 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.2.capture":0 [有効、不変] - エンティティ 40: mxc_isi.2.capture (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video2 pad0: シンク <- "mxc_isi.2":1[有効、変更不可] - エンティティ 48: mxc_isi.3（パッド2個、リンク2個、ルート0個） タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev4 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":8 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.3.capture":0[有効、変更不可] - エンティティ 51: mxc_isi.3.capture（パッド1枚、リンク1つ） タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video3 pad0: シンク <- "mxc_isi.3":1[有効、変更不可] - エンティティ 59: mxc_isi.4（パッド2個、リンク2個、ルート0個） タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev5 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":9 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.4.capture":0 [有効、不変] - エンティティ 62: mxc_isi.4.capture (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video4 pad0: シンク <- "mxc_isi.4":1[有効、変更不可] - エンティティ 70: mxc_isi.5 (パッド 2 つ、リンク 2 つ、ルート 0 つ) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev6 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":10 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.5.capture":0 [有効、不変] - エンティティ 73: mxc_isi.5.capture (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video5 pad0: シンク <- "mxc_isi.5":1[有効、変更不可] - エンティティ 81: mxc_isi.6 (パッド 2 個、リンク 2 個、ルート 0 個) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev7 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":11 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.6.capture":0[有効、変更不可] - エンティティ 84: mxc_isi.6.capture（パッド1枚、リンク1つ） タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video6 pad0: シンク <- "mxc_isi.6":1[有効、変更不可] - エンティティ 92: mxc_isi.7 (パッド 2 個、リンク 2 個、ルート 0 個) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev8 pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1536 合成:(0,0)/1920x1536] <- "crossbar":12 [有効、不変] pad1: ソース [stream:0 fmt:YUV8_1X24/1920x1536 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "mxc_isi.7.capture":0 [有効、不変] - エンティティ 95: mxc_isi.7.capture (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 デバイスノード名 /dev/video7 pad0: シンク <- "mxc_isi.7":1[有効、変更不可] - エンティティ 103: mxc_isi.output (1 パッド、1 リンク) タイプ ノード サブタイプ V4L フラグ 0 pad0: ソース -> "crossbar":4 [有効、不変] - エンティティ 110: 4ac10000.syscon:formatter@20（パッド2個、リンク2個、ルート1個） タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev9 ルート: 0/0 → 1/0 [アクティブ] pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "csidev-4ad30000.csi":1[有効、変更不可] pad1: ソース [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":2 [有効、不変] - エンティティ 115: csidev-4ad30000.csi (パッド 2 つ、リンク 2 つ、ルート 1 つ) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev10 ルート: 0/0 → 1/0 [アクティブ] pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "max96724 3-0027":4 [有効] pad1: ソース [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "4ac10000.syscon:formatter@20":0[有効、変更不可] - エンティティ 120: max96724 3-0027 (パッド 6 個、リンク 3 個、ルート 4 個) タイプ V4L2 サブデバイス サブタイプ 不明 フラグ 0 デバイスノード名 /dev/v4l-subdev11 ルート: 0/0 → 4/0 [アクティブ] 1/0 → 4/1 [アクティブ] 2/0 → 5/2 [アクティブ] 3/0 → 5/3 [アクティブ] pad0: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] <- "mx95wecam 8-0062":0 [有効、不変] pad1: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] <- "mx95wecam 9-0062":0 [有効、不変] pad2: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] pad3: シンク [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] pad4: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 colorspace:raw] [stream:1 fmt:UYVY8_1X16/1920x1536 colorspace:raw] -> "csidev-4ad30000.csi":0[有効] pad5: ソース [stream:2 fmt:UYVY8_1X16/1920x1536 colorspace:raw] [stream:3 fmt:UYVY8_1X16/1920x1536 colorspace:raw] - エンティティ 129: mx95wecam 8-0062 (パッド 1、リンク 1、ルート 0) タイプ V4L2 サブデバイス サブタイプ センサー フラグ 0 デバイスノード名 /dev/v4l-subdev12 pad0: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "max96724 3-0027":0 [有効、不変] - エンティティ 133: mx95wecam 9-0062 (パッド 1、リンク 1、ルート 0) タイプ V4L2 サブデバイス サブタイプ センサ フラグ 0 デバイスノード名 /dev/v4l-subdev13 pad0: ソース [stream:0 fmt:UYVY8_1X16/1920x1536 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range クロップの境界:(0,0)/1920x1536 トリミング:(0,0)/1920x1536] -> "max96724 3-0027":1 [有効、不変] root@imx95evk:~# gst-launch-1.0 libcamerasrc camera-name=/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62 ! video/x-raw,width=1920,height=1536,format=YUY2 ! autovid eosink パイプラインを一時停止状態に設定しています... [0:03:53.646204235][1061] 警告 IPAManager ipa_manager.cpp:148'/media/jeffin/dev-work/nxp/codeaurora/libcamera/install/lib/libcamera/ipa' に IPA ファイルが見つかりませんでした。 [0:03:53.646456819][1061] INFO カメラ camera_manager.cpp:330libcamera v0.0.0+6194-lf-6.12.49-2.2.0-dirty (2026-04-24T21:03:02CST) [0:03:53.694436152][1068] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 8-0062': 静的プロパティにセンサー遅延が見つかりませんでした。未検証のデフォルト値を前提としています。 [0:03:53.694678277][1068] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x00980911の遅延要求ですが、デバイス/dev/v4l-subdev12によってコントロールが公開されていません。 [0:03:53.694785485][1068] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x009e0903の遅延要求ですが、デバイス/dev/v4l-subdev12によってコントロールが公開されていません。 [0:03:53.702510985][1068] WARN CameraSensor camera_sensor_legacy.cpp:502 'mx95wecam 9-0062': 静的プロパティにセンサー遅延が見つかりませんでした。未検証のデフォルト値を前提としています。 [0:03:53.702685235][1068] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x00980911の遅延要求ですが、デバイス/dev/v4l-subdev13によってコントロールが公開されていません。 [0:03:53.702777610][1068] エラー DelayedControls delayed_controls.cpp:87コントロールID 0x009e0903の遅延要求ですが、デバイス/dev/v4l-subdev13によってコントロールが公開されていません。 [0:03:53.708162819][1068] INFO カメラ camera_manager.cpp:220パイプラインハンドラ simple にカメラ '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@0/mx95wecam@62' を追加します [0:03:53.709431777][1068] INFO カメラ camera_manager.cpp:220パイプラインハンドラ simple にカメラ '/base/soc/bus@42000000/i2c@42540000/max96724@27/i2c-mux/i2c@1/mx95wecam@62' を追加します パイプラインは稼働中で、事前登録は不要です。 パイプラインは事前登録済みです... パイプラインを再生中に設定します... 新しい時計: GstSystemClock [0:03:53.713476694][1069] INFO カメラ camera.cpp:1215ストリームの設定: (0) 1920x1536-YUYV/未設定 [0:03:53.724398360][1068] エラー V4L2 v4l2_videodevice.cpp:1991/dev/video0[15:cap]: ストリーミングの開始に失敗しました: パイプが壊れています エラー: 要素 /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0 から: カメラの起動に失敗しました: パイプが壊れています 追加のデバッグ情報: ../src/gstreamer/gstlibcamerasrc.cpp(871): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: カメラ開始()エラーコード-32で失敗しました。 実行は0:00:00.013385834秒後に終了しました。 パイプラインをNULLに設定中... パイプラインを解放する... Re: i.MX95 max96724 2 cameras bringup issue はい、GMSL2リンクAとBは、max96724から2台のmax9295aカメラまでロックされています。   ドライバーログ: [ 9.882277] max96724 3-0027: GMSLリンクマスク: 設定済み = 0xf、ロック済み = 0x3 ドライバーコード: while (retries -- ) { locked_links = max96724_check_gmsl_links (priv); if (locked_links == priv->gmsl_link_mask) 壊す; usleep_range ( 2000 , 2500 ); } if (locked_links == 0 ) { regmap_write (priv->rmap, MAX96724_TOP_CTRL_PWR1 , RESET_ALL ); dev_err (dev, "3回の再試行後もGMSLリンクがロックされませんでした。中止します！ \n " ); 戻り値- ENODEV; } dev_info (dev, "GMSLリンクマスク: 設定済み = 0x %x 、ロック済み = 0x %x \n " 、 priv->gmsl_link_mask、locked_links); つまり、max96724とmax9295aの間でフレーム同期は必須なのでしょうか？ Re: i.MX95 max96724 2 cameras bringup issue カメラのセンサは何ですか？ドライバーの設定でフレーム同期モードになっていますか？一部のカメラはデフォルトでフリーランモードで動作します。この場合、単一のカメラはMAX96724に直接接続できますが、複数のカメラの場合は、MAX96724はフレーム同期モードで動作する必要があります。すべてのカメラは、MAX96724からSYNC信号を受信した後、ビデオフレームを送信する必要があります。 お客様が使用したmedia-ctlコマンドは何ですか？ Re: i.MX95 max96724 2 cameras bringup issue GMSLロックだけでは不十分で、MIPI CSI2出力にはビデオロックが必要です。複数のカメラを使用する場合、フレーム同期モードでのみビデオロックが発生します。 Re: i.MX95 max96724 2 cameras bringup issue コード： ./drivers/media/mc/mc-entity.c ret = entity->ops->link_validate(link); if (ret) { printk( 「リンク ' %s':% u -> ' %s':% u の検証に失敗しました: %d\n」 リンク->ソース->エンティティ->名前、 リンク→ソース→インデックス、 リンク->シンク->エンティティ->名前、 link->sink->index, ret); エラーへ移動; } Re: i.MX95 max96724 2 cameras bringup issue ドライバを追跡したところ、エラーログは以下のとおりでした。 <7>[ 26.481786] mx95wecam 8-0062: !!!!!! ドライバ/media/i2c/mx95wecam.c:L302mx95wecam_get_fmt() <4>[ 26.481797] !!!!!! drivers/media/mc/mc-entity.c:L875__media_pipeline_start() <4>[ 26.481802] リンク 'mx95wecam 8-0062':0 -> 'max96724 3-0027':0 は有効です <4>[ 26.481807] !!!!!! ドライバ/media/mc/mc-entity.c:L897__media_pipeline_start() <4>[ 26.481811] パッド 'mx95wecam 8-0062' を検証中:0 <4>[ 26.481815] !!!!!! ドライバ/media/mc/mc-entity.c:L836__media_pipeline_start() <4>[ 26.481819] !!!!!! drivers/media/mc/mc-entity.c:L897__media_pipeline_start() <4>[ 26.481824] パッド 'max96724 3-0027' を検証中:1 <4>[ 26.481827] !!!!!! ドライバ/media/mc/mc-entity.c:L836__media_pipeline_start() <4>[ 26.481832] !!!!!! drivers/media/mc/mc-entity.c:L863__media_pipeline_start() <7>[ 26.481839] mx95wecam 9-0062: !!!!!! drivers/media/i2c/mx95wecam.c:L302mx95wecam_get_fmt() <4>[ 26.481845] リンク 'mx95wecam 9-0062':0 -> 'max96724 3-0027':1 の検証に失敗しました: -32 <4>[ 26.481851] !!!!!! ドライバ/media/mc/mc-entity.c:L919__media_pipeline_start() <4>[ 26.481860] !!!!!! ドライバ/media/プラットフォーム/nxp/imx8-isi/imx8-isi-video.c:L1312mxc_isi_video_streamon() リンク A パイプ 0 カメラ mx95wecam 8-0062 はパイプリンク OK です。 リンクBパイプ1カメラmx95wecam 9-0062はパイプラインが故障しています。 それは配管の問題ですか？ Re: i.MX95 max96724 2 cameras bringup issue デフォルトのmx95mbcamドライバはox03c10+MAX96717と組み合わされていますが、お客様がコードを変更する必要があると思います。また、dts設定はどうなっていますか？ Re: i.MX95 max96724 2 cameras bringup issue はい、imx95-19x19-evk-ox03c10.dtsoとmx95mbcam.cを使ってコードを修正しました。 ちなみに、カメラを1台だけ接続しても問題ありません。 私の95年式EVKはA1バージョンのチップで、B0バージョンのチップではありません。 Re: i.MX95 max96724 2 cameras bringup issue DTSの設定ではカメラ4台のままにしておいても構いませんが、ポート0とポート1にそれぞれ2台のカメラを接続するだけで大丈夫です。

#S32K144 Cache write Test ##S32K144 support modifying cache values? Why is it that after I modify a value, reading the same address still returns the original value? Additionally, can the cache's parity bit be tested？thanks Re: #S32K144 Cache write Test Hi @joshua9264, It is technically possible to change the cache value through the LMEN registers. Let me create a simple test project. BR, Daniel Re: #S32K144 Cache write Test Hi @joshua9264, Have a look at this example: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K142-LMEM-Cache-v1-0-S32DS3-6-RTD300/ta-p/2368498 Regards, Daniel Re: #S32K144 Cache write Test OK，thank you，i will have a test

RNG用のSE052Fを備えたOpenSSLプロバイダ SE052FをFIPS準拠の乱数生成器として使用する必要がある。OpenSSLにはSE052Fを使用することを義務付けており、ひいてはopensslライブラリを使用するすべてのアプリケーションにも、乱数発生器としてSE052Fを使用することを義務付けています。 NXP MWのaccessManagerとOpenSSLプロバイダを使用する必要があることは理解しています。 使用しているのは SE-PLUG-TRUST-MW_04.07.01 です。 私は以下の指示に従いました： AN14028.pdf SE-PLUG-TRUST-MW_04.07.01/simw-top/doc/hostlib/hostLib/accessManager/doc/accessManager.html そして、こちらのREADME情報（ただし、このリポジトリは使用していません）： https://github.com/NXPPlugNTrust/se05x-openssl-provider accessManagerは以下のcmakeオプションを使用してビルドされました。 NXP_SE_MW_CONF_OPTS += -DWithSharedLIB=OFF -DPTMW_Host=Raspbian -DPTMW_SMCOM=T1oI2C -DPTMW_Applet=SE05X_C \ -DPTMW_FIPS=None -DPTMW_SE05X_Ver=07_02 -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS -DSE05X_EN_PIN=582 -DSE_RESET_LOGIC=0 \ -DPAHO_BUILD_SHARED=FALSE -DPAHO_BUILD_STATIC=TRUE 以下のcmakeオプションを使用してビルドされたOpenSSLプロバイダ： NXP_SE_MW2_CONF_OPTS += -DWithSharedLIB=ON -DPTMW_HostCrypto=OPENSSL -DPTMW_Host=Raspbian -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=None openssl.cnfを以下のように変更しました。 [provider_sect] nxp_prov = nxp_sect default = default_sect [nxp_sect] identity = nxp_prov module = /usr/lib/libsssProvider.so activate = 1 [default_sect] activate = 1 accessManagerが起動します。 Starting accessManager (Rev.1.1). Protect Link between accessManager and SE: YES. accessManager JRCPv1 (T1oI2C SE side) ****************************************************************************** Server: waiting for connections on port 8040. Server: only localhost based processes can connect. コマンドラインからopensslを使用して乱数生成を行うと、問題なく動作するようです。 # openssl rand -hex 64 sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 DUMMY_ATR=0x01.A0.00.00.03.96.04.03.E8.00.FE.02.0B.03.E8.00.01.00.00.00.00.64.13.88.0A.00.65.53.45.30.35.31.00.00.00. Replacing *_ATR by default (pre-cooked) ATR. ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 SM_EstablishPlatformSCP03Am (Entry) App :WARN :Using SCP03 keys from:'/tmp/SE05X/plain_scp.txt' (FILE=/tmp/SE05X/plain_scp.txt) SE051 connected. SM_EstablishPlatformSCP03Am (Exit); Status = 0x9000 sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_get_ctx_params sssprov-dbg: Enter - sss_rand_generate sssprov-flw: Get random data from SE05x Command 0x01 from client 5 SM_SendAPDUAm: smStatus = 0x9000 5f0f4d63e4ec771b8cfd46dd50c497b7e4e56e203ad5bc6eca9f8c28d23f39aa2d4a807915e3c60cf2e6a833794cb1208554f3e635811354eadd7b2c911c60da sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_teardown Received 0 byte from client 5 (Message Header Phase) . しかし、sshデーモンの起動に失敗します。 # /usr/sbin/sshd & sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 Pre-cooked response (rspAppletSelect) sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_get_ctx_params PRNG is not seeded Received 0 byte from client 5 (Message Header Phase) . [2]+ Done(255) /usr/sbin/sshd どんな助けでも大変ありがたいです。 Sam Re: OpenSSL Provider with SE052F for RNG こんにちは、 @sam123 さん。 現在、当社のプロバイダではOpensshのサポートはテストされていません。これはさらに分析する必要があり、変更が必要になるかもしれない。研究開発部門向けに内部チケットが作成され、彼らが分析を行う予定です。そこから何か新しい情報が入り次第、お知らせします。 お待ちいただきありがとうございました！ すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - 最後の投稿から7週間はThreadをフォローしますが、それ以降の返信は無視されます。 後日、関連する質問がある場合は、新しいThreadを作成し、閉じられた Threadを参照してください。 -------------------------------------------------------------------------------

Need Passive 125 kHz RFID Chip Recommendation Hello fellow developers, I’m looking for a recommendation for a passive 125 kHz RFID chip with the following requirements: Memory size: 2048 bits or higher Read/write capability Lock bit or another reliable write-protection mechanism Suitable for reliable production use Currently available / active production line Any recommendations for suitable NXP chips, alternatives, or compatible reader solutions would be greatly appreciated. Thanks in advance, Ben Sella Re: Need Passive 125 kHz RFID Chip Recommendation Hello @benSella, For new designs, the only LF RFID solution currently recommended in our portfolio is the HITAG µ /Advanced. Please note that this IC offers a maximum total memory capacity of 512 bits. BR Habib Re: Need Passive 125 kHz RFID Chip Recommendation Hello Habib, Thank you for your reply and recommendation. I’m afraid that this chip would not be suitable for our application, as the maximum memory capacity of 512 bits is too limited for our needs. We are specifically looking for a passive LF RFID solution with at least 2048 bits of memory, along with read/write capability and a reliable locking or write-protection mechanism. If NXP does not currently offer such a solution, I would still appreciate any recommendation you may have for a suitable alternative. Thank you again for your help. Best regards, Ben Sella Re: Need Passive 125 kHz RFID Chip Recommendation Hello @benSella, Sorry for taking a while to get back to you. Unfortunately, HITAG u/Advanced is the only recommended for new designs that supports the low-frequency (LF) RFID. We have some HF and UHF tags in our portfolio, I can suggest you a recommendation based on these tags in case you are interested. If so, could you provide me more details about your application? BR Habib

マカオバカラにおける短期的な利益と長期的な損失の根本的な理由。オンラインカスタマーサービス：15368832624

RTD PACKAGE ISSUE FOR THE S32K312 MICROCONTROLLER FOR EXAMPLE PROJECTS Using the s32k312 microcontroller for my project and try to compile the example project for communication but gives the error regarding the RTD package not compatible, tried the different RTD package but not work for it, i am using the s32 design studio 3.6 version, then how to solve the issue regarding the 

HSE_FWが存在する場合、S32K324のWFIビットがPRTN0_CORE0_STATに設定されない S32K324 MCUにおいて、HSE_FWが存在する場合にPRTN0_CORE0_STATのWFIビットが設定されないという問題が発生しています。 HSE_FWを搭載していないMCUでは、WFIは適切に設定され、アプリは正常に動作します。 HSE_FWをインストールする際に、何か特別な操作が必要ですか？ ありがとうございます アニル Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、ダニエルさん。 ご質問への回答は以下のとおりです。 ユースケースについて詳しく説明していただけますか？ HSE_B FW をインストールしました。FreeRTOS タスクでさまざまなペリフェラルを使用するアプリケーションを実行しようとしています。HSE_FW の処理をサポートするためにアプリケーション コードはまだ変更していませんが、Crypto_43_HSE ドライバ モジュールを含めただけです。初期化のための API はまだ呼び出していません。チケットに記載されているように、ハードフォールトが発生しています。 コアスタンバイモードに移行しようとしていますか、それともシステムスタンバイモードに移行しようとしていますか？いいえ、通常の起動時のみです。 RTDドライバを使用していますか、それとも独自のドライバを使用していますか？私はRTDドライバを使用しており、Crypto_43_HSEドライバのみを含めています。 HSEコアのWFIが設定されていることを確認していただけますか？WFI については、 PRTN0_CORE2_STATは設定されていますが、PRTN0_CORE0_STATは設定されておらず、そこでこのハードフォルトが発生します。   他のご提案についても、さらに検討してみます。でも、もっと何か試してみたいことがあれば、ぜひ返信してください。   ありがとうございます アニル Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present main() 関数から MCU_SetMode() 関数を呼び出しています。これは/* 実行モードに切り替える */ の関数です。 このRTD関数は、内部的に以下の関数を順番に呼び出します。例外発生時のスクリーンショットも添付しました。Power_Ip_MC_ME_ConfigureCore() Mcu_SetMode(McuModeSettingConf_Run); Mcu_Ipw_SetMode(); Power_Ip_SetMode(); Power_Ip_MC_ME_ConfigCoreCOFBClock(); Power_Ip_MC_ME_ConfigureCOFB(); Power_Ip_MC_ME_ConfigureCore(); 。 する ヤージュ TimeoutOccurred = Power_Ip_TimeoutExpired(&StartTime, &ElapsedTime, TimeoutTicks); CoreStatus = Power_Ip_pxMC_ME->McMePrtnArray[PartitionIndex].McMePrtnCoreArray[CoreIndex].PRTN_CORE_STAT; } while ( (MC_ME_PRTNX_COREX_STAT_WFI_EXECUTED_U32 != (CoreStatus & MC_ME_PRTN0_CORE0_STAT_WFI_MASK)) && (!TimeoutOccurred) ); 。 。 while() ループがタイムアウトするため、次のソースコードが呼び出されます Power_Ip_ReportPowerErrors ( POWER_IP_REPORT_TIMEOUT_ERROR 、 POWER_IP_ERR_CODE_RESERVED ) は、前のスクリーンショットに示されているようにハードフォルトを引き起こします。 ありがとうございます アニル Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、アニルさん。 PRTN0_CORE0_STAT[WFI] = 1 にしたい理由がまだ理解できません。どのようなユースケースがありますか？ これはどのような種類の障害例外ですか？ 以下の資料をご参照ください。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 よろしくお願い申し上げます。 Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、@anilsp31PA さん。 具体的な使用事例について詳しく教えていただけますか？ コアスタンバイモードに移行しようとしていますか、それともシステムスタンバイモードに移行しようとしていますか？ RTDドライバを使用していますか、それとも独自のドライバを使用していますか？ HSEコアのWFIが設定されていることを確認していただけますか？ リファレンス・マニュアルのセクション46.1.7「アプリケーションコアのシャットダウンプロセス」を参照してください。このセクションでは、システムスタンバイモードに入る前にアプリケーションコアを無効にする方法について説明します。 セクション46.1.4も参照してください。– コアクロックゲーティングとは、HSE_Bコアにはクロック制御がないことを意味します。シャットダウンが必要な場合（例えば、スタンバイモードの場合）のみ、WFIモードにする必要があります。 HSEが有効になっているデバイスでは、保留中のサービス要求や内部タスクがない場合、HSEコアは自動的にWFI状態に移行します。HSEコアは、アプリケーションコアから新しいサービス要求を受信すると、自動的に起動します。 予期しない動作が見られた場合は、クロック構成を再確認し、リファレンスマニュアルに記載されているサポートされている構成のいずれかと一致していることを確認してください。たとえば、表157 – オプションA（CORE_CLKが160MHzのハイパフォーマンスモード）などです。 よろしくお願いいたします。 ダニエル Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、 @anilsp31PA さん、 なるほど、つまりあなたはCM7_0を無効にしようとしているのですね。 「注：メインコアのクロックは常に有効にする必要があります。アプリケーションによってメインコアが設定されている場合は、McuCoreUnderMcuControl のチェックを外すか、McuCoreUnderMcuControl と McuCoreClockEnable の両方にチェックを入れる必要があります。」 S32K3_S32M27x MCUドライバのユーザーマニュアル、Rev0000R7.0.1 Rev. 1.0 つまり、私はまだその使用例を理解していません。メインコアをこのように無効化してはならない。 よろしくお願いいたします。 ダニエル Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、ダニエルさん。 コアクロックが有効になっていないことは承知しています。 しかし、RTD経由で暗号化ドライバを統合する際に、なぜ今になってこの問題が発生するようになったのか、確認していただけますか？ また、RTD の Crypto Driver を統合する際に MCU モジュールで構成変更が行われていないことを確認するため、RTD の Crypto Driver の代わりに、NXP DEMO HSE (HSE_FW_S32K3XX_0_2_1_0) に付属する Demo App (HSE_DEMOAPP_S32K3XX_0_2_1_0) ファイルをソースコードに統合してみました。 しかし、私も同じ問題に直面しています。 ここで検討しているユースケースは、HSE（OEMであるGMが提供するもの）と通信できるドライバコードを、当社のアプリケーションファームウェアに追加することです。 今回初めて、ターゲットチップセットに書き込まれたHSEと共に、自社開発のアプリケーションファームウェアを実行しようと試みています。 そこで、HSE（健康・安全・環境）対策を実施する際に、他にどのような点に注意する必要があるのかを知る必要がある。 注：この問題発生中、当社はHSE（英国安全衛生庁）への要請は一切行っていません。 アプリケーションのファームウェア上では、暗号化リクエストに関連するコードは実行されていません。 また、私の場合もHSEファームウェアの書き換えは行っていません。 参考までに、既存のIVTは0x0040000000にあります。以下はIVTの抜粋です。BCWを更新する必要があるかどうか確認していただけますか？ その間、MCUの各コアのクロックを有効にして、テストを試してみます。 締め切りが迫っているため、早急なご支援をお願いいたします。 よろしくお願いいたします。 ヴェンカテシュ・プラサンナ・K. Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、ダニエルさん。 CM7_0とCM7_1のクロック有効化を有効にした後、コードはMcu_SetMode()を通過しましたが、今度はPwm Init()で失敗します。 以下にコールスタックを示します。 なお、変更はコアクロックの有効化と生成のためにMCUモジュールに対してのみ行われました。 参考のためにローカル変数を添付しました。 よろしくお願いいたします。 ヴェンカテシュ・プラサンナ・K. Re: S32K324 WFI bit not setting in PRTN0_CORE0_STAT when HSE_FW is present こんにちは、ベンカテシュさん。 お使いのRTDのリビジョン番号をご確認いただけますでしょうか？ 障害例外はなく、DevAssertのみが発生するということを理解しています。 どのDevAssertがトリガーされているのか具体的に教えていただけますか？ クロック設定がサポートされているクロックオプションのいずれかと完全に一致していることを確認していただけますか？ よろしくお願い申し上げます。

How Are You Optimizing Packet Processing Performance on QorIQ T-Series Platforms? Has anyone worked on optimizing packet processing performance on QorIQ T-Series platforms under heavier network traffic conditions? We are currently testing a T-Series based system for continuous packet forwarding and noticed that CPU utilization increases quite quickly once traffic bursts become sustained. The platform remains stable, but latency consistency between cores starts varying under load. I am particularly interested in understanding how others are handling: interrupt distribution queue balancing multicore workload tuning memory/cache optimization latency reduction during high throughput Would appreciate hearing about any practical tuning methods or performance observations from real deployments. Re: How Are You Optimizing Packet Processing Performance on QorIQ T-Series Platforms? Hello, Yes — there is documented guidance for exactly the kinds of tuning you listed on QorIQ T-Series/DPAA1 systems, in the LA1224-RDB-BSPUG and it aligns closely with the behavior you are seeing under sustained bursts: as load rises, the critical tradeoff becomes throughput vs. per-core latency consistency . The retrieved documentation points to five main levers: interrupt moderation, FQ/channel distribution policy, dequeue/QMI tuning, cache stashing/CPC usage, and order-handling mode selection. Regards

S32K314 chip Debug port unlocking issue using Lauterbach Spoiler (Highlight to read) Hello NXP Technical Support: I used Lauterbach to unlock the Debug port of the S32K314 chip according to the S32K3_SecureDeburg-UserGuide.pdf document, and the Debug port encryption method was password. The phenomenon is that unlocking failed, and the command window for unlocking success was displayed for a moment before disappearing. What's going on? Hello NXP Technical Support:I used Lauterbach to unlock the Debug port of the S32K314 chip according to the S32K3_SecureDeburg-UserGuide.pdf document, and the Debug port encryption method was password. The phenomenon is that unlocking failed, and the command window for unlocking success was displayed for a moment before disappearing. What's going on? Re: S32K314 chip Debug port unlocking issue using Lauterbach Application created, Service Request Number: 00982977. The email belongs to the company, [email protected] The current inquiry is using my personal account Re: S32K314 chip Debug port unlocking issue using Lauterbach Please create support ticket and I could send you example code (NDA is required). https://www.nxp.com/support/support:SUPPORTHOME Re: S32K314 chip Debug port unlocking issue using Lauterbach Hello, NXP technical support: I unlocked the Debug port of S32K314 chip using Lauterbach based on the S32K3_SecureDeburg-UserGuide.pdf document, and the Debug port is encrypted with a password. The phenomenon is that unlocking failed, and the command window for successful unlocking disappeared after a while. What's wrong?

Need help with NXP IMX 1050evkb I’ve done C Programming. Now, I’m trying to learn basics of embedded development. I just bought an NXP 1050 evaluation kit. But it does not align with the basic steps mentioned on the NXP Getting Started guide. - It doesn’t have an accelerometer project in built. I tried installing the driver but the Link takes me to build an SDK. And the guide says to install the SDK but I can’t find any installable files there. All the videos in there are too old. Can somebody help? Re: Need help with NXP IMX 1050evkb Hi @hatanmaek, Of course! Glad you are exploring the world of embedded development using NXP. If you are following the Getting Started Guide, you will be instructed to use MCUXpresso IDE and a downloadable SDK zip for development, but perhaps its good time to use the MCUXpresso extension for VSCode instead for a more modern development process. You can still use the SDK Builder to get the SDK package, if you already downloaded the "ARM GCC / MCUXpresso for VS Code" as the Toolchain / IDE option: If not, don't worry, you can download the SDK from VS Code directly instead. With respect to VS Code, here is the full documentation that explains in great detail how to install, configure, and develop with MCUXpresso on VS Code. If you are getting started, make sure to download the "MCUXpresso SDK Developer" package from the Software Kits section, both ARM components, and all three utilities marked under Debug Probes Software when installing the extension. Then install the SDK you previously downloaded by following the "Import standalone MCUXpresso SDK zip archive" section of this chapter of the documentation. Alternatively, if the SDK you downloaded didn't work or wasn't for the correct toolchain, you can download the correct one by following the "Import MCUXpresso SDK using SDK Builder" section of the previously mentioned chapter instead. Important note! the SDK of the EVKB-RT1050 is not compatible with the EVK-RT1050 (and vice versa) so make sure to download the correct SDK for your board. Please follow the steps described previously and let me know if you encounter any obstacles or have any further inquiries along the way. BR, Edwin.

Code warrior Jtag IDE connection diagnosis issue Hi Team, We are using a custom board based on the NXP LX2160A chipset and are currently trying to set up the CodeWarrior IDE environment for JTAG flashing. The flash device used on our board is MT25QU512ABB. After configuring the IDE environment and adding the required files, we proceeded to open the Flash Programmer. During the connection process, after "Connection Diagnosis", the Flash Programmer opens successfully, but we are facing an issue at the step: "Run Target Initialisation Script" . The error observed is attached in the screenshot. The DIP switch is set to Hard-Coded RCW mode where we encounter the following error: "Failed to write memory at address ..." We have already verified the following: * Hardware connections * JTAG connectivity is proper * Relevant signals were probed and appear normal We request your support in helping us isolate the root cause and fix the issue at the earliest. Please let us know if any additional logs or configuration files are required. Thanks & Regards, Swetha K After clicking "Flash programmer" icon, CodeWarrRe: Code warrior Jtag IDE connection diagnosis issue 1. First Please double click LX2160_RDB(1) to Open "Target Initialization File" panel, please do the following modification. USE_SAFE_RCW = True 2. After clicking "Flash programmer" icon, CodeWarrior Connection Server(CCS) will pop up in the Windows task bar, please double click it to open CCS console, and type "log v" in the console, then click "Flash programmer" icon again, the low level CCS log will be printed in the console. Please capture this log and send it to me. Re: Code warrior Jtag IDE connection diagnosis issue Please find the screenshot attached : Re: Code warrior Jtag IDE connection diagnosis issue Hi The issue has been resolved. It was caused by a hardware connection fault, which has now been fixed. We are no longer experiencing the error. Thank you for your support

件名：FreeMASTERとS32K144EVBおよびMC33771Bを使用したCellVoltの監視に関する問題 こんにちは、 私は、以下のNXP製ハードウェアとモデルベース設計ツールボックス（MBDT）を使用して、バッテリー監視システムを開発しています。 MCUボード：S32K144EVB-Q100 BMS ICボード：FRDM33771BSPIEVB エミュレータ：BATT-14CEMULATOR 接続の詳細： セットアップのどの部分にもハンダ付けは一切行われていないことを強調しておきたいと思います。 FRDM33771BSPIEVBのジャンパーはデフォルト設定になっています。 S32K144EVBとFRDM33771BSPIEVBの間：これらは、はんだ付けや直接シールド接続ではなく、ジャンパー線で接続されています。 BATT-14CEMULATORとFRDM33771BSPIEVBの間：ここでもジャンパー線を使用しました。2つのボードの物理的なコネクタ仕様が互換性がなく、直接差し込むことができないためです。 問題： 現在、FreeMASTERでデータが全く表示されません。変数（CellVoltを含む）が更新されておらず、ツールはMCUからのアクティブな通信の兆候を示していません。 このデータ不足の原因として、以下の点が懸念されます。 信号の完全性／接触の問題：ジャンパー線を使用していることと、はんだ付けが全く行われていないことが原因です。 ハードウェアの非互換性：エミュレータとBMS IC間の手動ジャンパー接続に起因する、配線ミスや電圧レベルの問題が発生する可能性があります。 MBDT/FreeMASTER構成：SPI通信ブロックまたはFreeMASTERドライバ設定に潜在的なエラーがあります。 配線図と、モデルファイルおよびプロジェクトファイルを含むZIPファイルを添付しました。この設定は実現可能でしょうか、それとも私の設定に重大な誤りがあるでしょうか？ご教示いただけますでしょうか？ ご協力ありがとうございます。 FRDM33771BSPIEVB - X1 PinmapFRDM33771BSPIEVB - X1 PinmapFRDM33771BSPIEVB - X1 ピンマップ BATT-14CEMULATOR - J1 PinmapBATT-14CEMULATOR - J1 PinmapBATT-14CEMULATOR - J1 ピンマップ Re: Subject: Issue monitoring CellVolt via FreeMASTER with S32K144EVB and MC33771B こんにちは、 S32DSでアプリケーションのデバッグを試してみましたか？この方法を試して、MCUがハードフォルトを受信したかどうか、および変数の値を確認してください。 FreeMASTERに関しては、.elfファイルが正しくあることを確認する必要があります。FreeMASTERプロジェクトの設定でファイルが正しく選択されており、通信が正常であることを確認してください。この部分が正しく動作していることを確認する一つの方法は、アプリケーションに変数を追加し、各ステップでその変数をインクリメントすることです。すると、FMダッシュボード上で、その変数の値が増加していくのが確認できます。 よろしくお願いいたします。 ソリン・バンシラ

LA9310 Design file/hardware layout examples Are there design examples available (schematic/board layout) for the LA9310? 

古いAndroid 4.4.2はどこでダウンロードできますか？iMX6DLのソースコード こんにちは。Westonデスクトップが正常に動作するまで、u-bootのロゴ表示を維持する方法を調べています。 Android 4.4.2用のパッチを見つけました下記の議論には長期間にわたって添付されています。パッチがどのように機能したのかを知りたいので、パッチの対象となるソースコードが必要です。 NXP LinuxおよびAndroid BSP（HDMI、LCD、LVDS）向けに、ubootからカーネルへのubootロゴ保持をサポートするパッチ 残念ながら、現時点ではAndroid 4.4のソースコードアーカイブをダウンロードする方法はないようです。 ソースコードの入手方法を教えていただけませんか？「 android_kk4.4.2_1.0.0-ga_source.tar.gz」

USB hub multiple devices connection issue I am using an i.MX RT1060 controller in my project development. I am facing issues with USB hub functionality when multiple devices (MSD — pen drive, and CDC — printer) are connected in the following sequence: Case 1 A) Printer: Attach event occurred and working fine B) Flash drive:  No attach event is triggered for the flash drive. When the flash drive is removed, the system hangs inside USB_HostReleaseDeviceResource. Case 2 A) Flash drive: Connected and working B) Printer: Attach event occuured, but full interface is not properly completed. It returned error in some port open event call back. When the flash drive is removed, both devices got disconnected. Case 3 Both flash drive and printer inserted: Only the flash drive attach event occurred and working. When the flash drive is removed and reconnected, it works fine. CDC device connection/disconnection generates no event. The only way to recover CDC functionality is to restart the system. Findings: When I connect the hub to a PC to verify its functionality, both devices are visible in Device Manager. Based on this, I conclude that the issue lies in the USB driver implementation /Composite device handling for USB on the i.MX RT1060. Is there a way to handle this issue so that both MSD and CDC devices can be reliably enumerated and managed through the hub? Regards, Pavan #IMXRT1060 #nxp #Microcontroller #USB Hub #USB Composite device handling. USB Re: USB hub multiple devices connection issue Hi @Gangapavan, What SDK version are you using? Are you basing your project in any USB example we provide from our SDK? How did you implement USB features for MSD and CDC on your application? Are you implementing the USB Host HUB drivers we provide under 'usb' > 'host' > 'class' folder to manage the standard USB hub operations? BR, Edwin. Re: USB hub multiple devices connection issue Anyone have  suggestion for the above? Re: USB hub multiple devices connection issue Hi @EdwinHz  Thanks for the reply. We are using SDK version 2.13.0. We have used SDK examples as base to develop application Yes, we are using Hub file also from above given location. Need Quick resolution for the issue as project is under production stage. If required, I can share the files via email or any other method you suggest. Thanks. Re: USB hub multiple devices connection issue Hi @EdwinHz  Any suggestions for the above?

Questions on DH Key Support in HSE-B Hello NXP Community Team,   I have a couple of quick questions regarding DH key support in HSE-B: Does HSE-B support Diffie-Hellman (DH) keys? If yes, then why does the call HseResponse = App_GetHseAttrCapabilities(MU0_INSTANCE_U8, &Hse_AttrCapabilities); return a zero value for the HSE_CAP_IDX_CLASSIC_DH (25th bit) in Hse_AttrCapabilities After adding the following key group to the NVM catalog: {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_DH_PAIR, 2U, 1024U, {0U, 0U}}, the call to formatKeyCatalog returns HSE_SRV_RSP_NOT_ALLOWED. Could you clarify why this happens? How can i generate the DH key pair, which later use for generate DH-shared-secret computation. Thank you for your guidance. Best regards, Rushikesh Re: Questions on DH Key Support in HSE-B Hi @KaleRushikesh  This feature was available in earlier versions of HSE firmware but it was removed due to limited size of flash for HSE firmware. You can check release notes file of the firmware. I can see that it was removed from version 0.2.40.0 and higher: If you need this feature, there’s an option to request premium customized version of HSE firmware. Please contact local sales person for details. Regards, Lukas

TJA1028のスリープモードではVCCが遮断されない こんにちは、 Raspberry Pi 5のGPIOを使用してTJA1028モードをテストしています。モードを切り替えるために、ENピンとTXDピンのみを制御します。通常モードからスリープモードに移行すると、RSTNは低くなりますが、VCC(3.3V)出力は遮断されず、2.76Vまで低下します。まずTXDピンをローに設定し、次にENピンをローにプルダウンします。これは電圧レギュレータをスリープ状態にするための正しい方法でしょうか？ Re: TJA1028 Sleep Mode Doesnt Shutoff VCC VCCはOFFになっているはずです。念のため、VCCのリアステージ回路を再度確認するか、切り離していただけますでしょうか？