Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
如何转换数字信号的电压?(日语博客) 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 对于识别它们的重要含义。 此外,我们将解释在各种转换方法中应该选择哪种电压电平转换器。 我们将仔细研究双向开漏信号的转换,这需要特殊的处理方法。 界面 介绍 日本博客
記事全体を表示
S32K344 ハングアップ問題 MCU: S32K344 OS: FreeRTOS S32 Design Studio: 3.4.3 問題: I2C 書き込みブロッキングによる MCU のハング (タイムアウトなし) こんにちは、チーム S32K344 MCU をベースにしたカスタム ボードを使用しています。特定の I2C エラー条件下では実行時に MCU がハングするという問題が発生しています。 I2C インターフェースを介して接続された IMU スレーブ デバイスがあります。時々、次のようなとき: IMUに電源が入っていない、または I2C書き込み操作が失敗する(例:ACKなし/バススタック) I2C 書き込み API はタイムアウト状態を返さないか、タイムアウト状態になりません。その結果、 I2C トランザクションを実行する FreeRTOS タスクが無期限に停止し、最終的にアプリケーションがハングすることになります。 観察: この問題は、スレーブが応答しないか、バスが低く保持されている場合に発生します。 I2C ドライバは転送の完了を待機してブロックしているように見えます。 RTOS またはドライバ レベルではタイムアウトまたは回復メカニズムはトリガーされません。 サポートのリクエスト: S32K344 上の I2C トランザクションにタイムアウトを追加または強制するにはどうすればよいですか? スタックした I2C バス (SDA/SCL が低く保持される) を回復するための推奨される方法はありますか? S32K3 デバイス上のFreeRTOS で I2C を安全に使用するベスト プラクティスは何ですか? このシナリオを堅牢に処理する NXP のドライバ構成または例はありますか? あらゆるガイダンスや参考資料をいただければ幸いです。 ありがとう、よろしく。 ヴィナイ Re: S32K344 Hanging issue こんにちは@vinaykl 、 非常に古い RTD をお持ちです。 何か理由があるのでしょうか? RTD 2.0.0 と現在の RTD 7.0.0 の間では多くのバグが修正されています。 I2C ドライバのブロッキング API を使用すると想定しています。 代わりに、GetStatus() とタイムアウトとともに非同期転送 API を使用してください。 スレーブデバイスが SDA を低く保持し続ける場合は回復できます。I2C ユーザーマニュアルを参照してください。 セクション3.1.16バスはクリア https://www.nxp.com/docs/en/ユーザーガイド/UM10204.pdf   RTD ドライバには回復用の API がありません。 例としてはAN4803があります I2C復元関数の定義 https://www.nxp.com/docs/en/application-note/AN4803.pdf よろしくお願いいたします。 ダニエル
記事全体を表示
Zephyr SDK install error in Windows: setup.cmd Toolchain download failed Recently some Windows users started reporting issues installing the Zephyr SDK, required for building Zephyr applications.  Users first ran into this issue using NXP's MCUXpresso Installer, but had the same issue trying to manually install the Zephyr SDK. The root cause is that setup.cmd and these other tools use wget to download the individual toolchain packages.  And apparently recent changes in Windows or security settings interpret this wget download as unsecure, and wget is blocked. Context The Zephyr SDK is a package of multiple toolchains that support all the hardware platforms and CPU architectures available in Zephyr.  The binary bundle releases for download are available in two options: Minimal and Full.  For example, these bundles can be downloaded here for v0.17.4, currently the latest release. The Full bundle is a large download and includes all the toolchains and other tools in that download package.  The Minimal bundle is much smaller and does not contain any toolchains and allows users to choose the toolchains to download and install.  Minimal has an extra step after download to run the setup script and the user selects the tools to download.  In Windows, this script is setup.cmd. If installing the Minimal bundle and wget downloads are blocked for setup.cmd, then the Zephyr SDK install fails.  MCUXpresso Installer v25.12 and other install options use the Minimal bundle, and can be blocked by this issue. Workaround NXP is working on improving the MCUXpresso Installer to address this issue.  But in the meantime, downloading and installing the Full bundle avoids using wget and avoids this issue.   Download the Full bundle, here for v0.17.4, and extract the bundle in your user folder.  After extracting, the full Windows path will be  C:\Users\ \zephyr-sdk-0.17.4 .  West and other build tools will find this folder during the build.  The Zephyr SDK can also be installed elsewhere using an environment variable, see the Zephyr SDK documentation.  After extracting, run the setup.cmd to finish setup.  But with the Full install, setup.cmd will not need to download with wget. Be aware, this article was written when v0.17.4 was the latest release of the Zephyr SDK.  Check here for the latest release. Return to Zephyr Knowledge Hub
記事全体を表示
S32K3 FLEXIO数据异常 我在使用S32K314 RTD400的SAI0(主机)与FLEXIO模拟的I2S(从机)通讯,SAI只使用d0,MUX_DISABLE,word width为16,发现从机接收到的数据都是主机的数据循环左移一位得到的数据,比如发送0x8002,在代码里面从机得到的数据是0x5,改了很多配置都没用,最后勾选了下图中的Enable User Mode Support,数据就正常了,这是为什么 SAI配置如下 Re: S32K3 FLEXIO数据异常 Hi@Jason22 我查看了编译的结果,这个选项你勾不勾选完全不影响运行的结果。 按照你提供的工程,我勾选和不勾选Enable User Mode Support所编译生成的结果是完全一样的,这说明这不会导致你所说的问题。 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数据异常 没有勾选"启用用户模式支持",配置还是有效的 不勾选"Enable Flexio Common Support",配置才无效,我使用的是 S32DS 3.5.14,这和 S32DS 版本有关嘛 Re: S32K3 FLEXIO数据异常 嗨@Jason22 你不勾选 "启用用户模式支持"下面的配置不是不生效了嘛 Re: S32K3 FLEXIO数据异常 我也比对了,发现也是一样,重新运行了一下程序,发现勾选后,又出现了数据循环左移的情况,但我第一次勾选的时候,数据确实是正常了,重复跑了几次也正常,不知道是什么因素导致的。 那我想询问一下,是我的配置还是代码有问题嘛,为什么从机接收到的数据刚好是主机发送的数据循环左移的结果?谢谢 主机发送的数据 从机收到的数据 Re: S32K3 FLEXIO数据异常 Hi@Jason22 逻辑分析仪自己去测一下你发出的数据是不是正确的
記事全体を表示
如何安装"S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip" 您好, 我从 GreenVIP 安装了"S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite" ,但在下面的截图中找不到它。 如果我再次安装,就会出现错误提示。 请帮帮我。 谢谢! Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip" 你好,Lvyang508 感谢您的回复。 您是否安装了 SW32ZE_RTD_R21-11_2.0.1_D2505_? 在 S32DS IDE 中使用 DesignStudio_updatesite.zip? BR 乔伊 Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip" S32DS IDE:S32DS for Platform 3.6.5 我下载了相应的软件包并根据 UG_S32ZE_GreenVIP.pdf 进行了安装 Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip" 你好,Lvyang508 请检查您的 RTD 版本,RTD 和 RTOS 软件包之间似乎存在冲突。 另外,您使用的是什么版本的 S32DS 集成开发环境? BR 乔伊 Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip&&&& 嗨,乔伊、 我已经安装了 SW32ZE_RTD_R21-11_2.0.1_D2505_。 S32DS 集成开发环境中的 DesignStudio_updatesite.zip 文件。 谢谢您! Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip&&&& 你好,Lvyang508 感谢您的回复。 这个问题可能是由版本冲突引起的。请尝试使用 S32DS IDE 3.6.1 参考 UG_S32ZE_GreenVIP.pdf。 BR 乔伊 Re: How to install "S32ZE_R52_NXP_RTOS_4_7_181_RTM_1_1_0_D2412_DesignStudio_updatesite.zip&&&& 嗨,乔伊、    感谢您的回复。 我已经安装了 S32IDE 3.6.1、但问题依然存在。 BR、
記事全体を表示
S32K148 ロック 誤ってJ-LINKを使用してS32K148 MCUをフラッシュしてしまったため、再度接続しようとした際に「JLINK unsecured is no longer working」というエラーが発生しました。どうすれば解決できますか? 接続中... - USB経由でプローブ/プログラマデバイス0に接続 - プローブ/プログラマーファームウェア: J-Link V9 コンパイル日: 2022年12月13日 11:14:50 - プローブ/プログラマー S/N: 25994751 - デバイス「S32K148」が選択されました。 - ターゲットインターフェース速度: 50 kHz (固定) - VTarget = 3.301V - ConfigTargetSettings() の開始 - ConfigTargetSettings() 終了 - 305us かかりました - InitTarget() 開始 - SWDが選択されました。JTAG -> SWD切り替えシーケンスを実行しています。 - フラッシュ内のアドレス 0x400 - 0x40F の保護バイトは、読み出し保護が設定されていることを示します。 デバッガー接続の場合、デバイスはセキュリティ保護されていない必要があります。 注意: セキュリティを解除すると、内部フラッシュの一括消去が実行されます。 - 以前にレジストリに保存されたデフォルトの動作を実行します。 - デバイスは保護されなくなります。 - デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は停止しません。 - InitTarget() 終了 - 2.17秒かかりました - ID 0x2BA01477 の SW-DP が見つかりました - DPv0が検出されました - CoreSight SoC-400 以前 - APマップをスキャンして利用可能なすべてのAPを見つける - AP[2]: APマップの終端に達したため、APスキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011, ADDR: 0x00000000) - AP[1]: JTAG-AP (IDR: 0x001C0000, ADDR: 0x01000000) - APマップを反復処理して使用するAHB-APを見つける - AP[0]: スキップ。CPUIDレジスタを読み取れませんでした - AP[1]: スキップ。AHB-APではない - CPUへの接続に失敗しました。リセット状態で接続を実行しています。 Re: S32K148锁死 こんにちは@ドンクイリ まず、暗号化されたセグメントは永続的なエラー値で書き込まれており、大量消去ではサポートされない可能性があるため、回復は保証されません。 ドキュメント6. S32K1xxシリーズMCUチップロックアップ現象についてお読みください。 https://mp.weixin.qq.com/s?__biz=MzI0MDk0ODcxMw==&mid=2247485716&idx=1&sn=979631aa2385a4e3c7651ee75ee252b4&chksm=e9124d92de65c484f1cfec7de451958cfd5cf818c46a4f71a7d3dd8a522af229c5a18aad58ff&scene=21#wechat_redirect Re: S32K148锁死 お返事ありがとうございます。 リンク先のドキュメントとチップのマニュアルをよく読みましたが、何度か試しても一括消去では復元できませんでした。S32FlashTool_v2.3.4を使いたかったのですが、S32K148をサポートしていません。S32K148をサポートするS32FlashToolはありますか? Re: S32K148锁死 こんにちは@ドンクイリ これは使用しているソフトウェアとは関係ありません。記事にもあるように、リセットピンの波形をテストして、復旧できるかどうかを確認してください。復旧できない場合は、時間を無駄にしないでください。
記事全体を表示
弗劳恩霍夫 IIS 将主办 2014 年飞思卡尔®杯欧洲、中东和非洲地区面向有志工程师的决赛 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 位于德国埃尔兰根的弗劳恩霍夫集成电路研究所(与汤姆逊合作)发明了我们目前在智能手机和媒体播放器中广泛使用的 MP3 文件。他们拥有超过 20,000 名研究人员,是德国乃至全球研发界的一支力量。 该学院将于2014年4月29日至30日举办飞思卡尔杯2014年欧洲、中东和非洲地区决赛。 对于参加活动的学生团队来说,这是一个绝佳的机会,可以一睹工程研发的最佳成果,并与塑造未来世界的弗劳恩霍夫研究所的优秀工程师进行交流。 请参阅新闻稿20130715_Freescale_2014 - 弗劳恩霍夫集成电路研究所 IIS 飞思卡尔杯内容
記事全体を表示
TMU 导致 LS1046a CPU 在 -40C 的低温室下 RESET 我们有一块基于 LS4046a 的板正在零下40摄氏度的温度箱中进行测试,系统已关闭,报告“温度过高”,如下所示。我在散热驱动器中添加了日志代码来报告关机时的确切温度,关机温度为 101 度,这让我们感到困惑,板的低温室低于 -40 摄氏度,为什么 TMU 报告了临界高温? [2025-12-23 15:41:31.267] root@E7-2:~# [ 2435.041159] thermal thermal_zone0: ddr-controller:达到临界温度十六进制 0x18a88,十进制 101000,无符号 101000,正在关闭。 [2025-12-23 15:46:04.940] [ 2435.053636] 重新启动:硬件保护关闭(温度过高) Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我与 AE 团队讨论了这个问题,请参阅他们的以下更新。 TMU 的指定测量范围为 0~110C。-40℃超出范围,寄存器值可能会被软件误读。 客户可参阅 AN12310 和 LSDK 用户指南第 11.3 章。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我还编写了一个脚本,在 -40C 环境下轮询温度寄存器(TRITSR0 - TRITSR4),大部分时间 V 位为 0(无效),但不时 V 位设置为 1(有效),当 V 位为 1 时,TEMP 字段显示高温,见下图,温度寄存器报告 0x65000080,其中 0x80 表示 V 位为 1,0x65 是温度值,十进制为 101 度。 temp_val=0x65000080, (temp_val& 0xff000000)=0x65000000, (temp_val& 0x000000ff)=0x00000080 为什么 TRITSR 寄存器的 V 位被设置为 -40C 下有效,从而误导软件读取无效温度? Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请参阅 AE 团队提供的以下信息。 这不是错误,而是预期行为。 LS1046A TMU 的指定测量温度范围有限(约 0 °C 至 110 °C)。在 -40 °C 时,TMU 的工作温度超出其有效范围。 当温度超出范围时,TMU 仍会偶尔断言 V(有效)位,这意味着转换已完成,尽管转换结果没有物理意义。 与此同时,TMU 状态寄存器(TSR)中的 ORL(低电平超出范围)标志也会被确认。 如果软件仅检查 V=1 而忽略 ORL=1,它可能会将该值误解为正常温度(例如,0x65 → 101 °C),并触发错误的超温关机。 建议 在使用 TRITSR 温度值之前,请务必检查 ORL 标志。 如果 ORL=1,则将温度读数视为无效,与 V 位无关。 或者,推迟启用 TMU 监控,直到 SoC 温度恢复到有效范围内(≥0 °C)。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我检查了 ORL 位,似乎该位在检测超出范围的低温时并不可靠,如下所示 我的显卡在室温下运行,TMU 的温度约为 58 摄氏度。 root@E7-2:~# cat /sys/class/thermal/thermal_zone0/temp 58000 root@E7-2:~# cat /sys/class/thermal/thermal_zone1/temp 59000 读取 TMU 模式寄存器 (TMR) 和 TMU 状态寄存器 (TSR),启用 TMU 模式并钳位 ORL root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00004 w 0x000000A0 然后我禁用了 TMU 监控模式,发现 ORL 已被清除 root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00000 w 0xFFFF000C #disable the monitoring mode root@E7-2:~# devmem 0x1f00000 w 0xFFFF000C root@E7-2:~# devmem 0x1f00004 w #ORL bit was cleared 0x00000020 然后我重新启用了 TMU 监控模式,ORL 位又被钳位 root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00004 w 0x000000A0 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber TMU 温度测量范围为 0-125°C。 RM 表示寄存器 ORL - 检测到超出范围的低温测量值。温度传感器检测到的温度读数低于 0 摄氏度的最低可测量温度。TMU监控(重新)启用后,该位将自动清零。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 该卡处于室温下而不是环境低于 0 摄氏度,TMU 报告 56 摄氏度,而 ORL 仍然钳位 ORL 表明低温超出范围,这没有道理,为什么即使卡在室温下也钳位 ORL 位?如前面的评论所示,我重新启用了 TMU 监控,重新启用 TMU 监控模式后,ORL 位仍处于钳位状态。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 这个问题有什么新进展吗? 上周,我们在另一种具有相同 CPU 的显卡上发现了同样的问题,我们想知道是否有解决方法,谢谢。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请参考我在 LS1046ARDB u-boot 上的验证结果。 => mw 0x1f000000x00F8000C => mw 0x1f000000x00F8008C => md 0x1f00100 1 01f00100:25000080...% => md 0x1f00004 1 01f00004:00000000.... = md 0x1f00004 1 01f00004:00000000.... => Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请使用以下值配置寄存器0x1f00000。 => mw 0x1f00000 0x00F8000C => mw 0x1f00000 0x00F8008C Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 将 TMU 寄存器的 RESERVED 位(bits21 ~ bit31)设置为 0 似乎可以清除我的卡上的 ORL 位。如果这些保留位为 1,则无法清除 ORL,不知道为什么。总之,我会在 TMU 驱动程序中将这些位初始化为 0,然后在读取温度之前检查 ORL 位。谢谢 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 是的,谢谢,我做到了,而且将再次进行 -40C 下的热测试,以检验代码的更改,希望它能通过测试。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber root@LG871:~# devmem 0x1f00000 w 0x00F8008C //保留位为 0,则未钳位 ORL 位 root@LG871:~# devmem 0x1f00004 w 0x00000080 root@LG871:~# root@LG871:~# devmem 0x1f00000 w 0xFFF8008C //保留位为 1,然后 ORL 位钳位为 root@LG871:~# devmem 0x1f00004 w 0x000000A0
記事全体を表示
如何下载芯片的相关资源的文档 例如:S32K3xx_interrupt_map.xlsx Re: 如何下载芯片的相关资源的文档 Hi@PQF 在官网下载数据手册和指导手册。在指导手册的附件中可以找到你要的这些文档。 https://www.nxp.com/products/S32K3
記事全体を表示
S32K3xx、FLSアレイ整合性チェック こんにちは、チームの皆さん 3.0.0などの古いRTDバージョンのFLSドライバでArrayIntegrityCheckを使用する例や検証テストプロジェクトはありますか?お客様と共有できるものはありますか? 新しいRTDリリース(例:6.0.0)のユーザーマニュアルには、そのような例が含まれていますが、古い FLS バージョンでは同様のものは見つかりませんでした。 ありがとうございました。 BR、ダニエル RTD Re: S32K3xx, FLS ArrayIntegrityCheck こんにちは@danielmartynek 、 RTD 3.0.0に基づくC40_Ip_ArrayIntegrityCheckの例を添付しました。P07バージョン。 よろしくお願いいたします。 ダン Re: S32K3xx, FLS ArrayIntegrityCheck こんにちは@DanNguyenDuy 、 例をありがとうございます。 現在、外出中なので、まだテストできていません。 ただし、お客様は命令バス障害例外が発生したと報告しています。 明確に言うと、私の理解では、テスト中はフラッシュ アレイが使用できなくなるため、アレイ整合性チェックに関係する C40_Ip API は SRAM から実行する必要があるということです。 これは正しいですか? ドライバのテスト/検証中に、どの特定のドライバ API が SRAM から実行されたかを確認できますか? ありがとうございました。 BR、ダニエル Re: S32K3xx, FLS ArrayIntegrityCheck こんにちは@danielmartynek 、 1. これは正しいですか? => はい、その通りです。 2. ドライバのテスト/検証中に、どの特定のドライバ API が SRAM から実行されたかを確認できますか? => 今のところ、SRAM 上で C40_Ip_ArrayIntegrityCheck を実行することをサポートする特定のドライバはありません。 よろしくお願いいたします。 ダン Re: S32K3xx, FLS ArrayIntegrityCheck こんにちは@DanNguyenDuy 、 ご返信ありがとうございます。 C40_Ip_ArrayIntegrityCheck()とC40_Ip_CheckUserTestStatus() をSRAM に配置する必要があることは理解しています。 SRAM に配置する必要がある追加の機能はありますか? C40_Ip ドライバの機能はテスト済みであるはずですよね? SO、テストのセットアップについて詳細を教えていただけますか?ドライバ所有者が検証の実行方法についてコメントしていただければ助かります。 BR、ダニエル Re: S32K3xx, FLS ArrayIntegrityCheck こんにちは@danielmartynek 、 RTD チームは、linker_flash の代わりに linker_ram を使用してこの機能をテストしました。 この例では、ユーザーはmakefile内の変数を変更できます: LOAD_TO=ram はlinker_ramを使用します。 よろしくお願いいたします。 ダン
記事全体を表示
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
記事全体を表示
TPMS 位定时 大家好, 我正在尝试使用 FXTH87E 传感器匹配 OEM TPMS 传感器的位定时。 我修改了入门项目 FXTH87_E_FW_Periodic_RF_Tx。 我所遇到的问题是,我正试图使发送的数据达到 ~25us 位定时,但有些位是 ~50us 位,有些位是 ~25us 位。 我曾尝试通过 RFCR0 将数据传输速率提高一倍,达到 ~40 kbits,这样就解决了前导码问题,但最终得到的比特数却只有 ~13us。 我使用的也是曼彻斯特编码。 我似乎无法找到正确的设置,让所有比特都以相同的数据速率传输。 我附上了我的 main.c 和两个逻辑分析仪捕获,一个是 OEM TPMS 传感器,另一个是我的。我正在尝试复制 ~5ms 的数据包长度和 ~25us 的位定时。 目前,我得到的数据包长度约为 7ms,可变位定时约为 50us 和 25us。 如有任何建议,我们将不胜感激。 致以最诚挚的问候 Re: TPMS bit timing 你好,克雷格、 从主设备中的代码来看,以 19200 bps 的数据传输速率(RFCR0 配置)传输 136 比特。因此传输时间为 136/19200 = 7 毫秒。因此,从代码来看,完全可以预期帧的持续时间是 7 毫秒,而不是 5 毫秒。 数据传输速率为 19200 bps,一个比特持续约 50 秒。在射频配置中,曼彻斯特编码被选择为 434 MHz。而在曼彻斯特,在位的中间(约 25 秒后)有一个高到低或低到高的转换。这意味着低电平或高电平状态可以持续 25 us 或 50 us。 我将手册(UM11227)中显示曼彻斯特编码的摘录复制如下。 因此,捕获的波形与 main.c 中的配置相匹配,没有什么不正常的。 BRs, Tomas Re: TPMS bit timing 你好,托马斯、 感谢您的详细答复。 同样使用 FXTH87E 的 OEM 传感器一定没有使用标准的数据发送方式? 下面的逻辑分析器捕获没有像 UM11227 中显示的那样有过渡效果。据我所知,连续的 0 和 1 并没有产生转换,它只是在两个周期内保持相同的值,即 ~50us。 解码后的捕获为: 010101010101010101010010110010101010101 他们是否可能以某种方式修改了发送的数据,以创建上述数据,使连续比特的比特时序加倍,而不发生转换? 我尝试过使用不同的 CODE[1:0] 设置,还将位定时提高到 40 kbit 以获得 ~25us 位定时,但并没有消除过渡。 对不起,我的问题很简单,这是我第一次尝试复制数据包。 如能提供进一步指导,将不胜感激。 致以最诚挚的问候 克雷格 Re: TPMS bit timing 经过几个小时的实验,我相信我已经取得了进展。 我知道数据是曼彻斯特编码的。 了解到这一点后,我使用了 NRZ,这样就能实现单个比特 25us 和两个连续比特 50us 的一致比特定时。 然后我继续使用曼彻斯特编码对数据字节进行编码。经过反复试验,我终于能够复制 OEM 数据包,并通过接收器成功解码。 在我努力工作的过程中,感谢您的指导。 请将此问题视为已解决。 致以最诚挚的问候 克雷格
記事全体を表示
[MPC5777C] 了解 e200z759n3 内核的指令流水线 您好! 在研究 e200z759n3 内核的指令执行路径时,我想到了以下问题: 看来e200z7核心参考手册在管道执行单元的内容上并不十分一致。在图 17 中,整数执行单元和乘法单元是分开的。不过,"4.2.1 整数执行单元 "部分涵盖了整数乘法和除法。4.6 并发指令执行 "一节提到了 "双标量整数单元 "的存在,但没有提到任何乘法单元。我认为内核有两个整数执行单元,可以执行任何整数运算(如和、乘、除)。我的结论正确吗?双发行流水线能否同时执行两个乘法运算? 我画了下图来说明管道执行流程,并根据参考手册更好地理解它。我误解了什么概念吗? 顺祝商祺! 马特乌斯 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 1) 当然是的,这张图片与 e200z4 有关,也是双重问题 2) 这取决于管道内容本身。您可以从上一个答案的图片中看到。第一条指令很短,不会对另一条指令造成任何停滞。第二条指令较长,会导致停滞,因为第三条指令取决于第二条指令的结果。 3) 还得再等等。 4) 基本上是的。在此,编译器优化也会对其产生影响,编译器可能会改变指令顺序,以更好地利用双发架构(即:"......")。指令调度),以实现最高级别的优化。 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 感谢您的回复,大卫! 还有几个问题: 由于流水线具有双发功能,而执行单元有两个整数单元,那么它能否在同一时钟周期内启动两个独立的整数乘法或整数除法指令的取数阶段? 在执行加法这样的简单指令时,手册上说它在一个时钟周期内完成执行阶段。WB 级是紧随 E0 级之后进入时钟周期,还是必须再等待三个空闲时钟周期,就像必须增加一个空闲填充,才能使用流水线的所有 10 级完成从 IF0 到 WB 的整个周期? 当两条指令之间存在数据依赖关系时,目标指令是在与源指令最后执行阶段相同的时钟周期内开始执行阶段,还是必须等待下一个时钟周期?我不清楚馈送器是如何工作的。 既然是解码阶段检查指令之间的数据依赖性,那么所有流水线停滞都发生在 D1 和 E0 流水线阶段之间的结论是否正确? 顺祝商祺! 马特乌斯 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 1) 我认为它无论如何都不会与执行单元分离,它只是执行单元的一部分: 2) 我无法确认您的草图是否准确,但从原则上讲,这肯定是正确的,而且符合流水线的各个阶段。原则上,这肯定是正确的,也符合管道阶段的要求: 我可以推荐以下演示文稿,它可能比 e200 手册更容易阅读: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/e200-Core-Training-relevant-to-MPC55xx-and-MPC56xx-device-family/ta-p/1115124 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 你好,戴维 为了了解指令流水线中的内存依赖性,我为以下代码片段构建了时序图,其中包含与 r6 相关的依赖关系: mtctr r5 .loop: e_addi r6, r6, 1 e_mulli r6, r6, 1 e_bdnz .loop 不过,在绘制图表(附在本回复后)时,我注意到,虽然吞吐量保持不变,但指令执行延迟每次迭代都会增加两个周期,而且似乎没有上限。我错过了什么吗?流水线是否规定了滞留指令的最大数量? 欢迎指出我图表中的其他错误。 致以最诚挚的问候, Matheus Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core FF 的意思是前锋,与 STALL 不同。我建议大家也看看 e200z6 RM,因为它是较早的核心变体,有些主题的描述方式有些不同,可能更容易理解。 https://www.nxp.com/webapp/Download?colCode=E200Z6RMAD&location=null 是的,演示可能会简化,但我觉得差别不大。 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 你好 似乎每迭代一次循环,滞留指令的数量就会增加两条。 流水线对停滞指令的数量有限制吗? 它们被储存在某个缓冲器中吗? 如果是,该缓冲区有多少条目? 这是否与缓冲区的问题有关? 如果停滞的指令被保存在某个缓冲区中,那么当缓冲区满了,又有一条指令停滞时,会发生什么情况? 顺祝商祺! 马特乌斯 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 我认为这可能是正确的,乘法运算的延迟指定为 3 或 4 个周期(每 4 个周期有一个结果)。这种情况是最糟糕的极端情况,即所有操作都依赖于前一个操作的结果,此外还在循环中运行,这基本上导致管道的完全消除。 它的工作原理与完全无管道的情况基本相同。 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 您好! 回到管道填充问题上来。如果没有像您发送的图像所示的那样填充所有四个执行阶段的填充,那么为什么参考手册中的图表显示 " FF " 边距? 没有填充物的演示图不是简化版吗? 带填充的参考手册图: 顺祝商祺! 马特乌斯 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 我认为你的图表中的错误在于,你总是从左侧开始。我不知道我是否能够解释清楚。 使用 e200z6 手册中的图片,在指令缓冲器之后是指令寄存器(标记),然后是解码级。当执行单元出现停滞时,意味着指令缓冲区中的指令在无法进入后续阶段时也无法解码。 理想情况下,您可以考虑每个单位在某些点的确切状态。总之,在图表中将停滞点置于何处并不重要,因为其结果总是导致相同的性能。 性能受限于流水线的瓶颈,这里指的是欧盟单元的停滞,影响整个系统。 我不确定这是否有帮助。 总之,你为什么要知道这么确切的细节呢? 无论如何都无法以这种方式分析真实代码,为此目的,有性能监测器、调试跟踪等工具。 Re: [MPC5777C] Understanding the instruction pipeline of the e200z759n3 core 你好,戴维 我正在研究通过共享硬件进行的内核间交互如何影响执行时间和资源消耗。我使用性能监测进行了一些验证,但我无法理解我的结果,现在我明白了。非常感谢你的澄清! 最良好的祝愿, Matheus
記事全体を表示
NHS3152 上的 DAC 产生三角信号的 ADC 采集问题 我正在使用NHS3152设备通过 DAC 生成三角波形,并使用 ADC 测量该信号。配置如下 使用带有参数 ADCDAC_IO_ANA0_5 的函数 Chip_ADCDAC_SetMuxDAC 在引脚ANA0_5上配置 DAC 输出。 使用 Chip_ADCDAC_SetMuxADC 和参数 ADCDAC_IO_ANA0_3 在引脚ANA0_3上配置 ADC 输入。 一根电缆将 ANA0_5 物理连接到 ANA0_3,以使信号循环。 技术细节: 两个引脚的 IOCON 配置均设置为模拟模式 (IOCON_FUNC_1)。 DAC 在SINGLE_SHOT模式下运行,以在每次写入时更新输出,但切换到CONTINUOUS模式并不能解决问题 - 它只会稍微影响信号质量。 ADC 以连续模式运行,检测阈值设置为1500 (LOW_THRESHOLD)和2000 (HIGH_THRESHOLD)。 代码为三角波形(范围从 DAC_MIN_VALUE 到 DAC_MAX_VALUE)生成查找表 (LUT),并且 16 位计时器定期触发 DAC 更新。 尽管输出上可以清晰地观察到三角信号,但没有触发 ADC 中断,也没有记录 ADC 转换结果。 采取的故障排除步骤: 我已验证 MUX 选择功能(Chip_ADCDAC_SetMuxADC 和 Chip_ADCDAC_SetMuxDAC)使用正确的通道(ADC 为通道 3,DAC 为通道 5),如文档中所述(UM10876 手册第 9.4 章,图 90)。 我确认两个引脚的 IOCON 设置都正确设置为模拟模式(IOCON_FUNC_1),并且连接 ANA0_5 和 ANA0_3 的电缆已正确安装并具有公共接地。 我测试了修改 ADC 中断例程中 ADC 转换就绪标志(ADCDAC_INT_CONVERSION_RDY_ADC)的检查,但这并没有改变行为。 除了信号质量略有变化外,在 SINGLE_SHOT 和 CONTINUOUS 之间更改 DAC 模式对问题没有显著影响。 请求协助: 我希望您能帮助我了解: 考虑到它采用循环调度程序运行,通过模拟多路复用器使用两个不同引脚的当前配置对于 NHS3152 上的共享 ADCDAC 块是正确的。 还有一些其他限制(例如时序或配置序列问题)可能会阻止在此设置中触发 ADC 中断。 其他修改方法(例如以单次模式测试 ADC 或对 ADC 和 DAC 使用相同通道)可以解决该问题。 请参阅附件中用于此配置的完整代码。提前感谢您的帮助和建议。 问候, 托马斯 回复:NHS3152 上 DAC 生成三角信号的 ADC 采集问题 我想向您更新我所提交的票的情况。主要问题如下: DAC 产生的三角波形太快。这个快速信号没有给 ADC 足够的时间来正确捕获值。 我错误地使用了中断处理程序的错误名称。它必须命名为ADC_IRQHandler(void)而不是ADCDAC_IRQHandler(void) 。 降低频率(或增加每个周期的样本数)并重命名中断例程后,ADC 开始按预期工作。
記事全体を表示
PBRIDGE accessed by two resources at the same time Please, in MPC5777C what happens if SPI is sending data through the PBRIDGE at the same time another resource is sending data as well, for example the temperature sensor. What data will be processed first? How bridge chooses the data to be processed first? Re: PBRIDGE accessed by two resources at the same time Yes, this is managed by XBAR (if it is the same PBRIDGE as some devices has two or more). Re: PBRIDGE accessed by two resources at the same time If two cores try to simultaneously access resources connected in PBRIDGE, will these accesses be arbitrated by XBAR or there is another arbitration mechanism in bridge? Re: PBRIDGE accessed by two resources at the same time SPI does not initiate any data transfer over PBRIDGE as it is XBAR slave port. XBAR master initiates (core, eDMA, ..) data transfers (but it can be according interrupt or trigger signal from XBAR slave). However transfers over XBAR are processed according XBAR priority.
記事全体を表示
MIPI-CSI-2 とベイヤーパターンカメラ (RAW10) を使用した i.MX93 こんにちは、 カスタムの i.MX93 ベースのボードを持っています。提供されている CSI-2 インターフェースを使用して、ベイヤーパターン カメラ (IMX327) で RAW10 データを転送したいと考えています。 デバイスツリーの設定とプレスリリース、製品ニュース-ctlの設定はSO far正しいのですが、パイプラインを開始するとdwc-mipi-csi2からIRQストームが発生し、「 IPIインターフェース致命的イベント情報」カウンタが増加します。INT_ST_IPI_FATALレジスタの値は0x2aで、IPI FIFOオーバーフローを示しています。IPIがIRQを1つも持っていないため、ISIにデータをプッシュしていないのではないかと考えています。 https://community.nxp.com/t5/i-MX-Processors/About-settings-to-operate-ov5640camera-on-i-MX93EVK/mp/1716885/highlight/true#M212016を参照何らかの特別な設定があるようです。これらの値をRAW10に適合させようとしましたが、CAMERA_MUX[DATA_TYPE]の値0x31(ユーザー定義16)について疑問がありました。CSI-2 データ型 RAW10 の場合、これが 0x2b ではなくユーザー定義であるのはなぜですか? IPI エラーの原因は何でしょうか?この問題をさらにデバッグするにはどうすればよいでしょうか? 感謝と敬意を表します。 アレクサンダー Re: i.MX93 using MIPI-CSI-2 with a Bayer Pattern camera (RAW10) アップデートはありますか?Omnivision 9732でも同じ問題が発生しています Re: i.MX93 using MIPI-CSI-2 with a Bayer Pattern camera (RAW10) こんにちは@brian14さん、 i.MX93 と RAW10/12 Bayer データを出力するカメラ センサでも同じ問題が発生しています。 何かアイデアや提案はありますか? よろしくお願いします。 Re: i.MX93 using MIPI-CSI-2 with a Bayer Pattern camera (RAW10) こんにちは、 連絡あった?もう1ヶ月が経ちました。 ありがとう、アレクサンダー Re: i.MX93 using MIPI-CSI-2 with a Bayer Pattern camera (RAW10) こんにちは、 このトピックに関して何かニュースはありますか? ありがとう、そしてよろしく。 アレクサンダー Re: i.MX93 using MIPI-CSI-2 with a Bayer Pattern camera (RAW10) こんにちは@steinaさん、 NXP サポートにお問い合わせいただきありがとうございます。 このCASEについては社内チームで検討し、できるだけ早くお問い合わせいたします。 すてきな一日を!
記事全体を表示
S32K144: Integration of FlexCAN inside lin_master_s32k144 (S32DS.ARM2.2) Good morning: Currently using the S32K144EVB board to prepare a system demo, where we must manage 1 classical CAN-HS network (500k) and 3 LINs. (19200, multiple slaves in each LIN)  k144EVB board will behave as LIN master for the 3 LINs, that's why as starting point I've selected the LIN_master_S32K144 example. LINStACK is working fine and now I've started to check the integration of the CAN communication into the project. Reviewing S32K144 documentation and examples, i see that the K144 has 2 different ways to manage the CAN communication... either via FIFO or either via MBs... Unclear the benefits of one over the other...  for a system where i must receive 4-5 CAN messages, process some of the content data and transmit periodically 1 or 2 CAN messages: 1) which configuration is easier/better to use, considering that my LIN master will operate at full capacity?FIFO or MB? 2) do we expect any registers/clock/interrupts conflicts between NXP linstack and the FlexCAN integration? 3) is there any example available already with such an integration (LIN-MASTER + CAN-HS)? Re: S32K144: Integration of FlexCAN inside lin_master_s32k144 (S32DS.ARM2.2) Hi@rricart There's no relationship between LIN and CAN; they are two independent peripheral modules. For the S32K1 FlexCAN, the CAN FIFO does not support CAN FD, so you need to consider whether need to support CAN FD or not. If your project doesn't require CAN FD feature, either the MB or the FIFO will fine. You can refer to the demo provided in this link, which categorizes the different ways to use FlexCan and provides a simple test demo. https://community.nxp.com/t5/S32K-Knowledge-Base/S32K1xx-FlexCAN-Mask-Setting-Demo/ta-p/1519753
記事全体を表示
LPC1115 Rev A 驱动程序与 Windows11 的通信问题 需要在 PC 上安装 massDfu64.sys 驱动程序才能进行通信。但是,由于 Windows 11 的内存完整性问题,该驱动程序无法安装。请问,在不关闭内存完整性功能的情况下,我该如何解决这个问题? 谢谢 Re: LPC1115 Rev A Driver communication issue with Windows11 您好, 当 LPC1115 与电脑连接时,它通常会尝试安装驱动程序,但却不起作用。此外,我也没有 LinkServer.exe。 此致, 卡斯滕 Re: LPC1115 Rev A Driver communication issue with Windows11 你好,@CKGrech、 您可以通过以下链接找到链接服务器安装可执行文件:适用于微控制器的LinkServer | 恩智浦半导体 请下载并以管理员权限打开。 如果安装后仍有问题,请告诉我。 Re: LPC1115 Rev A Driver communication issue with Windows11 您好, 我安装了 Link Server,当我打开它时它启动了 LinkFlash,当我按下探测时它会告诉我 " 未连接任何设备 "。 此致, 卡斯滕 Re: LPC1115 Rev A Driver communication issue with Windows11 你好,@CKGrech、 您在 MCUXpresso IDE 上看到相同的行为吗?或者,你最初使用的是什么集成开发环境?
記事全体を表示
KW45 Knowledge Hub KW45’s three-core architecture integrates a 96 MHz CM33 application core, dedicated CM3 radio core and an isolated EdgeLock Secure Enclave. The Flash-based radio core with dedicated SRAM delivers a highly configurable and upgradeable software-implemented radio, freeing resources on the main core for customer application space. The Bluetooth Low Energy 5.3-compliant radio supports up to 24 simultaneous secure connections. The EdgeLock Secure Enclave’s isolated execution environment provides a set of cryptographic accelerators, key store operations and secure lifecycle management that minimizes main core security responsibilities. The KW45 MCU additionally integrates FlexCAN, helping enable seamless integration into an automobile’s in-vehicle or industrial CAN communication network. The FlexCAN module can support CAN’s flexible data rate (CAN FD) for increased bandwidth and lower latency. KW45 Block Diagram KW45 Architecture Block Diagram Documents Reference Manual Datasheet Errata Secure Reference manual** Security Certifications  SESIP Level 2 Cert SESIP Level 2 ST PSA Level 2 Certification Regulatory Certifications RED Certification EUROPEAN UNION DECLARATION OF CONFORMITY (EVK) EUROPEAN UNION DECLARATION OF CONFORMITY (LOC) Japan MIC KW45-LOC _TELEC-20250221 Bluetooth Qualifications Qualified Products | Bluetooth® Technology Website Qualification Workspace - KW45/MCX W71 Bluetooth IInterested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology, like NXP! 2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth AI Assistant - Amber   Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview Bluetooth Core Specification Core Specification 4.0 Core Specification 4.1 Bluetooth 4.1 FAQ Core Specification 4.2 Bluetooth 4.2 FAQ Core Specification 5.0 Core Specification 5.1 Core Specification 5.2 Core Specification 5.3 Core Specification 5.4 Core Specification 6.0 Core Specification 6.1 Core Specification 6.2 Core Specification 6.3 Evaluation boards KW45 KW45-EVK KW45-EVK Schematic KW45-EVK Design Files KW45-EVK User manual KW45-LOC User manual KW45-EVK Getting Started Application Notes Software, Hardware and Peripherals: AN14122 : How to use RTC on KW45 This application note describes how to configure and use the RTC peripheral in a BLE demo AN14141 : Enabling Watchdog Timer Module on KW45 Bluetooth Low Energy Connectivity Stack This application note describes the process to implement the WDOG timer in a Connectivity Stack demo. AN13855 : KW45/K32W1 Integrating the OTAP Client Service into a Bluetooth LE Peripheral Device This Application note provides the steps and process for integrating the Over the Air Programming Client Service into a BLE peripheral device. AN13584 : Kinetis KW45 and K32W1 Loadpull Report This application note describes measurement methodology and associated results on the load-pull characteristics. AN13860 : Creating Firmware Update Image for KW45/K32W1 using OTAP tool This application note provides the steps to create and upgrade the image on the KW45 board via OTAP. AN14077 : Steps to migrating KW45 (1MB) to KW45 (512kB) This application note describes the initial steps require to migrate from 1MB flash to 512kB flash. AN14746 : EEPROM Emulation for the KW45B41Z and K32W148 This document describes the process for the EEPROM emulation for the KW45B41Z and K32W148. AN14298 32kHz Cystal-Less Mode on KW45: This application note provides information on the 32 kHz Crystal-less mode on the KW45 device. This mode allows you to reduce the cost of the system, without compromising the 32 kHz clock accuracy.  AN13227 Hardware Design Considerations for KW45B41Z and K32W148 Bluetooth LE Devices: This application note describes printed-circuit board (PCB) design considerations for the KW45B41Z83AFTA, and KW45B41Z82AFTA and K32W1480VFTAT MKW35A, MKW36A, MKW35Z, and MKW36Z 40-pin HVQFN (6x6) and 48-pin Laminated QFN (HVLQFN-7x7 pitch 0.5 mm) wettable flank) package and KW45B41Z83AFPA and KW45B41Z82AFPA MKW35A, MKW36A, MKW35Z, and MKW36Z 40-pin HVQFN (6x6) and 40-pin Laminated QFN (HVLQFN-6x6 pitch 0.5 mm) wettable flank) package Power Management: AN13230: Kinetis KW45 and K32W1 Bluetooth LE Power Consumption Analysis This application note provides information about the power consumption of KW45 wireless MCUs, the hardware design and optimized for low power operation. AN13831: KW45/K32W1 Power Management Hardware This application note describes the usage of the different modules dedicated to power management in the KW45/K32W1 MCU. AN14664 Coin cell Hardware Recommendations for Kinetis Bluetooth LE Applications: This document describes some hardware and software solutions to minimize the peaks of current at the coin cell level RF: AN13687 : K32W1 Connectivity test for 802.15.4 Application This application note describes how to use the connectivity test tool to perform K32W1 802.15.4 RF performance. AN13728 : KW45 RF System Evaluation Report for Bluetooth LE and IEEE 802.15.4 Applications This application note provides the radio frequency evaluation test results of the KW45 board for BLE (2FSK modulation) and for IEEE 802.15.4 (OQPSK modulation) applications. Also describes the setup and tools that can be used to perform the tests.  AN14098: KW45-LOC RF Test Report This application note provides basic RF test result of the KW45B41Z localization board.  AN13228 : KW45-EVK RF System Evaluation Report for BLE Applications This application note provides the RF evaluation test result of the KW45B41Z-EVK for BLE application using two frequency Shift Keying modulation. AN13229 : KW45-EVK Co-existence with RF System Evaluation Report for BLE application This application note provides the RF evaluation test results of the KW45B41Z-EVK for BLE application (2FSK modulation) AN13512 : Kinetis Wireless Family Products BLE Coexistence with Wi-Fi Application This application note provides the K32W1/4X low energy family products immunity on Wi-Fi signals and methods to improve coexistence with Wi-Fi  AN14294 : Out of Band Implementation with KW45 This document explains the steps required to set up an Out of Band (OOB) pairing connection between two KW45 EVK boards, using UART and CAN communication interfaces to share OOB data. AN2731 Compact Planar Antennas for 2.5GHz Communication: This document is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays AN14645 How to Use Random Static Device Address for Bluetooth Application: This document introduces how to enable Random Static Device Address for a Bluetooth Low Energy application. The default device address type in the SDK is Public Device Address. AN14112 Car Connectivity Consortium (CCC) Digital Key R3 - Bluetooth LE Vehicle Keyless Access System: This document provides a hardware and software platform to implement a simple CCC Digital Key Release 3.0 system. The hardware and software components of this system allow the user to get familiar with the CCC Digital Keys R3 specification and how it can be implemented using NXP products and tools. AN13953 Integrating NFC Reader Library in a KW4X Bluetooth Low Energy Application:  This document gives instructions on how to create a Bluetooth Low Energy (Bluetooth LE) project for the EVK-KW45 development board and MCUXpresso IDE, and how to integrate NFC Reader Library. AN13049 Wi-Fi/Bluetooth/802.15.4 M.2 Key E Pinout Definition: This document defines M.2 usage for both NXP Wi-Fi/Bluetooth and Tri-Radio M.2 module design Security: AN13859 : KW45/K32W1 In-System Programming Utility This application note provides steps to boot KW45/K32W1 MCU in ISP mode and establish various serial connections to communicate with the MCU. AN14003 : Programming the KW45 Flash for Application and Radio Firmware via Serial Wire Debug during mass production This application note describes the steps to write, burn and programming all the necessary settings via SWD in mass production.  AN13883 : Updating KW45 Radio Firmware Via ISP Using SPSDK This application note provides steps to boot KW45/K32W1 MCU in ISP mode and update the radio firmware with secure binary. AN14109 : KW45 and K32W148 Secure  Boot Using the SEC Tool This application note provides steps to do secure boot KW45/K32W1 MCU using signed images and secure binaries on the SEC GUI tool. AN13838 :  KW45 and K32W148 Secure  Boot Using the SPSDK Command line Tool This application note provides steps to do secure boot KW45/K32W1 MCU using signed images and secure binaries on the SPSDK command line tool. AN13931 : Managing Lifecycles on KW45 and K32W148 This application note provides steps to do transition lifecycles KW45/K32W1 MCU using the SEC GUI and SPSDK command line tools.  AN14158: Debug Authentication on KW45/ K32W148 This application note describes how to do debug authentication to securely debug an application in the field.  AN14544 : EdgeLock 2GO Services for MPU and MCU This application note introduces the EL2GO services for NXP devices. This allows trust provisioning of the device in an untrusted environment.  AN14174: KW45/K32W1 Flash Encryption using NPXThis application note provides steps to do enable on-the-fly encryption on KW45/K32W1 MCU. AN14158: debug authentication on KW45/K32W148 This application note describes the steps for debug authentication using the Secure Provisioning SDK tool (SPSDK). AN15038 EdgeLock 2GO Provisioning MCUs via Product Type using Secure Provisioning (SEC) Tool:  This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via product type" flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server. AN14670  EdgeLock 2GO Provisioning via SPSDK for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the “Device provisioning via proxy” flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server.  AN14624 EdgeLock 2GO Provisioning via Secure Provisioning Tool (SEC) for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via proxy" flow. Useful Links [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  Clock Measuring using the Signal Frequency Analyzer (SFA) module for KW45/KW47/MCXW71/MCXW72 - NXP Community : this community provides the steps on how to use the Signal Frequency Analyzer  The best way to build a PCB first time right with KW45 (Automotive) or K32W1/MCXW71 (IoT/Industrial)... Community : In this community provides the important link to build a PCB using a KW45 or K32W148 and MCXW71 and all concerning the radio performances, low power and radio certification (CE/FCC/ICC) How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide : This article describes a simple process for enabling the user controls the radio through serial commands. Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization):  This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47/KW43) and MCX W7x (MCX W71/W72/W70) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery lifetime of your solution. KW45/K32W1 32MHz & 32kHz Oscillation margins: this article provides the properly configuration for the Oscillation margins for the circuit. KW45/MCXW71 Changing Clocking peripherals from FRO6M to other clock sources:  This article provides a comprehensive guide to selecting and configuring alternative clock sources   Reference Designs Bluetooth Ranging Access Vehicle Enablement System - NXP Community Blue Ravens (Bluetooth Ranging Access Vehicle Enablement System) is a system solution developed by NXP to assist customers in designing their own BLE-based car access solutions using NXP products. Demo (video) KW45 Based CS 1 to Many Demo NXP - Channel Sounding   Training BLE Introduction  RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements     Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Development Tools  SDK builder: The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. SDK GitHub: SDK open-source Drivers, middleware and reference examples in Github NXP MCUXpresso: MCUXpresso IDE offers advanced editing, compiling and debugging features with the addition of MCU-Specific debugging. Supports connections with all general-purpose Arm Cortex-M.  NXP SPSDK: Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool: The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool: Is an application that helps the user to perform an over the air firmware update of an NXP development board. Config Tool: MCUXpresso Config Tools, an integrated suite of configuration tools, these configuration tools allow developers to quickly build a custom SDK and leverage pins, clocks and peripheral to generate initialization C code or register values for custom board support. SDK Examples for Wireless MCUs: The wireless examples feature many common Bluetooth configurations. **For secure files is necessary to request additional access.  KW45
記事全体を表示
Linux Embedded Challengeプロジェクト - 2014 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.歩行者用スポットライト機能付きアダプティブダイナミックヘッドライト-eVisionによる チームメンバー: バラバン・ヴァレリウ - マスター、アドバンスト・マイクロエレクトロニクス、エレクトロニクス、UPB Voicu Tudor Alexandru - 学士、応用電子工学、電子工学、UPB Stanescu Sebastian - 学士、テレコムネットワーキングおよびソフトウェア、UPB 簡単な説明: 夜間の事故と夜間の事故の間の死亡率が高いため、技術開発のために多くの研究が行われています。 夜間にドライバーの視界を広げ、これが避けられなかった場合の事故による損傷を減らすため。ザ アダプティブヘッドライト機能は、暗い場所、特に曲がり角でさらに見るのに役立ちます:コーナリングライト ヘッドライトを進行方向に回転させ、CPUによって計算された回転角度で、できるだけ多くの道路を照らします 可能な限りの面積 興味深い解決策は、潜在的な危険を具体的に照らすLEDビームであるスポットライト照明機能です。 近赤外線カメラが道端の鹿や道路上の歩行者を検出した場合、それらを短時間照らすことができます メインビームで覆われた通常の領域を超えて、スポットライトによってドライバーに危険の可能性に注意を向けます。 プレゼンテーション: eVisionPresentation.pdfご相談ください。 ドキュメンテーション: eVisionDoc.pdfご相談ください。 コードソース https://github.com/izzi/app-evision https://github.com/izzi/meta-evision 2. DriverVehicleインタラクションのための音声コマンドインターフェース - by She# チームメンバー: ユリア・ネアゴエ - コンピュータサイエンスと軍事情報システム、軍事技術アカデミー Mihaela-Anca Sorostinean - コンピュータサイエンスと軍事情報システム、軍事技術アカデミー 簡単な説明:     自動車および通信領域における継続的な技術進歩の文脈では、ドライバー 責任は、単に車を制御することから、によって提供される多数のガジェットとの相互作用に変わりました。 生産者。このプロジェクトの目的は、ドライバーが制御する可能性を提供するインターフェイスを設計することです ドライバーが彼の注意を集中することを可能にするために、音声コマンドによる車の非重要な機能の一部 道路上では、車との快適なコミュニケーション手段も備えています。     私たちは、ラジオ、窓、気候、電話などのいくつかの基本的な機能の音声認識システムを開発しました それをワンドボードに実装しました。また、認識されたグラフィカルインターフェイスをユーザーに提供します 彼の車両との相互作用を強化するためのコマンド。 プレゼンテーション: ShePresentation.pdfご相談ください。 ドキュメンテーション: SheDoc.pdfご相談ください。 コードソース She#_Project_Source.zipをご覧ください 。 3. 運転制御ソフトウェア - by FreeSoftwares チームメンバー: Petrosanu Adrian-Sabin - コンピュータサイエンス、UPB Birsan Nicoleta Cosmina - コンピュータサイエンス、UPB Radoi Ioana Gabriela - コンピュータサイエンス、UPB 簡単な説明: 「ドライビングコントロールソフトウェア」は、オートマチックギアボックスを制御するためのソフトウェアです。このプロジェクトは、動作のシミュレーションで構成されています ワンドボードのオートマチックギアボックスの。オートマチックギアボックスは、自動車のトランスミッションの一種です。 車両の動きに合わせてギア比を自動的に変更します。 プレゼンテーション: FreeSoftwaresPresentation.pdfご相談ください。 ドキュメンテーション: FreeSoftwaresDoc.pdfご相談ください。 コードソース Freesoftwares_Project_Source.zipをご覧ください 。 4. 自動駐車場 - ATM利用 チームメンバー: Mihai Coca - コンピュータサイエンスと軍事情報システム、軍事技術アカデミー グルジアのアンドレイ - コンピュータサイエンスと軍事情報システム、軍事技術アカデミー Hiji Iulian - コンピュータサイエンスと軍事情報システム、軍事技術アカデミー Shortの説明: 多くの企業が、 その分野での作業を 特定の使用例:駐車場。この目的 プロジェクトは、ドロップオフできるコンセプトカーを設計することです その所有者によって縁石で 、スポットパークに入るために独自のデバイスに残されました。このプロセスを逆にすることさえできます 所有者が行く準備ができているとき、車はスポット公園を離れて、そのを満たすために自分自身で 縁石に再びキーホルダー。 ドキュメンテーション: ATMにご相談くださいDoc.pdf コードソース ATM_Project_Source.zipをご覧ください 。 5.衝突検出-Beer2.0による チームメンバー: Nitu Adrian - コンピュータサイエンス、UPB 簡単な説明: 私たちのプロジェクトの目的は、車に前方の道路の感覚を提供し、予防策を講じることができるようにすることです 衝突;このようにして、道路での事故を減らしたいと考えています。さまざまなハードウェアから信号と情報を収集します ドライバーに警告するか、ドライバーを保護するために重要な操作を行うために車を即座に制御します 生命を脅かす出来事から。 フリースケールのカップカーには、ワンドボードと2台のUSBカメラが装備され、環境を追跡できます。初期処理後 オブジェクトトラッキングは、リモートコントロールによるヒューマンインタラクションを組み込みます。このプロジェクトでは、単純な警告システムを信じています および/またはブレーキングは、概念の証明として十分です。 プレゼンテーション: ご相談くださいBeer20Presentation.pdf ドキュメンテーション: ご相談くださいBeer20Doc.pdf コードソース https://bitbucket.org/adriannitu92/freechallenge 6.サブバンド正規化filtered-X LMSアルゴリズムを使用したフィードフォワード適応型ノイズキャンセリング - Brainiacsによる チームメンバー: Cristian Monea - 電気通信および情報技術、エレクトロニクス、UPB Madalin Zaharia - 電気通信および情報技術、エレクトロニクス、UPB 簡単な説明 このプロジェクトでは、サブバンド正規化フィルタリングX LMS(NFXLMS)に基づくフィードフォワード適応型ノイズキャンセレーション(ANC)アルゴリズムを提案します。 適応アルゴリズムの使用には、固定FIRやIIRフィルターなどの単純なフィルタリングアルゴリズムよりも利点があります。また、ノイズは 車の環境は、スペクトル分布、平均、分散など、その特性の一部を保持するため、静止していると見なすことができます。 車の騒音キャンセリングアプリケーションで適応フィルターを使用できるようにします。 フィードフォワードシステムは、フィードバックシステムよりも効率的である必要があります。この場合、コヒーレントなリファレンスノイズ入力がその前に検出されます キャンセルスピーカーを通過して伝播します。 したがって、アルゴリズムは2つのセンサー(マイク)をシミュレートします:キャンセルされる一次ノイズを測定する基準センサー。 とエラーセンサー。 プレゼンテーション: ご相談くださいBrainiacsPresentation.pdf ドキュメンテーション: ご相談くださいBrainiacsDoc.pdf Linux Embedded Challenge 2014 (英語)
記事全体を表示