调用 Clock_Ip_Init() 时外部数据中止 您好， 我正在尝试使用RTD和S32 DS mex工具初始化一些外设时钟。（注意：我是在 M7 项目中生成代码，但实际构建和运行是在 A53 项目中进行的。） 然而，在 Clock_Ip_Init() 函数内部发生了外部数据中止。具体来说，调用堆栈如下所示： Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref()。 这似乎是首次尝试向 CMU 外围存储器写入数据。故障发生在内存0x4005'C028上的LDR指令中，根据 S32G3 内存映射，该内存正确地位于 CMU 内存区域内。 目前 MMU 尚未启用，但据我了解，外部数据中止发生在 CPU/MMU 之外，可能与安全访问或“锁定”的外围设备有关。 我的理解是，在调用 Clock_Ip_Init() 之前，需要以某种方式使 CMU 可以从 A53 内核“访问”，这种说法对吗？如果可以的话，您能否告知我具体的操作步骤？ 顺祝商祺！ 乔尼 设备 = S32G399A 编译器 = S32DS_GCC_11_4 核心 = 皮层 A53 Re: External Data Abort when calling Clock_Ip_Init() 嗨， jonnyWHIS 感谢您与我们联系。 您打算在 S32DS IDE 中创建可在 S32G A53 内核上运行的裸机代码吗？ BR 乔伊

iMX8 Nano 内核从 5.15 更新至 6.18 你好 在将 A53 内核从 5.15 移植到 6.18 时，遇到了 rpmsg 的问题。 # dmesg -T | grep -Ei 'rpmsg|rproc' [2024年10月8日星期二 15:42:28] imx rpmsg 驱动程序已注册。 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：错误 -ENOENT：启用时钟失败 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：使用驱动程序 imx-rproc 进行探测失败，错误代码为 -2 [2024年10月8日星期二 15:42:29] remoteproc remoteproc0：正在释放 imx-rproc 我遇到了这个错误。我在网上搜索这个错误时，有人建议我在 DTS 文件中添加一个虚拟时钟，如下所示。 imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7"; rsc-da = <0xb8000000>; clocks = <&clk IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; 内存区域 = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; 状态 = "正常"; } 请问是否只需要做这一项更改？更改的原因是什么？ 问候 亚杜纳特·R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 不——我不会将 clocks = <&clk IMX8MN_CLK_DUMMY>; 视为唯一需要的更改。或许可以解决眼前的 -ENOENT：启用时钟探测失败的问题，但对于 i.MX8M Nano 来说，重要的要求是，当 Linux 加载/启动 M7 固件时，Cortex-M7 根时钟必须保持启用状态。 原因： imx-rproc 节点应该有一个时钟条目；AN5317 显示了 i.MX8M remoteproc DTS 节点，其 compatible = "fsl,imx8mn-cm7" 和 clocks = <...> 属性，以及邮箱和内存区域条目。 您的错误意味着内核 6.18 imx-rproc 驱动程序尝试从该节点获取/启用时钟，但时钟查找失败并出现 -ENOENT 错误，因此在 remoteproc0 保持注册状态之前探测中止。 NXP 的 AMP 指南指出： “对于 i.MX 8M 平台，Linux 必须始终启用 M7/M4 的根时钟，才能加载固件代码并启动 Cortex M7/M4。”它还指出，NXP Linux 电路板支持包 在 M 内核从 U-Boot 启动时保持此根时钟启用；否则，如果 M 内核首先从 Linux 启动，则必须更新 drivers/clk/imx/clk-composite-8m.c 以跳过 M 内核时钟的门注册。 所以这一变化有两种可能的含义： 使用虚拟时钟作为兼容性替代方案 如果内核 6.18 imx-rproc 需要一个 clocks 属性，但实际的 M7 时钟并非有意通过通用时钟框架控制，则添加 IMX8MN_CLK_DUMMY 可以满足驱动程序的时钟句柄要求，并避免 -ENOENT。 真正的时钟控制修复 如果 Linux 实际上负责加载/启动 M7，那么仅使用虚拟时钟可能会掩盖探测错误，但不能保证 M7 时钟已启用。在这种情况下，您必须确保 M7/M4 根时钟保持开启状态，这可以通过 NXP 电路板支持包时钟驱动程序处理或 clk-composite-8m.c 文件来实现。AN5317 中描述的变更。 此外，还要检查 remoteproc/rpmsg DTS 的其余部分，而不仅仅是时钟线： imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7";         rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* 或您的 电路板支持包 使用的正确 M7 时钟 */ mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>; memory-region = , , , ;         status = "okay"; }; 内存区域列表很重要，因为 AN5317 指出此属性必须包含固件 ELF 使用的内存部分，以便 remoteproc 可以从 sysfs 重新加载它。 推荐检查路径： 如果从U-Boot启动 M7，请使用 NXP 流程，例如 prepare_mcore / bootaux，然后启动 Linux；AN5317 指出，这是 BSP 保持 M 内核根时钟启用的路径。 如果您从Linux remoteproc启动 M7，请确认您的 6.18 时钟驱动程序包含 NXP 处理，以保持 M 内核根时钟始终启用；否则，虚拟时钟可能只能修复探测，而不能修复运行时启动/加载。 将您的 DTS 与 NXP imx8mn-*-rpmsg.dts 进行比较对于同一个 BSP 版本，特别是时钟、mboxes、rsc-da 和保留内存布局。 虚拟时钟解释了立即出现的 -ENOENT 探测失败，但真正的设计要求是保持 i.MX8MN M7 根时钟启用；仅靠 DTS 是否足够取决于你的 6.18 BSP 时钟驱动程序是否已经保留了该时钟。

