S32Z RTU0 core0 性能问题 我在 S32Z270 RTU0 内核 0 (R52) 上运行一些测试代码，RTU0_CORE_CLK 设置为 1GHz，执行时间似乎过长。 相比之下，我在 SS32K388 内核 0 (CM7) 上运行相同的代码，内核时钟设置为 320MHz。 鉴于时钟频率的提高，我本以为执行速度会更快一些，但执行时间反而更长了。 两个二进制文件的版本/编译标志保持不变（参见随附的 txt 文件 buildinfo.h） (1) 由于 S32 配置工具中的时钟配置对于 S32Z 来说有点复杂，我如何才能确保 RTU0 内核 0 的时钟频率按计划为 1GHz？ 我已经通过 MC_CGM_3_MUX4_CSC（例如，SEL_CTL = 0x3D）将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4（BGA594 的 PAD_040），包括 MC_CGM_3_MUX4_DC_0（例如，DIV = 0x9）中为 10 的分频器。另请参见所附的登记册读数。 如果我在 CLKOUT_4 测量到 50MHz，我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz，(b) RTU0_CORE_CLK 为 1GHz？ CGM_3_MUX_4_Register_Configuration.png CLOCKOUT4_Measurements_RTU0_CORE_DIV2_CLK_50MHz.png (2) 我使用 S32Z RTD2.0.1 测量了引脚写入 GPIO 的执行时间，并测量了示波器通道 CH5 - TESTFLAG 的高/低时间，大约为 3.4us。您是否有可能确认一下它们看起来是正常还是太慢了？ Screenshot 2026-04-25 123853.png Setting_GPIO_Low_3.4us.png Setting_GPIO_High_3.4us.png (3) 我不知道我错过了什么。     Re: S32Z RTU0 core0 performance issue 随函附上包装标记的照片。 Scan from 2026-04-27 09_28_21 AM.jpg0   Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 感谢您的快速回复。 下面是我对这些问题的回答： 1) 我使用的是 S32Z2XX 主板 + S32Z2XX 子板的组合。 a) S32ZXX 主板 X-S32X-MB A 版 b) S32ZXX 子板 SCH-50588 REV B2 / 700-50588 REV A2 S32Z2XX_Complete_Setup.jpg S32Z2XX_Motherboard_Tag.jpg S32Z2XX_Daughterboard_Tag.jpg 2) 代码使用 S32DS 版本 3.6.7 Build 260420 进行编译和链接。使用 S32DS 的先前版本（例如版本 3.6.6 或 3.6.5）时没有任何变化。我正在为 S32Z2XX 使用 RTD2.0.1。 Screenshot 2026-04-27 092032.png Screenshot 2026-04-27 092336.png 3) 我会使用 DM 发送项目副本。 Re: S32Z RTU0 core0 performance issue 你好，德克-埃兹勒 感谢您与我们联系。 1. 你使用开发板还是客户板？ 2.您使用的是 S32DS 的 IDE 吗？您测试的 IDE 版本是什么？ 3.能否与我分享您的测试代码？ BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 感谢您的答复和详细资料。 我会帮你检查，并在晚些时候回复你。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 抱歉，回复晚了。 (1) 我已经通过 MC_CGM_3_MUX4_CSC（例如，SEL_CTL = 0x3D）将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4（BGA594 的 PAD_040），包括 MC_CGM_3_MUX4_DC_0 中的分频器 10（例如，DIV = 0x9）。另请参见所附的登记册读数。如果我在 CLKOUT_4 测量到 50MHz，我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz，(b) RTU0_CORE_CLK 为 1GHz？ >>>关于这个问题，数字 7 被分配给 RTU0_CORE_DIV2_CLK，您还应通过编程 GPR3.CLKOUT4SE 来设置该值。您能确认一下是否设置了这个寄存器吗？ Joey_z_0-1777434680768.png BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好@Joey_z 关于这个问题： >>>关于这个问题，数字 7 被分配给 RTU0_CORE_DIV2_CLK，您还应通过编程 GPR3.CLKOUT4SE 来设置该值。 您能确认一下是否设置了这个寄存器吗？ 我检查了 GPR3.CLKOUT4SEL[MUXSEL] 的寄存器设置，该寄存器设置为 7，用于在相应的多路复用器中选择 RTU0_CORE_DIV2_CLK。 Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 我不确定我之前的留言是否已被确认为回复。 我检查了 GPR3.CLKOUT4SEL[MUXSEL]是否设置为 0x7，因此RTU0_CORE_DIV2_CLK 通过多路复用器路由。 使用所述配置并在输出引脚上看到 50MHz，我推测 RTU0 内核的时钟频率为 1GHz。 如果内核频率设置为 1GHz，但我仍然没有看到预期的性能（例如，使用 CoreMark 测试台），还有什么其他不正确的配置吗？ 如何检查缓存配置是否正确？ 我查看了汇编器启动脚本和使用过的链接器脚本，没有发现任何可疑之处。 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 感谢您的答复和详细资料。 您可以尝试参考 AN14245 的第 3、4 章来检查缓存配置。 高速缓存机制有助于提高内存性能。您可以下载以下图片。 Joey_z_0-1778036409619.png 此外，GPIO 翻转到测量时间，主要反映了外设的"延迟" 访问路径，但会对 CPU 内核运算性能产生偏差。另外，在此应用程序中包含CoreMark的内容，您可以作为测试的参考。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 谢谢，我将阅读上述应用笔记（AN14245 S32ZE 安全可靠的高性能实时处理器）的第 3 章和第 4 章，了解缓存的正确设置。 顺便提一句，获得的 CoreMark 分数太低，这也是支持案例的起因。

Flexera License Dongle Hello, We have been using CodeWarrior 5.2 and 11.1 for some time with the Flexera License keys. Everything was working correctly and then all of a sudden the CodeWarrior Suites do not seem to recognize the Dongle anymore.  lmtools correctly displays the FLEXid: zstill1992_0-1770385958047.png I have the license.dat files at the following paths: C:\Program Files (x86)\Freescale\CWS12v5.2 C:\Freescale\CW MCU v11.1\MCU For CodeWarrior 5.2 I get the following error: zstill1992_1-1770386050631.png And for 11.1 I get: zstill1992_2-1770386108240.png The computer I am using is running Windows 11. We have some older laptops that are Windows 10 and have no issues on those. Any help will be greatly appreciated! Thank you, Zach

MC33772B 的 EPAD MC33772B 底部有一块 5.4 毫米 × 5.4 毫米的裸露金属区域。 然而，PCB 设计指南建议阻焊层的开口度仅为 3.7-3.8毫米，这表明 EPAD 的尺寸约为 3.7 毫米。 在实际检查中，集成电路底部裸露的金属面积为 5.4 毫米，大于建议的 PCB 开口。 根据数据表，从 3.7 毫米（最小）到 5.4 毫米（最大）的区域被指定为 PCB 布线保留区域。 如果 3.7 毫米是建议的 EPAD 尺寸，而 3.7-5.4 毫米是建议的 EPAD 尺寸。mm 区域被定义为 PCB 布线禁止区域，为什么将整个区域设计为封装底部的裸露金属？ Re: MC33772B's EPAD 您可以从下面链接文件的第 12 页阅读更多裸露焊盘的 PCB 设计。 AN4388: 四侧扁平封装 (QFP) — 应用笔记 5.2 焊锡钢网和焊锡膏 Re: MC33772B's EPAD 我已经知道了你的答案，但我真正想知道的是，为什么 MC33772 底部的金属开口面积是 5.4 毫米。 根据应用笔记，焊接开口面积为 3.7 mm，但设备的底部金属面积为 5.4 mm。为什么会有区别？ 根据数据表，3.7 毫米至 5.4 毫米区域被指定为布线禁区。 有鉴于此，我想了解为什么同样是 3.7-5.4mm 区域以开放金属的形式暴露在设备底部。

