KSDK发布的内容 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetis SDK v2 现已推出！ Kinetis SDK v2 简介 KSDK 的第一步 如何开始使用 KSDK * 已发布示例列表： KSDK示例列表* 已发布文件清单： KSDK 文件清单* *以上所有源代码仅供示例使用。恩智浦不对用户应用程序中使用这些代码承担任何责任。 概述

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？ (2) 我使用 S32Z RTD2.0.1 测量了引脚写入 GPIO 的执行时间，并测量了示波器通道 CH5 - TESTFLAG 的高/低时间，大约为 3.4us。您是否有可能确认一下它们看起来是正常还是太慢了？ (3) 我不知道我错过了什么。     Re: S32Z RTU0 core0 performance issue 随函附上包装标记的照片。 0   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 2) 代码使用 S32DS 版本 3.6.7 Build 260420 进行编译和链接。使用 S32DS 的先前版本（例如版本 3.6.6 或 3.6.5）时没有任何变化。我正在为 S32Z2XX 使用 RTD2.0.1。 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 来设置该值。您能确认一下是否设置了这个寄存器吗？ 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 章来检查缓存配置。 高速缓存机制有助于提高内存性能。您可以下载以下图片。 此外，GPIO 翻转到测量时间，主要反映了外设的"延迟" 访问路径，但会对 CPU 内核运算性能产生偏差。另外，在此应用程序中包含CoreMark的内容，您可以作为测试的参考。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 谢谢，我将阅读上述应用笔记（AN14245 S32ZE 安全可靠的高性能实时处理器）的第 3 章和第 4 章，了解缓存的正确设置。 顺便提一句，获得的 CoreMark 分数太低，这也是支持案例的起因。