RT1171CVM8BでのモバイルSDRAM(1V8)サポート 私たちは新製品に使われるRT1171CVM8Bを調査しています。 このRTファミリーのメンバー i.MX モバイル(低消費電力、1.8V)SDRAMに対応していますか? データシート、リファレンスマニュアル、利用可能なアプリケーションノートや回路図からは、それがすぐには明確ではありません。これは1V8および3V3の両方で指定されているポートドライバ(NVCC_EMC1,2)によって推論されます。また、RT1060およびRT1050 i.MX の類似の質問や回答から肯定の推論も得られます。 EMCやSDRAMインターフェースの特殊な部分が1V8の部品で故障するようなトラブルは避けたいです。 そうでなければ、なぜデータシートに明確に記載されていないのでしょうか!? 敬具 ジョージ・ツァナトス。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B @georgetzanatos様、 RT1171はモバイルSDRAM(低消費電力1.8V SDRAM)をサポートしています。 現在のドキュメントにはこれを明確に記載していないことには同意します。データシートおよびリファレンスマニュアルでは、メモリプロトコルのサポートとI/O電圧モードが別々に説明されており、単一の「モバイルSDRAMサポート」文にまとめられているわけではありません。 ご心配は理解できます。RT1171のモバイル SDRAMを使っても構いません。重要な要件は、関連するNVCC_EMC1/2電源ドメインを1.8V動作用に設定し、SDRAMのI/O電圧レベルに合わせることです。   よろしくお願いいたします。 シェリー

T2081プロセッサからMT29F64G08AECAB 8GB NANDフラッシュにアクセスできない こんにちは、 私はT2081 NXPプロセッサを、IFC経由で外部NANDフラッシュMT29F64G08AECABに接続しています。 私の目標は、CodeWarrior上でこのNANDフラッシュの診断テストを実行するか、あるいはCodeWarrior上でこのデバイスのデバイスIDと製造元IDを読み取ることです（そのためのコードは既に作成済みです）。 この目標を達成するために、私は既に以下のことを実行しました。 1. 生成されたT2081QDS_init_core.tcl で、0xFF800000 から始まるサイズ 1MB のNAND IFC 用の LAW を設定しました。 ## LAW3からIFCへのNAND # ローバー mem [CCSR_ADDR 0x000C30] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000C34] = 0xFF800000 # 戦争 mem [CCSR_ADDR 0x000C38] = 0x81F00013 2. また、以下のようにNANDに対応するCSPRレジスタとFTIMレジスタを設定しました。 NAND_CS 5 を設定 # NANDフラッシュ、アドレス0xFF800000、サイズ1MB、8ビットNAND、ECC無効 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 #マスク mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 プロセッサからNANDへ向かうチップセレクトが2つあり(CS5とCS6)、今のところ最初の4GBにアクセスしようとしているので、CS5のみの設定をしています。 3. 設定済みのTLB: 細かい 1M TLB エントリ 5 : 0xFF800000 - 0xFF8FFFFF (NAND キャッシュ禁止、ガード付き) reg ${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. インストール済みディレクトリにはこのMT29F64G08AECABのサポートが見つからなかったため、マニュアルに従ってこのデバイス用の.xml(4GB分)を作成し、ここに添付しました。 これらすべてを実行した後、CodeWarriorでNANDデバイスの診断テストを実行すると、以下のエラーが表示されます。 Nisarga_R_0-1786096350786.png 代替案として、このデバイスからデバイスIDを読み取るための簡単なC言語コードを書いてみました。そこで、以下のコードをCode Warriorで書き、ここに添付しました。その結果、IFC_NAND_MDRレジスタを読み戻すと、デバイスIDと一致しない0x124E0000が返されます。 診断テストを実行できない、またはデバイスIDを読み取れないのは、私が何か間違ったことをしているか、何かを見落としているからでしょうか。 参考資料として、関連するT2081QDS_init_core.tclファイルと回路図を添付しました。 よろしくお願いいたします。 ニサルガR   QorIQ T2デバイス Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor 現在、社内チームと話し合っています。 よろしくお願いします。