在 MIMXRT685-EVK 上配置 8CH-DMIC 板、闪存和测试 您好， 我正在尝试使用 8-DMIC 阵列板在 EVK-MIMXRT685 上运行 dmic_multi_channel CM33 演示。 根据演示文档，在 J31 上启用 8-DMIC 板需要移动多个电阻器（例如R379、R380、R384、R389、R390、R391、R392 至 2-3）。执行此操作后，FlexSPI 八进制闪存 (U19) 变得无法访问： -LinkServer 闪存失败 -ROM ISP (blhost) 已连接，但是 FLEX-SPI-或非显示扇区大小 = 0 /页面大小 = 0-无法擦除/写入闪存 我的问题是： 该演示能否在不使用八进制闪存（仅使用内存的工作流程）的情况下运行？ 更换电阻器后是否有官方的闪存/启动程序？ 是否所有电阻器都需要更改，还是某些电阻器可以保持默认状态以保证 FlexSPI 闪存工作？ 现在看来所需的DMIC硬件设置会阻止正常的闪存编程/启动。如何测试和运行演示程序？ 感谢您的指导。 MIMXRT685-EVK 8通道-麦克风 i.MX RT600 Re: 8CH-DMIC board configuration, flashing and testing on MIMXRT685-EVK 你好@mlkezarev、 非常感谢您关注我们的产品并使用我们的社区。 问题 1：该演示能否在不使用八进制闪存（仅使用内存的工作流程）的情况下运行？ A1: 是的。该演示设计为仅通过 SRAM 运行，不需要八进制闪存。 问题2：更换电阻器后是否有官方的闪烁/启动程序？ A2: 电阻器更改后，外部闪存将被物理断开。 因此，此硬件配置不支持闪存刷新或从闪存启动。 问题 3：是否所有电阻器都需要更改，还是某些电阻器可以保持默认状态，以保证 FlexSPI 闪存工作？ A3： 如果要启用 8 个 DMIC，则需要更改所有指定的电阻。 我已经发布了引脚配置屏幕截图供您参考。 mayliu1_0-1769497506571.png 问题 4：现在看来所需的DMIC硬件设置会阻止正常的闪存编程/启动。如何测试和运行演示程序？ A4：您可以在 SRAM 上运行，就像 SDK 演示一样"evkimxrt685_dmic_multi_channel_cm33" mayliu1_1-1769497840920.png 顺祝商祺！ MayLiu

使用MCUXpresso IDE构建和烧写应用 下面的步骤将指导您使用 MCUXpresso IDE 的 Cortex-M33 应用程序完成 hello_world 演示应用程序。MCUXpresso IDE 安装和 MCXN 系列的 SDK 可在本入门指南的 Get Software 部分找到。 在左下角找到快速启动面板。   Sabina_Bruce_1-1767118880216.png 然后点击导入 SDK 示例。 Sabina_Bruce_2-1767118904196.png 单击您正在使用的板选择可以在该板上运行的示例，然后单击 “下一步”。 Sabina_Bruce_3-1767118948399.png 使用箭头按钮展开 demo_apps 类别，然后单击 hello_world 旁边的复选框选择该项目。要使用 UART 进行打印（而不是默认的半托管），请在项目选项下选择 UART 作为 SDK 调试控制台复选框。然后点击完成 Sabina_Bruce_4-1767118968268.png 选择项目并通过单击上面提供的快捷方式中的 “生成图标” 或单击 “快速入门面板” 中的 “版本” 来版本项目 Sabina_Bruce_5-1767118993960.png 该项目应在控制台中不出现任何错误或警告的情况下构建 Sabina_Bruce_6-1767119004337.png 使用连接到 “MCU-LINK” 端口的 C 型 Sabina_Bruce_7-1767119052616.png USB 线将板连接到计算机 。有关说明，请查看板的用户手册。 单击上方的 “调试” 图标或单击 “快速入门面板” 中的 “调试”，将应用程序下载到您的板上 Sabina_Bruce_8-1767119086969.png 选择 MCU-Link CMSIS-DAP 调试探针 Sabina_Bruce_9-1767119109335.png 打开串行终端，查看应用程序的输出。选择 "终端 "窗口并按下 "新终端 "图标 Sabina_Bruce_10-1767119145379.png 选择 "串行终端"，然后将 UART 设置为 115200 波特率、8 位数据大小、无奇偶校验和 1 停止位。按确定 Sabina_Bruce_11-1767119154921.png 按 "运行 "图标运行应用程序。查看打印在终端上的输出结果 Sabina_Bruce_12-1767119186546.png

[RTD600 IP] S32K3X4EVB-T172 GPIOウェイクアップ このサンプル プロジェクトでは、WKPU + SIUL2 (GPIO) の基本機能を使用および構成する方法をユーザーに示します。 ------------------------------------------------------------------------------ * テストハードウェア: S32K3X4EVB-T172 (SCH-53148 REV B2) * MCU: S32K344 * IDE: S32DS v3.5 および S32DS v3.6.x * SDKリリース: RTD 6.0.0 * デバッガ: PE Micro * ターゲット: internal_FLASH ------------------------------------------------------------------------------ このサンプル ルーチンは、GPIO 割り込みウェイクアップ用に WKPU ユニットを構成します。これは最も単純な WKPU の例です。ピン PTB19 (WKPU42) はウェイクアップ用に構成されています。 ルーチンはSW5が押されるのを待機し、緑色の LED をオフにして、次の処理を実行する Wkpu_EnterStandby() 関数に入ります。 コアクロックを FIRC に切り替えます。 WKPU インスタンスを初期化します。 WKPU42 (PTB19) を設定します。 スタンバイ（または高速スタンバイ）状態になります。 SW6を押すと、MCU が起動してリセットし、 SW5が再度押されるかどうかをポーリングします。 この例は現状のまま提供されており、保証やサポートはありません。

iMX95 上の Panthor ドライバ こんにちは、皆さん 私は、iMX95 でグラフィック スタックがどのように動作するかを学習しようとしており、オープン ソースの DRM ドライバー (Panthor) を使用して、スタック全体 (OpenGL から下位のドライバー アクションまで) を理解できるようにしたいと考えています。 Mesa3D + OpenSource ドライバーは Arm スタックとしてより理解しやすいため、DRM ドライバーを使用する Linux カーネルを作成したいと考えています。 DTS の GPU ノードを Panthor ドライバと互換性があるように変更し、menuconfig でオプションを強制しました (Arm ドライバのオプションは無効にしています)。 起動時に、panthor_devfreq.c:panthor_devfreq_init の "devm_pm_opp_set_regulators" が呼び出されるまで、panthor は正常にロードされます。 このボードでこのドライバをすでに使用したことがある人はいますか、または何を変更する必要があるかご存知の方はいらっしゃいますか? ありがとうございます。 Re: Panthor driver on iMX95 こんにちは、 残念ながら、i.MX95 はまだ試作段階であるため、確定的な実装パスを提供するための検証済みのリファレンスや公式にサポートされている構成はまだありません。 Re: Panthor driver on iMX95 こんにちは、 devm_pm_opp_set_regulators の障害は、i.MX95 が GPU の電圧と電源状態を直接の個別レギュレータではなく SCMI (システム制御および管理インターフェイス) を介して管理し、Panthor ドライバが従来のレギュレータ ストリングで DVFS を管理することを期待するために発生します。これを修正するには、デバイス ツリーの GPU ノードに、SCMI ベースのレギュレータを指す mali-supply プロパティ (例: mali-supply = <&scmi_perf_gpc>;) が含まれていることを確認するか、より迅速なテストのために、DTS で「ダミー」の固定レギュレータを定義し、それを GPU にリンクして、ドライバの初期化チェックを満たす必要があります。電力管理を考慮せずに、より低いドライバーアクションだけを実現したい場合は、panthor_devfreq.c の devm_pm_opp_set_regulators 呼び出しをコメントアウトします。ただし、ドライバは最終的にはMali CSFファームウェア（mali_csffw.bin）を必要とすることに注意してください。G310 ハードウェアを初期化するには、rootfs に存在している必要があります。