如何转换数字信号的电压？（日语博客） 0. 目录 0. 目录 1. 什么是电压电平转换器？ 2. 数字信号 2.1 各种数字信号 2.2 CMOS 和 TTL：使用简单的电压高电平和低电平表示逻辑电平信号 2.3 输入/输出电压规格：VOH/VOL 和 VIH/VIL 2.3.1 输出电压规格：VOH 和 VOL 2.3.2 输入电压规格：VIH 和 VIL 2.3.3VOH/VOL 与 VIH/VIL 之间的关系 3. 基本电压电平转换方法：单向信号转换 3.1 即使芯片的电源电压不同，也不需要进行转换的示例。 列：TTL 值 VIH(min) = 2.0V 和 VIL(max) = 0.8V 是如何确定的？ 3.2 需要转换的示例 3.2.1 利用开漏输出进行转换 3.2.2使用标准逻辑（通用逻辑）芯片进行转换 4. 需要自动方向切换的双向信号转换。 4.1 使用单个MOS晶体管的双向转换 4.2 使用专用设备的双向转换 4.2.1 I²C信号电压转换芯片 4.2.2 高速双向开漏信号电压转换芯片 4.2.3 双向推挽式信号电压转换器芯片 4.2.4I3C信号电压转换器芯片 4.2.5 基于缓冲区的转换 5. 总结 5.1 博客中介绍的方法/零件编号的比较 6. 参考资料 1. 什么是电压电平转换器？ 连接数字电路时，可以直接连接信号线…… 事实并非如此；如果“逻辑电平电压”不匹配，它可能无法工作、变得不稳定，或者在最坏的情况下，损坏芯片。 这时，电压电平转换器（也称电压电平移位器）就派上用场了。 电压电平转换器是一种允许不同电源电压的数字电路之间交换信号的电路。 例如，在以下情况下需要用到它： 3.3V 微控制器 ↔ 5V 传感器连接 将 1.8V FPGA 连接到 3.3V 外围设备 图 1：信号电压差异   本博客解释了数字电路中使用的各种逻辑电路类型（*TTL、*LVTTL、*CMOS）之间的电压电平差异，以及 VOH / VOL / VIH / VIL 在确定这些差异时的重要含义。此外，它还解释了在各种转换方法中如何选择合适的电压电平转换器。 此外，本博客将探讨电压电平转换器的具体示例，这些转换器可以自动检测和转换信号的方向。 NXP 还提供用于 SD 卡/SIM 卡的电压电平转换器和特定应用转换器，例如 GTL↔TTL 电平转换，但本博客将重点介绍面向通用或串行总线应用的产品。 *TTL（晶体管-晶体管逻辑） *LVTTL（低压晶体管-晶体管逻辑） *CMOS（互补金属氧化物半导体） *GTL（Gunning Transceiver Logic） 2. 数字信号   2.1 各种数字信号 所谓的“数字信号”是逻辑电平 1 和 0 的电信号表示。历史上，处理逻辑电平 1 和 0 有多种电路设计方法。这些方法包括用简单的电压高低来表示逻辑电平的方法，以及使用电压差来表示高低电平的方法。 TTL简单地用 5V/0V 表示高电平/低电平。进一步将 TTL 电压降低到 3.3V/0V，例如LVTTL ，这类系统的电压电平是根据双极型晶体管电路确定的。 类似地，ECL（电子分类）也使用双极型晶体管，但采用负电源来实现低幅度差分逻辑电平，从而获得更高的速度。GTL（全局晶体管叠层）则使用参考电压来传输高/低信号，以及低幅度单端信号等等。 此外，即使采用简单的高/低表示法，为降低功耗而开发的 4000 系列CMOS通用逻辑电路也允许使用 3V 至 18V 作为高电平。 https://en.wikipedia.org/wiki/Logic_family 本博客将解释如何处理 TTL (LVTTL) 和 CMOS 中的电压电平，它们使用简单的高电平和低电平来表示逻辑，以及上面提到的各种逻辑电平。 其他信号转换使用专用芯片，因此本文不予赘述。 此外，近年来半导体技术变得更小、更快、更节能，电源电压也随之降低。因此，用于桥接信号电压差的电压电平转换器变得尤为重要。 图 2：信号波形 - 电压电平（高/低）表示逻辑电平。   2.2 CMOS 和 TTL：使用简单的电压高电平和低电平表示逻辑电平信号 在数字电路中，简单的基于电压的逻辑电平信号通常使用高电平（HIGH）和低电平（LOW），高电平通常使用电源电压，低电平通常使用0V。只要高低电平的电压值相同，即使电源电压不同，信号也能传输。 例如，TTL（LVTTL）将2.0V或更高的输入信号解读为高电平，0.8V或更低的输入信号解读为低电平。由于这种约定，即使电源电压不同，TTL信号的高/低电平也不会改变。 另一方面，CMOS电路以电源电压的一半作为高/低电平的定义依据。因此，当电源电压变化时，CMOS电路的高/低电平电平也会发生变化。 图 3：输入信号电压规格   2.3 输入/输出电压规格：V OH /V OL 和 V IH /V IL 在数字电路中，高电平和低电平的输出电压以及用于判断输入信号是高电平还是低电平的电压都是有明确规定的。这些规定在每个芯片的规格书中都有明确说明，因此您需要查阅数据手册。 V OH ：高电平输出电压 VOL ： 低电平输出电压 V IH ：高电平输入电压 VIL ： 低电平 输入电压 2.3.1 输出电压规格：V OH 和 V OL 考虑输出时，必须考虑输出高/低信号所需的电流。电流会根据负载的变化而增大或减小。 在最大流出电流下，高输出时可保证的电压称为 VOH （最小值） ；在最大流入电流下，低输出时可保证的电压称为 VOL （最大值） 。 V OH (min) 是电路输出级中上方晶体管导通时的输出电压。该晶体管具有一个称为“导通电阻”的电阻。 当大电流流过晶体管时，会产生一个等于“晶体管电阻乘以流过电流”的电压。这会导致输出电压比电源电压低相应的数值，从而导致 VOH 值降低。因此， VOH (min)是指在达到预期最大输出电流时能够保证的最小电压。 图 4：数字信号输出电路（推挽式）   图 5：高输出电压随负载而变化。   VOL 则相反。当电路输出级中的低电平晶体管导通时，如果输入电流较大，由于晶体管导通电阻产生的电压，输出电压将高于 0V，如上所述。考虑到这一点， VOL (max) 是在预期输入电流最大时能够保证的最大电压。 图 6：低输出电压也会根据负载而变化。   2.3.2 输入电压规格：V IH 和 V IL 输入端有两个电压电平，用于判断高电平和低电平： V IH （最小值）和V IL （最大值） 。如果电压高于 V IH （最小值），则判定为高电平；如果电压低于 V IL （最大值），则判定为低电平。 在CMOS输入中，电源电压的一半用作高电平和低电平的参考电压，但这并不直接用作V IH (min) 和V IL (max) 。这是因为不同芯片之间的差异会导致阈值波动。此外，为了减轻输出端缓慢上升沿信号噪声引起的毛刺，通常会在输入端引入迟滞。基于这些原因，V IH (min) 和V IL (max) 被定义为具有一定的电压差。 2.3.3 VOH / VOL 与 VIH / VIL 之间的关系 要实现正常的信号交换，输出和输入之间的关系必须满足以下等式。 高水平：V OH （分钟）> V IH （分钟） 低水平： VOL （最大值）< VIIL （最大值） 如果保持这种关系，输出电路就能正确地将高/低信号传输到下一个输入电路。此外，它们之间的电压差“V OH (min) - V IH (min)”和“V IL(max) - V OL (max)”就成为“ 噪声容限”，并作为保持高抗噪性的指导原则。 图 7：V OH (min) / V OL (max) 和 V IH (min) / V IL (max) 3. 基本电压电平转换方法：单向信号转换   3.1 即使芯片的电源电压不同，也不需要进行转换的示例。 当“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”满足关系式时，通常不需要进行电压电平转换。例如，尽管TTL和LVTTL芯片使用的电源电压不同，但它们的输入和输出电压规格相同。 在 TTL (5V) 和 LVTTL (3.3V) 模式下， VOH (最小值) 为 2.4V， VOL (最大值) 为 0.4V。由于在两种情况下 VIH (最小值)/ VIL (最大值) 也均为 2.0V/0.8V，因此它们可以毫无问题地相互连接。 但是，如果输出电压高于输入芯片的电源电压，则需要格外小心。如果输出芯片使用 5V 电源，而输入芯片使用 3.3V 电源，则输入芯片必须支持“ 5V 耐受输入”。 5V 耐压输入是指即使将 5V 高电平信号连接到工作电压为 3.3V 的芯片的输入端，也能正常工作的输入端。虽然典型的芯片输入端都配备了静电放电 (ESD) 保护电路来防止静电损坏，但如果该 ESD 保护电路的配置如下图所示，5V 输入可能会导致电流从输入端反向流回 3.3V 电源，从而可能损坏芯片。5V 耐压输入的设计正是为了避免此类问题。耐压输入并非缺少 ESD 保护；它们内置了 ESD 保护电路，该电路能够处理高于电源电压的信号而不会造成任何问题。 如图 7 所示的 ESD 保护二极管，即使输入芯片断电，也可能导致问题。在独立控制每个芯片电源的系统中，即使输入芯片已关闭，输出信号也可能反馈到电源，导致输入芯片继续工作。 图 7：ESD 保护二极管 - 非容错输入 列：对于 TTL 电路，如何确定 V IH (min) = 2.0V 和 V IL (max) = 0.8V？ CMOS的输入阈值基于电源电压的中点(VCC/2)，而TTL的V IH (min) /V IL (max) 为2.0V/0.8V，相对于电源电压(5V)而言，这个比例并不十分理想。这与TTL的输入级由双极型晶体管构成有关。 标准 TTL 逻辑 IC 的内部电路示例：SN7400（2 输入 NAND）。 该信息包含在《1988 年最新通用逻辑器件规格表》（CQ 出版社）中。 典型的TTL门电路的输入级由一个多发射极输入晶体管和一个串联的相位分离晶体管组成。门电路开始响应的“开关阈值”由这两级中PN结的正向电压决定。由于单个硅PN结的正向电压约为0.6至0.7V，因此两级的总正向电压约为1.3至1.5V，这就是TTL门电路的有效开关阈值。 然而，约 1.4V 的值仅仅是一个“典型值”， 由于个体差异和温度变化，它会因批次和工况的不同而有所波动。 因此，数据手册中指定的 V IH (min) 和 V IL (max) 值被定义为保证值，在约 1.4V 的典型值上下留有足够的裕量，这意味着“如果电压降至此值，则可以可靠地判断为低电平 (V IL (max) = 0.8V)”，“如果电压升至此值，则可以可靠地判断为高电平 (V IH(min) = 2.0V)”。 此外，该值并非孤立地确定，而是根据 VOH 和 VOL 之间的关系设计而成，如第 2.3.3 节所述。在标准 TTL 电路中，由于输出级配置，高电平输出并非电源电压，而是略低的电压（比上述电路示例中的 130Ω 电阻、晶体管和二极管产生的电压低 2.4V）。当与 VOL(max)=0.4V 结合时， 高噪声容限：V OH （最小值）− V IH （最小值）= 2.4 − 2.0 = 0.4V 低侧噪声容限：V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V 如图所示，其设计旨在确保上下对称地提供 0.4V 的噪声容限。换句话说，TTL 的 2.0V/0.8V 数值相对于电源电压而言可能看起来“奇怪”，但实际上是合理的数值，其计算基于两个要求：双极型晶体管结电压的物理特性和噪声容限设计。 此图显示的是一个 SN7420（4 输入 NAND），其中三个输入引脚设置为高电平，一个引脚接收 100kHz 三角波（通道 1）。 当高电平 (Vcc=5V) 时，空载 (ch2) 输出小于 4V。 本专栏介绍的电路是一个没有指定型号的标准 TTL 电路示例（例如 74 LS 00 或 74 HC 00，没有 LS/HC 前缀；有时在英语中被称为“vanilla TTL”），但 V IH /V IL 规格相同的原因（输入级的双极结特性）与其他 TTL 系列（例如 74LS）相同。   3.2 需要转换的示例   虽然 TTL 和 LVTTL 连接由于电压电平匹配而可行，但当连接电源电压不同的 CMOS 芯片，或将 CMOS 芯片连接到 TTL 芯片时，逻辑电平不匹配的情况时有发生。这是因为上述关系“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”不成立，或者电平差过小，导致噪声容限不足。 电压电平转换器可以解决这个问题。 图 9：逻辑电平不匹配示例 (1)：高电平输入电压不足   图 10：逻辑电平不匹配示例（2）：输入的低电压不足。     3.2.1 利用开漏输出进行转换 无需使用电压转换芯片，也有简便的方法可以调节电压。 如果信号方向从输出芯片到输入芯片是固定的且不会切换，那么这种方法需要将高电平输出设置为开漏输出，以匹配输入电压。开漏输出是指数字电路输出级的上部晶体管缺失，高电平电压是通过连接到输入芯片电源电压的上拉电阻获得的。 图 11：数字信号输出电路（开漏）   明渠排水是一种简单且廉价的方法，但有几点需要注意。 首先，输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种类型的输出。 首先，输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种输出。如果输出固定为推挽输出且无法配置为开漏输出，则需要外部晶体管或类似器件将其转换为开漏输出。 此外，上拉电阻的选择也很重要。 为了获得高电压，需要使用上拉电阻，但如果电阻值太小，输出为低时流过的电流就会很大（类似于重负载），这将增加功耗，导致 电压 升高。 相反，如果该值过大，则会受到线路和引脚电容的影响，导致从低电平到高电平的上升时间变慢，从而降低通信速度。 3.2.2使用标准逻辑（通用逻辑）芯片进行转换 对于简单的电压电平转换，您也可以使用标准逻辑电路。例如， Nexperia 的 74AVCH4T245是一款通用 CMOS 逻辑芯片，可以执行 4 位双向电平转换。 该芯片可转换0.8V至3.6V的信号，并可通过DIR引脚切换信号方向。信号传输速度取决于转换电压，但可支持约100Mbps至380Mbps的速度。 图 12：标准逻辑示例 - 74AVCH4T245 该芯片能够实现高速双向电压信号转换，但转换方向必须由外部信号控制。虽然在并行总线上可以通过读/写等信号实现这种控制，但在串行总线等通信系统中，由于通信方向会根据协议而切换，因此难以应用这种控制方式。 图 13：标准逻辑示例。信号方向必须由外部指定。 4. 需要自动方向切换的双向信号转换。 迄今为止介绍的“开漏输出”和“使用标准逻辑芯片的电压转换方法”主要只能在一个方向上进行转换，或者需要通过外部信号来切换方向。 像I²C和I3C这样的通信方式，由于信号方向会动态变化，需要“双向电压电平转换”来自动检测并切换信号方向。外部控制这类信号的方向非常困难，而且使用上述缓冲芯片实现起来也很有挑战性。 此外，由于 I²C 是开漏信号，因此无法将标准的开漏逻辑缓冲器反向连接。图 14 展示了一个示例，其中开漏缓冲器反向连接。当缓冲器的两端均为高电平时，不会出现问题；但一旦其中一端变为低电平，缓冲器就会持续将另一端的输入拉低，并且无法恢复到高电平。 图 14：典型的开漏缓冲器不能自动在双向通信之间切换。   4.1 使用单个MOS晶体管的双向转换   迄今为止，I²C信号到电压的转换一直采用简单的电路。我们将以MOS晶体管为例，介绍一种最简单的方法。 图 15：使用 MOS 晶体管进行转换的示例   图 15 取自 I²C 规范 2.1 版（2000 年），展示了一个使用两个 MOS 晶体管（TR1、TR2）分别转换 3.3V 和 5V 信号的示例。尽管由于后文所述的问题，这种仅使用晶体管的简单转换示例已从当前的 I²C 规范中移除，但此处仍将其保留以帮助理解其原理。 I²C信号线，分别称为SDA和SCL，均为开漏双向信号。上拉电阻分别连接到3.3V和5V端。 在这个电路中，当3.3V和5V信号均为高电平时，该晶体管的栅极(g)和源极(s)处于同一电位，因此源极(s)和漏极(d)截止，它们之间的连接断开。当3.3V信号在此状态下变为低电平时，3.3V侧的晶体管（位于s和d之间）导通， 5V侧的信号也变为低电平。 当3.3V侧变为高电平，5V侧变为低电平时，连接3.3V侧和5V侧的寄生二极管（体二极管）首先导通。二极管导通后，电源电压下降。因此，晶体管导通， 3.3V侧的信号也变为低电平。 虽然这种使用晶体管作为开关的简单机制可以实现电压电平转换，但它也存在一些问题。晶体管的差异会影响信号转换的阈值电压。此外，随着处理更低信号电压的需求日益增长，例如在1V左右的信号电压下，这种电路无法工作，因为它无法获得足够的栅源电压（Vgs）。 附录： 与图 15 相同的电路仍以应用笔记 AN10441“I²C 总线设计中的电平转换技术” 的形式公开提供，该笔记由 Nexperia 公司发布。Nexperia 是一家由恩智浦半导体 (NXP) 分拆出半导体分立/逻辑产品业务后成立的公司。该应用笔记最初于 2007 年（版本 01）发布，与 I²C 规范分开，并于 2020 年以 Nexperia 品牌进行了修订（版本 2）。 4.2 使用专用设备的双向转换   通过使用 专用电压电平转换器 IC ， 可以轻松实现 I²C 和 I3C 等双向通信总线的电压电平转换。 4.2.1 I²C信号电压转换芯片 PCA9306和NVT20xx系列（ NVT2001/02 、 NVT2003/06 、 NVT2008/10 ）是专为双向信号转换而设计的电压电平转换器。这些芯片可以同时处理多条信号线（多位信号线）。虽然它们被指定为 I²C 信号电压转换芯片，但如果信号规格匹配，它们也可以用于其他用途（例如 SPI 和其他推挽信号） 。 PCA9306 和 NVT20xx 系列具有相同的内部结构，只有当要转换的电压差为 1V 或更大时，才需要将上拉电阻连接到较高的电压侧。 图 16 显示了其内部结构以及与外部芯片的连接（摘自应用笔记AN11127的图 2：“双向电压电平转换器 NVT20xx 和 PCA9306” ）。该芯片包含信号线（比特）数 + 1 个 MOS 晶体管。每个晶体管的源极和漏极可以互换。 信号传输路径中的晶体管称为传输晶体管，其余的晶体管称为参考晶体管。 图 16：NVT20xx (PCA9306) - 芯片工作原理示意图。   观察电路图，参考晶体管的栅极和漏极短接，并通过一个200kΩ的电阻连接到高压电源。参考晶体管的源极连接到低压电源。在这种连接方式下，参考晶体管相当于一个二极管，其栅极电压比低压电源高一个二极管电压。 剩余的传输晶体管的漏极连接到高压信号线和一个1kΩ的上拉电阻，其源极连接到低压信号线，其栅极连接到参考晶体管的栅极。当传输晶体管的高电平和低电平信号均为高电平时，高压侧的电压由1kΩ电阻上拉至高电平。 一个传输晶体管构成一个称为“源极跟随器”的电路。低压侧（源极）的电压比施加在栅极上的电压低，低的电压值等于晶体管导通所需的Vgs值。换句话说，源极的电压与低压电源的电压相同。此时晶体管处于半导通状态（工作在线性区），既非完全导通也非完全截止。 在这种状态下，当高电平或低电平信号变为低电平时，栅极和信号端之间的电压差会使晶体管导通（工作在完全导通的饱和区），另一个端也变为低电平。 该系列芯片可处理的信号速率受上拉电阻和信号线电容的影响。数据手册显示，PCA9306 最高可处理 2MHz 的信号速率。NVT20xx 系列芯片在上拉电阻为 192Ω、电容为 50pF 时，最高可处理 33MHz 的信号速率。对于 1MHz 左右的信号，即使不太在意上拉电阻和电容（假设其在 I²C 的常用范围内），也能正常工作。但是，如果要将该芯片用于推挽电路以处理更高速率的信号，则必须充分了解其特性并仔细选择合适的元件。 此类电压电平转换器的运行细节在文章“ PCA9306 的内部结构和运行”中进行了描述。 4.2.2 高速双向开漏信号电压转换芯片 我们推出NTS030x系列（ NTS0302JK 、 NTS0304E ）高速双向开漏信号转换芯片。 该芯片可执行 2 位或 4 位双向信号转换，可处理高达 2Mbps (1MHz) 的开漏信号和 20Mbps (10MHz) 的推挽信号。   图 17：NTS030x - 芯片内部框图   图 17 显示了 NTS030x 中一个信号比特的内部结构。 在图中，晶体管T3是一个直通晶体管，并对其施加了栅极偏置电压，因此当信号 A 或 B 变为低电平时，它会导通。 当 A 和 B 都为高电平时，T3 关闭，由于 A 和 B 通过相对较大的上拉电阻 (10kΩ) 连接到各自的电源，因此它们将具有各自的电压。 这款芯片包含T3以及T1和T2 。其中T1和T2用于一种名为“边沿速率加速器”的功能。我们将重点介绍其中一个T1，并解释其工作原理。 T1位于 A 侧，其源极连接到 A 信号，漏极连接到 A 侧电源。栅极连接到标有“单稳态和转换速率控制”的模块，该模块控制 T1。 “单次触发和转换速率控制”模块连接到另一端的 B 信号，用于检测 B 信号从低电平到高电平的变化。检测到此变化时，晶体管 T1 暂时导通，绕过 10kΩ 上拉电阻，允许电流通过，从而加速 A 信号从低电平到高电平的变化。通过这种方式加快信号的上升时间，可以处理更快的信号。 顺便一提，当 T1 打开时，其转换速率受到控制，以抑制电流突然增加引起的振铃。 另一个T2使用相同的机制，但方向相反，也应用于 B 面信号。 NTS系列还有另一个方便用户使用的功能。 对于前面提到的MOS晶体管和PCA9306/NVT20xx，存在一个问题：如果一个电源关闭，另一个电源的信号会被置为低电平。为了解决这个问题，NTS030x的设计使得当两个电源都未开启时，信号引脚会被置为高阻抗状态，从而避免相互影响。利用此功能，可以对系统的电源进行部分控制，使其处于开启/关闭状态。 NTS010x 系列（ NTS0102 、 NTS0104 ）与 NTS030x 系列等效，但缺乏处理高速信号的转换速率控制功能。 NTS0304E 配有评估板NTS0304EUK-ARD，可进行快速简便的运行验证。有关 NTS0304EUK-ARD 评估板的概述和操作方法，请参阅视频“如何操作 NTS0304EUK-ARD” 。 4.2.3 双向推挽式信号电压转换器芯片 此外，对于仅用于推挽信号的器件，还有NTB010x系列（ NTB0102 、 NTB0104 ），它提供了一种更快的选择。 当信号稳定处于高电平或低电平状态时，信号会通过一个 4kΩ 电阻。与 NTS030x 系列类似，它在高电平和低电平两端都具有单稳态功能，并且具有一种机制，当任一端的信号发生变化时，该机制会改变另一端的信号。 该机制能够以 70-80 Mbps 的速度实现信号到电压的转换，同时还具有自动信号方向检测功能。   图 17：NTB010x - 内部芯片框图 4.2.4I3C信号电压转换器芯片 I3C规范允许在开漏和推挽通信模式之间切换。在开漏模式下，它与 I²C 兼容，工作频率最高可达4MHz 。在推挽模式下，则使用12.5MHz 的时钟频率。由于信号电压通常在 1V 到 3.3V 的范围内，因此当存在电压差时，需要一个符合信号规范的电压电平转换器。 图 18 显示了P3A1604一位的内部框图。如图所示，该芯片集成了一种机制，不仅可以加速低电平到高电平的转换，还可以加速高电平到低电平的转换，并且还集成了一个可以开关的上拉电阻。   图 18：P3A1604 - 芯片内部框图 P3A1604是一款 4 位 I3C 电压电平转换器。另有 2 位版本P3A9606可供选择。   4.2.5 基于缓冲区的转换 转换双向信号的另一种方法是使用专用缓冲区。 缓冲器的主要目的是增强驱动能力并隔离连接信号线的电容，但也有一些产品支持电压转换。 正如这篇博客中所述，简单的缓冲器无法相互缓冲双向开漏信号。因此，市面上出现了各种具有双向开漏信号专用功能的缓冲器产品。 我会在以后的场合详细解释缓冲区的问题。 5. 总结 电压电平转换器是安全可靠地在不同电源电压的数字电路之间交换信号的关键组件。了解 TTL、LVTTL 和 CMOS 等逻辑电平的定义，以及 VOH/VOL/VIH/VIL 之间的关系，有助于选择合适的连接和转换方法。 对于单向转换，可以使用开漏输出或标准逻辑集成电路；而对于双向转换，可以使用MOS晶体管或专用集成电路（例如PCA9306/NVT/NTS/NTB/P3A系列）。 具有自动信号方向检测功能的电压电平转换器对于需要双向通信的总线（例如 I²C 和 I3C）特别有用。 此外，半导体技术的最新进展带来了更低的电压和更高的速度，这就对电压电平控制提出了更高的要求。虽然电压电平转换的方法和方案有很多，但根据应用需求，并考虑信号规格、速度和系统电源管理等因素，选择最佳的方法和元件至关重要。 5.1 博客中介绍的方法/零件编号的比较 方法/部件编号 目的 位数 方向改变 开放式布线兼容 低压侧 [V] 高压侧 [V] 比特率 [bps] 具有开漏输出的转换器 通用 1 单向 - - - - 标准逻辑（例如，74AVCH4T245） 通用型（并行总线等） 4 + 4 外部控制 不支持 0.8 ~ 3.6 0.8 ~ 3.6 1亿~3.8亿 使用单个MOS晶体管进行双向转换 I²C，通用 1 自动的 一致 根据晶体管规格而定 约100万 PCA9306 I²C，通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz，视情况而定） NVT2001 I²C，通用 1 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2002 I²C，通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2003 I²C，通用 3 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2006 I²C，通用 6 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2008 I²C，通用 8 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2010 I²C，通用 10 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NTS0302JK I²C、SPI、通用 2 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口，20米@推拉式排水口 NTS0304E I²C、SPI、通用 4 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口，20米@推拉式排水口 NTS0102 I²C、SPI、通用 2 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTS0104 I²C、SPI、通用 4 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTB0102 SPI，通用 2 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 NTB0104 SPI，通用 4 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 P3A9606 I3C、I²C、SPI、通用 2 自动的 一致 0.72 ~ 1.98 0.72 ~ 1.98 （12.5MHz） P3A1604 I3C、I²C、SPI、通用 4 自动的 一致 0.72 ~ 1.98 1.62 ~ 3.63 6.8米（明排水），40米（推拉式排水） 表 1：博客中介绍的方法/零件编号对比   6. 参考资料 产品介绍页：电压电平转换器 NXP系统管理I2C、I3C、SPI选型指南 I2C总线规范和用户手册（版本5.0）（日语版） I2C总线规范和用户手册（版本7.0）英文版） NXP社区博客： I3C总线概述——下一代串行总线 日本网络研讨会视频： “您现在需要了解的下一代接口‘I3C’基础知识” Qiita @teddokano： PCA9306 的内部运作和运行 变更历史记录： 2025年8月28日：第一版 2025-08-28：添加了有关 NTS0304EUK-ARD 的信息以及包含视频的博客链接。 2026-04-10：修正表 1 中的低压侧 [V] 和高压侧 [V]。 2026-06-20：第 3.1 节“列：TTL 的 VIH（最小值）”新增“如何确定 VIL(max) = 2.0V 和 VIL(max) = 0.8V？”。新增标准 TTL 逻辑 IC 的内部电路示例：SN7400（2 输入 NAND 门）和 SN7420 的输出波形。 2026-07-10：在第 4.1 节中添加了图 15 中的电路也作为 Nexperia 应用笔记 AN10441 发布。 ========================= 即使您在本文的“评论”栏留言，我们目前也无法回复。 给您带来不便，我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 （如果您已经是NXP的代理商或与其有合作关系，可以直接向负责人咨询。） 本博客解释了数字电路中使用的各种逻辑电路（*TTL、*LVTTL、*CMOS）之间的电压电平差异，以及 VOH 、 VOL 、 VIH 和 VIL 对于识别它们的重要含义。 此外，我们将解释在各种转换方法中应该选择哪种电压电平转换器。 我们将仔细研究双向开漏信号的转换，这需要特殊的处理方法。 界面 介绍 日本博客