Selection of FS2613 chip The FS2613 series chips are quite powerful, and the values and timings of each power rail are editable. However, we don't have much time for software development and prefer not to implement OTP ourselves. Are there any models that are factory-configured to be compatible with the S32K358? For example, like the one shown in the image below? Rio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 See attachment Re: 关于FS2613芯片的选型 Okay, for the MFS2633AMDB2AD model, what are the output voltages of each of the following channels after power-on by default? Where do VCORE, LDO1, LDO2, VREF, VBST, TRK1, and TRK2 originate? Re: 关于FS2613芯片的选型 MFS2633AMDB2AD Search | NXP Semiconductors You can choose this one! Re: 关于FS2613芯片的选型 The MFS2633AMDB2AD is discontinued. With the same specifications, I should replace it with the MFS2633HMDB2AD, right? Re: 关于FS2613芯片的选型 Yes! Re: 关于FS2613芯片的选型 Please submit a new ticket for new questions. Thank you! Re: 关于FS2613芯片的选型 How are PIN.17 FCCU1 and PIN.18 FCCU2 used on this chip? What truth table do the input values of these two pins form, triggering different protection mechanisms of the chip?

rt1189 启动流程 1.如图所示，“图像认证”过程是否会在 安全散列算法(SHA)-512 哈希阶段验证哈希值？ yanyanwang_0-1786097643048.png 2. 如果我设置了哈希值，BootROM 会验证镜像完整性吗？如果 BootROM 验证失败，它会进入恢复模式吗？ Re: rt1189 Boot Flow yanyanwang_0-1786444750281.png yanyanwang_1-1786444764361.png 如上图所示，如果我只对镜像进行签名而不进行加密，它是否能够通过 bootrom 验证流程？此外，启用 oem_close 后，它是否还能进入 bootrom 验证流程？     Re: rt1189 Boot Flow 以下是您两个问题的答案： 1. 仅签名（未加密）的镜像能否通过 BootROM 验证流程？是的。在 RT1180 AHAB 中，签名（认证）是安全启动的必要部分，可确保映像的真实性和完整性，而加密（OTFAD/IEE）是一个独立的、可选的防克隆功能，并非验证的先决条件。因此，仅签名的图像将正常地经过完整的 AHAB 签名验证流程，这也是 NXP 官方 SPSDK rt118x_secure_boot 示例中的标准方法。 2. 启用 oem_close (OEM_CLOSED) 后，是否仍会进入验证流程？是的，验证将成为强制性要求。 建议：在执行 oem_close 之前，请先将签名映像编程到 OEM_OPEN 状态，并确认其启动成功且无 ELE 事件，然后再关闭设备（SRKH 一旦熔丝就不可逆），以避免损坏设备。 （请参阅：i.MX RT1180 网络安全参考手册。）通过公司账户签署保密协议后，请向在线技术销售代表提交申请。） Re: rt1189 Boot Flow 1. 是否只有在启用签名认证功能时才启用哈希验证？如何独立启用哈希验证？如何将设备过渡到 OEM_CLOSED 生命周期状态？ 2. 我将启用恢复启动熔丝。 3. 我的目标是使用未加密的图像。启动ROM应计算并验证镜像哈希值。如果哈希验证失败，启动 ROM 应进入恢复启动流程，并从 LPSPI NOR Flash 启动恢复映像。 Re: rt1189 Boot Flow 嗨@yanyanwang ， A1：是的。RT1180 使用 AHAB 协议，并采用两层认证： 签名层：ECDSA（安全散列算法(SHA)-256 / 安全散列算法(SHA)-384）验证容器头和图像数组条目（存储每个图像的哈希值）。 哈希层：ROM 重新计算已加载图像主体的摘要，并将其与存储在图像数组条目中的哈希值进行比较。 图中所示的 安全散列算法(SHA) 哈希阶段正是这种强制性的完整性检查，它确实会验证哈希值。 A2： ROM始终会计算并比较哈希值，但是否强制执行错误取决于设备的生命周期：出厂默认配置为 Open，此时会运行身份验证，但所有身份验证错误都会被忽略，镜像仍然可以执行。只有在设备切换到 OEM_CLOSED 状态后，哈希值不匹配才会真正阻止启动。 是否进入恢复模式取决于恢复启动熔丝。如果启用，主启动身份验证失败将触发从恢复设备重新加载和重新身份验证；如果未启用，则流程将进入串行下载器/致命模式/RESET循环。 此致， 加文 Re: rt1189 Boot Flow 使用 multicore_trigger 和 cm7_helloworld 这两个演示程序时，我没有为 CM7 ITCM 启用 ECC。我使用 SPT 工具将 CM33 镜像和 CM7 镜像（旨在从内存运行）合并成一个镜像，然后通过 UART 将合并后的镜像编程到或非 Flash 中。然而，启动过程失败了。根据手册，一个容器最多可以包含 8 个 OEM 图像条目。在我的测试中，我只包含了两张图片：一张 CM33 图片和一张 CM7 图片。CM7 ITCM ECC 未启用。 CM33 和 CM7 镜像均未启动。但是，当我检查容器头时，发现其中只有 CM33 镜像。CM33 镜像本身单独使用时可以正常启动，不会出现任何问题。 我想了解为什么 CM7 镜像没有被包含或按预期处理，以及缺少 CM7 ITCM ECC 配置是否会影响 Boot ROM 处理 CM7 镜像的方式。 问题2： 如果我将 8 个 CM7 镜像和 1 个 CM33 镜像合并到一个容器中，启动过程中 Boot ROM 会执行什么操作？ 由于只有一个 CM7 内核，启动 ROM 如何确定应该启动哪个 CM7 镜像？如果所有 8 个图像条目都是 CM7 图像，启动 ROM 会加载所有 8 个图像、只选择一个图像，还是将选择权交给 CM33 应用程序？ Boot ROM 如何识别和处理同一容器中的多个 CM7 映像条目？是否存在优先级、映像索引、核心 ID、加载地址、入口点或其他机制来确定执行哪个 CM7 映像？ 我还想了解启用 CM7 ITCM ECC 和未启用 CM7 ITCM ECC 时启动 ROM 的确切行为。 启用 CM7 ITCM ECC 时，启动 ROM 是否会初始化 CM7 ITCM ECC 存储器，将 CM7 映像从 NOR Flash 复制到 CM7 ITCM，然后释放 CM7 的 RESET 状态？或者说，Boot ROM 只负责加载 CM7 镜像，而 CM33 应用程序负责解除 CM7 的 RESET 状态并启动它？ 当 CM7 ITCM ECC 未启用时，启动 ROM 在遇到加载地址位于 CM7 ITCM 中的 CM7 映像时会做什么？启动 ROM 是否会跳过 CM7 镜像、无法加载、使 CM7 保持重置状态，或者导致整个容器启动过程失败？ 我尤其想确认一下是否支持以下容器： 图片 0：CM33 图1：CM7 图2：CM7 图3：CM7 图4：CM7 图5：CM7 图6：CM7 图7：CM7 图8：CM7 如果支持，那么在启动 ROM 时，这 8 个 CM7 镜像究竟会发生什么？哪个元器件负责选择实际执行的 CM7 镜像？ 最后，我想澄清一下，最多 8 个 OEM 镜像条目是指容器可以简单地存储 8 个不同的镜像，还是 Boot ROM 也提供了一种机制，可以为给定的核心选择和启动特定的镜像。