S32K3 FLEXIO数据异常 我在使用S32K314 RTD400的SAI0（主机）与FLEXIO模拟的I2S（从机）通讯，SAI只使用d0，MUX_DISABLE，word width为16，发现从机接收到的数据都是主机的数据循环左移一位得到的数据，比如发送0x8002，在代码里面从机得到的数据是0x5，改了很多配置都没用，最后勾选了下图中的Enable User Mode Support，数据就正常了，这是为什么 Jason22_0-1769418452512.png SAI配置如下 Jason22_1-1769418801807.png Re: S32K3 FLEXIO数据异常 Hi@Jason22 我查看了编译的结果，这个选项你勾不勾选完全不影响运行的结果。 按照你提供的工程，我勾选和不勾选Enable User Mode Support所编译生成的结果是完全一样的，这说明这不会导致你所说的问题。 Senlent_0-1769504537946.png Re: S32K3 FLEXIO数据异常 编译没问题，是出现没有”Mcal.h“文件嘛，如果是的话，清除工程，再次编译就没问题了（不知道这是不是IDE版本的问题，S32DS 3.6似乎没出现过这个错误）。如果不是这个错误，方便说一下编译时出现了什么问题嘛 Re: S32K3 FLEXIO数据异常 Hi@Jason22 抱歉，我看错了，这不是IDE版本的原因，是我将Enable User Mode Support看成了Enable Flexio Common Support 你能再次检查下你提供的工程吗，我无法编译成功。 Re: S32K3 FLEXIO数据异常 没有勾选"启用用户模式支持"，配置还是有效的 Jason22_1-1769499402529.png Jason22_2-1769499419710.png 不勾选"Enable Flexio Common Support"，配置才无效，我使用的是 S32DS 3.5.14，这和 S32DS 版本有关嘛 Jason22_3-1769499528290.png Jason22_4-1769499545206.png Re: S32K3 FLEXIO数据异常 嗨@Jason22 你不勾选 "启用用户模式支持"下面的配置不是不生效了嘛 Senlent_0-1769498578945.png Re: S32K3 FLEXIO数据异常 我也比对了，发现也是一样，重新运行了一下程序，发现勾选后，又出现了数据循环左移的情况，但我第一次勾选的时候，数据确实是正常了，重复跑了几次也正常，不知道是什么因素导致的。 那我想询问一下，是我的配置还是代码有问题嘛，为什么从机接收到的数据刚好是主机发送的数据循环左移的结果？谢谢 主机发送的数据 Jason22_1-1769505898767.png 从机收到的数据 Jason22_2-1769505933794.png Re: S32K3 FLEXIO数据异常 Hi@Jason22 逻辑分析仪自己去测一下你发出的数据是不是正确的

PCIe：i.MX 95：分配多个 MSI IRQ 向量 您好， 我们在基于 i.MX95 的系统上使用 ATH12K Wi-Fi 模块，通过 PCIe2 实例连接。 在基于 linux-imx lf-6.12.y 的内核上，这个设置失败了，而在基于 lf-6.6.y 的内核上，它却能正常工作。 内核驱动程序成功请求并接收了 16 个 MSI 中断。但是，它随后无法启动 Wi-Fi 模块： [ 5.888139] ath12k_pci 0001:01:00.0：添加到 iommu 组 5 [ 5.888506] ath12k_pci 0001:01:00.0：BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0：启用设备 (0000-> 0002) [5.889315] ath12k_pci 0001:01:00.0：MSI 向量：16 [ 5.889334] ath12k_pci 0001:01:00.0：硬件名称： wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0：chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0：fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0：无法接收控制响应完成，轮询... [8.675241] ath12k_pci 0001:01:00.0：服务连接超时 [ 8.681002] ath12k_pci 0001:01:00.0：连接 HTT 失败： -110 [ 8.692180] ath12k_pci 0001:01:00.0：未能启动核心：-110 在使用不同的 PCIe 设备的内核邮件列表 [1] 上进行了相关讨论，但尚未确定我们系统的有效配置。 最好的办法是什么？ 感谢您的支持。 最大值 [1]https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 你好 i,MX95 还处于早期阶段，某些配置还没有设计出来。然而，您的 i.MX95（带 ATH12K，通过 PCIe2）在下列情况下出现故障 lf-6.12.y 但可在 lf-6.6.y 上运行提示新内核的 PCIe 或 Wi-Fi 堆栈存在回归或驱动程序交互变化，可能涉及 ATH12K 的 PCIe 电源管理单元 (ASPM)、MSI 映射或 PCIe 特定 PCIe 端点异常，通常可通过内核补丁或在较新内核的启动参数中禁用 ASPM 来解决；检查 dmesg 中是否有 PCIe 错误，比较设备树，并在 NXP/Linux 内核邮件列表中查找相关提交。  以下是潜在原因和故障排除步骤的详细介绍： 1.检查内核日志 （dmesg） 查找 PCIe 错误： 在失败的 lf-6.12.y 内核的 dmesg 中搜索"PCI","MSI","ATH12K","Error","Firmware", 或"Timeout" 消息。 固件加载：验证是否正确加载了 ath12k 固件，以及初始化过程中是否出现任何错误。  2。PCIe 电源管理单元 (ASPM) 常见问题：较新的内核通常默认启用主动状态电源管理 (ASPM)，这可能会导致嵌入式系统上的 ATH12K 等 PCIe 设备出现问题，尤其是较旧的固件/硬件。 尝试禁用 ASPM：将 p cie_aspm=off 添加到内核启动参数（例如，在 U-Boot 或 GRUB 中），然后再次测试。  3.Devicetree/DTB 的差异 比较 DTB： 生成并比较两个内核（.dtb 文件）中使用的设备树 Blob (DTB)。 查看 p ci2 的 PCIe 节点的变化，尤其是与中断、功率域或兼容性特性相关的变化。  4.内核驱动程序/固件回归 特定提交： lf-6.12.y 中的 ATH12K 驱动程序 ( ath12k)、 mac80211 或核心 PCIe/ARM 代码可能引入了一项破坏设置 的更改。 搜索邮件列表：查看 Linux 内核邮件列表 (LKML) 和恩智浦列表，了解相关补丁或有关 ath12k 、 i.MX95 和较新内核（6.12 以上）的讨论。  5.微星处理 中断重映射：在接收中断的同时，处理中断的方式（MSI-X 与 MSI、中断重映射）可能会发生微妙的变化。 检查 proc/interrupts 中的中断：查看不同内核的中断分布或计数是否不同。  6.固件 Blob 固件版本：确保为 ATH12K 使用正确的固件，并与较新内核的驱动程序兼容。有时，更新的驱动程序需要更新的固件。  总之，从 dmesg 开始，尝试禁用 ASPM；这些是导致嵌入式平台上较新内核出现 PCIe Wi-Fi 故障的最常见原因   此致 Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 虽然这些建议是调试问题的好指导，但我找不到解决方案，也就是说，并非所有的 MSI IRQ 向量都触发了驱动程序中的 IRQ 例程。 最后，我改变了 ath12k 驱动程序，只请求一个 MSI IRQ，从而解决了这个问题。 请注意，当前的 Linux 主版本不存在这个问题。 此致 最大值