RT1170 USB CDC は、実行されていないコードにブレークポイントを設定しても kStatus_USB_Busy で停止します。 こんにちは、 私は i.MX RT1170 (M7 コア) で以下の作業を行っています: SDKバージョン25.09 FreeRTOS USB CDC (仮想COM) CAN-FDの並列実行 初期化は正常です。 USB 列挙が正常に完了しました。 通常実行中は、CAN-FD と USB 通信は両方とも正常に動作します。 通常の状態でのシステムの動作: CAN-FDはデータを正しく受信します USB CDCはPC（Tera Term）にデータを正常に送信します USB_DeviceCdcAcmSend() は期待通りに動作します USBコールバックが実行され、ビジーフラグが適切にクリアされます 問題： プロジェクトの任意の場所にブレークポイントを配置すると、現在実行されていないコード内であっても (たとえば、初期化後の main() 内や関連のない関数内)、システムは実行を継続しますが、USB CDC は最終的に停止してしまいます。 重要な観察事項: ブレークポイントはヒットしていません。 コードは正常に実行され続けます。 FreeRTOS タスクは実行を継続します。 CAN-FD は正常に動作し続けます。 USB CDC のみが機能を停止します。 この現象が発生すると、次のようになります。 USB_DeviceCdcAcmSend() は kStatus_USB_Busy を返します USB転送コールバックが呼び出されない ビジーフラグが消えない ボードをリセットするまでUSB通信は永久に停止します 実行時に printf() を使用した場合でも、同様の動作が引き起こされることがあります。 構成： #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 2 #USB_DEVICE_INTERRUPT_PRIORITY (6U) を定義します。 USBタスクスタックサイズ: #APP_TASK_STACK_SIZE を 8000L と定義します スタックオーバーフローは発生しません。 システムはクラッシュしません。 USB CDC 通信のみが停止します。 質問: 実行されていないコードにブレークポイントが設定されている場合でも、USB CDC が停止するのはなぜですか? デバッガーは、USB HS タイミングに影響を与えるような方法で M7 コアを一時的に停止しますか? USB 割り込みの遅延サービスにより、CDC ドライバが永続的に kStatus_USB_Busy 状態のままになる可能性はありますか? これは、CPU が停止したときの USB HS コントローラ (EHCI) の予想される動作ですか? 転送の破損を起こさずに RT1170 上の USB CDC をデバッグするための推奨方法は何ですか? どのようなご指導でもいただければ幸いです。 よろしくお願いします。 USB Re: RT1170 USB CDC stuck in kStatus_USB_Busy even when breakpoint is placed in non-executing code こんにちは@Harisha 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 問題に関しては、次の調整を試すことをお勧めします。 1：USB がタイムリーな割り込みサービスを確実に受信できるように、USB 割り込み優先度を FreeRTOS が管理できる最高の優先度に設定します。 2：他のモジュール（アプリケーション内の CAN-FD など）の割り込み優先度を下げて、USB プロセッシングが停止しないようにします。 これらの変更を試して、もう一度テストしてください。   よろしくお願いいたします。 メイリュー  