iMX8 Nanoのカーネルを5.15から6.18にアップデート こんにちは A53コア用にカーネルを5.15から6.18に移植する際、rpmSGの問題に直面しています。 # dmesg -T |grep -Ei 'rpmsg|rproc' [2024年10月8日火曜日 15:42:28] IMX RPMSGドライバーが登録されました。 [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: error -ENOENT: クロックを有効にしられませんでした [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: ドライバ付きプローブ imx-rproc エラー -2 で失敗 [火曜日 2024年10月8日 15:42:29] remoteproc remoteproc0: releaseingimx-rproc このエラーが出ます。このエラーをオンラインで検索したところ、DTSにダミークロックを追加するように求められました。 IMX8Mn-CM7 { 互換性 = "FSL,IMX8mn-CM7"; RSC-DA = <0xb8000000>; クロック = <&CLK IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mbox = <μ 0 1 &ミュー 1 1 μ 3 1>; memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "OK"; } これが唯一の変更なのでしょうか?この変更の理由は何ですか。 よろしくお願いいたします ヤドゥナス・R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 いいえ、私は clocks = <&clk IMX8MN_CLK_DUMMY>; を唯一の必要な変更として扱うつもりはありません。これで即時の-ENOENT: Failed to Enable Clock probe failureを乗り越えられるかもしれませんが、i.MX8M Nanoの場合、重要な要件はLinuxがM7ファームウェアを読み込み/起動する際にCortex-M7のルートクロックが有効のままであるということです。 理由： imx-rproc ノードにはクロックエントリがあることが想定されています。AN5317 では、compatible = "fsl,imx8mn-cm7" と clocks = <...> プロパティ、さらに mailbox および memory-region エントリを持つ i.MX8M remoteproc DTS ノードが示されています。 あなたのエラーは、カーネル6.18のimx-rprocドライバーがそのノードからクロックを取得して有効化しようとした際、-ENOENTでクロック検索が失敗したため、リモートプローク0がレジスタジアムのままになる前にプローブが中止されたことを意味します。 NXPのAMPガイダンスには「i.MX 8Mプラットフォームでは、M7/M4のルートクロックを常にLinuxで有効にしてファームウェアコードを読み込み、Cortex M7/M4を起動させる必要があります」とあります。 また、NXP Linux BSPはU-BootからMコアを起動した際にこのルートクロックを有効にしているとも書かれています。それ以外の場合、MコアをLinuxブートから起動した場合、ドライバ/clk/imx/clk-composite-8m.cを更新してMコアクロックのゲート登録をスキップする必要があります。 したがって、この変化には二つの意味が考えられます。 ダミークロックを互換性回避策として使う カーネル6.18 imx-rprocがクロックの性質を必要としているが、実のM7クロックが共通クロックフレームワークで意図的に制御されていない場合、IMX8MN_CLK_DUMMYを追加することでドライバーのクロック処理要件を満たし、-ENOENTを回避できます。 実クロック制御の修正 もしLinuxが実際にM7の読み込みや起動を担当している場合、ダミークロックだけではプローブエラーを隠すかもしれませんが、M7クロックが有効になる保証はありません。その場合、NXP BSPクロックドライバーの処理かclk-composite-8m.cのいずれかでM7/M4のルートクロックがオンになっていることを確認してください変更内容はAN5317に記載されています。 クロックラインだけでなく、remoteproc/rpmsg DTSの残りの部分も確認してください。 imx8mn-cm7 { 互換性 = "fsl,imx8mn-cm7";      rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* または、お使いのBSPで使用される正しいM7クロック */      mbox-names = "tx", "rx", "rxdb";      mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;      memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "オーケー"; }; メモリ領域リストは重要で、AN5317ではこのプロパティがファームウェアELFで使用されるメモリセクションを含まなければならず、remoteprocがsysfsから再ロードできるとされています。 推奨されるチェックパス： M7をU-Bootから起動する場合は、NXPのprepare_mcore/bootauxなどのフローを使い、その後Linuxを起動します。AN5317によると、BSPはこの経路でMコアのルートクロックを有効にしています。 Linux remoteprocからM7を起動する場合、6.18クロックドライバーにNXP対応が含まれているか確認し、Mコアのルートクロックを常に有効にしてください。そうでなければ、ダミークロックはプローブのみを修正し、実行時の開始・ロードは修正されません。 作成したDTSファイルをNXP imx8mn-*-rpmsg.dtsと比較してください。同じ BSP リリースの場合、特にクロック、mboxes、rsc-da、および予約済みメモリレイアウト。 ダミークロックは即時の-ENOENTプローブ故障を説明しますが、実際の設計要件はi.MX8MN M7のルートクロックを有効にしておくことです。DTSだけで十分かどうかは、6.18 BSPクロックドライバーがすでにそのクロックを保持しているかどうかに依存します。