NETC IEEE 1588タイマーソフトウェアはRMの要件を満たしていません S32ZE NETCリファレンスマニュアルの「文書識別子：S32E27NETCRMリファレンスマニュアルRev. 4、2024-12-12」、3.2.5.3.1ドリフトおよびエラー調整付き通常モードでは、「通常動作中、TMR_ADD更新を除く1588タイマー構成（たとえばTMROFF_H/L）を変更するには、タイムゲートスケジューリング、時間指定出発スケジューリング、ストリームゲーティング、レートポリシングなどのTSN関連機能を無効にする必要があります。」と記載されています。しかし、gPTP ソフトウェアも NETC ドライバもこの仕様を満たしていません。 GPTP_STACK RTD Re: NETC IEEE 1588 timer software does not meet the requirement of RM NXP の gPTP ソフトウェア モジュールがありますが、正しいでしょうか? 現在の時刻を更新するために関数「EthSwt_43_NETC_CorrectPtpClk」を呼び出します。 「タイマーの修正に関する機能を提供する」ということについては話していません。 私の質問は、gPTP が EthSwt_43_NETC_CorrectPtpClk() 関数を呼び出して現在の時刻を更新している間に、802.1Qbv 機能に影響を与えないようにするにはどうすればよいかということです。 Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん ETH ドライバー RTD2.0.1 は、次のようなタイムスタンプ用のいくつかの API 関数を含む ASR 21-11 に準拠しています。 このため、おっしゃる通りタイマーの修正に関する機能は提供されていないのではないかと思います。タイマー修正に関する機能は ASR23-11 でサポートされるようですが、ASR21-11 でそれらを使用する必要がある場合は、gPTP は要件を変更して要求を行う必要があります。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM ご清聴ありがとうございました。「ドライバーはこれまで、TMR レジスタから現在のタイマーを取得することだけをサポートしており、それらを構成することはサポートしていません」と述べられていますが、理解できません。OFFSET レジスタを変更する gPTP ソフトウェアはどうでしょうか?gPTP ソフトウェアでは OFFSET レジスタを必ず変更する必要があると思います。私の質問は、gPTP ソフトウェアが OFFSET レジスタを変更しようとしている間に、802.1Qbv 機能などの TSN 機能をスムーズに動作させるために、RM をどのようにフォローアップするかということです。 Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん NETC ドライバに関するこのトピックに回答します。 - ZE の最新リリースは RM rev 3 に続く RTD 2.0.1 であり、私の知る限り、次のリリース RTD 2.0.2 も RM Rev 3 に続きます。ただし、RM バージョンに関する更新がある場合、SW チームには新旧の RM 間の変更を確認するためのチケットがあります。彼らはその変化を感知CANと思います。 - 私の知る限り、タイムスタンプはこれまでドライバーでサポートされていたもので、デフォルトのカウント TMR_CTRL[TE] = 0 と、1588 タイマー TMR_CTRL[TE] = 1 で動作する RTD 2.0.1 に追加された EthEnableFreeRunningTimer 機能です。現在のタイマーは 1588 レジスタ TMR_FRT_L/H から取得されますが、TE をどこにも設定しなかったため、ここでバグが発生しているようです (詳細については、チケット: ARTDCC1-593)。とにかく、ドライバーはこれまで、TMR レジスタから現在のタイマーを取得することだけをサポートしており、それらを構成することはサポートしていませんでした。あなたが言った主張は、ユーザーが 1588 レジスタの設定を変更したい場合にのみ発生するようです。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん つまり、1588 レジスタ リストを変更する前に TSN 機能を停止したいということですか? 現在のドライバでは、TSN を停止する機能をサポートしていないことがわかりました。TSN の各機能を無効にしたい場合は、各テーブルのエントリを削除する必要があるようです。例えば： - レートポリシー: Netc_EthSwt_Ip_DeleteRatePolicerTableEntry(); - Netc_EthSwt_Ip_DeleteStreamGateControlListTableEntry(); - EthSwt_43_NETC_StopTas(); よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん ETH ドライバーについてもう何もわからない場合は、このトピックから RTD を削除して、gPTP の担当者が回答できるようにしてください。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは、 はい、まだ質問があります。イーサネット ドライバーの観点から 802.1Qbv を無効化/再有効化する方法の確認にご協力ください。また、このようなアクションが 802.1Qbv スケジュール サイクルの重大なトラフィック遅延を引き起こすかどうかを分析するのにご協力ください。 ありがとうございます ジェフ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは、 大変助かりました。ありがとうございます。 車載のお客様にとって非常に重要な点を 1 つ強調しておきます。TSN IEEE802.1Qbv 機能を使用している場合、当然ながら、802.1Qbv の時間同期要件に従って gPTP も有効にする必要があります。 gPTP が 1 つの 802.1 Qbv スロットにある重要なトラフィックに影響を与えるかどうかが懸念されています。私たち（NXP）はそれを明確にし、その方法を提供する必要があります。これは非常に厳密かつ明確な要件です。これは状況を理解するための良い例、あるいはユースケースです。 はい、確かに、お客様が有効にしている TSN 機能がいくつあるかはわかりません。しかし、すべてのユーザーが使用できるように、解決策が必要です。お客様はユースケースに基づいて適切な選択を行うことができます。 ありがとうございます ジェフ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは、 gPTP がタイマー オフセット レジスタを変更する前に TSN 機能を無効にしたいわけではありません。これは NETC RM の要件です。 お客様はNXPのRM仕様を満たすための公式ソリューションを求めています。TSN機能を無効にする方法、つまりこのような状況下でのIEEE802.1Qbv。お客様は、これはハードウェア要件とハードウェア関連のコーディングであるため、NXP によって提供されるはずだと想定しています。 ところで、あなたの提案はよく設計される必要があると思います。特に 802.1Qbv の場合、gPTP 同期アクションによってアプリケーション トラフィックが影響を受けないようにする方法。たとえば、一部のトラフィックが 1 つの Qbv スケジュール サイクル遅延する可能性はありますか? ありがとうございます ジェフ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん 私の観点からすると、TSN を停止する公式機能では、ETH ドライバからのこの要件を満たすことは困難です。ご覧のとおり、ポート ゲート タイム スケジュールを無効にするには、タイム ゲート有効ビットPTGSCR [TGE]をリセットするだけです。ただし、レート ポリシーなどの一部の TSN 機能では、この機能はこの表の要素に基づいて有効化/無効化されます。しかし、ETH からは、要素を削除または更新して無効にするためにこのテーブルにエントリが追加されたかどうかを知ることはできませんが、上位層ではこれをより適切に処理できます。このため、前回の回答では、各テーブルのエントリを削除する関数を呼び出すことを提案しました。 ユーザーがオプション機能（レートポリシング、ストリームゲート制御リストなど）を有効にしていない場合、関数EthSwt_43_NETC_StopTas()を使用して TSN を無効にすることができます。 とにかく、チケット ARTDCC1-607 を作成しました。何か見逃した場合に備えて、このチケットをフォローして SW チームからの分析を取得できます。RM Rev4 はまだ RTD リリースに適用されていません。このトピックに関して ETH について詳しいアイデアがない場合は、お知らせください。このCASEについては gPTP に任せ、引き続き gPTP 側からCAN回答させていただきます。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん 私の観点からすると、問題は有効になっている TSN 機能の数だけではありません。お客様が ASR コンテキストを使用する場合、これらの機能はマクロによってプリコンパイル時に有効/無効にされるだけでなく、各機能にも存在するためです。ご存知のとおり、レート ポリシング、ストリーム ゲートなどの各機能は、以下の表を通じて制御されます。 ユーザーが構成ツールで要素を構成しただけの場合、SW チームは、この機能を無効にするときに、エントリ ID を持つエントリをいくつ削除するかを制御できます。しかし、ユーザーが関数を呼び出して要素を追加した場合、SW はそれを知る方法がありません。しかし、ユーザーはアプリケーションからこれを制御できると思います。何か見逃したのかもしれませんが、TSN はタイマー値を参照するので、タイマー構成を変更する前に停止し、新しいタイマー値を取得するために再度開始するのが理にかなっていると理解しています。SW チームはそのチケットを分析する際に深い洞察力を発揮できると信じています。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは、 あなたはまだ私の質問を理解していないようですね。より詳しい説明をお願いします。お客様が Qbv 構成を持っており、それが以下のパラメータで実行状態にあると仮定します。 1. サイクルタイムは10msです 2. 10 ミリ秒の期間内に、それぞれ 5 ミリ秒のスロットが 2 つあります。つまり、ゲート リストには 2 つのエントリがあります。 3. 最初のタイムスロットが開いている間に、NETC が重要なフレームを送信していると仮定します。この時点で gPTP は現在の時刻の更新を開始します。RM 要件に従って、お客様は 802.1Qbv を無効化/再度有効化する必要があります。 4. 802.1Qbv が再度有効になった後、NETC ハードウェアが引き続きタイム スロット 1 を開いたり、ゲート リストの 2 番目のエントリに移動したり、新しい Qbc スケジュール サイクルを待機したりする可能性があります。ハードウェアが 2 番目のエントリに進むと、NETC キュー内の重要なフレームが次の 10 ミリ秒サイクルで送信されることを意味します。そして、大きな遅延が発生し、アプリケーションに影響を及ぼす可能性があります。 5. お客様はこのような状況を回避する方法を尋ねています。つまり、アプリケーションへの影響を軽減するために、Qbv をスムーズに無効化/再有効化する方法です。 物事が明らかになることを望みます。 ありがとうございます Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは@shuangjunzhuさん 802.1 Qbv の機能は NETC とスイッチの両方をサポートしていることがわかりました。したがって、この機能は次の方法で設定できます。 - Eth_NETC: - ポートスイッチ: 機能は次のとおりです。 ETH_NETCの場合: - Eth_43_NETC_StartTas() - Eth_43_NETC_StopTas() ポートスイッチの場合: - EthSwt_43_NETC_StartTas() - EthSwt_43_NETC_StopTas() この質問「この種のアクションが 802.1Qbv スケジュール サイクルの 1 つで重大なトラフィック遅延を引き起こすかどうかを分析する」については、私の観点からすると、この機能を有効/無効にする関数 Netc/PortSwt_Ip_ConfigPortTimeGateScheduling() を見るとわかるように、この機能を無効にするには、1 ビットをリセットするだけで、この機能を有効にするには、ゲート タイムを有効にして、ゲート タイム テーブルを設定する必要があります。今回は計測可能です。 「 802.1Qbv スケジュール サイクルの 1 つ」とは、ゲート制御リストの実行時間を繰り返す必要があるという意味だと理解していますか?そうであれば、これを設定することができます。 よろしくお願いいたします。 ニ Re: NETC IEEE 1588 timer software does not meet the requirement of RM こんにちは、 前回の返信で述べた 2 つの機能以外に、TAS を有効/無効にする別の方法は見つかりませんでした。私の観点からすると、タイム ゲート制御を無効にすると、時間間隔、サイクルなどのすべての機能も無効になります。TAS の無効化と有効化の間の期間には、gPTP からのタイマーの更新を完了するまでの時間が含まれます。TAS を有効にすると、ベース時刻が現在の時刻に更新されます。ただし、新しいベース時間 = 次の古い間隔時間でない場合は、要件を確認できません。 これについてはもうわかりませんが、SW チームがあなたのCASEについて提案できるように、上記のチケットでこの質問も更新しました。 よろしくお願いいたします。 ニ

linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx linux6.12+imx8mp内核启动时报告： [ 0.057737] /soc@0: Fixed dependency cycle(s) with /soc@0/bus@30000000/efuse@30350000/unique-id@8 [ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.059239] /soc@0/interrupt-controller@38800000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/miscgrp [ 0.061986] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/hoggrp [ 0.062566] imx8mp-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver [ 0.063301] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.064431] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.065497] /soc@0/bus@30000000/clock-controller@30380000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 原因是什么？需要处理吗 Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is normal, no need to deal with it. Best Regards, Zhiming Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is the patch that was introduced upstream of the kernel, the commit message is: driver core: fw_devlink: Stop trying to optimize cycle detection logic commit bac3b10b78e54b7da3cede397258f75a2180609b upstream. In attempting to optimize fw_devlink runtime, I introduced numerous cycle detection bugs by foregoing cycle detection logic under specific conditions. Each fix has further narrowed the conditions for optimization. It's time to give up on these optimization attempts and just run the cycle detection logic every time fw_devlink tries to create a device link. The specific bug report that triggered this fix involved a supplier fwnode that never gets a device created for it. Instead, the supplier fwnode is represented by the device that corresponds to an ancestor fwnode. In this case, fw_devlink didn't do any cycle detection because the cycle detection logic is only run when a device link is created between the devices that correspond to the actual consumer and supplier fwnodes. With this change, fw_devlink will run cycle detection logic even when creating SYNC_STATE_ONLY proxy device links from a device that is an ancestor of a consumer fwnode. The fw_devlink framework on top of 6.12 is more robust than before, and Fixed dependency cycle(s) with indicates that fw_devlink detected the ring and solved the problem by adjusting the linking policy (e.g., downgrading certain link types or not creating certain links). This is not an error, but an informational note that the system handles potential deadlock risks at boot time. driver core: fw_devlink: Make cycle detection more robust fw_devlink could only detect a single and simple cycle because it relied mainly on device link cycle detection code that only checked for cycles between devices. The expectation was that the firmware wouldn't have complicated cycles and multiple cycles between devices. That expectation has been proven to be wrong. For example, fw_devlink could handle: +-+ +-+ |A+------> |B+ +-+ +++ ^ | | | +----------+ But it couldn't handle even something as "simple" as: +---------------------+ | | v | +-+ +-+ +++ |A+------> |B+------> |C| +-+ +++ +-+ ^ | | | +----------+ But firmware has even more complicated cycles like: +---------------------+ | | v | +-+ +---+ +++ +--+A+------>| B +-----> |C|<--+ | +-+ ++--+ +++ | | ^ | ^ | | | | | | | | | +---------+ +---------+ | | | +------------------------------+ And this is without including parent child dependencies or nodes in the cycle that are just firmware nodes that'll never have a struct device created for them. The proper way to treat these devices it to not force any probe ordering between them, while still enforce dependencies between node in the cycles (A, B and C) and their consumers. So this patch goes all out and just deals with all types of cycles. It does this by: 1. Following dependencies across device links, parent-child and fwnode links. 2. When it find cycles, it mark the device links and fwnode links as such instead of just deleting them or making the indistinguishable from proxy SYNC_STATE_ONLY device links. This way, when new nodes get added, we can immediately find and mark any new cycles whether the new node is a device or firmware node. Best Regards, Zhiming