Cortex-M33 上的 i.mx93 LPSPI + eDMA 问题 我使用的是 Tria i.MX9332（B1 硅）SMARC 模块，并尝试在 Cortex-M33 上使用带有 eDMA 的 LPSPI6，但无法正常工作。 开发环境 VS 代码 1.109.0 用于 VS 代码扩展的 MCUXpresso 26.1.56 SDK 25.09.00 硬件 在定制载板上试用 SM2S-IMX93 通过 SPI（LPSPI6）连接带有ILI9341控制器的 LCD 现状 使用不带 DMA 的 LPSPI6 时，显示正常。 我试图切换到LPSPI6 + eDMA以提高吞吐量，但无法收到完成通知。 问题 基于 DMA 的传输似乎开始了，但我从未在传输结束时收到 LPSPI DMA 完成回调。 详细信息和相关代码/配置见附件。 有人能指出我可能遗漏了什么，或者为什么没有触发信号吗？ Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 感谢您提供的示例代码。回顾范例让我明白了这一点。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 你好@albi84 请参考附件中的补丁文件配置 LPDPI 与 EDMA B.R Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 你好 能否请您分享带有 eDMA 的 LPSPI 的骨架？ 谢谢。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 这不是一个骨架，而是我使用的实际代码。这有帮助吗？

RDMMA845X issues with Win 7 Pro. As a retired electronics man (but total newbie with PC + dev. boards) I hope this isn't too much of a stupid question. I have bought the above board. It works great on a Win 8.1 PC, but not on the Win 7 Pro PC - which is a shame because that's the one in my hobby lab! Win 7 finds the USB device and the Demo Screen correctly identifies the chip in use, etc. But hitting any of the 'lit' buttons just generates an Exception Handler window and I can go no further than that. I don't know what Ex Handler means so am at a loss! Wisdom greatfully accepted. Tks. John Accelerometers Re: RDMMA845X issues with Win 7 Pro. As an addition to my original post I should say that the exception window calls this an "unhandled exception". After some internet research I updated the .net framework to the latest ver (4.6.2) in case that was the cause. But it is not! Tks. J 

CAN based WakeUp Transrecevier TJA1465 Hi  I am using TJA1465 CAN SIC transceiver with partial networking for CAN Based Wake up i have configure this with 500kbs bitrate and ID 0x18ff21b1 for CAN wake up using partial networking using SPI. But transreceiver wake ups for other bitrate also which is not configured in the Partial networking data rate and filter configuration register (address 031h). why does transreciever wake up for bitrate also other than configured.  below is the sample code   static void tja1465_configure_can_wakeup_ext_dlc0(void) { uint8_t mode_stat,sys_stat; printf("CAN Wakeup Config Enter \n" ); tja1465_read(REG_MODE_STATUS, &mode_stat); printf("Mode Status (0x070) = 0x%02X (%s)\n",mode_stat, mode_str(mode_stat)); tja1465_write(0x031, 0x14); /* WUF ID = 0x18FF21B1 *//*0x18FF0180* MASK 0x0000304D*/ tja1465_write(0x020, 0xB1); tja1465_write(0x021, 0x21); tja1465_write(0x022, 0xFF); tja1465_write(0x023, 0x18); /* WUF ID mask (match full 29-bit ID) */ tja1465_write(0x024, 0x00); tja1465_write(0x025, 0x00); tja1465_write(0x026, 0x00); tja1465_write(0x027, 0x00); tja1465_write(0x028, 0x05); tja1465_write(0x029, 0x00); tja1465_write(0x02A, 0x00); tja1465_write(0x02B, 0x00); tja1465_write(0x02C, 0x00); tja1465_write(0x02D, 0x00); tja1465_write(0x02E, 0x00); tja1465_write(0x02F, 0x00); tja1465_write(0x030, 0xC8); tja1465_write(0x011, 0x00); tja1465_write( 0x060, 0xFF); tja1465_write( 0x061, 0xFF); tja1465_write( 0x062, 0x04); tja1465_write(0x032, 0x03); uint8_t pn_status_reg; tja1465_read(0x073, &pn_status_reg); tja1465_read(0x071, &sys_stat); printf("PN Status (0x073) = 0x%02X (CPNS: %s),CPNERRS :0x%02X\n", pn_status_reg, (pn_status_reg & 0x20) ? "OK" : "Error",(pn_status_reg & 0x40)); printf("System Status(0x071) = 0x%02X\n", sys_stat); tja1465_write(REG_MODE_CTRL, MODE_SLEEP); usleep(3000); tja1465_read(REG_MODE_STATUS, &mode_stat); printf("Mode Status (0x070) = 0x%02X (%s)\n", mode_stat, mode_str(mode_stat)); tja1465_read(REG_SYS_STATUS, &sys_stat); printf("System Status(0x071) = 0x%02X\n", sys_stat); printf("CAN Wakeup Config Exit \n" ); } Re: CAN based WakeUp Transrecevier TJA1465 Hello Vivekananda Good day! I'm going to run tests to find the error and I'll get back to you as soon as I have an answer. Have a great day and best of luck. Re: CAN based WakeUp Transrecevier TJA1465 Hello Vivekananda Can you clarify what they mean with below green sentence on ‘other bitrates’, is this about CAN FD frames? But transreceiver wake ups for other bitrate also which is not configured in the Partial networking data rate and filter configuration register (address 031h). If it’s indeed CAN FD frames, then after the wake-up please check if PNFDER =1. If so, try changing below yellow line to: tja1465_write(0x032, 0x07). This will set PNECC = 1 and CAN FD frames would not increase the error counter anymore, PNFDER should stay 0 and the device does not wake up. The Application Notes (AN14388, which can be downloaded on our page) are showing an example SPI sequence for a PN configuration for your reference (section 4.2, pages 23-24). Please take a look. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

在 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，则需要更改所有指定的电阻。 我已经发布了引脚配置屏幕截图供您参考。 问题 4：现在看来所需的DMIC硬件设置会阻止正常的闪存编程/启动。如何测试和运行演示程序？ A4：您可以在 SRAM 上运行，就像 SDK 演示一样"evkimxrt685_dmic_multi_channel_cm33" 顺祝商祺！ MayLiu