FS2613チップの選定 FS2613シリーズのチップは非常に高性能で、各電源レールの値とタイミングを編集できます。しかし、ソフトウェア開発にあまり時間をかけられないため、OTPを自社で実装することは避けたいと考えています。S32K358と互換性を持つように工場出荷時に設定されているモデルはありますか？例えば、下の画像に示されているようなモデルです。 Rio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 添付ファイルを参照してください Re: 关于FS2613芯片的选型 さて、 MFS2633AMDB2ADモデルの場合、電源投入後の各チャンネルの出力電圧はデフォルトでどのくらいですか？ VCORE、LDO1、LDO2、VREF、VBST、TRK1、TRK2はどこから発生するのですか？ Re: 关于FS2613芯片的选型 MFS2633AMDB2AD 検索 | NXPセミコンダクターズ あなたはこれを選ぶことができます！ Re: 关于FS2613芯片的选型 MFS2633AMDB2ADは製造中止になりました。同じ仕様であれば、MFS2633HMDB2ADに交換すれば良いですよね？ Re: 关于FS2613芯片的选型 はい！ Re: 关于FS2613芯片的选型 このチップでは、PIN.17 FCCU1とPIN.18 FCCU2はどのように使用されますか？これらの2つのピンの入力値はどのような真理値表を形成し、チップのさまざまな保護メカニズムをトリガーしますか？ Re: 关于FS2613芯片的选型 新しいご質問については、新しいチケットを送信してください。よろしくお願いいたします。

S32DSのアクティベーションコードが必要です。 S32DSのインストールに必要なアクティベーションコードを取得するには、署名済みの秘密保持契約書（NDA）と会社のメールアドレスが必要です。会社のメールアドレスをお持ちでない場合は、申請方法をご確認ください。

重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 过去，我的项目使用了 S32DS V2.2 和 SDK RTM 2.0.0。现在，重新安装后，我使用的是 S32DS.ARM.2018.R1，并且也安装了 SDK RTM 2.0.0。但我现在无法编译这个项目。它似乎无法识别该项目本身。图片中可以看到细节。 Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi 你好@yangcao1234 请注意，S32K1 SDK RTM 2.0.0 是专门为 S32DS for ARM 2018.R1 Update 6 发布的。它并非设计用于 ARM 2.2 的 S32DS，并且不能保证与该版本兼容。 BR，VaneB

