Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
HMB-N1984 开发 HomeKit 和 iPod -MFi- 配件,采用 NXP 处理器和软件 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍如何开发 Made For iPod (MFi) 配件,包括基于 NXP 微控制器 (MCU)、微处理器 (MPU)、HomeKit 软件开发套件 (SDK)、MFi SDK 和 NXP 专业服务软件的音频、非音频、CarPlay、AirPlay 和 HomeKit 应用程序。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍如何开发 Made For iPod (MFi) 配件,包括基于 NXP 微控制器 (MCU)、微处理器 (MPU)、HomeKit 软件开发套件 (SDK)、MFi SDK 和 NXP 专业服务软件的音频、非音频、CarPlay、AirPlay 和 HomeKit 应用程序。 智能家居和智能建筑
查看全文
NET-N1886 QorIQ LS1043A 处理器硅片启动技巧 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将提供有助于加速 QorIQ LS1043A 处理器硅片启动的技巧。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将提供有助于加速 QorIQ LS1043A 处理器硅片启动的技巧。 智能网络
查看全文
APF-ACC-T0983 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、KEAシリーズとKFAシリーズを含む、新しいKinetisマイクロコントローラの自動車製品ファミリの概要を説明します。Kinetisマイクロコントローラの自動車ファミリは、車載市場向けの32ビットARM® Cortex-M0®+/M4ベースのAEC Q100認定マイクロコントローラの、拡張性に優れたポートフォリオです。このファミリは、コスト重視のアプリケーション向けに最適化されており、非常に低い消費電力でピン数の少ないオプションを提供します。2.7-5.5V電源を備え、優れたEMC/ESD堅牢性に重点を置いたKinetisマイクロコントローラ・オート・シリーズ・デバイスは、ボディ・アプリケーション、インフォテインメント接続モジュール、パーキング・アシスタンス、セーフティ・コンパニオン・チップ、汎用センサ・ノードなど、幅広いアプリケーションに適しています。Kinetisマイクロコントローラのオート・ファミリのすべての製品は、同様のペリフェラルを共有しており、さまざまなサードパーティ製およびフリースケールのHW/SW開発ツールによってサポートされています。開発者は、Kinetisマイクロコントローラのオート・ファミリを使用して、設計を迅速に開始できます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、KEAシリーズとKFAシリーズを含む、新しいKinetisマイクロコントローラの自動車製品ファミリの概要を説明します。Kinetisマイクロコントローラの自動車ファミリは、車載市場向けの32ビットARM® Cortex-M0®+/M4ベースのAEC Q100認定マイクロコントローラの、拡張性に優れたポートフォリオです。このファミリは、コスト重視のアプリケーション向けに最適化されており、非常に低い消費電力でピン数の少ないオプションを提供します。2.7-5.5V電源を備え、優れたEMC/ESD堅牢性に重点を置いたKinetisマイクロコントローラ・オート・シリーズ・デバイスは、ボディ・アプリケーション、インフォテインメント接続モジュール、パーキング・アシスタンス、セーフティ・コンパニオン・チップ、汎用センサ・ノードなど、幅広いアプリケーションに適しています。Kinetisマイクロコントローラのオート・ファミリのすべての製品は、同様のペリフェラルを共有しており、さまざまなサードパーティ製およびフリースケールのHW/SW開発ツールによってサポートされています。開発者は、Kinetisマイクロコントローラのオート・ファミリを使用して、設計を迅速に開始できます。
查看全文
传感器发布示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP技术支持发布的软件示例列表: NXP 技术支持发布的传感器软件示例* NXP技术支持设计的分线板列表: 飞思卡尔传感器分线板设计 – 主页 *以上所有源代码仅供示例使用。恩智浦不对用户应用程序中使用这些代码承担任何责任。
查看全文
i.MX Multimedia Explained: How-to Effectively Create Multimedia Application for i.MX Applications Processors Lecture including a live demo, showing how to develop multimedia application for i.MX applications processors, taking advantages of the hardware multimedia accelerators of the i.MX SoC.  Presented by Daniele DallAcqua Presented at DwF Istanbul - May 12, 2015 Session ID: EUF-DES-T1474 Lecture including a live demo, showing how to develop multimedia application for i.MX applications processors, taking advantages of the hardware multimedia accelerators of the i.MX SoC.  Presented by Daniele DallAcqua Presented at DwF Istanbul - May 12, 2015 Session ID: EUF-DES-T1474 i.MX Applications Processors Re: i.MX Multimedia Explained: How-to Effectively Create Multimedia Application for i.MX Applications Processors Great presentation! Very complete. Would you share the hands on source code? I'm specially interested in the src/hmi.c and media_server.c.
查看全文
调整 S08P MCU <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本文档的目的是展示调整微控制器单元 (MCU) 的重要性,并展示未调整和调整后的设备之间的差异。 概述
查看全文
DwF MCU及汽车解决方案 - 天安 - 2015-03-19 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 汽车和联网汽车 汽车 MCU 概述,包括 Kinetis 和 S12 MagniV 混合信号 MCU 汽车模拟和传感器概述,包括 BCC 和高压传感器 洞察与创新 Kinetis 微控制器概述 - Kinetis 性能优势及应用 设计、软件和服务 Freescale MQX™实时操作系统介绍 Arm® 处理器 Kinetis Cortex ® -M 微控制器 传感器 软件和工具
查看全文
S32K3 Motor control SW examples The S32K3 family of 32-bit AEC-Q100 qualified MCUs combines a scalable family of Arm® Cortex-M7-based microcontrollers built on long-lasting features with a comprehensive suite of production-grade tools. S32K3 MCUs are included in NXP’s Product Longevity Program, guaranteeing a minimum of 15 years of assured supply. The S32K3 offers dedicated peripherals set for rapid motor control loop implementation: enhanced Modular IO Subsystem(eMIOS), Logic Control Unit (LCU), TRGMUX, BodyCross-triggering Unit (BCTU), Analog to Digital Converter(ADC), and Analog Comparator (CMP). The comprehensive motor control ecosystem based on Automotive Math and Motor Control Library(AMMCLib) set, FreeMASTER with Motor Control ApplicationTuning (MCAT) tool and Model-Based Design Toolbox (MBDT) helps to enable S32K3 MCU in wide range of motor control use cases. The table below points to the articles with more detailed description each of S32K3 motor control use cases, hardware description, links to appropriate application notes and their addendums, and software repositories.  Device HW Article S32K344 MCSPTE1AK344 12 V development kit engineered for 3-phase PMSM and BLDC motor control applications FOC with dual shunt current measurement Article focuses on solution based Field Oriented Control (FOC) technique (typically used for 3-phase PMSM motors) with dual shunt current measurement and without any position sensor (sensorless). The Encoder sensor is supported by SW option, but missing on HW kit. The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with high-level Autosar compliant API or low-level non-Autosar API.    FOC with single shunt current measurement Article focuses on solution based Field Oriented Control (FOC) technique (typically used for 3-phase PMSM motors) with single shunt current measurement and without any position sensor (sensorless). The Encoder sensor is supported by SW option, but missing on HW kit. The single shunt current measurement is advanced technique that allows decrese the cost of Bill of Material (BOM). The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with high-level Autosar compliant API or low-level non-Autosar API.    FOC integrated with FreeRTOS Article focuses on integration of motor control software (based on FOC with dual shunt current measurement) and Real Time Operating System (FreeRTOS). The available example code is based ANSI-C  code and uses RTD drivers with low-level non-Autosar API.    Six-step commutation control. Article focuses on solution based Six-step commutation (6-step) technique (typically used for 3-phase BLDC motors) with Hall position sensor and without any position sensor (sensorless). The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with low-level non-Autosar API.    Note: the list of use cases cannot cover all combinations of MCU, current measurement scenario, control technique and sensor inputs, but should work as a base reference for most common configurations. This list is not final, please follow this acticle to be notified about updates with new use cases.   
查看全文
I.MXRT1021 Flash Operation Demo on FreeRTOS in XIP Mode        由于RT系列没有内置 Flash,大多数用户会选择外部 QSPI Flash 作为应用代码和数据的非易失存储设备,同时外部Flash的大容量在满足用户代码存储需求之外也会为用户提供了足够的灵活空间存储应用数据,但是其中涉及到的对数据读擦写以及用户的应用程序均需要在外部 Flash 执行,这为 Flash 的操作带来了麻烦。        对于在XIP(eXecute-In-Place)模式下的应用,对Flash读擦写的操作需要在内部 RAM 里执行,而RT系列由于高主频而引入了内核 Dcache 以及 Flexspi 模块自带的 Pre-fetch 功能,对外部 Flash 的操作会有很多需要注意的地方,这些问题在带有 RTOS 的系统里则更是突显出来,而无论在 XIP 模式下的裸机还是基于 RTOS 方式对 Flash 的操作,SDK 里均没有提供例程可供参考。        本参考方案来自很多客户的实际应用需求,所以编写了基于 FreeRTOS 下的对片外 QSPI Flash 的读擦写操作,客户可以基于此例程移植到自己的应用里面做相关的应用开发,并配套对应的指导文档提醒用户在移植过程中需要注意的几个常见的 tips。 Products Product Category NXP Part Number URL MCU MIMXRT1021 i.MX RT1020 Crossover MCU with Arm® Cortex®-M7 core MCUXpresso SDK Software SDK v2.6.1 Welcome | MCUXpresso SDK Builder    Tools NXP Development Board URL MIMXRT1020-EVK MIMXRT1020-EVK: i.MX RT1020 Evaluation Kit Industrial
查看全文
Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey
查看全文
Solyball Cooling Ace Designed for Modern Living Solyball When temperatures begin to rise, maintaining a comfortable indoor environment becomes a priority for many people. Whether at home, in the office, or in a personal workspace, excessive warmth can affect concentration, relaxation, and overall comfort. This is where Solyball offers a convenient and practical solution. Designed with portability, simplicity, and modern living in mind, Solyball is a compact cooling device that helps users create a more pleasant atmosphere in a variety of indoor settings. One of the most notable features of Solyball is its lightweight and portable design. Unlike large cooling systems that can be difficult to move or require significant space, Solyball is compact enough to fit comfortably in almost any room. Its portable nature allows users to carry it from one location to another with ease, making it suitable for use throughout the day as needs change. Whether you are working in a home office, relaxing in the living room, or preparing for a restful night's sleep, Solyball can be positioned wherever additional comfort is desired. The versatility of Solyball makes it a valuable addition to many different indoor environments. In bedrooms, it can help create a more enjoyable atmosphere during warm evenings. Comfortable sleeping conditions are important for overall well-being, and a compact cooling device can contribute to a more pleasant bedtime experience. Solyball's convenient size allows it to fit neatly on a bedside table or nearby surface without creating clutter. For professionals and remote workers, Solyball maintaining a comfortable workspace can be essential for productivity. Warm indoor temperatures may sometimes make it difficult to stay focused on tasks and responsibilities. Solyball offers a practical way to improve comfort while working, helping users create a more pleasant environment throughout the day. Its compact footprint means it can sit conveniently on a desk or workstation without occupying excessive space. Solyball Living rooms and shared family spaces can also benefit from the convenience of Solyball. These areas often serve as central gathering points where people spend time watching television, reading, socializing, or simply relaxing. By incorporating Solyball into these spaces, users can enjoy a more comfortable atmosphere while going about their daily activities. Its modern appearance ensures that it blends naturally with contemporary home décor.
查看全文
Solyball Cooling Ace 专为现代生活而设计 当气温升高时,保持舒适的室内环境成为许多人的首要任务。无论是在家、办公室还是个人工作空间,过高的温度都会影响注意力、放松度和整体舒适度。Solyball 正是为此提供了一个便捷实用的解决方案。Solyball 的设计兼顾便携性、简洁性和现代生活方式,是一款小巧的降温设备,可帮助用户在各种室内环境中营造更舒适的氛围。 Solyball 最显著的特点之一 是其轻巧便携的设计。与笨重难搬或占用大量空间的大型制冷系统不同,Solyball 体积小巧,几乎可以完美融入任何房间。其便携性使用户能够轻松地将其从一个地方搬到另一个地方,从而满足全天候不同需求。无论您是在家办公、在客厅放松,还是准备享受一夜安眠,Solyball 都可以放置在任何您需要额外舒适感的地方。 Solyball 的多功能性 使其成为各种室内环境的理想之选。在卧室里,它有助于在温暖的夜晚营造更舒适的氛围。舒适的睡眠环境对整体健康至关重要,而小巧的降温设备可以提升您的睡眠体验。Solyball 尺寸适中,可轻松放置在床头柜或其他平面上,不会造成空间杂乱。 对于专业人士和远程办公人员来说, Solyball能帮助他们保持舒适的工作空间,从而显著提高工作效率。室内温度过高有时会影响专注力,难以集中精力完成工作。Solyball 提供了一种切实可行的提升工作舒适度的方法,帮助用户在一天中营造更加愉悦的工作环境。其小巧的体积使其可以方便地放置在办公桌或工作台上,而不会占用过多空间。 Solyball的便利性也体现在客厅和家庭共享空间中。这些区域通常是人们聚集的中心场所,他们会在这里看电视、阅读、社交或放松身心。将 Solyball 融入这些空间,用户可以在日常活动中享受更舒适的氛围。其现代外观确保它能与现代家居装饰自然融合。
查看全文
Falcon Mode Enablement - iMX8MP_EVK Hi, I need to enable Falcon Mode on iMX8MP_EVK in the Yocto branch 6.12-walnascar. However, as per the AN14641 document, the meta-imx-fastboot layer is available only in the lf-6.6.36-2.1.0-secure branch. How can I port this layer to my walnascar branch and enable Falcon Mode? Please help here.. Re: Falcon Mode Enablement - iMX8MP_EVK Please use the following command. uuu -b emmc_all - .rootfs.wic For example: $ uuu -b emmc_all imx-boot-imx95evk-sd.bin-flash_all     core-image-minimal-imx95evk.rootfs.wic Re: Falcon Mode Enablement - iMX8MP_EVK Hi Tipingwang, Thanks for your reply. I am trying to enable Falcon mode and have followed the steps provided in AN14641, but I am getting stuck during the flashing process. As per the README, the flashing steps are mentioned as below (for eMMC): unzstd -[secure-boot]- .rootfs.wic.zst uuu -b emmc_all - .rootfs.wic uuu -b emmc My boot memory is eMMC. I attempted to flash the image using the following command: sudo ./uuu -d -v -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evk imx-image-core-imx8mpevk.rootfs-20260616051114.wic However, during execution, the flashing process fails with the following error: sudo ./uuu -d -v -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evk imx-image-core-imx8mpevk.rootfs-20260616051114.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086   Build in config: Pctl Chip Vid Pid BcdVersion Serial_No ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX91 0x1fc9 0x0159 SDPS: MX95 0x1fc9 0x015d SDPS: MX95 0x1fc9 0x015c SDPS: MX943 0x1fc9 0x0027 SDPS: MX952 0x1fc9 0x0028 SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb FB: 0x1d6b 0x0104   Run built-in script:   uuu_version 1.4.149   # @_flash.bin            | bootloader, which can extract from wic image # @_image   [_flash.bin] | wic image burn to emmc.     # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx8mpevk-sd.bin-flash_evk -scanlimited 0x800000   # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -scanterm -f imx-boot-imx8mpevk-sd.bin-flash_evk -scanlimited 0x800000   # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx8mpevk-sd.bin-flash_evk -offset 0x57c00 SDPU: jump -scanlimited 0x800000 # }   # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx8mpevk-sd.bin-flash_evk -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 # }     FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all imx-image-core-imx8mpevk.rootfs-20260616051114.wic FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx8mpevk-sd.bin-flash_evk FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done     Wait for Known USB Device Appear... New USB Device Attached at 1:2-152E1000D9DE520A 1:2-152E1000D9DE520A>Start Cmd:SDPS: boot -scanterm -f imx-boot-imx8mpevk-sd.bin-flash_evk -scanlimited 0x800000 14%1:2-152E1000D9DE520A>Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7)(20.07s) The detailed uuu logs are attached above for reference. Could you please guide me on the correct procedure to flash a Falcon-enabled OS into eMMC, or let me know if I am missing any required steps or configurations? Thanks in advance for your support. Re: Falcon Mode Enablement - iMX8MP_EVK Falcon Mode is not incompatible with Secure Boot BUT On lf-6.12.20-2.0.0-secure, you cannot enable Secure Boot together with Falcon Mode using the provided Yocto flow About 0001-imx8m-reset-ethernet-phy-in-spl.patch For i.MX8MP EVK → strongly recommended Not strictly required if you don't use Ethernet during early boot Re: Falcon Mode Enablement - iMX8MP_EVK Hi Yiping Wang, Thank you for your response. I have a couple of additional questions for clarification. According to the information provided, the branch lf-6.12.20-2.0.0-secure supports Falcon Mode v2, but Secure Boot is marked as not yet supported. Since Secure Boot is a requirement for my i.MX8MP platform, will Falcon Mode work correctly if I use this branch, or is Falcon Mode incompatible when Secure Boot is enabled? For the i.MX8MP EVK, do I need to apply the patch 0001-imx8m-reset-ethernet-phy-in-spl.patch, or is it optional depending on the use case? Re: Falcon Mode Enablement - iMX8MP_EVK You probably do not need to port the layer from lf-6.6.36-2.1.0-secure yourself. The public nxp-imx-support/meta-imx-fastboot - GitHub repository already shows a lf-6.12.20-2.0.0-secure branch. Please refer to README in https://github.com/nxp-imx-support/meta-imx-fastboot Re: Falcon Mode Enablement - iMX8MP_EVK Please help here, And i am using UUU to flash eMMC Re: Falcon Mode Enablement - iMX8MP_EVK Screenshot from 2026-06-16 14-28-09.png As per this image i found in NXP forum it seems that flashing eMMC using the UUU tool may not be supported in this case. Could you please suggest the appropriate method to flash an eMMC device with a Falcon-enabled OS? In your previous reply, you suggested using the following command:   - .rootfs.wic> I tried this approach, but I encountered the same error again: Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7) (20.07s) Could you please guide me on the correct flashing procedure or any alternative tools or steps required for flashing eMMC with Falcon mode enabled? Re: Falcon Mode Enablement - iMX8MP_EVK I verified the following commands on IMX95FRDM, there is no problem, please refer to my log. C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -lsusb uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion Serial_no ==================================================================== 2:4 MX95 SDPS: 0x1FC9 0x015D 0x0002 61F49AAB2DCB4DDF C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -b emmc_all C:\Users\nxa22585\Downloads\i.mx95\imx-boot-imx95-15x15-lpddr4x-frdm-sd.bin-flash_all C:\Users\nxa22585\Downloads\i.mx95\core-image-minimal-imx8mnevk.rootfs.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Success 1 Failure 0 1:2-61F49AAB 8/ 8 [Done ] FB: done 2:4-61F49AAB 3/ 3 [=================100%=================] SDPV: jump -scanlimited 0x800000 C:\Users\nxa22585> Re: Falcon Mode Enablement - iMX8MP_EVK Please help here i have stucked in this part Re: Falcon Mode Enablement - iMX8MP_EVK In previous reply you gave a reference command for IMX95FRDM is that falcon enabled?  Here you can find what i was done in Yocto - IMX8MP 1) meta-imx-fastboot - lf-6.12.20-2.0.0-secure - Github_Link 2) Added this meta to my source - Github_Link 3) And followed all the instruction gave by  AN14641 document. 4)Bitbake commands that i followed:  bitbake -c clean linux-imx && bitbake -c clean imx-boot && bitbake -c clean u-boot-imx && bitbake -c clean imx-atf && bitbake -c clean imx-image-core  bitbake -c compile linux-imx && bitbake -c compile imx-boot && bitbake -c compile u-boot-imx && bitbake -c compile imx-atf && bitbake -c compile imx-image-core bitbake linux-imx && bitbake imx-boot && bitbake u-boot-imx && bitbake imx-atf && bitbake imx-image-core 5)  CASE 1: sudo ./uuu -b emmc_all imx-image-core-imx8mpevk.rootfs-20260617095251.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086 Success 0 Failure 0 1:2-152E1000 1/ 1 [=================100%=================] SDPS: boot -scanterm -f /home/smurugan8/YOCTO/LWT/image/imx-image-core-imx8mpevk.rootfs-20260617095251.wic -scanlimited 0x800000 CASE 2:  sudo ./uuu -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evk imx-image-core-imx8mpevk.rootfs-20260617095251.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086 Success 0 Failure 1 1:2-152E1000 1/ 1 [HID(W): LIBUSB_ERROR_TIMEOUT (-7) ] SDPS: boot -scanterm -f imx-boot-imx8mpevk-sd.bin-flash_evk -scanlimited 0x800000 IMPORTANT : I NEED TO FLASH A FALCON ENABLED OS INTO eMMC  Re: Falcon Mode Enablement - iMX8MP_EVK Please note uuu is only used to program images to emmc, it doesn't check the content of your images. I suspect there is problem with your uuu command itself. Where did you download uuu? Please download the latest UUU from https://github.com/nxp-imx/mfgtools/releases Please download the Windows version UUU to do verification. Re: Falcon Mode Enablement - iMX8MP_EVK Hi yipingwan I also tried using the UUU tool on Windows, but I am seeing the same result—it still does not work for flashing eMMC.  I have attached the UUU -log. However, when I flash the same Falcon-enabled OS to an SD card, it boots and works correctly. This confirms that the image itself and the Falcon configuration are valid. My question is: Why am I unable to flash this Falcon-enabled image to eMMC, even though the same image works from SD? Is there any alternative or recommended method to flash a Falcon-enabled OS to eMMC, other than using UUU? Could you please advise on the supported or reliable procedure for flashing eMMC in this scenario? Screenshot 2026-06-22 122141.png Re: Falcon Mode Enablement - iMX8MP_EVK Please help here. Re: Falcon Mode Enablement - iMX8MP_EVK Please execute the following command with your Windows version UUU and send the result to me to do more investigation. uuu.exe -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evk   imx-image-core-imx8mpevk.rootfs-20260617095251.wic Re: Falcon Mode Enablement - iMX8MP_EVK Please try the following command uuu.exe -b emmc_all  C:\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic Then send the result to me again. Re: Falcon Mode Enablement - iMX8MP_EVK Here you can find the output, PS C:\Users\vvdn\Sanjiv\uuu_source-uuu_1.5.243\uuu-uuu_1.5.243\uuu> .\uuu.exe -b emmc_all C:\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Success 0 Failure 1 1:3-152E1000 1/ 1 [HID(W): LIBUSB_ERROR_TIMEOUT (-7) ] SDPS: boot -scanterm -f C:\Users\vvdn\Sanjiv\Falcon\imx-b... Re: Falcon Mode Enablement - iMX8MP_EVK Screenshot 2026-06-22 171137.png I above you can find the log of UUU,  Command=> .\uuu.exe -b emmc C:\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic But it is not working in eMMC , Same Image will work in SD Card Re: Falcon Mode Enablement - iMX8MP_EVK I verified on IMX8MP_EVK target board, there is no problem to program emmc, please refer to my following log. C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -b emmc_all C:\Users\nxa22585\Downloads\i.mx95\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\nxa22585\Downloads\i.mx95\core-image-minimal-imx8mnevk.rootfs.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-0-g230f1b1 Success 1 Failure 0 2:4-0F0B9800 8/ 8 [Done ] FB: done C:\Users\nxa22585> Please extracted my image from the attached file, and only execute the following command. uuu.exe -b emmc imx-boot-imx8mpevk-sd.bin-flash_evk If it still fails, it seems there is problem with EMMC itself on your target board. You could use the following emmc command to check whether you could write something to emmc in u-boot. Usage: mmc read addr blk# cnt mmc write addr blk# cnt mmc erase blk# cnt Re: Falcon Mode Enablement - iMX8MP_EVK Please only try whether you can write a default boot image to emmc with UUU. Re: Falcon Mode Enablement - iMX8MP_EVK Yes, @yipingwang, When I include the meta-imx-fastboot layer in my build, the flashing process gets stuck. However, if I remove the meta-imx-fastboot layer, I am able to flash the image to eMMC successfully. Re: Falcon Mode Enablement - iMX8MP_EVK I have one question @yipingwang it is falcon enabled image Re: Falcon Mode Enablement - iMX8MP_EVK Please help here.. @yipingwang Re: Falcon Mode Enablement - iMX8MP_EVK Please send /home/smurugan8/YOCTO/LWT/image/falcon_mode/imx-boot-imx8mpevk-sd.bin-flash_evk to me. I will do verification on my target board. Re: Falcon Mode Enablement - iMX8MP_EVK Hi @Sanjiv_Mns  The meta-secure-boot Yocto layer is not implemented for the 6.12.20 BSP. Since the meta-imx-fastboot layer depends on the meta-secure-boot, the branch lf-6.12.20-2.0.0-secure does not implement secure boot. The 0001-imx8m-reset-ethernet-phy-in-spl.patch patch is mandatory if you need to use the Ethernet interfaces in Linux. It resets the PHYs, without which the Linux driver cannot initialize the interfaces. Re: Falcon Mode Enablement - iMX8MP_EVK Please find the attachment . Re: Falcon Mode Enablement - iMX8MP_EVK Hi @yipingwang , I have done the commands which you gave in previous reply, here you can find the command logs & Boot logs COMMAND LOGS: sudo ./uuu -b emmc_all /home/smurugan8/YOCTO/LWT/image/default/imx-boot-imx8mpevk-sd.bin-flash_evk /home/smurugan8/YOCTO/LWT/image/default/imx-image-multimedia-imx8mpevk.rootfs-20260622071640.wic uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086 Success 1 Failure 0 1:1-152E1000 8/ 8 [Done ] FB: done sudo ./uuu -b emmc /home/smurugan8/YOCTO/LWT/image/default/imx-boot-imx8mpevk-sd.bin-flash_evk /home/smurugan8/YOCTO/LWT/image/falcon_mode/imx-boot-imx8mpevk-sd.bin-flash_evk uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.243-5-g124d086 Success 1 Failure 0 1:1-152E1000 7/ 7 [Done ] FB: Done BOOT LOGS: U-Boot SPL 2025.04-g44898b9f3cfe-dirty (Sep 03 2025 - 09:56:50 +0000) DDRINFO: start DRAM init DDRINFO: DRAM rate 4000MTS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done SEC0: RNG instantiated Normal Boot Trying to boot from MMC2 spl_load_image_fat: error reading image kernel-atf-dtb.itb, err - -5 spl_load_image_fat: error reading image u-boot-atf.itb, err - -5 Error: -2 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Re: Falcon Mode Enablement - iMX8MP_EVK Hi @Sanjiv_Mns  Falcon Mode images works on both SD and eMMC. To flash a Falcon image on eMMC/SD you need to: 1. Build the default bootloader. In a clean Yocto environment, run: bitbake imx-boot. Make sure the meta-imx-fastboot layer is not added at this step. This will generate the tmp/deploy/images/imx8mp-lpddr4-evk/imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk default bootloader. 2. Build the falcon mode bootloader and the falcon mode image. Add the meta-imx-fastboot layer to your BBLAYERS. To compile the falcon mode bootloader, run: bitbake imx-boot This command will generate the tmp/deploy/images/imx8mp-lpddr4-evk/imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk_dual_bootloader falcon bootloader. This bootloader contains only the SPL, without the U-Boot proper. When the meta-imx-fastboot layer is added, the *_dual_bootloader is generated. See layer.conf.   To compile the falcon mode image, run: bitbake imx-image-multimedia This will generate the tmp/deploy/images/imx8mp-lpddr4-evk/imx-image-multimedia-imx8mp-lpddr4-evk.rootfs.wic.zst image. 3. Use UUU to flash the image on the eMMC. UUU is the only tool available to flash images on the eMMC. uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mp-lpddr4-evk.rootfs.wic.zst uuu -b emmc imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk_dual_bootloader Re: Falcon Mode Enablement - iMX8MP_EVK Please remove bld-xwayland build folder to rebuild images. $ rm -rf bld-xwayland $ MACHINE=imx8mpevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $ bitbake-layers add-layer ../sources/meta-imx-fastboot Please add the following line in bld-xwayland/conf/local.conf FALCON_KERNEL_BOOTARGS:mx8mp-generic-bsp = "console=ttymxc1,115200 root=/dev/mmcblk2p2 rootwait rw quiet" Then rebuild images: $ bitbake imx-boot $ bitbake core-image-minimal uuu.exe -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evk core-image-minimal-imx8mpevk.rootfs.wic uuu.exe -b emmc imx-boot-imx8mpevk-sd.bin-flash_evk imx-boot-imx8mpevk-sd.bin-flash_evk_falcon Please refer to my verification log: U-Boot SPL 2025.04-g9383f8387dc7-dirty (Jun 04 2025 - 09:48:20 +0000) DDRINFO: start DRAM init DDRINFO: DRAM rate 4000MTS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done SEC0: RNG instantiated Normal Boot Trying to boot from MMC2 Failed to find node!, err: -11! Failed to find node!, err: -11! NOTICE: Do not release JR0 to NS as it can be used by HAB NOTICE: BL31: v2.12.0(release):lf-6.12.20-2.0.0-dirty NOTICE: BL31: Built : 08:15:07, May 9 2025 [ 0.324123] imx8mp-ldb ldb-display-controller: Failed to create device link (0x180) with 32e90000.lcd-controller [ 0.395104] : mipi_csis_imx8mp_phy_reset, No remote pad found! [ 0.514210] imx8mp-ldb ldb-display-controller: Failed to create device link (0x180) with 1-004c [ 0.576883] imx8mp-ldb ldb-display-controller: Failed to create device link (0x180) with 1-004c [ 0.625848] ov5640 1-003c: ov5640_write_reg: error: reg=3008, val=42 [ 0.632862] ov5640 1-003c: ov5640_write_reg: error: reg=3103, val=11 [ 0.639669] ov5640 1-003c: ov5640_read_reg: error: reg=3108 [ 0.645268] ov5640 1-003c: failed to power on [ 0.661389] imx8mp-ldb ldb-display-controller: Failed to create device link (0x180) with phy-lvds [ 0.694937] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-41: -19 [ 0.706570] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi [ 0.714859] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -19 NXP i.MX Release Distro 6.12-walnascar imx8mpevk ttymxc1 imx8mpevk login: root root@imx8mpevk:~# Re: Falcon Mode Enablement - iMX8MP_EVK Please use the following commands to program images to the target board with UUU. unzstd <image_name>-[secure-boot]-<machine_name>.rootfs.wic.zst uuu -b emmc_all <default_bootloader> <image_name>-<machine_name>.rootfs.wic uuu -b emmc <default_bootloader> <falcon_mode_bootloader>  The first parameter is the default bootloader, falcon mode bootloader is only specified in the second parameter of the second uuu command. Re: Falcon Mode Enablement - iMX8MP_EVK Hi @yipingwang & @elena_popa  Thank you so much for your support
查看全文
S32G_Howto_Boot_MiniLinux_from_QSPI This article explains how to boot a minimal Linux on the S32G using only QSPI Nor, for the most important purposes: emergency/upgrade/test mode for Linux, or fast booting catalogs 1 Background and Information Note... 2 1.1 Background note... 2 1.2 Description of the information required... 2 2 S32G QSPI Nor Mirror Layout Description... 3 2.1 S32G Linux BSP Support for QSPI Nor Boot... 3 2.2 S32G Yocto fsl-image-flash mechanism analysis... 5 2.3 Mirror Layout and Modification Targets for S32G QSPI Nor Boot... 7 3 Image modification and compilation... 8 3.1 Mirror image modification... 8 3.2 Yocto compilation methods... 10 3.3 Standalong compilation method... 11 4 How to shrink a Linux kernel image... 12 5 How to Make Minimum Rootfs. 12 5.1 Direct shrink based on existing rootfs... 12 5.2 Other methods... 14 6 Testing... 14 6.1 Burning Approach... 14 6.2 Running log. 16 7 How to add apps to Rootfs... 17 7.1 Adding methods to the Yocto environment... 17 7.2 Other methods ... 17 7.3 Test results... 17 8 Annexes... 17
查看全文
2026 年最佳 IPTV 提供商有哪些? 人们观看电视的方式发生了前所未有的变化。有线电视费不断上涨,观众希望获得更大的灵活性,流媒体已成为新常态。这就是为什么现在很多用户会问,2026 年最好的 IPTV 提供商是什么?他们希望有更好的频道选择、更流畅的播放以及不受传统电视限制的娱乐体验。 🛰️ 探索最佳 IPTV 供应商 IPTV 是互联网协议电视的缩写。它通过互联网连接提供直播电视频道、电影、体育和在线点播内容。用户不使用卫星或有线电视线路,而是直接在智能电视、Firestick、安卓设备、平板电脑和笔记本电脑上直播内容。 2026 年,IPTV 服务将继续增长,因为它们提供了便利、价值和现代化的观看功能。本指南将解释是什么让供应商脱颖而出,以及如何找到满足您需求的最佳 IPTV 解决方案。 2026 年最佳 IPTV 提供商因何而闻名? 2026 年的最佳 IPTV 提供商不仅要拥有众多频道。质量比数量更重要。顶级供应商应提供稳定的数据流、便捷的导航和强大的客户支持。 可靠的 IPTV 服务投资于更好的服务器,以减少缓冲。他们还定期刷新频道列表,在繁忙时段保持畅通无阻。这对体育迷和现场活动观众尤为重要。 强大供应商的另一个标志是用户友好的设置过程。良好的IPTV平台使激活变得简单,并与流行的应用程序和流媒体设备兼容。 2026 年 IPTV 为何更受欢迎 许多家庭现在更喜欢流媒体,因为它符合现代生活方式。用户希望按自己的日程安排娱乐,而不是固定有线电视套餐。 在任何设备上灵活查看 IPTV 发展的一个主要原因是设备自由。用户可以在智能电视、手机、平板电脑和流媒体棒之间轻松切换。这就创造了一种无缝的娱乐体验。 比传统电视更有价值 许多人都在寻找价格合理的 IPTV 提供商,因为他们想要更多的内容,而不需要支付高昂的有线电视月租费。IPTV 通常将全球频道、体育和电影合而为一。 按需便利 观众不再愿意等待预定的广播节目。IPTV 通常提供回放选项、电视补播和适合繁忙生活的视频在线点播内容。 2026 年最佳 IPTV 提供商的主要特点 如果您知道应该注意什么,选择合适的服务就会变得更加容易。 稳定的流媒体质量 2026 年最佳 IPTV 提供商注重快速服务器和高正常运行时间。与无法正常工作的冗长频道列表相比,流畅的播放更为重要。 广泛的渠道选择 顶级供应商通常包括娱乐、新闻、体育、儿童内容和国际网络。均衡的阵容为用户带来更多价值。 支持高清和 4K 现在,许多用户都希望获得高分辨率的流媒体。高级 IPTV 服务支持的频道通常包括高清、全高清和 4K 选项。 快速响应的客户支持 当出现登录问题、设置错误或应用程序问题时,快速支持可提供帮助。可靠的客户服务是选择 IPTV 提供商的一个重要因素。 如何选择最适合您的 IPTV 提供商 每个观众都有不同的侧重点。有些人想要体育报道,而另一些人则专注于电影或家庭娱乐。 如果体育赛事直播最重要,则应选择稳定的赛事流和覆盖面广的体育频道。如果您喜欢电影和连续剧,请选择具有强大 VOD 库和最新内容的供应商。 家庭可能更喜欢多设备访问和儿童频道。旅行者可能需要全球兼容性和灵活的登录选项。 订购前进行测试也是明智之举。许多用户在购买长期计划之前都会搜索 IPTV 免费试用服务,以检查服务质量。 推动 IPTV 搜索的搜索引擎优化趋势 2026 年最佳 IPTV 提供商、顶级 IPTV 服务、优质 IPTV 计划和无缓冲 IPTV 等搜索短语越来越常见。这反映出对灵活的流媒体解决方案的需求日益增长。 随着全球网速的提高,IPTV 也变得越来越容易使用。智能电视和流媒体设备也更实惠,这有助于提高IPTV的采用率。 人们想要个性化娱乐,而IPTV比标准电视套餐为他们提供了更多的控制权。 选择 IPTV 时应避免的错误 有些用户只选择最便宜的方案。低廉的价格可能很有吸引力,但较差的流媒体质量和薄弱的支持可能会导致失望。 另一个错误是忽视兼容性。务必确认提供商可在您的首选设备上运行。 跳过研究也会造成问题。阅读近期评论和试用测试有助于避免使用不可靠的服务。 2026 年 IPTV 的未来 预计 IPTV 将变得更加智能,更加以用户为中心。更快的网络、改进的应用程序和更好的内容库将继续塑造市场。 许多供应商正在改进界面、搜索工具和流媒体的稳定性。这意味着用户今后可以期待更流畅的体验。 随着需求的增加,IPTV 提供商之间的竞争也可能提高定价和服务质量。 结束语 那么,2026 年有哪些最佳 IPTV 提供商?这些服务集稳定的流媒体、优质的内容、简单的设置和强大的支持于一身。最佳选择取决于您的观看习惯、设备和预算。 选择 IPTV 提供商时,应注重性能而不是承诺。回放可靠、功能实用的服务总是更有价值。 如果您已准备好升级您的娱乐体验,请探索值得信赖的 IPTV 提供商,在 2026 年享受更智能的流媒体服务。 Re: What Are the Best IPTV Providers in 2026? 您在寻找无需立即付费即可享受优质内容的最佳方式吗?2026 年,寻找优质供应商的最有效方式是免费试用 IPTV。 为什么要从免费测试开始? 免费试用允许您在订购前验证几个关键因素: 稳定性:确保服务提供无缓冲流媒体和高正常运行时间(理想情况下为 99% 或更高)。 内容丰富:查看 20,000 多个直播频道,包括高级体育、新闻和国际网络。 质量:验证对高清、全高清和 4K 流媒体的支持。 设备兼容性:确认它可以在您的首选硬件上运行,例如亚马逊 Firestick、智能电视、安卓/iOS 设备或电脑。 2026 年的热门推荐 为了获得具有丰富频道选择和可靠性能的优质体验,我们建议您测试GoldCard TV。它旨在提供无缝娱乐解决方案,将停机时间降至最短。 👉 现在就开始免费试用: https://omeulink.com/GoldCardTv Re: What Are the Best IPTV Providers in 2026? 在过去几个月里,我测试了几家 IPTV 提供商,根据我的经验,HypoTV 是稳定性、流媒体质量和日常娱乐方面最好的提供商之一。如果您正在寻找以体育为重点的流媒体,BekuTV的表现非常出色,直播频道流畅,缓冲极少。对于成人内容和大型 VOD 库,PillowIPTV 是一个不错的选择。我还看到许多用户推荐MomipTV,因为它具有可靠的国际频道选择和多设备支持。总的来说,每种服务都有自己的优势,这取决于您最常观看的内容类型。 Re: What Are the Best IPTV Providers in 2026? 我测试过很多 IPTV 服务,NexusIPTV 的稳定性和画质确实让我大吃一惊。 频道速度快,几乎没有缓冲,而且有大量体育、电影和国际高清/4K 内容可供选择。 可在 Firestick、智能电视、安卓、iPhone 和电脑上完美运行。 如果您想在 2026 年获得可靠的 IPTV 服务,NexusIPTV 绝对值得一试。 www.nexusiptv.live Re: What Are the Best IPTV Providers in 2026? 我最近测试了几项服务,主要是体育直播,UHDSports 是迄今为止最流畅的服务之一。 我最喜欢的是,它不会让人感觉负担过重或杂乱无章。设置很简单,频道在我的设备上打开得很快,体育直播在高峰时段也很稳定,这通常是大多数提供商开始缓冲的地方。我还在智能电视和安卓设备上对其进行了测试,两者都运行良好。 VOD 方面也很不错,但对我来说,使用它的主要原因是体育直播。如果您要选择一家提供商,我还是建议您先申请免费试用,并在实际的实时比赛中进行测试,而不仅仅是在安静的时段。这才是真正的考验。 我并不是说它完美无缺,但根据我的经验,如果您优先考虑的是稳定的体育直播和快速的支持,UHDSports还是值得一试的。 Re: What Are the Best IPTV Providers in 2026? 如果您厌倦了寻找链接、切换应用程序或在大型比赛期间忍受延迟,那么 tvaccess.xyz 就是为您打造的平台。这项高级付费服务提供世界上所有主要体育赛事——全部采用高清、全高清和 4K 超高清画质,播放流畅稳定。 观看所有体育赛事高清/4K直播,尽在tvaccess.xyz Re: What Are the Best IPTV Providers in 2026? 我同意,在 2026 年选择 IPTV 提供商时,真正取决于可靠性、频道选择和流媒体质量。我也喜欢那些能让我在做决定前轻松核实信息的服务。最近,我在进行其他研究时发现Franklin Property Data对查询房产相关细节很有用。仔细比较各种方案,选择最符合自身需求的服务总是没错的。
查看全文
MRF300AN停产了吗? MRF300AN 在产品网站上仍然显示为在售产品,但我收到 Digi-Key 的通知,称该产品已停产。 我想了解目前的情况以及有哪些替代方案? Re: MRF300ANは生産終了ですか? 亲爱的吉田信二 请查看产品页面: https://www.nxp.com/part/MRF300AN MRF300AN 已报废 最后购买日期 2026-09-30; 最后交货日期 2027-09-30. 不建议直接替换。谢谢。祝您愉快致以最诚挚的问候 帕夫拉
查看全文
NXP Zephyr OS - 概述页面(日语博客) 最近,一款相对较新的实时操作系统引起了人们的关注。它名为“Zephyr ® OS”,发音为“Zephyr”。 Zephyr OS 是一款开源实时操作系统,其开发合作和支持得到了世界知名公司的大力支持,而 NXP 自 Zephyr 诞生以来一直是其白金会员。 本页面汇总了使用 Zephyr OS 的实用信息,请充分利用。 Zephyr ®系列(Zephyr OS 入门步骤) 步 文章 1 【Zephyr ®系列】第一部分:最近流行的 Zephyr OS 究竟是一款怎样的操作系统?(日语博客) →首先,让我们来了解一下 Zephyr OS 本身的功能特性。 2 【Zephyr ®系列】第二部分:首次构建与测试(日语博客) →接下来我们实际构建并运行 Zephyr OS。我们将以 FRDM-MCXA153 为例,但同样的步骤也适用于其他开发板。 3 【Zephyr ®系列】第三部分:LED 闪烁和软件复用的第一步(日语博客) →以 LED 闪烁程序为例,体验“传统的硬件相关编码”与“Zephyr 推荐的硬件无关(可扩展)编码”之间的区别。 4 [Zephyr ®系列] 第 4 部分:Kconfig 和设备树的概述及实际应用(日语博客) →对于传统的MCU软件工程师来说,“Kconfig”和“设备树”是Zephyr操作系统中比较陌生的概念。本文将通过实际示例进行解释。 Zephyr实用信息☕ 概述 文章 我使用 NXP 的 GUI 生成工具“GUI Guider”(支持用于微控制器的轻量级 GUI 库“LVGL”)生成了一个示例 GUI 代码,然后在 Zephyr OS 上运行了它。 试用 UI:Zephyr OS 上的 GUI Guider 示例代码(日本博客) *有关如何使用 GUI Guider 的说明,请参阅以下文章。 GUI Guider入门指南(Nexty Electronics Co., Ltd.) Zephyr 附带丰富的示例代码,其中包括一个易于运行的 HTTP 服务器示例。本指南提供了在 NXP 评估板“ FRDM-MCXN947 ”上运行该示例的分步说明。运行此示例后,您可以通过 PC 的 Web 浏览器访问 FRDM-MCXN947,并使用页面上的按钮打开/关闭板上的 LED 灯。 我尝试在 FRDM-MCXN947 上运行 Zephyr HTTP 服务器(日本博客) 截至2026年3月23日,NXP工程师发现安装最新版Zephyr环境后,调试器无法启动。本文档详细介绍了该问题及其解决方案。 使用 Zephyr OS(4.3.99 开发版)和 MCUXpresso for VSC 时,调试器是否无法启动?本文将解释如何避免调试器启动错误。(日语博客) 合作伙伴 Zephyr 相关信息 合作伙伴/概览 文章 Lineo Solutions Co., Ltd. 本文分两部分发表了使用 NXP 评估板“ MIMXRT1170-EVKB ”的说明文章:第 1 部分和第 2 部分。 在第一部分中,我们对 Zephyr 进行了基本解释,并介绍了源代码树结构以及用于验证本文运行情况的 NXP MIMXRT1170-EVKB 评估板。 在第二部分中,我们将从准备 Zephyr 环境开始,并解释构建和运行 Zephyr 应用程序的步骤。 第三部分还包括在液晶屏幕上实际显示信息的示例。   Zephyr博客,第一部分:我的第一辆Zephyr(第一部分) Zephyr博客,第二部分:我的第一辆Zephyr(第二部分) Zephyr博客,第三部分:“试用液晶显示屏” IT Access有限公司 本文档清晰地阐述了 Zephyr OS 的基本特性、与传统实时操作系统 (RTOS) 和 Linux 的区别,以及其适用的应用场景。随后,以恩智浦 (NXP) 的高性能微控制器评估板“ MIMXRT1060-EVKC ”为例,介绍了将 Zephyr 与安全引导加载程序“MCUboot”相结合的实际开发流程。通过实际硬件上的构建、烧录和固件更新等步骤,您可以了解使用 Zephyr 进行安全嵌入式系统开发的具体步骤。 什么是 Zephyr OS?本文将解释其特性、优势以及与其他实时操作系统和 Linux 的区别。 在 NXP ® MIMXRT1060-EVKC 上使用 Zephyr ®和 MCUboot 入门:安全启动 IAR Systems Co., Ltd. 我们经常收到用户关于无法配置 IAR 工具链的咨询。右侧链接提供了基于 NXP MCU 的“Zephyr x IAR 工具链”的详细日语配置步骤说明。 Zephyr 项目文档(英文版)中也包含了如何使用 IAR ARM 工具链的说明。   在 NXP 的 FRDM_MCXN947 上运行 ZephyrOS! 在 NXP 的 FRDM-MCXA153 上运行 Zephyr OS! 在 NXP 的 MIMXRT1020-EVK 上运行 Zephyr OS! 如果您对 Zephyr OS 相关内容有任何改进要求或建议,请随时使用以下信息与我们联系。 NXP日本技术博客(日语)内容请求/改进调查——请填写表格 =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便,我们深表歉意,但 在进行咨询时, 请 参考“ NXP 技术问题 - 如何联系我们 ( 日语博客 ) ” 。 (如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ,您可以直接咨询您的代表。 ) 最近,一款相对较新的实时操作系统引起了人们的关注。它名为“Zephyr ® OS”,发音为“Zephyr”。 Zephyr OS 是一款开源实时操作系统,其开发合作和支持得到了世界知名公司的大力支持,而 NXP 自 Zephyr 诞生以来一直是其白金会员。 本页面汇总了使用 Zephyr OS 的实用信息,请充分利用。 i.MX RT 处理器 i.MX 处理器 MCX SW | 下载 日本博客
查看全文
How do I convert the voltage of digital signals? (Japanese blog) 0. Table of Contents 0. Table of Contents 1. What is a voltage level translator? 2. Digital signals 2.1 Various Digital Signals 2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW 2.3 Input/Output Voltage Specification: VOH/VOL and VIH/VIL 2.3.1 Output voltage specifications: VOH and VOL 2.3.2 Input voltage specifications: VIH and VIL 2.3.3 The relationship between VOH/VOL and VIH/VIL 3. Basic voltage level conversion method: One-way signal conversion 3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Column: How are the TTL values VIH(min) = 2.0V and VIL(max) = 0.8V determined? 3.2 Examples requiring conversion 3.2.1 Conversion using open-drain output 3.2.2 Conversion using standard logic (general-purpose logic) chips 4. Conversion of bidirectional signals requiring automatic direction switching. 4.1 Bidirectional conversion using a single MOS transistor 4.2 Bidirectional conversion using dedicated equipment 4.2.1 I²C signal voltage conversion chip 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip 4.2.3 Bidirectional push-pull signal-to-voltage converter chip 4.2.4 I3C signal voltage converter chip 4.2.5 Buffer-based conversion 5. Summary 5.1 Comparison of methods/part numbers introduced in the blog 6. Reference materials 1. What is a voltage level translator? When connecting digital circuits, you can simply connect the signal lines directly... That's not the case; if the " logic level voltage " doesn't match, it may not work, become unstable, or in the worst case, damage the chip. That's where a voltage level translator (also called a voltage level shifter) comes in handy. A voltage level translator is a circuit that allows signals to be exchanged between digital circuits with different power supply voltages. For example, it is needed in the following cases: 3.3V microcontroller ↔︎ 5V sensor connection Connecting a 1.8V FPGA to 3.3V peripheral devices スクリーンショット 2025-08-21 12.39.23.png Figure 1: Differences in signal voltage   This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH / VOL / VIH / VIL for determining them. Furthermore, it explains which voltage level translator to choose from among various conversion methods. Furthermore, this blog will look at specific examples of voltage level translators that automatically detect and convert the direction of a signal . NXP also offers voltage level translators for SD cards/SIM cards and application-specific translators such as GTL↔︎TTL level conversion, but this blog will focus on products targeted at general-purpose or serial bus applications. *TTL (Transistor-Transistor Logic) *LVTTL (Low Voltage Transistor-Transistor Logic) *CMOS (Complementary Metal-Oxide-Semiconductor) *GTL (Gunning Transceiver Logic) 2. Digital signals   2.1 Various Digital Signals So-called "digital signals" are electrical representations of logic levels 1 and 0. Historically, there have been various circuit design methods for handling these logic levels 1 and 0. These include methods that represent logic levels with simple voltage HIGH and LOW, and methods that use voltage differences to represent HIGH/LOW. TTL simply represents HIGH/LOW as 5V/0V. Further reducing the voltage of TTL to 3.3V/0V, such as LVTTL , are systems where the voltage level is determined based on a bipolar transistor circuit. Similarly, ECL (Electronic Classification) uses bipolar transistors but employs a negative power supply to implement low-amplitude, differential operation logic levels, resulting in higher speeds. GTL (Global Transistor Lapping) uses a reference voltage to transmit HIGH/LOW signals with low-amplitude single-ended signals, etc. Furthermore, even with a simple HIGH/LOW representation, the 4000 series of CMOS general-purpose logic, developed with the aim of reducing power consumption, allowed the use of 3V to 18V as the HIGH level. https://en.wikipedia.org/wiki/Logic_family This blog will explain how to handle voltage levels in TTL (LVTTL) and CMOS, which represent logic using simple HIGH and LOW voltages , among the various logic levels mentioned above. Other signal conversions utilize dedicated chips and are therefore not covered here. In addition, in recent years, semiconductor technology has become smaller, faster, and more power-efficient, and the voltage used for power supplies has been decreasing. For this reason, voltage level translators, which bridge the signal voltage difference, have become particularly important. スクリーンショット 2025-08-21 12.42.23.png Figure 2: Signal waveform - Voltage levels (HIGH/LOW) represent logic levels.   2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW In digital circuits, simple voltage-based logic level signals using HIGH and LOW typically use the power supply voltage for HIGH and 0V for LOW. As long as the HIGH/LOW voltage levels are the same, the signals can be transmitted even if the power supply voltages are different. For example, TTL (LVTTL) interprets an input signal as HIGH if it is 2.0V or higher, and LOW if it is 0.8V or lower. Because of this convention, the HIGH/LOW voltage levels of TTL signals do not change even if the power supply voltages are different. On the other hand, CMOS defines HIGH/LOW based on half the power supply voltage. Therefore, the HIGH/LOW voltage levels of CMOS change when the power supply voltage is different. スクリーンショット 2025-08-21 12.52.04.png Figure 3: Input signal voltage specification   2.3 Input/Output Voltage Specification: V OH / V OL and V IH / V IL In digital circuits, the voltages output as HIGH and LOW , and the voltage used to determine whether an input signal is HIGH or LOW, are specified. These are defined in the specifications of each chip used, so you need to check the datasheet. V OH : High-level output voltage VOL : Low-level output voltage V IH : High-level input voltage V IL : Low-level input voltage 2.3.1 Output voltage specifications: V OH and V OL When considering the output, you must take into account the current required when outputting HIGH/LOW signals. The current will increase or decrease depending on the load. The voltage that can be guaranteed at the maximum outflow current with HIGH output is called VOH (min) , and the voltage that can be guaranteed at the maximum inflow current with LOW output is called VOL (max) . V OH (min) is the voltage output when the upper transistor in the circuit's output stage is turned ON. This transistor has a resistance called "ON resistance". When a large current flows out of a transistor, a voltage is generated equal to "the transistor's resistance x the current flowing through it". This causes the output voltage to drop below the power supply voltage by that amount, resulting in a low VOH . Therefore, VOH (min) is the minimum voltage that can be guaranteed when the maximum expected outflow current is reached. スクリーンショット 2025-08-21 12.53.04.png Figure 4: Digital signal output circuit (push-pull)   スクリーンショット 2025-08-21 12.53.18.png Figure 5: HIGH output voltage varies depending on the load.   VOL is the opposite. When the lower transistor in the output stage of the circuit is turned ON, if the incoming current is large, the output will rise above 0V due to the voltage generated by the ON resistance of the transistor, as described above. Taking this into consideration, VOL (max) is the maximum voltage that can be guaranteed when the maximum incoming current is anticipated. スクリーンショット 2025-08-21 12.53.31.png Figure 6: LOW output voltage also changes depending on the load.   2.3.2 Input voltage specifications: V IH and V IL The input has voltage levels to determine HIGH and LOW : V IH (min) and V IL (max) . If the voltage is above V IH (min), it is judged as HIGH; if it is below V IL (max), it is judged as LOW. In CMOS inputs, half the power supply voltage serves as the reference for HIGH and LOW, but this is not directly used as V IH (min) and V IL (max). This is because the threshold can fluctuate due to variations between chips. Also, to mitigate glitches caused by noise on slow-rising signals appearing in the output, it is common practice to incorporate hysteresis into the input. For these reasons, V IH (min) and V IL (max) are defined with a certain voltage difference. 2.3.3 The relationship between VOH / VOL and VIH / VIL For normal signal exchange to occur, the relationship between the output and input must satisfy the following equation. HIGH level: V OH (min) > V IH (min) LOW level: VOL (max) < VIIL (max) If this relationship is maintained, the output circuit can correctly transmit HIGH/LOW signals to the next input circuit. Furthermore, the voltage difference between them, "V OH (min) - V IH (min)" and "V IL (max) - V OL (max)," becomes the " noise margin " and serves as a guideline for maintaining high noise immunity. スクリーンショット 2025-08-21 12.55.13.png Figure 7: V OH (min) / V OL (max) and V IH (min) / V IL (max) 3. Basic voltage level conversion method: One-way signal conversion   3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Voltage level conversion is generally not necessary when the relationships "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" hold true. For example, although TTL and LVTTL use different power supply voltages for their respective chips, the input and output voltage specifications are the same . In both TTL (5V) and LVTTL (3.3V), V OH (min) is 2.4V and V OL (max) is 0.4V. Since V IH (min)/V IL (max) are also 2.0V/0.8V in both cases, they can be connected to each other without any problems. However, caution is required if the output voltage is higher than the power supply voltage of the input chip. If the output chip uses a 5V power supply and the input uses a 3.3V power supply, the input must support " 5V tolerant input ". A 5V tolerant input is an input that can operate without problems even when a 5V HIGH signal is connected to the input of a chip that operates on a 3.3V power supply voltage. While typical chip inputs have ESD protection circuits to protect against static electricity, if this ESD protection circuit is configured as shown in the following diagram, a 5V input can cause current to flow back from the input to the 3.3V power supply, potentially damaging the chip. A 5V tolerant input is designed to prevent such problems. Tolerant inputs do not lack ESD protection; they incorporate an ESD protection circuit that is structured to handle signals higher than the power supply voltage without causing problems. ESD protection diodes like the one shown in Figure 7 can also cause problems when the power to the input chip is turned off. In systems where the power to each chip is controlled individually, the output signal may feed back into the power supply even when the input chip is off, causing the input chip to operate. スクリーンショット 2025-08-21 12.57.16.png Figure 7: ESD protection diode - non-tolerant input Column: How are the V IH (min) = 2.0V and V IL (max) = 0.8V determined for TTL? While the input threshold of CMOS is based on the midpoint of the power supply voltage (VCC/2), the V IH (min)/V IL (max) of TTL is 2.0V/0.8V, which is not a particularly neat ratio with respect to the power supply voltage (5V). This is related to the fact that the input stage of TTL is composed of bipolar transistors. スクリーンショット 2026-06-20 6.45.38.png Example of the internal circuit of a standard TTL logic IC: SN7400 (2-input NAND). This information was included in the "Latest General-Purpose Logic Device Specifications Table 1988" (CQ Publishing). A typical TTL gate's input stage consists of a multiple emitter input transistor and a subsequent phase splitter transistor, both connected in series. The "switching threshold," at which the gate actually begins to react, is determined by the forward voltage of the PN junctions in these two stages. Since the forward voltage of a single silicon PN junction is approximately 0.6 to 0.7V, the combined forward voltage of the two stages is approximately 1.3 to 1.5V, which is the effective switching threshold for a TTL gate. However, this value of approximately 1.4V is merely a "typical value," and it will fluctuate from lot to lot and from condition to condition due to individual differences and variations in temperature. Therefore, the specified values V IH (min) and V IL (max) on the datasheet are defined as guaranteed values, with sufficient margins above and below this typical value of approximately 1.4V, meaning that "if it drops to this level, it can be reliably determined to be LOW (V IL (max) = 0.8V)" and "if it rises to this level, it can be reliably determined to be HIGH (V IH (min) = 2.0V)." Furthermore, this value is not determined in isolation, but is designed taking into account the relationship between VOH and VOL , as explained in Section 2.3.3. In standard TTL, due to the output stage configuration, the HIGH output is not the power supply voltage, but a slightly lower voltage (lower by the voltage generated by the 130Ω resistor, transistor, and diode in the circuit example above) (VOH(min)=2.4V). When this is combined with VOL(max)=0.4V, HIGH noise margin: V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V Low-side noise margin: V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V As shown, it is designed to ensure a noise margin of 0.4V symmetrically above and below. In other words, the 2.0V/0.8V figures for TTL, which may seem "odd" relative to the power supply voltage, are actually reasonable values derived from two requirements: the physical reality of the bipolar transistor junction voltage and the noise margin design. スクリーンショット 2026-06-20 8.20.24.png This image shows an SN7420 (4-input NAND) with three input pins set to HIGH and one pin receiving a 100kHz triangular wave (ch1). The output under no load (ch2) is less than 4V when HIGH (Vcc=5V). The circuit introduced in this column is an example of a standard TTL without a designation (such as 74 LS 00 or 74 HC 00, without LS/HC prefixes; sometimes called "vanilla TTL" in English), but the reason why the V IH /V IL specifications are the same (bipolar junction characteristics of the input stage) is common to other TTL families such as the 74LS.   3.2 Examples requiring conversion   While TTL and LVTTL connections are possible because the voltage levels are aligned, mismatches in logic levels often occur when connecting CMOS chips with different power supply voltages, or when connecting a CMOS chip to a TTL chip. This occurs when the aforementioned relationship "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" does not hold true, or when the difference becomes too small, resulting in insufficient noise margin. A voltage level translator solves this problem. スクリーンショット 2025-08-21 12.56.11.png Figure 9: Example of mismatched logic levels (1): Insufficient HIGH voltage input   スクリーンショット 2025-08-21 12.56.20.png Figure 10: Example of mismatched logic levels (2): Insufficient LOW voltage is input.     3.2.1 Conversion using open-drain output There are ways to easily adjust voltage levels without using a voltage level conversion chip. If the signal direction is fixed from the output chip to the input chip and does not switch, then this method involves making the HIGH output an open-drain output to match the input voltage. An open-drain output is a configuration in which the upper transistor of the output stage of a digital circuit is absent, and the HIGH voltage is obtained by a pull-up resistor connected to the power supply voltage of the input chip . スクリーンショット 2025-08-21 12.58.18.png Figure 11: Digital signal output circuit (open drain)   Open drains are a simple and inexpensive method, but there are a few things to keep in mind . First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this type of output through configuration. First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this output through configuration. If the output is fixed to push-pull output and cannot be configured for open-drain output, an external transistor or similar device will be needed to convert it to open-drain output. Furthermore, the selection of pull-up resistors is also important. A pull-up resistor is necessary to obtain a HIGH voltage, but if the resistance value is too small, the current flowing when the output is LOW will be large (similar to a heavy load), which will increase power consumption and lead to an increase in VOL . Conversely, if the value is too large, it will be affected by the capacitance of the wiring and pins, causing the rise time from LOW to HIGH to be slow, resulting in a decrease in communication speed. 3.2.2 Conversion using standard logic (general-purpose logic) chips For simple voltage level conversion, you can also use standard logic. For example, Nexperia's 74AVCH4T245 is a general-purpose CMOS logic chip that can perform 4-bit bidirectional level conversion. This chip can convert signals from 0.8V to 3.6V, and the signal direction can be switched using the DIR pin. The signal speed depends on the voltage being converted, but it can support speeds of approximately 100M to 380Mbps. スクリーンショット 2025-08-22 3.29.11.png Figure 12: Example of standard logic - 74AVCH4T245 This chip enables high-speed bidirectional voltage conversion of signals, but the direction must be controlled by an external signal. While such control is possible with signals like READ/WRITE on a parallel bus, it is difficult to apply to communications like serial buses where the communication direction switches depending on the protocol. スクリーンショット 2025-08-22 3.29.26.png Figure 13: Example of standard logic. The signal direction must be specified externally. 4. Conversion of bidirectional signals requiring automatic direction switching. The "open-drain output" and "voltage conversion methods using standard logic chips" introduced so far mainly perform conversion in only one direction, or require switching of direction by an external signal. Communication methods like I²C and I3C , where the direction of the signal changes dynamically, require " bidirectional voltage level conversion " that automatically detects and switches the direction. Controlling the direction of such signals externally is difficult, and it is challenging to implement this with the buffer chips mentioned above. Furthermore, since I²C is an open-drain signal, it is not possible to connect standard open-drain logic buffers in opposite directions. Figure 14 shows an example of this, where open-drain buffers are connected in opposite directions. There is no problem when both sides of the buffer are HIGH, but once one of them goes LOW, the buffers will keep pulling the other input LOW and will not be able to return to HIGH. スクリーンショット 2025-08-22 3.29.39.png Figure 14: A typical open-drain buffer cannot automatically switch between bidirectional communication.   4.1 Bidirectional conversion using a single MOS transistor   Until now, simple circuits have sometimes been used for I²C signal-to-voltage conversion. We will present the simplest method, using a MOS transistor, as an example. VLT_by_MOS.png Figure 15: Example of conversion using a MOS transistor   Figure 15 is taken from the I²C specification version 2.1 (2000) and shows an example where two MOS transistors (TR1, TR2) are used to convert 3.3V and 5V signals, respectively. Although such a simple conversion example using only transistors has been removed from the current I²C specification due to the problems described later, it is included here to understand the principle . The I²C signal lines, called SDA and SCL, are both open-drain bidirectional signals. Pull-up resistors are connected to the 3.3V and 5V sides, respectively. In this circuit, when the 3.3V and 5V signals are HIGH, the gate (g) and source (s) of this transistor are at the same potential, so the source (s) and drain (d) are OFF, and the connection between them is broken. When 3.3V changes to LOW in this state, the 3.3V side transistor (between s and d) turns ON , and the 5V side signal also goes LOW . When the 3.3V side changes to HIGH and the 5V side changes to LOW , the parasitic diode (body diode) connecting the 3.3V side to the 5V side first turns ON . When the diode turns ON, the source(s) voltage drops . As a result, the transistor turns ON , and the signal on the 3.3V side also becomes LOW . While this very simple mechanism using a transistor as a switch allows for voltage level conversion, there are problems. Transistor variations affect the threshold voltage for signal conversion. Furthermore, with the increasing need to handle lower signal voltages, for example, at signal voltages of around 1V, such a circuit cannot operate because it cannot obtain a sufficient gate-to-source voltage (Vgs). Addendum: The same circuit as in Figure 15 is still publicly available as application note AN10441 "Level shifting techniques in I²C-bus design" from Nexperia , a company formed when the semiconductor discrete/logic products business was spun off from NXP. The application note was first published in 2007 (Rev.01) separately from the I²C specification, and was revised under the Nexperia brand in 2020 (Rev.2). 4.2 Bidirectional conversion using dedicated equipment   By using a dedicated voltage level translator IC , voltage level conversion for bidirectional communication buses such as I²C and I3C can be easily performed. 4.2.1 I²C signal voltage conversion chip The PCA9306 and NVT20xx series ( NVT2001/02 , NVT2003/06 , NVT2008/10 ) are voltage level translators specifically designed for bidirectional signal conversion. These chips can handle multiple signal lines (multi-bit signal lines) simultaneously. While they are designated as I²C signal voltage conversion chips, they can also be used for other purposes (such as SPI and other push-pull signals) if the signal specifications match . The PCA9306 and NVT20xx series share the same internal structure, and the pull-up resistor only needs to be connected to the higher voltage side if the voltage difference to be converted is 1V or more . Figure 16 shows its internal structure and connection to external chips (excerpted from Fig. 2 of Application Note AN11127 : "Bidirectional voltage level translators NVT20xx and PCA9306" ). This chip contains the number of signal lines (bits) + 1 MOS transistors. Each transistor has a structure in which the source and drain are interchangeable. The transistors in the signal transmission path are called pass transistors , and the remaining one is called a reference transistor . スクリーンショット 2025-08-22 15.56.50.png Figure 16: NVT20xx (PCA9306) - Diagram illustrating chip operation.   Looking at the circuit, the gate and drain of the reference transistor are shorted and connected to the higher voltage power supply via a 200kΩ resistor. The remaining terminal of the reference transistor, the source, is connected to the lower voltage power supply. With this connection, the reference transistor acts as a single diode , and its gate voltage is one diode higher than the lower voltage power supply . The remaining pass transistor has its drain connected to the high-voltage signal line and a 1kΩ pull-up resistor, its source connected to the low-voltage signal line, and its gate connected to the gate of the reference transistor. When both the high and low signals of the pass transistor are HIGH, the high-voltage side becomes the voltage pulled up by the 1kΩ resistor . A pass transistor forms a circuit known as a "source follower." The terminal on the lower voltage side (source terminal) has a voltage that is lower than the voltage applied to the gate by the amount of Vgs required to turn the transistor ON . In other words, it has the same voltage as the low-voltage power supply. The transistor is in a semi-ON state (operating in the linear region), neither ON nor OFF. In this state, when either the high or low signal becomes LOW , the voltage difference between the gate and the signal terminal causes the transistor to turn ON (operating in the saturation region where it is fully ON), and the other terminal also becomes LOW . The signal speed that this series can handle is affected by the pull-up resistor and the capacitance of the signal line. The datasheet states that the PCA9306 can handle up to 2MHz. The NVT20xx series can handle signal speeds up to 33MHz with a 192Ω pull-up resistor and a capacitance of 50pF. For signals around 1MHz, it will work without problems even if you don't worry too much about the pull-up resistor and capacitance (assuming it's within the range typically used for I²C). However, when using this chip to handle higher-speed signals in a push-pull configuration, a thorough understanding of its characteristics and careful component selection are necessary. Details of the operation of this type of voltage level translator are described in the article " The Internals and Operation of the PCA9306 ". 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip We introduce the NTS030x series ( NTS0302JK , NTS0304E ) as high-speed bidirectional open-drain signal conversion chips. This chip can perform 2-bit or 4-bit bidirectional signal conversion and can handle signals up to 2Mbps (1MHz) for open-drain signals and 20Mbps (10MHz) for push-pull signals.   スクリーンショット 2025-08-22 15.59.57.png Figure 17: NTS030x - Internal Chip Block Diagram   Figure 17 shows the internal structure of one signal bit in the NTS030x. In the diagram, transistor T3 is a pass-through transistor , and a gate terminal bias voltage is applied to it, so it turns ON when either the signal labeled A or B goes LOW. When both A and B are HIGH, T3 turns OFF, and since A and B are connected to their respective power supplies with relatively large pull-up resistors (10kΩ), they will have their respective voltages. This chip has T3, as well as T1 and T2 . These T1 and T2 are used for a function called " edge rate accelerator ." We will focus on one of them, T1, and explain its operation. T1 is placed on the A side, with its source terminal connected to the A signal and its drain terminal connected to the A side power supply. The gate terminal is connected to the block labeled "ONE-SHOT AND SLEW RATE CONTROL" that controls it. The "ONE-SHOT AND SLEW RATE CONTROL" block is connected to the B signal on the opposite side and detects the change from LOW to HIGH in the B signal . When this is detected, T1 is temporarily turned ON, bypassing the 10kΩ pull-up resistor and allowing current to flow, thereby accelerating the change from LOW to HIGH in the A signal . By speeding up the rise time of the signal in this way, it becomes possible to handle faster signals. Incidentally, the slew rate when T1 is turned ON is controlled, taking into consideration the suppression of ringing caused by a sudden increase in current. The other T2 uses the same mechanism but in the reverse direction, and is applied to the B-side signal as well. The NTS series has another user-friendly feature . In the case of the MOS transistors and PCA9306/NVT20xx described so far, there was a problem in that if one power supply was turned off, the signal of the other would be set to LOW. To solve this problem, the NTS030x operates so that when both power supplies are not ON, the signal pins are set to a high impedance state to prevent them from affecting each other . By using this function, it becomes possible to partially control the ON/OFF state of the system's power supply . The NTS010x series ( NTS0102 , NTS0104 ) is equivalent to the NTS030x series, but lacks slew rate control functionality to handle higher-speed signals. An evaluation board, NTS0304EUK-ARD, is available for the NTS0304E to allow for quick and simple operational verification. For an overview of the NTS0304EUK-ARD board and how to operate it, please refer to this video , "How to operate the NTS0304EUK-ARD" . 4.2.3 Bidirectional push-pull signal-to-voltage converter chip Furthermore, for use with push-pull signals only, there is the NTB010x series ( NTB0102 , NTB0104 ), which offers a faster option. When stable in a HIGH or LOW state, the signal is driven through a 4kΩ resistor. Similar to the NTS030x series, it has a one-shot function on both the HIGH and LOW sides, and has a mechanism that uses this to change the signal on the opposite side when there is a change in the signal at either terminal. This mechanism enables signal-to-voltage conversion at speeds of 70-80 Mbps while also having an automatic signal direction detection function.   スクリーンショット 2025-08-22 16.04.45.png Figure 17: NTB010x - Internal Chip Block Diagram 4.2.4 I3C signal voltage converter chip I3C has a specification that switches between open-drain and push-pull communication modes . In open-drain mode, it is compatible with I²C and operates at frequencies up to 4MHz . In push-pull mode, a 12.5MHz clock is used. Since the signal voltage is usually in the range of 1V to 3.3V, a voltage level translator that operates according to the signal specifications is required when there is a voltage difference. Figure 18 shows the internal block diagram of one bit of the P3A1604 . As shown in the figure, this chip incorporates a mechanism to accelerate not only the LOW→HIGH change but also the HIGH→LOW change, as well as a pull-up resistor that can be switched ON/OFF.   スクリーンショット 2025-08-22 16.28.46.png Figure 18: P3A1604 - Chip internal block diagram The P3A1604 is a 4-bit I3C voltage level translator. A 2-bit version, the P3A9606 , is also available.   4.2.5 Buffer-based conversion Another method for converting bidirectional signals is to use a dedicated buffer. The primary purpose of a buffer is to enhance driving capability and separate the capacitance of connected signal lines, but there are also products that support voltage conversion. As explained in this blog, simple buffers cannot mutually buffer bidirectional open-drain signals. Therefore, various buffer products with special features for bidirectional open-drain signals are available. I will explain more about buffers on a later occasion. 5. Summary Voltage level translators are essential components for safely and reliably exchanging signals between digital circuits with different power supply voltages. Understanding the definitions of logic levels such as TTL, LVTTL, and CMOS, as well as the relationships between VOH/VOL/VIH/VIL, allows you to select the appropriate connection and conversion method. For unidirectional conversion, open-drain outputs or standard logic ICs can be used, while for bidirectional conversion, MOS transistors or dedicated ICs (such as the PCA9306/NVT/NTS/NTB/P3A series) can be used. Voltage level translators with automatic signal direction detection capabilities are particularly useful for buses requiring bidirectional communication, such as I²C and I3C. Furthermore, recent advancements in semiconductor technology have led to lower voltages and higher speeds, requiring more precise voltage level control. While there are many methods and options for voltage level conversion, it is important to select the optimal method and components according to the application, taking into account signal specifications, speed, and system power management. 5.1 Comparison of methods/part numbers introduced in the blog Method/Part Number Purpose Number of bits Direction change Open wiring compatible Low voltage side [V] High voltage side [V] Bitrate [bps] Conversion with open-drain output General purpose 1 unidirectional - - - - Standard logic (e.g., 74AVCH4T245) General purpose (parallel bus, etc.) 4 + 4 External control Not supported 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M Bidirectional conversion using a single MOS transistor I²C, General Purpose 1 automatic correspondence Depending on the transistor specifications ~ 1M PCA9306 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz, depending on conditions) NVT2001 I²C, General Purpose 1 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2002 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2003 I²C, General Purpose 3 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2006 I²C, General Purpose 6 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2008 I²C, General Purpose 8 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2010 I²C, General Purpose 10 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NTS0302JK I²C, SPI, General Purpose 2 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0304E I²C, SPI, General Purpose 4 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0102 I²C, SPI, General Purpose 2 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTS0104 I²C, SPI, General Purpose 4 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTB0102 SPI, General Purpose 2 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, General Purpose 4 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, General Purpose 2 automatic correspondence 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, General Purpose 4 automatic correspondence 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @ Open Drain, 40M @ Push Pull Table 1: Comparison of methods/part numbers introduced in the blog   6. Reference materials Product introduction page: Voltage Level Converter NXP System Management I2C, I3C, SPI Selector Guide I2C Bus Specifications and User Manual (Rev5.0) (Japanese version) I2C Bus Specifications and User Manual (Rev7.0) English version) NXP Community Blog: I3C Bus Overview – The Next Serial Bus Japanese Webinar Video: "The Basics of the Next-Generation Interface 'I3C' That You Need to Know Now" Qiita @teddokano: PCA9306's internals and operation Change history: 2025-08-28: First Edition 2025-08-28: Added information about NTS0304EUK-ARD and a link to the blog with the video. 2026-04-10: Correction of low voltage side [V] and high voltage side [V] in Table 1. 2026-06-20: Section 3.1 "Column: VIH (min) of TTL" Added "How are VIL(max) = 2.0V and VIL(max) = 0.8V determined?". Added internal circuit example of standard TTL logic IC: SN7400 (2-input NAND) and output waveform of SN7420. 2026-07-10: Added to Section 4.1 that the circuit in Figure 15 is also published as Nexperia application note AN10441. ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH , VOL , VIH , and VIL for identifying them. Furthermore, we will explain which voltage level translator to choose from among the various conversion methods. We will take a closer look at the conversion of bidirectional open-drain signals , which requires special handling. スクリーンショット 2025-08-21 12.52.04.png Interface Introduction Japanese Blog
查看全文
DMA 模式下 UART 通信失败(S32k311) 嗨,@nxp团队、 我在S32K311目标硬件的 DMA 模式下使用 UART 通信,但主站和从站之间甚至连一次传输都没有。双方都在使用 512 字节的缓冲区。但是,在微控制器方面,回调被触发并引发了 LPUART_UART_IP_EVENT_ERROR,而且 UARTState 的状态始终显示为超限状态。 我尝试过的波特率从 100 kbps 到 900 kbps 不等。 注:为确保波特率不是问题,我还测试了单次传输和基于周期的传输。然而,系统总是会进入超限状态。 能否请您检查一下我的配置?为了供你参考,我附上了配置屏幕截图以及 UART 模块设置。 为此,我为两个 USRT 通道的 TX 和 RX 创建了 4 个 DMA 通道。       Re: UART communication failed in DMA mode(S32k311) 感谢@Julián_AragónM的回复 事实上,由于版本兼容性问题,我无法在我的系统上加载给出的示例。不过,我会尝试添加 RM 模块并进行测试。 我的 S32 IDE 版本是 3.6.3RTD 版本为 6.0.0. Re: UART communication failed in DMA mode(S32k311) 你好,@jagannath、 我看到您还输入了一个内部案例,我已在该案例中回复了您的问题,但为了以防万一,我也将在此回复: 能否告知您使用的 RTD 和 S32DS 版本? 从图片中可以看出,"Rm" 模块并没有包含在项目中。要使用 DMA,必须添加"Resource Manager" 驱动程序,启用 Dma Mux 支持,并配置相应的 DMA MUX 通道: Snag_aff8e3.png 您可以参考社区中已有的例程:示例 S32K312 UART 发送& 接收使用 DMA DS3.5 RTD300。 致以最诚挚的问候, Julián Re: UART communication failed in DMA mode(S32k311) @nxp 如果您需要更多细节, 请 告诉我。 Re: UART communication failed in DMA mode(S32k311) 你好,@jagannath、 来自 RTD 3.0.0此后,DMA 支持从 MCAL 层移至 Rm 模块。RM 模块不支持 IP 层。因此,用户应将 RM 模块直接添加到高级层。 查看 S32K3XXRM 的 DMAMUX 映射 excel 文件附件,可以看到 LPUART0 被分配到 DMAMUX0,而 LPUART3 被分配到 DMAMUX1。 DMA 复用源字段已禁用,无法编辑. 我不明白这种说法。从您的图像中,我可以看到第一个 Dma Mux 源容器是可用的,但您将它们配置为 "REQ_DISABLED"。您必须将 LPUART 通道与 DMA MUX 信号源连接成类似这样: dmamux1.png dmamux0.png 至于我分享的示例,是的,您不能直接导入,因为该项目是在 RTD 3.0.0 中开发的、当您使用 RTD 6.0.0 时。不过,您可以将配置文件和主文件复制到工作区,以测试 UART + DMA。 致以最诚挚的问候, Julián Re: UART communication failed in DMA mode(S32k311) Hii@Julián_AragónM 我已添加 RM 模块,但DMA Mux Source 字段被禁用,无法编辑。这是我的配置与给出的示例配置之间的唯一区别。然而,我得到的结果与之前的错误一样。 我附上了配置示例的截图以及我的配置MEX 文件。 S32 集成开发环境版本:3.6.2 RTD 版本:6.0.0 能否请您在方便时尽早查看一下? Re: UART communication failed in DMA mode(S32k311) Hii@Julián_AragónM S32 集成开发环境版本:3.6.2 RTD 版本:6.0.0 注意: 由于 MCAL 通常在基于 AUTOSAR 的架构中使用,因此我们的项目目前不使用任何 AUTOSAR 模块,因此也不打算包含 MCAL 模块。我们的要求是在不使用 MCAL RM 驱动程序的情况下实现基于 DMA 的通信。请确认是否可以不依赖 MCAL (RM) 运行 DMA 模式? Re: UART communication failed in DMA mode(S32k311) 感谢@Julián_AragónM提供迄今为止的详细信息。 目前,当我向 MCU 发送数据时,会触发信号,但事件始终是 " LP UART_UART_IP_EVENT_ERROR "。正因为如此,我无法退出这个问题。我根据示例和社区帖子尝试了几种方法,但遗憾的是,到目前为止没有一种方法能解决问题。 我在这里附上了我的整个工作区。能否请您帮助审查一下,以确定是否存在任何问题?如果可能的话,希望您也能在自己的系统上试运行一下。 提前感谢您的支持。 Re: UART communication failed in DMA mode(S32k311) 你好,@jagannath、 对不起,我的回复晚了! 关于第一个问题,我在你的项目中看到 UART 缓冲区没有被声明在非缓存区内。为了避免启用 数据缓存 时可能出现的一致性问题,用户应确保用作 TCD 源和目标的缓冲区分配在不可缓存区域,或者尝试使缓存地址失效: Snag_57e873a.png #pragma GCC section bss ".mcal_bss_no_cacheable" uint8_t tx_data[15]; uint8_t rx_data[15]; #pragma GCC section bss 关于第二个问题,你能检查中断和处理程序吗?调用 uart 传输函数时,返回的是什么? 致以最诚挚的问候, Julián Re: UART communication failed in DMA mode(S32k311) Hii@Julián_AragónM 感谢您的支持。我们现在的情况要好得多--在添加 RM 模块并修正配置后,DMA 传输已开始工作。不过,似乎仍有一些数据丢失/覆盖问题,如下所述: 1.在第一次(新)传输过程中,前20字节和最后约10字节的数据总是丢失。 主设备每 100 毫秒定期发送 512 字节的数据。 MCU 缓冲区的大小也是 512 字节。 MCU 报告 接收到了 512 字节 ,但 前大约 20 字节(有时还有最后大约 10 字节)缺失,而从 第 21 字节开始的剩余字节 是 正确的。 2.在第二次及其后的传输过程中: 缓冲区内容的片段显示如下: 索引0 至 83→ 包含0xAA(默认值) 索引84 至 116→有效数据 索引117 至 308→0xAA(默认值) 索引308 至 340→有效数据 索引340 至 372→0xAA(默认值) 3.传输 4/5 次后,数据传输完全停止,但不会出现奇偶校验/成帧/超限等错误。 这种模式一直持续,几次传输后,数据传输完全停止。 能否请您帮助确定导致这种行为的原因? 谢谢!         Re: UART communication failed in DMA mode(S32k311) 非常感谢@Julián_AragónM的支持。现在问题已经解决,一切正常。非常感谢你们的帮助。 谢谢
查看全文
HAB ブート可能イメージ生成用の SREC ファイルの作成 アプリケーションイメージを MIMXRT1170 ( EVKB ボード) の NOR フラッシュにフラッシュするためのコマンドライン ツールを生成しています。 nxpimage ツールは、次のように axf/elf ファイルから SREC 形式のファイルを作成するのに役立つことがわかっています。 nxpimage utils バイナリイメージ変換-i " %AXF_FILE% " -f s19 -o " %SREC_FILE% "   しかし、生成されたSRECファイルは、MCUXpresso Secure Provisioning Toolを使用した際に生成されるSRECファイルとは内容とアドレス指定が異なります。MCUXpresso Secure Provisioning Toolを使用してelf/axfファイルを読み込み、ブートイメージを作成すると、MCUXpresso Secure Provisioning Toolのワークスペースのソースフォルダにsrecファイルと解析済みdcdファイルが追加されます。MCUXpresso Secure Provisioning Toolによってこれらのsrecファイルと解析済みdcdファイルがどのように生成されるのかを知りたいです。また、CLIツールを使用してSREC/elf/axfファイルから解析済みdcdファイルを個別に抽出する方法があるかどうかも確認したいと思っています。   MCUXpresso セキュア プロビジョニング ツールを CLI から呼び出してプロセス全体を自動化できることはわかっていますが、nxpimage ツールと blhost ツールだけで MCU をフラッシュできるスクリプトを作成しようとしています。     Re: Creating SREC file for HAB bootable image generation こんにちは@tj787さん、 ここでわかるのは、次のコマンドがこの出力を指定された「parsed-directory」に作成しているということです。 nxpimage.exe hab parse -f mimxrt1176 -o 解析ディレクトリ -b my-application-with-dcd.bin Kan_Li_0-1770780123329.png お役に立てれば幸いです。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記: - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう! - スレッドは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいスレッドを開いて、閉じたスレッドを参照してください。 ---------------------------------------------------------------------------------
查看全文