T4240から間違ったIDCODEを読み取ったため、USB-TAP経由でダウンロードできません T4240 (T4240RDB に類似) をベースにしたボードをデバッグしています。私の問題は、Codewarrior で USB-TAP 経由でコードをダウンロードできないことです。 1.ハードコードされた RCW をテストしたところ、T4240 は電源投入後約 10 ミリ秒以内に RESET_REQ をアサートすることがわかりました。 2. Codewarrior によって「JTAG チェーンを正しく構成できませんでした」というエラー メッセージが表示され、コンソールに表示されるチップ IDCODE は、QorIQ T4240 リファレンス マニュアルに記載されている 0x0022001d ではなく、0x1022001d になります。 3. Codewarrior のコンソールの出力メッセージには、「エラー メッセージ: T4240: トランザクション中に HRESET が発生しました」と表示されました (以下に添付)。 4. 電源とクロックをすべて測定しましたが、問題ないようです。 誰かこの問題を解決するのを手伝ってくれませんか? ---------------------------------------------------------------------------- ccs_open ipaddr = 127.0.0.1 ポート = 41475 タイムアウト = 15 サーバーh = 0 ccs_open; ccs_error = 0 ccs_get_connection_count サーバーh = 0 カウント = 1 ccs_get_connection_count; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_cc_バージョン サーバーh = 0 cc = 0 バージョン.メジャー = 1 バージョン.マイナー = 3 ccs_cc_version; ccs_error = 0 ccs_set_timeout サーバーh = 0 タイムアウト = 15 ccs_set_timeout; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_config_server サーバーh = 0 cc = 0 サーバー構成 = 0 値 = 4040 ccs_config_server; ccs_error = 0 ccs_config_chain サーバーh = 0 cc = 0 device_list: (サイズ = 1) デバイス[0]:: core_type=テストコア(20) ccs_config_chain; ccs_error = 0 ccs_jtag_ロック サーバーh = 0 cc = 0 ccs_jtag_lock; ccs_error = 0 JTAG診断   プローブ テスト時の始動電力... テスト結果: 合格   IR スキャン テストを開始しています... テスト結果: 合格   バイパス スキャン テストを開始しています... テスト結果: 合格   任意の TAP 状態移動テストを開始しています... テスト結果: 合格   検出されたJTAG IDコード: OK デバイス0 IDコード: 0x1022001D   ccs_jtag_unlock サーバーh = 0 cc = 0 ccs_jtag_unlock; ccs_error = 0 ccs_config_chain サーバーh = 0 cc = 0 device_list: (サイズ = 1) デバイス[0]:: core_type=T4240(206) ccs_config_chain; ccs_error = 39 エラーメッセージ: T4240: トランザクション中に HRESET が発生しました ccs_get_subcore_error サーバーh = 0 cc = 0 エラー = 60 チェーン位置 = 0 ccs_get_subcore_error; ccs_error = 0; 期間=2ミリ秒 ccs_close サーバーh = 0 ccs_close; ccs_error = 0 Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP こんにちは、 CW の問題のスクリーンショットを共有してください。RCW が間違っている可能性があります。RCWは SB_EN ビットが設定されたターゲットにロードされましたか? 他のボードでもこの問題は発生しますか? WCTAP が他のデバイスで正しく動作していることを確認できますか? Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP サポートありがとうございます。スクリーンショットを以下に添付します。ハードコードされた RCW を使用しており、この場合 SB_EN は無効になっています。私は 5 つのボードを持っていますが、すべて同じ問題で動作しています。現時点では、USB-TAP をテストできるリファレンス ボードがありません。 Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP こんにちは、 RCW が有効でないか、JTAG クロック速度が速いことが原因である可能性があります。JTAGクロック速度を下げて試してください。

IMX8M PLUS LPDDR4 2G互換性 ISSI IS43LQ32512A-046BLI 2GB RAM を実装してみます。キャリブレーション後、2000MHz に設定されたmemcpy SSN armv8_x32 テスト中に RAM が失敗します。 RAM を 1500MHz に設定すると、すべてのテストに合格します。 この LPDDR4 RAM を実装した人はいますか?IMX8M PLUSと全般的に互換性がありますか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M ミニ | i.MX 8M ナノ Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye DDR 構成ツールを使用してキャリブレーションを実行していますか?はい、そうであれば。設定ページと失敗ログファイルを共有してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility IS43LQ32512A-046BLI (ISSI 2GB LPDDR4X SDRAM) は、LPDDR4/LPDDR4X メモリの JEDEC 標準に準拠している限り、 NXP i.MX 8M Plus プロセッサと一般的に互換性があります。ただし、memcpy SSN armv8_x32 テストが 2000 MHz で失敗する (ただし 1500 MHz では成功する) という問題は珍しくなく、根本的な非互換性の問題ではなく、構成、ボード設計、またはキャリブレーションの課題から生じている可能性があります。 互換性確認 i.MX 8M Plus は、最大 4266 MT/s (2133MHz クロック) の LPDDR4/LPDDR4X メモリをサポートし、IS43LQ32512A-046BLI は NXP の仕様に準拠した最大 2133MHz (4266 MT/s データ レート) で動作します。 NXP のコミュニティ フォーラムでは、同様の ISSI LPDDR4X 部品 (例: ご使用のモデルのオートモーティブ バリアントである IS46LQ32512A-046BLA2) が、JEDEC 仕様に準拠している限り、i.MX 8M Plus と互換性があることが確認されています。ユーザーは、適切に構成されていれば問題なく実装できました。 2000MHzでのテスト失敗の潜在的な理由 NXP および組み込みフォーラムでの同様のレポートに基づきます。 タイミング/構成の不一致: i.MX 8M Plus DDR コントローラでは、RAM の SPD/データシートからの正確なタイミング パラメータ (CAS レイテンシ、tRCD、tRP など) が必要です。2000MHz では、キャリブレーションによって ISSI 部品の仕様が完全に最適化されない可能性があります (たとえば、高速では CL=32、RL=14)。1500MHz に下げるとストレスが軽減されて合格しますが、これは最適ではないチューニングを示します。 ボードデザインの問題: トレース長の不一致、インピーダンス エラー、不十分な電力デカップリングなどの信号整合性の問題により、高速動作時に障害が発生する可能性があります。オシロスコープを使用して、DQ/DQS ライン上の反射やノイズを確認します。 キャリブレーションの制限: i.MX 8M Plus は、キャリブレーションに NXP の DDR ツールを使用します。スクリプトまたは設定が Micron/Samsung 参照 (EVK で一般的) に基づいている場合、ISSI の特性と一致しない可能性があります。ISSI 固有のパラメータを使用してキャリブレーションを再実行します。 電力/温度: 2000MHz では、電流消費量が多くなると電圧低下や過熱が発生し、memcpy テスト (連続読み取り/書き込みに負荷をかける) に失敗する可能性があります。 この RAM を実装した人はいますか? はい、文書化された実装があります。 NXPコミュニティ スレッドでは、ユーザーが同様の ISSI LPDDR4X (IS46LQ シリーズなど) をインダストリアル アプリケーション用のカスタム i.MX 8M Plus ボードに統合し、微調整後に最大 2133MHz までの安定した動作を実現しています。 組み込み Linux/BSP 開発者は、Yocto ベースのビルドで ISSI パーツを使用した成功を報告していますが、512M x 32 構成 (16Gbit 密度) を処理するためにカスタム DDR init スクリプトを使用することが多いようです。 問題を解決するための推奨事項 データシートの配置を確認する: ISSI データシート (IS43/46LQ32512A シリーズ) をダウンロードし、タイミング パラメータを NXP の i.MX 8M Plus RM (リファレンス マニュアル、セクション 13.5 DDR コントローラ) と比較します。 RAM の主な仕様: 最大クロック 2133MHz、LVSTL インターフェース、1G x 16 構成 (デュアル チャネル合計 x32)。 キャリブレーションの再実行: ISSI 固有のストレス テストでは、NXP のDDR テスト ツールまたはSCFW DDR 構成ツールを使用します。 1600MHz から開始し、アイ ダイアグラムを監視しながら徐々に 2000MHz まで上げます。 U-Boot/Linux を使用している場合は、正しいタイミングでデバイス ツリー (.dtb) を更新します (例: mx8mp-ddrc-devfreq.dtsi)。 取締役会レベルのチェック: VDDQ = 1.1Vであることを確認する。VDD2 = 0.6V、クリーンなデカップリング（コンデンサをピンの近くに配置） 信号整合性シミュレータ (HyperLynx など) を使用してトレースを確認します。 熱スロットリングを排除するために、より低い温度またはより優れた冷却でテストします。 それでも失敗する場合は: コミュニティまたはチケット システムを通じて NXP サポートに連絡し、キャリブレーション ログとボードの回路図を提供してください。 比較のために、Micron MT53E512M32D2NP (NXP EVK デフォルト) などの検証済み RAM に切り替えることを検討してください。 全体的に RAMは互換性がありますが、2000MHz の障害はセットアップの問題である可能性があります。さらに詳しい情報（キャリブレーション ログやボードの回路図スニペットなど）を共有していただければ、さらにトラブルシューティングをお手伝いできます。 メッセージング アプリ経由で +8526583 (7594) に連絡し、彼から EOL ドキュメントを入手してから推奨事項を作成することをお勧めします。彼はあなたを助けることができます Re: IMX8M PLUS LPDDR4 2G compatibility ご対応ありがとうございます。 添付ファイルで設定.xlsを送信しますそしてテストログ。 Re: IMX8M PLUS LPDDR4 2G compatibility 使用済みのボードでは、3GB (MT53E768M32D2ZW-046 WTC) と 4GB (MT53E1G32D2FW-046 AAT:B) を正常に動作させています。 2000MHz の Micron LPDDR4。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん 構成ツール V 13.1 でも同じ結果になります。IS43LQ32512A-046BLIの設定が間違っているのでしょうか？正しい設定ファイル（*.dsファイル）をご提供いただけますか？当社のハードウェア設計は、LPDDR4 インターフェースに関する評価ボードの 1:1 コピーです。 敬具 トビアス Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 以下のリンクを使用して DDR 構成ツールをダウンロードし、2GB DRAM を構成して DDR テストを実行してください。 https://www.nxp.com/design/design-center/development-boards-and-designs/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 以下の設定を使用して DDR テストを実行してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility 設定例をありがとうございます。すでにこの RAM で試しましたが、まだエラーが発生します。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye 不思議ですね。DDR Config Tool v25.12 の失敗ログを共有してください BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@TMpieye DDR Config Tool を使用してストレス テストを実行しましたか?ログ ファイルから見ると、これは Config Tool の出力ではないようです。また、最新のツール バージョン v25.12 を使用してください。 BR Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhang ストレステストには、Mscale DDR Tool 3.31 を使用します。他の設定ツールでやってみます Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん ストレステストのログはこちらです。4GB ISSI IS43LQ32K01S2A-046BLI でも同じ問題が発生します。 Re: IMX8M PLUS LPDDR4 2G compatibility こんにちは@pengyong_zhangさん 構成ツールでテストを実行すると、合格しました。SO、これは MSCALER ツールのツール問題のようです。多大なるサポートをいただき誠にありがとうございます！