PCA9615 我写信是为了寻求帮助，解决 dI2C 通信两端的电路问题——两个 PCB 板之间通过双绞线束进行通信（DSDAP 和 DSDAM；DSCLP 和 DSCLM；两条 GND；以及两条 5V 线）。在此之前，我决定测试 Gemini，因此很遗憾，我依靠 AI 来生成与 dI2C 通信相关的两个 PCB 的部分。附件是与 dI2C 相关的原理图部分。不出所料，各板之间没有任何沟通，但我的懒惰，以及我不得不说的愚蠢（吸取教训了），让我浪费了很多时间。我最终查阅了演示板的数据手册和用户手册，发现一个明显的区别是，正极线（DSCLP 和 DSDAP）与 VDD(B) 之间有 600 欧姆的电阻，负极线（DSCLM 和 DSDAM）与 VSS 之间也有 600 欧姆的电阻，而正负极线之间则有 120 欧姆的电阻，这显然导致正负极线之间的电阻为 100 欧姆（我知道 1/600 + 1/120 = 1/600 + 5/600 = 100，但我无法从电路角度理解——也许是因为我是机械工程师？）。这个错误（或许是多个错误之一）是否是由于在每对导线之间缺少一个600欧姆的上拉电阻、一个600欧姆的下拉电阻和一个120欧姆的电阻造成的？（28 AWG双绞线的特性阻抗约为100欧姆，用于内部数据链路和USB/以太网配置；对于使用PVC或FEP绝缘导线的标准间距配置，阻抗为78欧姆至95欧姆。） 这是人工智能给出的结果与我在数据手册的图1、图7、图8和图9中看到的结果之间的一个显著区别。另一个区别是，AI 为两个 PCB 建议了不同的电容排列方式，而演示板上只有一种排列方式（我假设这种排列方式用于 dI2C 连接线的两侧）。此外，VDDA 引脚和 VDDB 引脚似乎各有两个电容——都是陶瓷电容（尽管我最初的想法是那两个黄色电容应该是钽电容）。我可以使用演示用户手册中提供的电容配置，而忽略 AI 在附件中提供和显示的内容吗？ 另一个问题是，在主控端（我使用的是 3.3V 微控制器），最初 Ai 指示将使能引脚连接到 5V 线，但在电路板制作完成后，两个电路板都没有任何功能，这促使 AI 确定主控端的使能引脚应该连接到 3.3V 线（主板上的 VDD(A) 连接到 3.3V 线）。然后，它要求完全切断主PCB板上使能引脚的所有电源，作为一项测试。请问是否需要向 EN 引脚供电，以及供电方式是什么？在测试或最终运行期间，我不会对任何电气硬件进行热插拔。 我正在考虑实施上述更改，但在进一步投入资金购买昂贵的电路板之前，非常希望得到您的帮助。 Re: PCA9615 关于电容还有一点需要说明，建议主PCB上的VDDA和VDDB引脚都只使用去耦电容。建议在从机PCB板上使用去耦电容，同时还建议在从机PCB板上的VDDB引脚上额外添加两个电容。 Re: PCA9615 您好！ 感谢您的详细解释。 请注意，NXP 为 PCA9615 系列提供了一个评估板，可作为您实现的参考设计。我们强烈建议您将您的原理图与 PCA9615 评估板及其相关用户手册进行比较，因为该设计包含了 NXP 验证过的推荐差分 I²C 终端网络、偏置电阻、去耦电容和 EN 引脚连接。 在设计基于 PCA9615 的定制系统时，以评估板原理图为基准通常是最佳方法，因为它能最大限度地降低配置或布局问题的风险，并遵循数据手册和应用文档中提供的建议。 我们建议您在进行另一次 PCB 修改之前，先查看评估板原理图并相应地更新您的设计。 https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL 希望这能帮到你！

imx95lpddr5 evk の全負荷状態をシミュレートするために i.MX95 LPDDR5 EVKボード上で、フルロード動作状態をシミュレートする方法。画像や事前コンパイルされたアプリケーションはありますか?私はLinuxのマルチメディアイメージを使っています。 Re: To simulate full load condition on the imx95lpddr5 evk こんにちは、 参考として、以下のアプリケーションノートをご利用ください: https://www.nxp.com/docs/en/application-note/AN14449.pdf 高負荷CPUテストを達成するためのユースケースはいくつかあります。 ぜひご覧になってみてください。 CA55 コアマーク eIQベンチマーク(GPU) eIQベンチマーク（NPU） よろしくお願いいたします。 

RT1171CVM8B 支持移动 同步动态随机存取存储器(SDRAM) (1V8) 我们正在研究将 RT1171CVM8B 用于新产品。 这款 i.MX RT 系列产品是否支持移动（低功耗，1.8V）同步动态随机存取存储器(SDRAM)？ 从数据手册、参考手册和可用的应用笔记和原理图中并不能立即看出这一点；这是因为端口驱动程序同时指定了 1V8 和 3V3 (NVCC_EMC1,2)。从 i.MX RT1060 和 RT1050 的类似问答中也可以得出肯定的结论。 我希望避免出现因 EMC 或 同步动态随机存取存储器(SDRAM) 接口的某些隐蔽部分与 1V8 器件不兼容而导致的故障；否则，为什么数据手册中没有明确列出呢！？ 此致敬礼， 乔治·扎纳托斯。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B 亲爱的@georgetsanatos ， RT1171 支持移动 SDRAM（低功耗 1.8 V SDRAM）。 我们同意，目前的文档没有明确说明这一点。在数据手册和参考手册中，内存协议支持和 I/O 电压模式是分别描述的，而不是合并到一个单独的“移动同步动态随机存取存储器\(SDRAM\) 支持”声明中。 我理解您的担忧。请放心在RT1171上使用移动同步动态随机存取存储器(SDRAM)。关键要求是配置相关的 NVCC_EMC1/2 功率域，使其在 1.8V 电压下运行，以匹配 SDRAM I/O 电压等级。   顺祝商祺！ 雪莉