Failed to load static DPL with 8x DPDMUX Hi Community, Using dynamic creation of DPDMUXs and DPNIs successfully, and generate the DPL by following commands: 8x ls-addni --fs-entries=8 --num-queues=8 -n source /usr/local/dpdk/dpaa2/dynamic_dpl.sh ... 8x restool dpdmux create 8x restool dprc connect dprc.1 --endpoint1= .n.0/1/2 --endpoint2= / /dpni.k> restool dprc generate-dpl dprc.1 > dpl-8-dpdmux.dts Update the static DPL with dpl-8-dpdmux.dtb (generate by dtc tool) for uboot to initiate MC layout. The error shows as blow: [E, mem_mng_get_phys_mem:655] MAJOR mem. manager memory allocation failed [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[6] - dpbp_allocate_buffers(), failed to allocate dpbp buffers [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, mem_mng_get_phys_mem:655] MAJOR mem. manager memory allocation failed [E, mem_mng_get_phys_mem:658] Required size 0x000040000 alignment 0x000000100 exceeds available memory for partition ID 7 [E, init_bman_bp:399, DPDMUX] ID[7] - dpbp_allocate_buffers(), failed to allocate dpbp buffers [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure : -12 [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpmac@9 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpni@15 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@6 and dpni@7 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpmac@10 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpni@16 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, resman_is_link_permitted:6375, RESMAN] Object wasn't found [E, linkman_probe_cb:205] No common ancestor - Failed to connect dpdmux@7 and dpni@8 [E, subnode_process:155] Probing module 'connection' return error code -1. Continue dpl processing... [E, dpl_process:527] Error while parsing 'connections'. Skip processing the rest of DPL. [E, main:198] DPL processing failed; continuing...  Is there any limitation on the static DPL to support same layout as dynamic way? QorIQ LS2 Device Re: Failed to load static DPL with 8x DPDMUX Hi yipingwang, Using '--max-dmat-entries' in dynamic creating layout don't change the final dts by 'restool dprc generate-dpl dprc.1'. So, I just give it a try by adding following elements 'mem-size' and 'max-dmat-entries' in .dts. manually: dpdmux@0 {     compatible = "fsl,dpdmux";     options = "DPDMUX_OPT_CLS_MASK_SUPPORT", "DPDMUX_OPT_AUTO_MAX_FRAME_LEN";     method = "DPDMUX_METHOD_CUSTOM";     manip = "DPDMUX_MANIP_NONE";     num_ifs = <0x2>;     mem-size = <0x100>;  // this is manually added by me     max-dmat-entries = <0x8>; // this is manually added by me }; Unfornately this doesn't fix it, the same error message showing from MC debug. Please also check my dpl as enclosed. Re: Failed to load static DPL with 8x DPDMUX Please try whether the following method is possible. When you create DPDMUX, please specify "--max-dmat-entries=8" to reduce the resource allocation. --max-dmat-entries= max entries in DPDMUX address table. Default is 64. If your problem persists, please share your whole console log to create DPDMUX and generate DPL file. In addition, which processor are you using? Re: Failed to load static DPL with 8x DPDMUX Hi, I've managed to fix this issue by correcting the DPL parameter names.

如何下载芯片的相关资源的文档 例如：S32K3xx_interrupt_map.xlsx Re: 如何下载芯片的相关资源的文档 Hi@PQF 在官网下载数据手册和指导手册。在指导手册的附件中可以找到你要的这些文档。 https://www.nxp.com/products/S32K3 Senlent_0-1766974059469.png Senlent_1-1766974085433.png

无法将 iMX93EVK 中的 lpuart1 更改为 lpuart7 在过去的一个多月里，我一直在尝试将默认控制台从 lpuart1 更改为 lpuart7。我想更改 linux 控制台和 u-boot 控制台，或者至少我想查看日志。这是为了让 iMX93EVk 的 SOC 在新的载体上工作。然而，我却无法做到这一点。这是我尝试使用的补丁。还有我发现的所有我认为可以帮助我的帖子。我错过了什么？ i-MX-93-91-使用yocto项目调试控制台重定位 i-MX-Processors/Change-UART-for-imx93-in-uboot-and-kernel i-MX 处理器/imx8ULP 将 u-boot 串行控制台从 UART5 更改为 UART4 非常感谢你们的帮助，谢谢 Linux Re: Cant change lpuart1 to lpuart7 in iMX93EVK 你好 要成功地将调试控制台从 lpuart1 更改为 lpuart7，你需要修改三个关键元器件：U-启动、Arm 可信固件和 Linux 内核配置。 完整解决方案： 1.对于 U-Boot（lf_v2024.04 分支）： - 修改设备树文件以更新控制台路径和引脚配置 - 更新板配置以指向 lpuart7 - 使用 imx93_11x11_evk_defconfig 作为配置基础 2. 对于 Arm 可信固件（lf_v2.10 分支）： - 更改 ATF 源中的 UART 控制台位置 - 更新 IMX_LPUART_BASE 以指向 lpuart7 的基址 - 在取消设置 LDFLAGS 后使用 "make plat=imx93" 构建 3. 对于 Linux 内核： -将 bootargs 更新为引用 ttylP6（对应于 lpuart7） -更新设备树中的选定部分 该过程需要使用这些修改后的元器件重建 flash.bin 映像。另一位客户需要将 i.MX93 上的 UART1 重新映射到 UART8，也成功解决了类似问题。 此致 Re: Cant change lpuart1 to lpuart7 in iMX93EVK 谢谢，我无法确认该解决方案是否有效。我已经执行了您的所有更改，但发现错误出在硬件本身。一旦定制载体修好了，一切都测试好了，我就可以确认了。 感谢您的回复

k344中心对齐pwm中心点触发adc bctu采样 基于https://community.nxp.com/t5/S32K-Knowledge-Base/RTD400-K344-Center-Aligned-PWM-Trigger-ADC-BCTU/ta-p/2034211、我想知道为什么需要三次 BCTU 触发信号中断才能触发 BCTU 水印。我想实现只触发信号一次中断，然后在中断中修改PWM周期，读取ADC值等。在 EB MCAL 开发的基础上，有哪些好的解决方案或示例例程可以实现相同的功能？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您关注我们的产品并为我们的社区做出贡献。 您可以直接回复帖子，以获得帖子主人的反馈。 另一方面，你可以参考另一种方法，使用单个 BCTU 触发信号： S32M27x/S32K3 - eMIOS/BTCU/ADC/DMA - [RTD600] -> https://community.nxp.com/t5/S32M-Knowledge-Base/S32M27x-S32K3-eMIOS-BTCU-ADC-DMA-RTD600/ta-p/2155542 有关 MCAL 的实现，请参阅 ADC 到 PWM 的硬件抽象层示例： 前往 S32K3 页面 -> 设计资源-> 软件-> S32K3 参考软件-> 汽车软件-S32K3-硬件抽象层-> SW32K3 HAL 集成示例 2025.07 它执行以下 ADC 触发信号： _Leo__0-1764612607002.png 同时，它根据捕获的 ADC 值更新占空比。 希望这些信息对您有所帮助。 Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您的解决方案。我想知道多次触发信号中断的原因以及避免此类中断的方法。或者，我是否有可能通过配置禁用该中断源？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 您好， 如果启用 BCTU 触发信号通知，则在 BCTU 触发信号 ADC 时调用。如示例中的 BCTU CL 包含 3 个项目，每个输入 (EMIO) 触发信号将触发三次 ADC。 只需在“触发信号”选项中输入 NULL 即可禁用此通知。 BR, Petr

串行下载器 - 奇怪的问题 我在 RT1052 上遇到了一个奇怪的问题，如果我将启动引脚配置为串行启动。 它无法启动固件，也不会进入串行下载器模式（既不是 UART 或非 USB）。 但当我将 GPIO_B0_15 下拉至 GND 时，串行下载正常工作。 我找不到任何关于这个信号对启动过程的影响的文档。 - 处理器出厂时是全新的 - TXD1/RXD1 有上拉电阻 顺便说一下：烧录 BT_FUSE_SEL 串行下载后可以正常工作 我们已经开发了几个类似的电路，以前从未遇到过这个问题。

在挂起期间将 GPIO 状态保持在 RAM 中 您好，NXP团队： 我们使用 s32g399ardb3 作为定制设计板的参考并使用 BSP35。 我有一个低电平有效的 GPIO (PB_12)，默认情况下使用 P3_3V_IO3P3 拉高。 我关注了 电路板支持包 UM 第 " 23.3 章挂起到 RAM " 让板暂停到 RAM 中。 但 P3_3V_IO3P3 会在 PB_12 变为低电平时关闭。 目前，我们通过 Linux 内核驱动程序来控制 GPIO 的动态，但在添加挂起相关功能后，我仍将 GPIO 状态保持为高电平失败。 我应该在 ATF 中移动 GPIO 动态控制吗？ 谢谢！ Re: Keeping GPIO status during suspend to RAM hi，GG0712 感谢您的回复。 S32G 使用 I2C 控制 PMIC，一般来说，您可以在 A 核中操作 PMIC，但我们不提供相关代码和文档。 另外，PB_12 是 VDD_IO_B 功能域，如果你想拉出引脚，你应该是 VDD_IO_B 的电压。设置 VDD_IO_B 电压时，可以尝试对引脚 PB_12 进行内部上拉。 Joey_z_1-1755574260443.png 有关电源的更多信息，请参见 AN14063。 Joey_z_0-1755574217693.png 希望能帮到你。 BR 乔伊 Re: Keeping GPIO status during suspend to RAM 你好@Joey_z、 如果我们目前没有使用 M 内核，这种方法是否可行？ 谢谢！ Re: Keeping GPIO status during suspend to RAM hi，GG0712 感谢您的回复。 这是 M 核 PMIC 模块设置方法，使用 S32DS IDE，如下图所示。 它可以在待机模式下设置 LDO3 和其他 vr5510 输出电压。 Joey_z_0-1755068905359.png 此设置适用于 M Core，S32G 使用 I2C4 与 vr5510 连接。这就是使用 12C4 作为 A 核来保持 LDO3_3v3 的方法。 Joey_z_1-1755069168470.png 希望能帮到你。 BR 乔伊 Re: Keeping GPIO status during suspend to RAM 你好@Joey_z、 如何通过您的图片设置LDO3_3v3？ 谢谢！ Re: Keeping GPIO status during suspend to RAM hi、GG0712 感谢您的回复。 请参阅 RMS32G3.pdf 和附件 S32G_IOMUX.xlsx，在待机期间，PB_12 的焊盘状态被设置为掉电模式。 Joey_z_0-1754983426001.png 因此，我认为可以在待机阶段将引脚设置为高电平电压。 您可以尝试将 LDO3_3v3 设置为该引脚上拉，并将 vr5510 设置为保持 LDO3_3v3 的电压。 Joey_z_1-1754983794754.png 此外，您还可以尝试在待机阶段将唤醒引脚选择为高电平电压。 希望能帮到你。 BR 乔伊 Re: Keeping GPIO status during suspend to RAM 你好，Joey_z、 我们使用我们的设计板并使用 PB_12 作为 GPIO。 谢谢！ Re: Keeping GPIO status during suspend to RAM hi，GG0712 感谢您与我们联系。 你使用 RDB3 板吗？您想使用 GPIO (PB_12) 作为 FLEX_LIN2_RX 的功能吗？ BR 乔伊

S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 現在、SimulinkでPWM生成にFlexIOピンを使用する方法を理解しようとしています。Simulinkには、PWM生成にFlexIOピンを使用するためのブロックは見当たらず、I2C、SPI、およびUARTのみに使用されています。どんな助けでも大歓迎です。 Re:S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 教えて頂きありがとうございました

clrc663 lpcd i 和 q 值 i 得到 0x00 我正在使用 clrc663 作为读卡器我在那里实现了 lpcd 模式我在运行 lpcd 校准功能时遇到了问题我得到了 i 而且 q 值是 0x00 我从天线得到的是什么问题怎么解决这个问题 我使用的这个函数   /* 执行 LPCD 校准 */ phStatus_t Calibrate_LPCD(uint32_t dwLPCDDemo, uint32_t *pdwLPCDRefValue) { phStatus_t wStatus； uint8_t bValueI = 0； uint8_t bValueQ = 0； uint8_t bVersion = 0； uint8_t bDigitalFilter = PH_ON； uint16_t wDetectionOption = PHHAL_HW_RC663_FILTER_OPTION1； uint16_t wPowerDownTimeMs = LPCD_POWERDOWN_TIME； uint16_t wDetectionTimeUs = LPCD_FIELD_ON_DURATION； DEBUG_PRINTF("\nLPCD 校准开始。"); phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5)；   /* 配置 LPCD 模式默认值，以执行 LPCD 校准循环。 * 提供输入参考 I 和 Q 值为零，并将检测时间提供给 * 在此持续时间内打开射频，使用 I 和 Q 通道值测量负载变化。 * 配置合适的掉电时间以节省 RC663 读卡器IC 的功耗。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_SetConfig(pHal，PHHAL_HW_RC663_CMD_LPCD_MODE_DEFAULT、 bValueI、bValueQ、wPowerDownTimeMs、wDetectionTimeUs）； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_SetConfig.")； /* 读取版本寄存器，以区分 RC663 Old（RC66301、RC66302）和 RC663 Plus（RC66303）。*/ wStatus = phhalHw_Rc663_ReadRegister(pHal,PHHAL_HW_RC663_REG_VERSION,&bVersion)； DEBUG_PRINTF("\nphhalHw_Rc663_ReadRegister.")； CHECK_STATUS(wStatus)； 如果 (bVersion == PHHAL_HW_CLRC663PLUS_VERSION)     { /* 配置充电泵，使其具有较高的检测范围。 * 启用电荷泵会在检测阶段增加功率级 * 探测范围。这导致平均电流消耗增加。*/ wStatus = phhalHw_SetConfig(pHal,PHHAL_HW_RC663_CONFIG_LPCD_CHARGEPUMP,PH_ON)； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_SetConfig.")； /* 配置数字滤波器会触发信号 RC663 Plus 算法以获得倍数的平均值 * 检测 I 值和 Q 值的变化。这反过来又延长了射频开启时间 * 增加平均电流消耗。*/ wStatus = phhalHw_SetConfig(pHal，PHHAL_HW_RC663_CONFIG_LPCD_FILTER、 ((uint16_t)(bDigitalFilter)|wDetectionOption))； CHECK_STATUS(wStatus)；    }   /* 执行 LPCD 校准周期并获取 LPCD 参考 I 和 Q 值。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_GetConfig(pHal,&bValueI,&bValueQ)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_GetConfig.")； CHECK_STATUS(wStatus)；   *pdwLPCDRefValue = ((bValueI) | (bValueQ<< 0x8))； DEBUG_PRINTF("\npdwLPCDRefValue.")；   DEBUG_PRINTF("\nLPCD 校准成功。");   返回 PH_ERR_SUCCESS； } 然后我在主 while 循环中调用 /* ------------------------------------------------------------------ * 开机后运行一次 LPCD 校准 * ------------------------------------------------------------------ */ phStatus_t LPCD_Calibrate(void) { phStatus_t status; uint32_t refVal; char dbg_buf[64]； // 确保在校准前开启 RF phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal,PHHAL_HW_TIME_MILLISECONDS,5)； status = Calibrate_LPCD(LPCD_DEMO_MODE_DEFAULT，&refVal)； // 校准后关闭射频 phhalHw_FieldOff(pHal)； if (status == PH_ERR_SUCCESS) { gLpcdValueI = (uint8_t)(refVal& 0xFF); gLpcdValueQ = (uint8_t)((refVal 0xFF)); gLpcdValueQ = (uint8_t)((refVal 0xFF)).>> 😎 & 0xFF); gLpcdCalibrated = 1； sprintf(dbg_buf,"LPCD Calibration OK (I=0x%02X, Q=0x%02X)\r\n", gLpcdValueI, gLpcdValueQ)； DEBUG_UART2((unsigned char*)dbg_buf, strlen(dbg_buf)); } else { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28); } return status; } 如果 (!lpcdCalibrated)     { 如果 (LPCD_Calibrate() == PH_ERR_SUCCESS) { lpcdCalibrated = 1; // 标记为已完成 DEBUG_UART2((unsigned char*)"LPCD Calibration OK\r\n", 23)；          } 不然 { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28)；      }    } Re: clrc663 lpcd i and q value i getting 0x00   您好，先生， 非常感谢您与我们分享您的示意图。不过，我还是要问一下你们天线的史密斯图。我们确实有一份应用笔记，其中显示了使用廉价的纳米VNA进行这些测量的步骤。 Re: clrc663 lpcd i and q value i getting 0x00 我在这里附上我的硬件测试和原理图，在正常模式下，我得到的是 uid，这不是问题；在 lpcd 模式下，我得到的是 0x00,0x00 的 q 值。在此查看我的测试文件。 Re: clrc663 lpcd i and q value i getting 0x00 抱歉，但是对自定义板的支持非常有限。   要提供任何具体信息，我需要您的硬件，因为评估套件的天线设置配置与您的配置存在很大差异。   不过，您是否介意分享一下天线的史密斯图和原理图，这将是我们提供良好建议的一个很好的起点。   正如我在上一篇文章中提到的那样，我们建议从一开始就遵循一些步骤。其中之一是将我们的 EVK 与您的新天线和新的匹配电路一起使用。所有这些都显示在我们的许多文档中。请看 NFC天线设计|恩智浦半导体视频2。   发送 RF 开启命令后，I 和 Q 值应显示与 0x0 不同的值。 Fabian_R_0-1758670886630.png Re: clrc663 lpcd i and q value i getting 0x00 我使用的是带有 stm32 硬件的定制 PCB Clrc663，只有在软件中天线调谐是正确的，我使用了 nfcrdlibEx6_rc663_LPCD_Demo.c 库中的校准演示代码，但 i 和 q 值均为 0x00，然后我使用错误寄存器来确定我在其中出现了什么错误。 printf debug i getting === EEPROM / LPCD 检查开始 === VERSION(0x7F)=0x1A ERROR(before)=0x00 ERROR(after LOADREG)=0x80 > > > EEPROM 错误 (0x80) 仍然存在。LPCD 可能无法正确校准！ === EEPROM / LPCD 检查完成 === // 这是代码 phStatus_t Rc663_EepromInitAndCalibrateLPCD( phhalHw_Rc663_DataParams_t *pHal, uint32_t *pdwLPCDRefValue) { phStatus_t status; uint8_t bVersion, bIrq1, bErr； uint8_t bValueI = 0, bValueQ = 0; char dbg[64]; uint8_t eepromVal; uint8_t addr; sprintf(dbg,"\r\n=== EEPROM + LPCD Init ===\r\n"); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 1.读取芯片版本 */ status = phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_VERSION,&bVersion)； CHECK_STATUS(status); sprintf(dbg,"VERSION(0x7F)=0x%02X\r\n", bVersion); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 2.清除任何现有错误 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(before)=0x%02X\r\n", bErr); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 3. 强制将 LOADREG 从 EEPROM 写入寄存器 */ status = phhalHw_Rc663_WriteRegister(pHal, PHHAL_HW_RC663_REG_COMMAND, PHHAL_HW_RC663_CMD_LOADREG)； CHECK_STATUS(status); /* EEPROM 加载稍有延迟 */ phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5); /* 4.再次检查错误寄存器 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(after LOADREG)=0x%02X\r\n", bErr)； DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); if (bErr& PHHAL_HW_RC663_BIT_EE_ERR) { sprintf(dbg,"> > > EEPROM 错误 (0x%02X) detected！\r\n" 、berR); DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg)); /*---EEPROM 转储（前 16 个字节用于调试）---*/ for (addr = 0；addr < 0x10；addr++) { phalHW_rc663_cmd_reade2 (phAL，addr，1，& eePromade2) val); spr intf (dbg，" EEPROM [0x%02X] = 0x%02X\ r\n "，addr，eepromVal)；DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg))；} /*---绕过 EEPROM 继续手动初始化---*/ sprintf (dbg，" 绕过 EEPROM，使用手动 RF 设置...\ r\n ")； DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg))；phhalHW_rc663_WriteRegister（phal，PHHAL_HW_RC663_RC663_REGISTER，PHAL_HW_RC663_RC663_RC663_）； phalHW_RC663_WriteRegister REG_TXAMP，0x1F）；phhalHW_RC663_WriteRegister（phal，PHHAL_HW_RC663_REG_DRVCON，0x18）；} else {sprintf（dbg，" EEPROM LOADREG OK。 \ r\n "); DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg));} /* 5. 清除 IRQ 标志 */ phHALHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ0、0x7F）；phalHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ1、0x7F）；/* 6。 启用校准模式 */ phHALHW_RC663_WriteRegister (phAL、PHHAL_HW_RC663_REG_LPCD_OPTIONS、0x02)；/* 7. 启动 LPCD_CALIBRATE（0x37 是隐藏的校准命令）*/ phhalHW_RC663_WriteRegister（ phal，PHHAL_HW_RC663_REG_COMMAND，0x37）；/* 8。 等待 LPCDIRQ */ 做 {phHalHW_rc663_readRegister ( phAL、PHHAL_HW_RC663_REG_IRQ1、& birQ1);} while (! (birQ1 & PHHAL_HW_RC663_BIT_LPCDIRQ)); /* 9. 读取 I/Q 结果 */ phHALHW_RC663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_I、& bValueI）；phalHW_rc663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_Q、& bValueQ）；/* 10。 存储 */ *pdwLPCDRefValue = (uint32_t)bValueI | ((uint32_t)bValueQ<< 8); sprintf(dbg,"[LPCD] 校准完成：I=0x%02X Q=0x%02X Ref=0x%08X\r\n", bValueI, bValueQ, *pdwLPCDRefValue); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); return PH_ERR_SUCCESS; } Re: clrc663 lpcd i and q value i getting 0x00 您好，先生， 为了校准 CLRC663 的 LPCD，我们强烈建议您使用NFC Cockpit。 这是一个图形用户界面工具，允许用户以图形方式对天线进行微调，同时进行LPCD 校准（第 4.5 节）。我们鼓励您使用这种方法，因为校准必须根据您自己的设计进行。没有任何手册可以按部就班地完成这一程序。 NFC Cockpit 允许用户在读写器卸载和加载时进行实时校准。 请探讨查看以下天线设计视频系列的第 4 段视频的可能性：NFC 天线设计 | 恩智浦半导体

复制： 手动输入"Os Isr 处理程序" on Ipcf 本帖复制自 此处 你好我有一个关于在 Vector Davinci 配置器上设置 IPCF 的问题。 环境 我使用的环境如下。 ・Microcontroller : S32K358 ・Vector Davinci configurator classic : 5.30.30 SP1 ・RTD : SW32K3_S32M27x_RTD_R21-11_5.0.0 ・IPCF : SW32K3_IPCF_4.2.0_D2412 背景& 问题 我正试图使用 Vector Davinci configurator classic 为 AUTOSAR 项目配置 "IpcfInstance "的 "Os Isr Handler"。 Os Isr 处理程序 "的 [...] 显示的窗口需要手动输入。 要求是否正确？ 如果要求正确，请告诉我需要什么样的路径。 如果要求不正确，我们是否需要其他插件或其他设置？ KONISH_0-1757660133697.png KONISH_1-1757660142016.png 顺祝商祺！ IPCF 优先级：中等 Re: Copy: Manual input of "Os Isr Handler" on Ipcf 嗨，拉杜、 请查看原始主题，因为我们在那里得出了最终结论。 https://community.nxp.com/t5/S32K/Manual-input-of-quot-Os-Isr-Handler-quot-on-Ipcf/td-p/2168682 如果您还有问题，请告诉我。 顺祝商祺！ 丹尼尔 Re: Copy: Manual input of "Os Isr Handler" on Ipcf 你好 您可以在下面找到新问题的答案： 问：根据您的回答，在申请 IPCF 时，IPCF 的 OsISR 是否必要？ 答：只有当你想在 I nterrupt 模式下使用 osiSR 时，才需要将其添加到 IPCF 中（一个内核触发信号 MU 中断，另一个内核接收它并在回调函数中处理消息）。IPCF 可以在轮询模式下使用，无需配置 IPCF 中断，无需从 IPCF 配置中配置 Os ISR 处理器。在这种情况下，Inter Core Rx IRQ 参数应设置为IPC_IRQ_NONE。 问：用 IPCF 的 osiSR 路径填写上面 " Os Isr " 的 " 参考路径 " 是对的吗？ 答：如果图片中出现的这四个IRQ中的一个应用于IPCF，则使用中断来通知另一个内核有数据，然后使用所需的 OSISR 路径手动填充参考路径，如下图所示。 nxf94150_0-1758201647900.png 如果配置的中断不适用于 IPCF，则可以使用轮询模式（IPCF 不需要中断），或者在 Os 中为 IPCF 添加专用的中断，并在 IPCF 配置中的 Os ISR 处理程序中进行参考。 另请查阅IPCF_S32K3_4.2.0_User_Manual.pdf第2.2.1章与 NXP RTOS 的集成。 问：如果 IPCF 需要 OsISR，我们对 IPCF 的 OsISR 有参考吗？ 答：我想上面的回答也包括这一点，如果不包括，请提供更多细节，因为不清楚。 问：例如，IPCF 设置的 osiSR 的 " Isr 资源参考 " 需要哪种参考资料？ 答："Isr Resource Ref" 不使用 OsISR，您不需要为 IPC 配置任何东西。 如果还有其他问题或不清楚的地方，我们可以召开会议，为您提供 IPCF 配置方面的支持。 顺祝商祺！ 丹尼尔 Re: Copy: Manual input of "Os Isr Handler" on Ipcf 来自 Daniel Hermenczi 的意见： " 你好 、 我们有几点需要澄清： 您是否使用 Vector 提供的 AUTOSAR Os？ 因为在您分享的图片中，我们看不到操作系统的配置，问题是是否配置了一个或多个 OsISR？ 如果你已经配置了它们，那么这可能是一个问题，你需要使用手动选项来选择对已配置的 OsiSR for IPCF 参数 Os Isr Handler 的参考。 以手动配置为例，您需要将高亮显示的路径与您的特定 OsISR 路径一起使用 如果需要更多信息，请告诉我。 顺祝商祺！ Daniel" 客户回复： "1.您是否使用 Vector 提供的 AUTOSAR Os？ 是的，我使用 AUTOSAR Os。 2.因为在你分享的图片中，我们看不到操作系统的配置，问题是是否配置了一个或多个 OsISR？ 是的，我的项目中有以下四种 OsISR 配置。 它们是用于 CAN 通信的 OsISR。 补充问题 根据您的回答，在申请 IPCF 时，IPCF 的 OsISR 是否必要？ 用 IPC@@ F 的 osiSR 路径填写上面 " Os Isr Handler " 的 " 引用路径 " 是对的 吗？ 如果需要用于 IPCF 的 osiSR，我们对 IPCF 的 osiSR 有参考吗？ 例如，OsiSR 的 " Isr 资源参考 " 需要什么样的参考才能进行 IPC F 设置？ 谢谢，并致以最崇高的敬意。"