首次成功设计 KW47（汽车级）或 MCX W72（物联网 / 工业级）PCB 的最佳方法 /*** 2025 年 4 月最新免责声明： - KW47、MCX W72 是 KW45 和 MCX W71 的直接衍生产品 —— 请将本页面加入书签以获取未来更新 - 本文基于 KW45、K32W148、MCX W71 进行早期启用说明，有待 2025 年 KW47 和 MCX W72 更广泛发布时更新 -- 大部分设计文档（包括数据手册、参考手册和硬件制造文件）可应要求提供--  ***/ 请参考以下重要链接，了解如何使用 KW47 或 MCX W72 设计 PCB，以及有关射频性能、低功耗和射频认证 (CE/FCC/IC) 的所有信息。 KW47 产品 NXP 官网页面：https://www.nxp.com/products/KW47 MCXW72 产品 NXP 官网页面：https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/mcx-arm-cortex-m/mcx-w-series-microcontrollers/mcx-w72x-secure-and-ultra-low-power-mcus-for-matter-thread-zigbee-and-bluetooth-le:MCX-W72X KW-MCXW-EVK 入门指南 NXP 官网页面（待 KW47/MCXW72 发布） KW47-LOC 入门指南 NXP 官网页面（待 KW47/MCXW72 发布） MCXW72-LOC 入门指南 NXP 官网页面（待 KW47/MCXW72 发布） 硬件  KW47 和 MCX W72 EVK 开发板：初步附件  KW47 LOC 信道探测板 - 原理图：初步附件  KW47-MCXW72-EVK 硬件指南：可应要求提供    HVQFN48 封装规格：SOT619-17 (D)（待 SOT619-17 (DD) 发布）    KW47-MCXW72-EVK 用户手册（待 KW47/MCXW72 发布）    最小物料清单（附件）>> KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers July25.pdf   DC-DC 管理指南 (AN13831)：KW45/K32W148 - 电源管理硬件 (nxp.com)（KW45 的内容适用于 KW47，待 KW47/MCXW72 版本发布）   Design-In 检查清单：请参阅本文底部附件   射频匹配：S 参数（附件）（待 KW47/MCXW72 发布）   PCB 上纽扣电池应用处理方法：AN14664_Coincell_Hardware_recommendation_Rev1.0.pdf 说明：“由于射频性能取决于 PCB 布局和制造工艺，基于 NXP 建议制作的 PCB 原型必须进行微调，以确保最终产品平台达到预期的射频合格标准。” 在 EVK 上，为连接 M10 模块进行射频测试，建议使用 μFL 转 SMA 电缆： CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France 在 KW47-LOC 或 MCXW72-LOC 上，需安装特定的 SMA 连接器以实现连接：TE Connectivity Ltd CONSMA021.062-G 从 KW45 到 KW47 的硬件移植： KW47 与 KW45 引脚到引脚兼容。然而，从硬件的角度来看，某些组件的值需要进行调整，例如 RF 匹配组件的值。 根据当前的硅验证，预计KW4x周围的其他组件不会发生变化。 另请注意，为实现 KW47 的新功能，部分引脚采用了新的复用配置。例如，KW47 提供了第二个 Flex CAN。详见附件。 射频   射频报告：KW45 和 K32W148 的蓝牙低功耗射频系统评估报告，以及 K32W148 的 802.15.4 应用评估报告……（待 KW47/MCXW72 发布，可应要求提供）   射频共存：Kinetis 无线系列产品的蓝牙低功耗与 Wi-Fi 共存应用（nxp.com）（待 KW47/MCXW72 发布）   距离性能：参考附件（待 KW47/MCXW72 发布）   天线： 用于NXP EVK板的2.4 GHz通信设计和应用的紧凑型平面天线 用于信道探测应用的天线   BLE 连接性测试二进制文件：可按需在 SDK 中获取   回波损耗 (S11) 测量：如何测量射频匹配的回波损耗 (S11)（射频报告 AN13728 的一部分）   负载牵引：待 KW47/MCXW72 发布 用于 RF 试验的 SW 工具：   IoT 工具箱（移动应用）   连接性产品的连接测试工具（IoT 工具箱的一部分）   DTM：如何在 Kinetis 系列产品上使用 HCI_bb……- NXP 社区 https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... 晶体  文章：KW45/K32W1 的 32MHz 和 32kHz 振荡裕量 - NXP 社区（待 KW47/MCXW72 发布） 推荐的水晶已附上 低功耗 蓝牙 LE 功耗配置文件估算工具 KW45_WK47_BLE_power_profile_calculator_v1.32.xlsm   低功耗              AN14554 Kinetis KW47 & MCX W72 Bluetooth LE Power profile analysis release.pdf 802.15.4 Matter & Zigbee 功率配置文件估算工具               MCX W7x 802.15.4 Matter ICD SIT LIT & ZED Power profile v0.2.xlsx                 AN MCX W72 802.15.4 Matter and Zigbee Power profile analysis - proposal.pdf CCC 信道探测 BLE 功率配置文件估算工具               KW47 Digital Key CCC CS Power Estimator tool v0.8.xlsx               AN14628_AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf Bluetooth ® 信道探测技术概述  认证 RF 预认证已完成 - 完整认证待 KW47/MCXW72发布 KW47 和 MCXW72 已通过蓝牙 6.0 信道探测认证！

MCXN647との接続問題（Ee(42)エラー） こんにちは、 FRDM-MCXN947に問題があります。プロジェクトをデバッグまたはフラッシュしようとすると、次のエラーが発生します。 関係があるかどうかはわかりませんが、while(1) ループのこの行を変更して頻度を上げたときに発生しました: SDK_DelayAtLeastUs( 30000 , SystemCoreClock); -> SDK_DelayAtLeastUs( 10000 , SystemCoreClock); 問題が発生する前にアップデートしていなかったのですが、その後LinkFlashをアップデートしても何も解決しませんでした。 すでに SPT 消去を試しましたが、機能しませんでした。（多分、やり方が間違っていたのでしょう。） SPT では、ISP モードを有効にした後、「イメージの構築」および「イメージの書き込み」操作を実行できましたが、消去はまだ機能しません。 ご協力をよろしくお願いいたします。 追伸: 英語と専門用語が下手で申し訳ありません。私は工学部でこのプロジェクトを始めたばかりです。 ブートROM|ブート|フラッシュ クロック|タイマー MCX N USB Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D SPT ツール内のフラッシュ プログラマーを使用して、blinky SDK デモを消去およびプログラムし、正常に動作するかどうかを確認してください。詳細は添付の動画をご参照ください。 これらの手順がうまく機能しても、オンボード デバッガーでデバッグできない場合は、外部デバッガーを使用してテストしてください。 まだ問題がある場合は、お気軽にお問い合わせください。 よろしくお願いします。 BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang 、 ご返信ありがとうございます。 ビデオの指示に従いましたが、その方法で LED が点滅しました。 ただし、MCUXpresso IDE からデバッガーに戻ると、同じエラーが発生します。 問題がオンボード デバッガーから発生している場合、特に私が使用しているボードは学校で貸与されたものなので、PEMicro や SEGGER J-Link (それが言及されている場合) などの外部デバッガーを購入するつもりはありません。 解決策が見つからない場合は、私のプロジェクトでも機能するフラッシュ プログラマーを引き続き使用し、教授に外部デバッガーがあるかどうかを尋ねます。 よろしくお願いいたします。 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D あなたのボード上のデバッガーが実際に壊れているかどうかはわかりません。次の手順に従って、デバッガー ファームウェアを更新してください: https://docs.nxp.com/bundle/UM12018/page/topics/Updating_MCU_Link_firmware.html 更新後、ボードの電源を入れ直し、MCUXpresso IDE で新しいワークスペースを作成し、新しい SDK デモをインポートして、再度デバッグを試みます。 ビデオを撮って私と共有していただけると嬉しいです。確認をお手伝いします。 よろしくお願いします。     BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang ご返信よろしくお願いします。 提案されたとおりに LinkServer を更新しましたが、問題が発生した後にすでに更新されていたと思います。とにかくもう一度アップデートを試み、ボードの電源を入れ直し、新しいワークスペースを作成し、デモ プロジェクトをインポートしましたが、デバッグしようとすると同じ Ee(42) エラーが発生します。 プロセスを示す短いビデオを録画したので添付します。 ご協力ありがとうございました。良い新年をお迎えください。 よろしくお願いします、 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D ビデオをありがとう。 .launch ファイル (下の画像) を削除して、ボードを再度消去してください。 デバッグを開始するには、下の図に示すデバッグ ボタンを使用します。 それでも動作しない場合は、ボードを交換することをお勧めします。 ちなみに、私は正月休みを頂き、1月5日に復帰します。もしご不明な点がございましたら、当日にお問い合わせください。 ご理解のほどよろしくお願いいたします。新年あけましておめでとうございます。 BR アリス

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