SL3S1206FUD2/HA 请求提供芯片识别文件/晶圆图 尊敬的供应商： 我们想确认您是否提供了任何文件或标记，用于区分晶圆上的“合格芯片”和“不合格芯片”。 具体来说，我们正在寻找： 晶圆图（显示哪些芯片通过/未通过测试）， 一份测试结果报告，或 晶圆表面的物理标记（例如墨点、激光标记），可以清晰地识别可用芯片。 我们在显微镜下检查了晶圆，没有发现任何可见的物理标记。这引发了人们的担忧，即我们可能无法可靠地区分合格芯片和有缺陷芯片。 请问您能否帮忙确认一下货物中是否包含这些信息，或者协助我们从制造商那里获取这些信息？我们需要这些数据来进行后续的处理步骤。 感谢您的帮助。我们期待您的回复。

FS32K144UAT0VLLTのタイマーのうち、入力キャプチャ機能を持つのはどれですか？ マネージャー： 質問： （１）FS32K144UAT0VLLTのデータシートには8つの独立したTIMEがあると記載されていますが、FTM0、FTM1、FTM2しか見当たりません。他にTIMEとして登録されているものは何ですか？ （２）FS32K144UAT0VLLTのどのTIME関数が入力キャプチャ機能を持っていますか？ ありがとう！ Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Robin_Shen こんにちは、追加の質問があります。 1. 表47-1 「S32K-RM Rev14.2のFTMインスタンスと機能」において、「障害入力」というパラメータは何ですか？ 2. S32K-RM Rev14.2のマニュアルのうち、各FTMが入力機能を備えていることが示されているページは何ページありますか？キャプチャ機能はどうでしょうか？ ありがとう！ Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ ハイ S32K-RM Rev14.2の表47-1。 FTM インスタンスと機能表裏S32K144FTM0 ～ FTM3 のサポートを参照してください。言及されたこれは、各 FTM が 8 チャネルのチャネルをサポートすることを意味します。 入力キャプチャ機能はすべてサポートされています。FTM インスタンスの機能領域を表示する場合、このテーブルに表示される機能も一部の FTM ではサポートされません。 よろしくお願いいたします ロビン Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ A1. これは、サポートされる外部障害入力の数を指します。S32K144を例にとると、表47-1に示すように、4つの入力をサポートしています。これらの4つの入力、FTM0_FLT0\1\2\3は、左側の表で確認できます。 Table 47-1. FTM instances and features Table 47-2. FTM signal descriptions.png A2. 各FTMがサポートする機能は通常、具体的に記載されていません。表47-5を参照してください。チャネルモード選択構成レジスタを使用すると、47.5.5 入力キャプチャモードに記載されている入力キャプチャモードを実装できます。

MC9S08QG8 编译器，如何获取适用于该芯片的 C 编译器 嗯，我有一款使用 MC9S08QG8 芯片开发的产品。我需要修改一些C代码。我使用的是Windows 11系统。我应该使用什么软件产品来生成芯片的调试器？我正在使用一块 Wiztronics 接口板，将电脑的 USB 端口连接到我产品中的芯片。我尝试过 8 种不同的软件包，但没有一种软件包的最终调试器能够正常工作。您建议使用哪个Software软件包进行调试？我在你的开发中心迷路了。 Re: MC9S08QG8 COMPILER, how do i get the c compiler for this chip Hello CodeWarrior 工具版本 11.1 支持 Windows 11，该工具支持不同的连接方式 [P&E USB Multilink Universal / USB Multilink、P&E Cyclone、开源 BDM、P&E 全芯片仿真]。 您可以从以下链接下载该工具： CodeWarrior ® for MCUs (Eclipse IDE) v11.1 我正在寻找 MC9S08QG8 设备，并且有此版本可供选择。 此致敬礼，路易斯