使用 PN7160 — P2P 与 Type-4 标签模式在两个 Linux 板之间共享 Wi-Fi DPP 凭证？ 您好，NXP团队， 我正在使用 PN7160 NFC控制器和恩智浦 Linux NFC 堆栈在两个 Linux 板（联发科 Genio 510 EVK）之间进行 Wi-Fi 接入 ： https://github.com/NXPNFCLinux/linux_libnfc-nci 系统设置 Board-1 (M1) 使用 hostapd 充当 Wi-Fi 接入点 (AP) PN7160 支持 NFC Board-2 (M2) 使用 wpa_supplicant 充当 Wi-Fi 站 (STA) PN7160 支持 NFC 目前是 手动配置凭证时，Wi-Fi 接入点/STA 连接正常工作 nfcDemoApp 中的 NFC 读/写和轮询示例正常工作 目标 我想使用以 NFC 作为引导通道的 Wi-Fi DPP（Easy Connect）自动配置从 M1（AP）到 M2（STA）的 Wi-Fi 凭证 ，这 与 Wi-Fi 联盟的入门操作类似。 问题 1.NFC 模式选择 对于两块板之间的 Wi-Fi DPP 凭证配置： 是否应使用NFC 点对点（P2P / LLCP / SNEP）模式？ 还是应该在接入点侧使用Type-4 Tag 仿真（NDEF、application/vnd.wfa.wsc 或 DPP URI），由 STA 充当 NFC 读卡器？ 从Wi-Fi联盟的参考资料来看，NFC似乎主要用作引导渠道，但我想确认一下在使用 PN7160 时推荐的NFC模式。 2.使用恩智浦 demoapp 使用现有的linux_libnfc-nci demoapp 示例： 能否将Type-4 标签仿真示例扩展到： 在 M1（接入点）上模拟 Wi-Fi 配置标签 向 M2（STA）提供 Wi-Fi 接入数据 对于 Wi-Fi DPP 上载，推荐还是不推荐使用NFC P2P + SNEP？ 3.Wi-Fi DPP 集成 一旦在 M2 上接收到 NFC 数据： 是建议的流量： NFC → DPP 引导信息（URI/公钥） 然后使用 wpa_supplicant通过 Wi-Fi 进行 DPP 验证？ 恩智浦是否有集成方面的参考示例或指南： PN7160 NFC 栈 Linux wpa_supplicant DPP 命令 可实现AP-STA 自动连接？ 摘要 我正在寻求以下方面的指导： Wi-Fi DPP 的正确 NFC 模式（P2P 与 Type-4 标签 如何重复使用或扩展现有的恩智浦演示应用程序 推荐架构，用于在两个 Linux 板之间实现安全、符合 Wi-Fi 联盟标准的接入 如有任何参考、样本流程或最佳实践，将不胜感激。 感谢您的支持。 致以最崇高的敬意， Niranjan Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 感谢您对我们的产品感兴趣。 建议的解决方案是使用我们的 "连接 "标签之一。在您描述的设置中，我们建议在 M1 (AP) 主板上连接 NTAG 5 Link 板。主机在 Tag 中生成要读取的正确的 NDEF 消息，并为安全访问配置所需的凭据。   如果您想使用 SNEP，则需要在双方都安装 NFC 阅读器。这将增加成本和 P2P 的实施，需要额外的指令交换。这还需要额外的符合规范的软件开发工作。   请记住，在接入点端使用 NTAG 5，您需要根据 NDEF 消息和 Type 5 标签内存配置规范的 NFC 论坛规范构建 NDEF 消息。有必要同时购买两种规格。 在 M2 板上，您将需要像 PN7160 这样的 NFC 读取器，它可以读取 NDEF 并与 AP 建立连接。 希望这些信息对您有所帮助。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 你好@Fabian_R 谢谢你的澄清。 我知道使用SNEP 需要在双方都安装 NFC 读卡器，这会增加 BOM 成本，而且由于P2P 命令交换和根据 NFC 规范进行额外的软件开发，也会增加复杂性。 不过，对于我们的使用案例，我们希望进一步评估这种方法。 能否请您就基于 SNEP 的解决方案澄清以下几点： 建筑指导 两个 Linux 板都应该在启用 P2P 读取器/启动器模式下运行吗？ 一个板应该充当 SNEP 服务器，另一个板充当 SNEP 客户端，还是两者都需要支持这两个角色？ 软件堆栈要求 能否使用linux_libnfc-nci 协议栈和演示应用程序（如 SNEP 或 P2P 示例）来实现？ 基于 SNEP 的凭据交换是否需要对 NFC 栈进行任何特定的配置更改？ 数据交换流程 是否建议通过 SNEP 有效载荷交换Wi-Fi DPP 引导信息（QR URI / 公钥）？ 通过 NFC 接收数据后，应用程序是否应该直接在注册者端触发信号 wpa_supplicant DPP 命令？ 合规方面的考虑 在这种情况下，基于 SNEP 的 P2P 通信是否需要遵守NFC 论坛的强制合规要求？ 有关使用 SNEP 在两个 Linux 主板之间传输 Wi-Fi DPP 凭证的详细分步流程或参考实施指南将对我们评估可行性非常有帮助。 感谢您的支持。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 您好，先生， 我们提供的应用程序接口支持客户端和服务器角色。有关使用和实施的详细信息，请查阅规范（SNEP 和 LLCP）。P2P 的相关函数和实用程序可在 NfcLibrary/NdefLibrary/src/P2P_NDEF.c 中找到。 关于数据交换流问题，可以在Wifi联盟规格文档中找到此信息：连接移交技术规范和Wifi Easy Connect规范（设备配置协议）。 请记住，我们无法提供这些文件的具体内容。请务必购买。

How to download documents on chip-related resources Example: S32K3xx_interrupt_map.xlsx Re: 如何下载芯片的相关资源的文档 Hi@PQF Download the datasheet and instruction manual from the official website. You can find these documents you are looking for in the attachment to the instruction manual. https://www.nxp.com/products/S32K3

TWR-KV58 硬故障 早上好 我在 TWR 板上犯了一个明显的错误。我以前在同样的状态下使用这个板，它能正常工作，它在那里停了一会儿，现在我直接从硬故障开始。 我使用的是连接了 JTAG 电缆的 Multilink。我以前是这样做的。我直接从硬故障开始。 这是屏幕截图 跳线 J19 和 J20 打开，以便使用 JTAG。应该够了。 请提出建议。我只能假设它坏了 谢谢大家 Pietro Re: TWR-KV58 Hard Fault 早安 请支持我。我已经订购了一个新的作为备用解决方案，但我需要帮助才能继续。 谢谢 Re: TWR-KV58 Hard Fault 你好@pietrodicastri、 谢谢您的帖子。 为帮助确定这是否是软件问题，请检查在运行 SDK 中包含的演示程序（如 "Hello World "演示程序）时是否仍会出现 HardFault？ SDK 链接：选择板 | MCUXpresso SDK 生成器 如需了解更多详情，请参阅https://www.keil.com/appnotes/files/apnt209.pdf。 BR 西莱斯特 Re: TWR-KV58 Hard Fault 你好 板现在正在工作...我很感激你的支持。 我现在要发表一些其他内容。 谢谢 Pietro

S32 DS 3.3 许可证过期 你好，我的 S32 Design Studio 3.3 已过期： S32 Design Studio v.3.3 版 订购编号 S32DS-3-3_146477567 订购单编号 许可证总数： 101 激活代码 AF1B-F377-2238-53BB 您能帮我解决这个问题吗？非常感谢！ 亚历山大-穆勒 Re: S32 DS 3.3 License expired 你好、 您的 S32DS 许可证已延期。请使用旧代码重新激活 S32DS。

EB Tresos 29.0 问题 我使用离线激活功能激活了 EBtresos 29.0，但遇到了以下问题：处理响应时出现错误（50019、41200、10246）。如何解决这个问题？在尝试了很多次都没有成功后，我别无选择，只能使用离线激活。 Re: EB Tresos 29.0 Issue 你好 我不确定您采取了哪些步骤，但以下是 EB 提供的激活指南： 请参阅本章： 5.1.3.离线激活单个用户或评估许可证 如果您能提供更多细节，也许我能帮上忙。 顺祝商祺！ Peter Re: EB Tresos 29.0 Issue @petervlna 您好，我使用的激活代码是B25C-AEBB-4319-BAB1（有效期至 06/30/2026），来自恩智浦官方网站。生成脱机激活文件 activation.xml 时显示了一个 失败。多次尝试后，activation.xml 文件仍显示为 失败.如何解决这个问题？非常感谢您的帮助。该软件是 EB Client License Administrator 1.5.1。 我还尝试用我的电脑生成激活请求文件，但用我同事的恩智浦账户生成的 activation.xml 文件仍显示为失败。 你是中国人吗？我们以后能用中文交流吗？ Re: EB Tresos 29.0 Issue 你好 我刚刚测试了有效期到年底的新代码，激活成功。 您将在一天左右的时间内在恩智浦 SW 账户中找到它。 顺祝商祺！ Peter Re: EB Tresos 29.0 Issue 你好 你是中国人吗？我们以后能用中文交流吗？ 否。 点击这里查看。免费许可证库似乎已经枯竭： https://community.nxp.com/t5/S32K/EB-activation-failed/td-p/2252930 顺祝商祺！ Peter Re: EB Tresos 29.0 Issue 你好 以下是 flexera 管理员给我的官方答复： 更新正在进行中。它已转交给有权更新它的人。 如果要进行严肃的开发，我建议从 EB 购买永久许可证。否则，您就必须在这种情况下等待评估许可证的更新。 顺祝商祺！ Peter Re: EB Tresos 29.0 Issue 您好，感谢您的回复。不过，截至目前，恩智浦官方网站上的许可证尚未更新。新许可证何时启用？ Re: EB Tresos 29.0 Issue 你好 这太奇怪了。我已再次通知管理员更新代码。 我会推动它。 我还注意到有新的 EB tresos v 30。 顺祝商祺！ Peter Re: EB Tresos 29.0 Issue 您好，我已经等了三天，但激活码今天仍未更新。激活码何时提供？ Re: EB Tresos 29.0 Issue 您好， 代码现已在恩智浦 SW 账户中更新。 顺祝商祺！ Peter