S32K324 通过 FEE 写入 DFlash 您好，关于使用 FEE 向 S32K324 写入 DFlash 有一个问题： 我计划使用 FEE 方法向 S32K324 的 DFalsh 写入大约 50 字节的数据。由于电路板上的硬件电源的备用时间约为 0.743 毫秒，我需要在该时间范围内保存关键数据。使用 FEE 方法写入 DFlash 是否可行？如果不可行，还有其他选择吗？ 谢谢。 Re: S32K324 write DFlash by FEE 好的，非常感谢。 Re: S32K324 write DFlash by FEE 你好@mmyjh_123 对于 0.743 毫秒的断电备份窗口，FEE 是不安全的。即使“接近 1 毫秒”，单个 Fls_MainFunction 块的写入执行时间也已经超过了您可用的保持时间。 您可以尝试使用 C40_Ip。使用四页（1024 位）程序时间，理论上写入 50 字节需要 450 微秒。然而，在紧急保持期间，0.743 毫秒内不可能进行任何擦除操作；擦除 8 KB 扇区可能需要长达 30 毫秒。 因此，在使用 C40_Ip 实现此功能时，应始终在空闲期间擦除要编程的 DFLASH 地址。此外，如果板能够在 MCU 断电之前检测到输入电压下降，则提交操作应在最早的阈值开始。否则，需添加大容量电容/备用电源，以确保保证的时间窗口能够覆盖最坏情况下的软件路径和闪存编程裕量。 以上仅为理论分析；建议进行多次实际测试，以确保足够的设计裕度。

GUI Guider 2.0 image storage type selected as Flash cannot be displayed. Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 Hi @sk-l  Could you please provide a more detailed description of the issue? It would be very helpful if you could also attach screenshots or relevant pictures for reference.   Thank you.   BR Harry Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 skl_2-1786613588252.png skl_0-1786612933574.png skl_1-1786612993765.png Image/animated image, Color format I4, storage type Flash, no display during simulation; Color format I4, storage type c array, image displays normally;

TJA1153（S32K344EVB） S32K344EVBのCANトランシーバはTJA1153、データシートに書かれている通り設定が必要です。しかし、私には自分の側に有利な2つの現象が見られます。 1.TJA1153のENピンとSTBピンの両方にハイを引っ張るだけで、パートナーと普通に通信できるので設定は不要です。 2. ENピンハイ、STBピンローの設定を行いたいです。データシートに記載されているように0x555U/0x18DA00F1のようなCAN IDを使い、実行Can_43_FLEXCAN_Write後にCan_43_FLEXCAN_MainFunction_Writeで実行しますが、一度も呼び出されCanIf_TxConfirmationありません。次の Can_43_FLEXCAN_Write の呼び出しでは、CAN_BUSY が返されました。 では、この二つの現象の理由は何でしょうか? Re: TJA1153 on S32K344EVB こんにちは、 観察された挙動に関するいくつかのコメント： 1. まず、ボード上のCANトランシーバが本当にTJA1153であることを確認してください。標準的なトランシーバ(例:代わりにTJA1043/TJA1042)が入力され、安全な設定シーケンスは不要で、通常のCAN通信が即座に動作するはずです。 2. 純正のTJA1153の場合、動作は現在の状態によって異なります。 初期状態（工場出荷時設定）：通常動作前に設定が必要であり、ローカル設定モードに入るにはSTB_N=Lowである必要があります。 オープンコンフィケーション/設定状態:トランシーバはすでに通常の通信を許可している場合があります。再構成は、初期ビットレート検出フレーム(ID 0x555)を使わずに、設定されたボーレートでCONFIG_ID拡張識別子付きで準備済みのクラシックCANフレームを送信することで実行できます。この設定メッセージは、バス上の別のノードによって確認応答（ACK）される必要があります。 2つ目の問題に関して、CanIf_TxConfirmation()が一度も呼び出されず、次のCan_43_FLEXCAN_Write()がCAN_BUSYを返す場合、TXメールボックスの送信が完了していないことを示します。フレームが実際に送信され、確認応答されたかどうかを確認するには、FlexCANステータスレジスタ（ESR1、ECR、MB CODEフィールド）をチェックすることをお勧めします。 BR、ペトル

S32G-VNP-RDB3:オンチップデバッグサポート こんにちは、 以下の環境でAUTOSARオペレーティングシステムベースのアプリケーションをデバッグしたいと考えています。 1) ボード名: S32G-VNP-RDB3 2) マイコンバリアント:S32G399 3) Cortex-M7コア 4) ホスト: Windows 前述の基板で、外部デバッガやプローブなしで接続できるオンチップデバッグサポートは有効になっていますか? もしこのボードでオンチップデバッグのサポートがない場合、S32デバッグプローブ(H/W)とs32 design studio IDE(S/W)でデバッグできますか? 敬具 マドゥスダン・グプタ Re: S32G-VNP-RDB3: Onchip debugging support こんにちは、 @madhusudangupta007 投稿ありがとうございます。 1.RDB3にはオンチップデバッガがないため、USBポート経由で直接RDB3をデバッグすることはサポートされていません。 2. 一般的に、Lauterbach TRACE32 DebugはS32G製品のデバッグに使用されており、NXP(S32 Debug Probe |NXP Semiconductors)も使用されています。 3. はい、前述の通り、S32デバッグプローブ(HW)とS32 Design Studio(IDE)はRDB3ボードのデバッグに組み合わせて使うことができます。   BR チェイン