Imx95 verdin EVK、Aquantia10gbpsインターフェースはudpで1.2gbpsに制限されています こんにちは、 私は、Aquantia 10 Gbps インターフェースを介して、2 つの Imx95 verdin EVK A1 シリコン バージョン ボード間の通信を確立しようとしています。両方のボードは、nxp インストーラー (aquantia-firmware-utility/aq_api_2_9_7 at master · nxp-qoriq/aquantia-firmware-utility · GitHub) を使用して適切にインストールされた aquantia10 G ファームウェア (AQR-G4_v5.6.D-AQR_Marvell_NoSwap_XFI_ID44834_VER2068.cld) とともに Debian 12 (Linux カーネル 6.12.3 ) を実行しています。これらは Cat6a イーサネット ケーブルを使用して物理的にコネクテッドされます。 iperf3 を使用してパフォーマンス テストを実行すると、ターゲット帯域幅を 7 Gbps に指定した場合でも、TCP で約 5 Gbps、UDP で約 1.2 Gbps が得られ、損失は 0% になります。 # TCPテスト 最初のボードで iperf3 -s # iperf3 -c -t 30 # 2番目のボード # UDPテスト iperf3 -s iperf3 -c -u -b 7G -t 30 ip link set dev enp1s0 mtu 9000 でジャンボ フレームを有効にしようとすると、制限を超えたというエラーが発生します (10Gbps インターフェースがジャンボ フレームを受け入れないのは奇妙です) また、UDPバッファサイズを増やそうとしましたが、同じビットフレームが発生します 両側でiperf3を実行してもCPU負荷は40%を超えません 最大スループット (10 Gbps 近く) を達成するために、適用する特定の n 構成やインストールする追加ツールはありますか? Aquantia FW バージョンは適切ですか? Linux カーネルのバージョンは適切ですか? FW インストーラーのバージョンは適切ですか? 誰かがすでにこのターゲットで 10Gbps インターフェースを使用しようとしましたか? よろしくお願いいたします。 アブデルモナエム Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1. 両方のシステムで次の設定を構成してみます。 cpufreq-set -g パフォーマンス sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 2. 可能であれば、iperfサーバーとは異なる参照システムを使用します（例：インテル Xeon 3. iperf3 自体はテスト ストリームごとにシングル Thread なので、-P オプションを使用してみてください。 例えばiperf3 -c -u -b 10G -t 30 -P 6 （6つのストリーム） 4. 順方向と逆方向の両方のストリームをチェックする（-R） iperf3 -c 192.168.1.1 -t 10 -b 10G -u -R Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp こんにちは、 ご意見ありがとうございます。 設定を適用します: cpufreq-set -g パフォーマンス sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 現在、送信側のみで10Gbps、時には8、8または9、8Gbpsを達成でき、iperfのみでiperf3は使用していません。レシーバ側では、フレーム損失が36%で5.59Gbpsしか達成できません。この問題を解決するのを手伝っていただけますか？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 6.12.49へのマイナーバージョンアップグレードとなります ところで、スループットを向上させるために、DPDK または AF_XDP も検討してみてはいかがでしょうか? Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCPとUDPの送信パフォーマンス iperf3 を使用して TCP パケットを送信する場合、各 TCP パケットは 128 KB であり、パケットは ENETC ハードウェアの LSO 機能によって断片化されます。SO、TCP 転送パフォーマンスが向上します。 iperf3 は、UDP ソケットを作成するときに UDP_SEGMENT を有効にしません。したがって： - 各 UDP パケットのサイズは、およそ MTU サイズ (≈1500 バイト) です。 - 同じデータ サイズの場合、UDP は TCP よりも多くのパケットを送信する必要があります。 パケット数の増加 → カーネルプロセッシングの増加 → LSO を使用した TCP と比較してパフォーマンスの低下。 => TCP の場合、受信が送信に比べて大幅に低いのはなぜですか? - Linux カーネルでは TX パスと RX パスが対称ではないため、カーネル内の各 RX パケットと各 TX パケットのプロセッシング時間は異なります。また、TCP は送信時に LSO オフロードを使用しています。 - RSC はカーネル内でデフォルトで有効になっていません。ENETC の RSC が適切に動作するように、TCP タイムスタンプを無効にする必要があります。現在、i.MX95 の RSC はデフォルトで無効になっています。 a) i.MX95（レシーバ）のRSCを有効にする： ethtool -K eth1 大容量受信オフロードオン b) TCPタイムスタンプを無効にする（送信側）: sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf RSC を有効にすると、レシーバの TCP パフォーマンスが向上します。 さらに、より高いスループットを得るためにジャンボ フレームを使用することもできます。(最新リリースを実行していることを願います)。 # 両側のMTUを9000に変更します IPリンク設定 dev eth1 mtu 9000 # イーサネット ドライバの RX バッファの長さを変更します。 ethtool -G eth1 受信バッファ長 16384 マルチストリーム モードでは、8 ～ 10 Gbps の UDP RX/TX が確認できます。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp こんにちは、 私は今のところUDPだけに興味があり、TCPには興味がありません。そして、オフロードは メカニズムはUDPには適用されません MTU を 9000 に設定してジャンボ フレームを有効にしようとしましたが、制限の 1500 を超えたというエラーが表示されます (カーネル バージョン 6.12.3 を使用しています) よろしくお願いいたします。 アブデルモナエム Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp RSC 設定により UDP パフォーマンスも向上します。 ENETC のジャンボ フレームの変更/修正は、2 週間以内にリリースされる LF-Q4 で利用可能になる予定です。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp わかりました、これを試してみます、そして結果がどうなったかお伝えします、 LF-Q4 の Linux カーネル バージョンを詳しく教えていただけますか?先ほど言ったように、私は 6.12.3 を使っていますが、シリコン リビジョンが A1 なので上位バージョンに移行できません。B0 リビジョンにアップグレードする必要があるかどうかを知る必要があります。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 問題はありません。iperf で 1 つのフローだけで 5Gbps の並列フローで 9、8Bps で 10Gbps まで行くことができますが、大きな問題は UDP です。モノフローでは 2Gbps でフレーム損失はなく問題ありませんが、並列フローでは 5、5Gbps で 42% の損失があります。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP や DPDK が 46% の損失を 0% に減らすのに役立つとは思えません。また、IRQ の親和性も検証したところ、10G インターフェースには 6 つの IRQ があり、それぞれが CPU に影響を与えていることがわかりました。テスト中に CPU 負荷の問題は発生しませんでした。1 つの CPU の最大 CPU 負荷は 40% です。フレームが失われ続ける理由がまだわかりません。使用しているカーネル バージョンがジャンボ フレームをサポートしていないことが原因かもしれません。 あなたの側（NXP）で10Gインターフェースのパフォーマンステストは実施しましたか？あなたの側でテストして、私と同じ問題があるかどうかを確認する必要があると思います。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP または DPDK はカーネル ネットワーク スタックを使用しません。 DPDK には特別なドライバがあり、ユーザー空間でのみ動作します。ネットワークとパケットプロセッシングに高度に最適化されています。すべての IP パケットに対して非常に高速なパフォーマンスをCANで提供できます。以下のサイトで確認することができます。 第10章: https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp このテストは、シリコン リビジョン A1 または B0 で実行されます。 このテストに使用されたカーネル バージョン 6.12.49 が B0 にのみ適用可能か、それとも A1 にも適用可能かを確認しますか? このカーネル バージョンは BSP 配信には表示されません。最新のものは 6.12.34 ですhttps://www.nxp.com/pages/alpha-beta-bsps-for-microprocessors:IMXPRERELEASES Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 新しいカーネル ツリーと変更は次の場所で入手できます。 https://github.com/nxp-imx/linux-imx/commits/lf-6.12.49-2.2.0 新しい LF リリースでは A1 サポートが削除されました。 次のオプションがあります。 1. カーネルを個別にビルドし、ビルド内のカーネルのみを置き換えます。（うまくいくかもしれない） 2. マーケティングお問い合わせにボードを B0 に交換してもらい、LF-Q4'2025 リリースを実行できるように SO CAN します。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp これらの行からは理解できません: 単一 UDP ストリーム送信 (1500 MTU): 2 Gbps (単一ストリームで MTU 1500 の送信では 2 Gbps になるようです) マルチ UDP ストリーム送信 (1500 MTU): 10 Gbps (これは、マルチ ストリームで MTU 1500 の送信では 10 Gbps になるようです) 単一 UDP ストリーム送信 (9000 MTU): 8.2 Gbps (単一ストリームで MTU 900 の送信では 8.2 Gbps になるようです) 単一 UDP ストリーム受信 (9000 MTU): 3.9 Gbps (単一ストリームで MTU 9000 の Rx では 3.9 Gbps になるようです) マルチ UDP ストリーム受信 (9000 MTU): 10Gbps (マルチストリームの MTU 9000 の Rx では 2Gbps になるようです) 私には見えません: 単一UDPストリーム受信（1500 MTU） マルチUDPストリーム受信(1500 MTU) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp わかりました。念のため、受信側で MTU = 1500 でテストを行ってください。この新しいバージョンで私と同じ結果が得られるか知りたいです。また、テストでは送信を 1500、受信を 9000 に設定していますが、これでは何も変わりません。両側で 1500 になっているようなものです。ジャンボ フレームをテストする必要がある場合は、両側で 9000 にする必要があります。次の構成でテストをやり直してください。 1- モノおよびマルチストリームで両側に MTU = 1500 の RX/TX 2- モノおよびマルチストリームで両側に MTU = 9000 の RX/TX よろしくお願いします Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp はい、このようにして結果がテストされました。 MTU はすべてのCASEで両側で同じでした (両方とも 1500 または両方とも 9000) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 添付資料参照 また、A1 SOCでも実行していることにも注意してください。 UBOOT ログ: - U-Boot 2025.04-g8c1de2e1deca(2025年5月9日 - 15:29:26 +0000) CPU: i.MX95 rev1.1（1800MHz） CPU: オートモーティブ温度グレード (-40℃～125℃)、30℃ LM ブート理由: sw、オリジン: 2、エラー: 1 LM シャットダウン理由: sw、発生元: 2、エラー: 1 モデル: NXP i.MX95 19X19 ボード DRAM: 15.8ギブ --- SMログ >$ 情報 SM バージョン = ビルド 633、コミット c37b26da SM 構成 = mx95evk、mSel=0 ボード = i.MX95 EVK、属性 = 0x00000000 シリコン = i.MX95 A1 ブートモード = 通常 ブートデバイス = MMC1 ブートステージ = プライマリ ブートセット = 1 ECID = 0x6E5F04BA0000000500041D0899123F81 PMIC 0 (0x08) = 0x20、0x09、0x10、0x00、0x01 PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A コンパイラ = gcc 14.2.1 20241119

操作指南：在 S32G 电路板支持包中配置静态 IP 1. 简介 当使用由电路板支持包（如 BSP43）生成的 Yocto 根文件系统时，默认的网络配置通常设置为使用 DHCP。因此，S32G-VNP-RDB3 板上连接到每个端口的 DHCP 服务器可能会为不同的以太网端口分配不同的 IP 地址。 这种默认行为对大多数客户来说很方便，因为它不需要额外的网络配置。端口在连接以太网电缆后立即可用，这与已包含DHCP服务器的典型开发环境非常吻合。 然而，有些客户可能没有可用的 DHCP 服务器，或者他们需要特定的网络配置，而不是使用 DHCP 自动分配的设置。例如，客户可能希望将某个以太网端口专门用于某个子网，以便通过 SSH 进行访问。在无法使用 UART 调试控制台的情况下，预先设置好静态 IP，便可在开发板启动后立即进行远程访问。 本文档介绍了一种方法，可为某个特定以太网端口配置静态 IP 地址，同时让其余端口继续使用默认的 DHCP 配置。客户还可以进一步定制配置以满足其具体的网络需求。 S32G