Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
将 UART 数据输出到 Arduino 引脚上的 MCXN947 我尝试通过 Arduino 引脚 :P4_3/FC2_UART_RXD-ARD_D0 / P4_2/FC2_UART_TXD-ARD_D1 输出 UART 数据,而不是使用内部调试器 (MCU-Link)。基于此,我更改了引脚复用器,并尝试使用简单的环回测试进行测试。但这完全行不通。我甚至尝试过使用不同的别针。除了 Mux 之外,我是否还遗漏了其他配置设置? 我附上我的项目供您参考。期待您的帮助。 通信与控制(I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO)
記事全体を表示
TJA1120A RGMII Auto-Ethernet We are working on TJA1120A RGMII Auto-Ethernet on our Custom Board based on TI AM62A7 Kindly help us with how to enable this interface on Yocto Linux  We have tried following DTS node format as in https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp%2Ctja11xx.yaml But driver didnt probe on Kernel dmesg We understand that this PHY has vendor ID D001B:B031 We have also enabled CONFIG_NXP_TJA11XX_PHY in kernel config CONFIG_NXP_C45_TJA11XX_PHY Re: TJA1120A RGMII Auto-Ethernet Hello @vikyhre , To narrow this down, could you please share: 1) Does U-Boot detect the PHY on the MDIO bus at the expected address? (e.g. output of “mdio list” / “mii info”) 2) Please share the relevant DTS snippets for the CPSW port node and the MDIO/PHY node (phy-handle, phy-mode, PHY reg/address), plus the boot log lines related to MDIO/PHY init: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" With these two items we can quickly determine whether the PHY is not visible on MDIO (HW/pinmux/reset/address) or if it’s a DT binding/reference issue. Best regards, Pavel Re: TJA1120A RGMII Auto-Ethernet We are using AM62A7 based iWave SoM, we didnt touch the u-boot/bootloader firmware residing in the eMMC as of now U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info  U-Boot firmware is something we didnt change, we just boot our Linux from SD-Card I have attached k3-am62a7-iwg55m.dtsi, where both ethernets eth0,eth1 are disabled &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; In k3-am62a7-iwg55s-prgjj-41.dts, i enabled both eth0 and eth1 with appropiate DT entries &cpsw_port1 and &cpsw3g_phy0 corresponds to our Auto-Ethernet &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; Here, my PHY TJA1120A has PHY Identification Register 1: 1B and PHY Identification Register 2: B030. So appropiate driver should be  compatible = "ethernet-phy-id001b.b030" Response for dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL I have also attached dmesg
記事全体を表示
通过 MU 安装 HSE 固件时出现 S32K3 恢复问题 我们目前正在使用 HSE 在 S32K344/S32K314 上开发安全启动功能,该功能基于 `S32K344_Advanced_SecureBoot` 演示程序,该演示程序来自 `S32K3_HSE_DemoExamples`。我们已经完成了大部分功能开发,并且可以成功进行调试。在我们的配置程序中,我们使用 ED25519 计算 BM、FBL 和 APP 的签名,将它们写入闪存中的指定地址,并为这三个应用程序配置 SMR 和 CR(BM 作为启动前 SMR,FBL 和 APP 作为启动后 SMR)。但是,我们遇到了一些不清楚的问题,希望您能提供帮助。我们目前使用的是 HSE 的FULL_MEM形式。 由于我们使用 ED25519 算法来计算所有应用程序二进制文件的签名,因此配置程序需要很长时间才能执行。如果在程序完成之前意外发生断电,我们发现 HSE 会进入不可恢复的错误状态。重启或重新刷新固件后,HSE 不再响应任何主机请求。通过检查 `0x4039C028` (HSE_CONFIG_GPR3) 处的寄存器,我们发现其值为 `0xC0`;第 0 位已变为 `0`,这表明 HSE 固件可能已被 SBAF 擦除。上电后,MU0 FSR 寄存器也为“0”。因此,我们尝试重新安装 HSE 固件。由于通常基于 IVT 的安装方法不再有效,我们尝试通过 MU 界面进行安装。 我们模拟了文档中描述的步骤,但发现将粉色图像的 SRAM 地址写入 MU Tx 寄存器(步骤 5)后,HSE_CONFIG_GPR3 中的值立即从 `0xC2` 变回 `0xC0` – 即,位 1 从 `1` 变为 `0` – 我们始终无法收到预期的成功响应 `0xDACACADA`。 我们在论坛上也提到过类似的问题: S32K3_HSE 的 MU 安装 AB_SWAP 过程不正确。我们尝试在步骤 5 之后立即执行功能 RESET,但 RESET 后仍然无法安装新的 HSE 固件。 请问如何处理和恢复这种损坏的 HSE 状态? 如果需要任何调整,请告诉我。 Re: S32K3 recovery issue when install HSE fw via MU 嗨@成金王 我无法读取您分享的项目中的源文件,因为它们已被加密。请提供包含纯文本(未加密)文件的版本。 几天前,我创建了一个 Trace32 脚本,用于通过 MU 接口恢复 HSE AB_SWAP 固件,所以我很快将其修改为 FULL_MEM 版本。我这边可以正常工作——我收到了 0xDACACADA 响应。 在输入粉色图像位置后,您是否会等待大约 1.5 秒再执行任何进一步操作?FULL_MEM 安装过程中没有明确提及此延迟,但 AB_SWAP 版本需要此延迟。这可能是问题所在。 如果你在使用 Trace32,请告诉我,我可以分享我的脚本。 此致, Lukas Re: S32K3 recovery issue when install HSE fw via MU 这是我通过 MU 安装 HSE 固件时使用的恢复程序;您能帮忙看一下哪里出了问题吗? Re: S32K3 recovery issue when install HSE fw via MU 附件是我当前使用的项目的未加密版本。我的测试中使用了 S32K344 芯片、PE 调试器和附件中的 S32DS 项目。我尝试在写入粉色图像后等待几秒钟,以接收来自 SBAF 的成功响应,但这也没有奏效。直接执行功能重置也无效。请您检查一下附件项目中我的 MU 安装程序是否存在任何问题? Re: S32K3 recovery issue when install HSE fw via MU 我在我的开发板上测试了这个项目。首先,我必须修复启动文件中的 RAM 初始化问题,因为当粉色文件复制到 RAM 时出现了硬故障。这些 HSE 演示示例中的 RAM 初始化并不理想,所以我做了如下快速修复: Pemicro 调试器会自动初始化 RAM,并且在功能复位后 RAM 内容仍会保留,因此您可能没有遇到此问题。但通电后却无法工作。我使用 Trace32 进行调试,所以一开始就看到了这个问题。 然后我修改了 IVT——我删除了指向粉色文件的指针,这样在第一次RESET后它就不会自动安装,我可以通过 MU 确认安装。 结果——我得到了 0xDACACADA,固件已通过 MU 安装。所以,这个步骤显然是正确的。 问题是为什么在你那边不起作用。 您的设备上的SBAF版本是什么?请读取 0x4039_C020 处的双字。 此致, Lukas Re: S32K3 recovery issue when install HSE fw via MU 这是我读到的结果。 Re: S32K3 recovery issue when install HSE fw via MU 此外,我们目前使用的是 HSE 固件版本 0.2.55.0。 Re: S32K3 recovery issue when install HSE fw via MU 你好, @lukaszadrapa 。这个问题我还没解决。如果您那边有任何进展,请告诉我。谢谢。 Re: S32K3 recovery issue when install HSE fw via MU 谢谢你!我通过直接触发 SWAP 请求成功恢复了 HSE 固件。然而,令我困惑的是,我一直都在使用 FULL_MEM 固件——那么为什么最终固件是通过 AB_SWAP 恢复的呢? Re: S32K3 recovery issue when install HSE fw via MU 很抱歉回复晚了。 您的 SBAF 版本为 0.15.0,与 HSE 固件 0.2.55.0 完全兼容。这没问题。 为了进行测试,我使用 HSE_SRV_ID_ERASE_FW 服务完全擦除了固件,因此被动分区中没有有效的备份。 就你的情况而言,备份似乎可用,所以流程可能有所不同(不确定为什么这样做行不通)。我从你的代码中看到,只交换功能没有实现。您能否尝试将其添加到您的代码中?这或许能解决问题。 此致, Lukas
記事全体を表示
S32DS 3.5 S32K344 freertos OsifUseSystemTimer If using FreeRTOS instead of MACL on the S32K344, can OsifUseSystemTimer be used? If so, how should the options in OsifCounterConfig be configured? If OsifUseCustomTimer is used, with Pit or STM as the timer, how should OsifCounterConfig be configured? Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer If anyone is reading this, this is not correct information. When OsIfsOperatingSystemType is set to OsIfFreeRtosType, the OsIf System Timer is disabled. Works only in baremetal mode https://community.nxp.com/t5/S32K/Microsecond-delay-outside-of-FreeRTOS-task-on-S32K344/td-p/1383622  Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer Hi @harryoceana, Sorry, I thought you meant to use System Timer without FreeRTOS. If you are using any operating system, you must use that clock instead. For example, in FreeRTOS_Toggle_Led_Example_S32K344, the OsIfFreeRtosType choice is set, and the FreeRTOS clock is used instead. Best regards, Julián Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer In FreeRTOS, the clock reference hint can only be used without an operating system. Does this have any impact? Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer Hi @harryoceana, Yes, you can use the System Timer. Please refer to this post: Solved: Delay function using OSIF - NXP Community. In the newer RTD updates, you can simply add the "Clock_Ip_ReferencePoints" component instead of the Mcu driver in the MCAL layer: Best regards, Julián
記事全体を表示
T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through CodeWarrior TAP Hello Team, We are working with a new T1040RDB board and are attempting to connect to the target through JTAG using CodeWarrior in order to load/program U-Boot onto the board. During the connection process, CodeWarrior reports the following error: "Failed to correctly configure the JTAG chain" As a result, we are unable to establish a JTAG connection with the board and proceed with loading U-Boot. It is important to note that we have previously used the same setup, including CodeWarrior and TAP, to successfully load U-Boot on other T1040RDB boards without encountering any JTAG-related issues. The issue is observed only with this new boards. Setup Details: Board: T1040RDB  Processor: T1040 Debug Probe/TAP: CodeWarrior TAP over USB Freescale Application: CodeWarrior Development Studio For PA Version: 10.5 Host OS: Windows 11 Pro Checks Performed: Verified board power-up sequence. Confirmed JTAG cable connections and orientation. Restarted CodeWarrior and power-cycled the board. Verified that the TAP/debug probe is detected by the host PC. Tried reconnecting multiple times with the same result. Verified the board switch settings and they are configured correctly. For reference, we have attached a screenshot of the current error as well as a screenshot from a previous successful session on another T1040RDB board using the same CodeWarrior and TAP setup. The previous board was able to proceed beyond the same step without any issues, whereas the new board fails with the "Failed to correctly configure the JTAG chain" error at this stage. Could you please advise on the possible cause of this issue and how to proceed further? Please assist. Best Regards, A.Maruthi QorIQ T1 Devices Re: T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through Code Probably there is no valid RCW on your target board, please choose one of the following method. 1. Please configure switch setting to set the target board as hard-coded RCW. 2. Please use CodeWarrior JTAG configuration file to override RCW. Please refer to section "8.4 Setting up a remote system to use a JTAG configuration file" in C:\Freescale\CW_PA_v10.5.1\PA\Help\PDF\Targeting_PA_Processors.pdf In addition, please open CCS console from C:\Freescale\CW_PA_v10.5.1\PA\ccs\bin\ccs.exe and type the following CCS commands to do verification. % delete all % config cc cwtap % show cc % ccs::config_chain t1040 % ccs::reset_to_debug Re: T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through Code Hello @yipingwang, Thank you for your suggestions. Regarding Point 1, we have already verified the board switch settings, and they are configured correctly while performing this process. Regarding Point 2, we referred to Section 8.4 - "Setting up a remote system to use a JTAG configuration file" in: C:\Freescale\CW_PA_v10.5.1\PA\Help\PDF\Targeting_PA_Processors.pdf As mentioned in Step 13, it instructs us to select the JTAG initialization file from: \PA\PA_Support\Initialization_Files\jtag_chains However, in our installation, this directory contains multiple JTAG initialization files (please refer to the attached screenshot). We are unsure which JTAG initialization file should be selected for the T1040RDB board. Could you please advise which JTAG initialization file is appropriate for our setup? For your reference, we have attached: The screenshot of the JTAG initialization files available under the jtag_chains directory. The screenshot of the error observed while attempting to connect to the board. Additionally, we were unable to execute the CCS commands (delete all, config cc cwtap, show cc, etc.) because we could not identify the CCS console associated with C:\Freescale\CW_PA_v10.5.1\PA\ccs\bin\ccs.exe. Could you please guide us on how to access the CCS console to run these commands? Please assist. Re: T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through Code Do you use T1040RDB with DDR3 or T1040D4RDB with DDR4? Re: T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through Code We are using the T1040RDB with DDR3 memory. Re: T1040RDB: "Failed to correctly configure the JTAG chain" while connecting through Code Please refer to the following to hard-coded RCW mode, then use CodeWarrior to connect to your target board. ON and OFF are being represented as 0 and 1 respectively, on the board. SW1[1:8] SW2[1]  0_1001_1110 (0x9E)
記事全体を表示
FRDM-A-S32M276-C064 overcurrent error on my encoder My hardware is: FRDM-A-S32M276-C064 Faulhaber 3216 BXTH BLDC 12V Encoder is IEF3 with 128L I have connected it as shown in the starting guide  https://www.nxp.com/document/guide/getting-started-with-frdm-a-s32m276-development-board-setup-and-programming:GS-FRDM-A-S32M276 I have connected the encoder directly to the pins corresponding to the enconder and I dropped (Anegated, Bnegated, Inegated). In the provided code from the application hub I've set ENCODER 1, which runs the following (in the setup part): Siul2_Port_Ip_SetInputBuffer(NULL_PTR, NULL_PTR, 1, 54, 3U); //this effectively functions as: //IP_SIUL2->IMCR[54] = SIUL2_IMCR_SSS(3U); /* Assign eMIOS0_CH7 input to TRGMUX_OUT_38 */ Siul2_Port_Ip_SetInputBuffer(NULL_PTR, NULL_PTR, 1, 55, 4U); Then Lcu_Ip_SyncOutputValueType EncLcuEnable[6U]; EncLcuEnable[0].LogicOutputId = LCU_LOGIC_OUTPUT_8; EncLcuEnable[0].Value = 1U; EncLcuEnable[1].LogicOutputId = LCU_LOGIC_OUTPUT_9; EncLcuEnable[1].Value = 1U; EncLcuEnable[2].LogicOutputId = LCU_LOGIC_OUTPUT_10; EncLcuEnable[2].Value = 1U; EncLcuEnable[3].LogicOutputId = LCU_LOGIC_OUTPUT_11; EncLcuEnable[3].Value = 1U; Lcu_Ip_SetSyncOutputEnable(EncLcuEnable, 4U); and finally AEC_VDDE_Enable(1); When I run this without the encoder connected, the application works correctly (sensorless). When I plug in the encoder and I rerun, it goes into fault immediately. Debugging I see the following: which corresponds to an overcurrent event #define AEC_AE_EVENTS_STATUS_OCD_VDDE_FL_MASK (0x8U) #define AEC_AE_EVENTS_STATUS_OCD_VDDE_FL_SHIFT (3U) How can I fix this problem? Any advice would be appreciated. Re: FRDM-A-S32M276-C064 overcurrent error on my encoder Hello @alovi, I understand that you are using VDDE to supply the encoder. However, the VDDE output current is limited. Please note that 175 mA represents the maximum overcurrent detection threshold; the minimum threshold is not specified. At the same time, the VDDE pin can continuously supply up to 30 mA at 5 V. Looking at the encoder datasheet, its current consumption can reach up to 40 mA even without load, which already exceeds the supported VDDE capability. Best regards, Daniel Re: FRDM-A-S32M276-C064 overcurrent error on my encoder Is there any other pin on the board that I can use to power the encoder or do I have to use an external source to power it? Re: FRDM-A-S32M276-C064 overcurrent error on my encoder Hi @alovi, Unfortunately, only VDDE can be used to supply external devices from the internal regulator. In this case, an external regulator is required. Regards, Daniel
記事全体を表示
How to Utilize VIT Voice Command Results from DSP in CM33 Hello, I am working with Voice Intelligent Technology (VIT) on the MIMXRT700 EVK using the "mimxrt700evk_dsp_xaf_record_cm33_core0" reference example. The VIT voice commands are being recognized on the DSP, and I would like to use the recognized command results in my CM33 application. Could you please let me know how the VIT results can be accessed from the CM33 core?  If there are any reference examples or documentation that explain the communication flow between the DSP and CM33 cores, please share them. Thanks Re: How to Utilize VIT Voice Command Results from DSP in CM33 Hi @arshtg , We have sdk demo on how to establish communication between CM core and DSP core, please kindly refer to https://github.com/nxp-mcuxpresso/mcuxsdk-examples/tree/release/26.06.00-pvw2/multicore_examples/rpmsg_lite_pingpong_dsp for details. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: How to Utilize VIT Voice Command Results from DSP in CM33 The mimxrt700evk_dsp_xaf_record_cm33_core0 example already establishes the RPMsg link between the DSP and CM33. As shown in the console logs: [DSP_Main] established RPMsg link When the VIT engine detects a wake word or a voice command, the DSP prints messages such as: [DSP VIT] - WakeWord detected 1 HEY NXP [DSP VIT] - Voice Command detected 6 STOP I would like to use these recognition results in my CM33 application. Specifically, I would like to know where these VIT detection results are generated on the DSP side and how I can access them. I also noticed that the DSP-side implementation has limited accessible source code, so I am unable to determine where the detected wake word and voice command results are obtained. Could you please point me to the relevant source files, APIs, callbacks, or documentation that describe how to obtain the detected wake word and voice command results?
記事全体を表示
TJA1120A RGMII 自动以太网 我们正在基于 TI AM62A7 的定制主板上开发 TJA1120A RGMII 自动以太网 请帮助我们了解如何在 Yocto Linux 上启用该接口。 我们按照 https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp% 2Ctja11xx.yaml 中的 DTS 节点格式进行了尝试 但驱动程序在内核 dmesg 中没有探测到 据了解,该 PHY 的供应商 ID 为 D001B:B031 我们还在内核配置CONFIG_NXP_C45_TJA11XX_PHY中启用了 CONFIG_ NXP_TJA11XX_PHY。 Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 为了缩小范围,请与我们分享一下: 1) U-Boot 是否在预期的地址检测到 MDIO 总线上的 PHY?例如“mdio 列表”/“mii info” 的输出) 2) 请分享 CPSW 端口节点和 MDIO/PHY 节点(phy-handle、phy-mode、PHY 注册/地址)的相关 DTS 片段,以及与 MDIO/PHY 初始化相关的启动日志行:dmesg | egrep-i " mdio|cpsw|phy|tja|nxp " 有了这两个项目,我们可以快速确定PHY在MDIO上是不可见的(硬件/PINMUX/RESET/地址),还是DT绑定/引用问题。 顺祝商祺! 帕维尔 Re: TJA1120A RGMII Auto-Ethernet 我们目前使用的是基于 AM62A7 的 iWave 系统模块,尚未修改 eMMC 中存储的 u-boot/引导加载程序固件。 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info U-Boot固件我们没有改动,只是从SD卡启动Linux系统。 我已附上k3-am62a7-iwg55m.dtsi文件,其中以太网接口 eth0 和 eth1 均已禁用 &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; 在 k3-am62a7-iwg55s-prgjj-41.dts 文件中,我使用相应的 DT 条目启用了 eth0 和 eth1。 &cpsw_port1 和 &cpsw3g_phy0 对应于我们的自动以太网 &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; 我的 PHY TJA1120A 的 PHY 标识寄存器 1:1B 和 PHY 标识寄存器 2:B030。 因此,合适的驱动程序应该兼容 = "ethernet-phy-id001b.b030" dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"的响应 root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL 我还附上了 dmesg 文件。
記事全体を表示
如何为 iMX95 FRDM 构建 libcamera 目前我已经克隆并能够在运行 ubuntu 20.04 的主机 PC 上构建 libcamera。提供的 README 文件没有提供任何关于所需工具链的信息。如何克服这个问题?是否有适用于 IMX95 FRDM 的 Yocto 构建源代码,以便我们能够填充 SDK 并进行相应的构建?
記事全体を表示
PN7220 Android 16 Porting to i.MX95 FRDM EVK Board Introduction Many customers are using PN7220 + Android 16 recently. In this document, I will show you how to porting the PN7220 to Android 16. I use the i.MX95 FRDM board as a reference target board. NOTE :  All the modifications are just for reference. They are NOT a NXP official patches for the newer release of AOSP porting. So the modifications may not be the best solution. Customer please base on their needs to modify the AOSP source code. This is not for production. Customer still need to perform full testing after the porting.  Hardware boards: i.MX95 FRDM Board (FRDM i.MX 95 Development Board | NXP Semiconductors) PN7220 EVK -- PNEV7220BP1 (PNEV7220BP1 Development Board for PN7220 NFC Controller | NXP Semiconductors) There is a 40pins connector on both PN7220 EVK and i.MX95 FRDM board. So PN7220 + i.MX95 FRDM connecting together is like this: Build the Android BSP for i.MX95 FRDM board: The i.MX Android BSP that I used is Android 16.0.0_1.4.0 (L6.12.49_2.2.0 BSP). It could be downloaded from here: Android OS for i.MX Applications Processors | NXP Semiconductors 1. Download the "Documentation" and the "Install Source Package".  2. Follow the steps in Android User's Guide to build the Android BSP for "evk_95" first.  $ export MY_ANDROID=`pwd` $ source build/envsetup.sh $ lunch evk_95-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt According to the android_build/.repo/manifests/aosp-android-16.0.0_1.4.0.xml, you will see the AOSP version is android-16.0.0_r4. According to the PN7220 Android 16 porting guide (PN7160/PN7220 – Android 16 porting guide), the patches is for AOSP release android-16.0.0_r2. So fortunately, the AOSP release version between them is not big different.  Now, we start the porting: 1. Kernel Driver To establish connection with the PN7220, the Android stack uses the nxpnfc kernel driver.  You could download the driver from github below: nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev · nxp-nfc-infra/nfcandroid_platform_drivers · GitHub The command is : git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev There is driver for Kernel 6.6 and 6.12. So, please download the correct one for your porting. For example, the kernel in i.MX Android BSP Android 16.0.0_1.4.0 is 6.12. So I will use the 6.12 driver for my porting. In your porting, make sure the PATH in Makefile and Kconfig files are setting properly.  For example in my porting: android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7220$ tree . ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig └── Makefile 0 directories, 7 files For simplifying everything, we will only add a support for I2C and not SPI. Replace drivers/nfc/pn7220/Makefile default code with following code (for easier understanding) nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o The contents of drivers/nfc/Makefile. Add the PN7220 like below: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7220/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o The contents of drivers/nfc/Kconfig. Add the PN7220 like below: source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" source "drivers/nfc/pn7220/Kconfig" endmenu 2. Adding the "nxpnfc" to the i.MX95 FRDM board device tree file android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts We need to check the connection between two boards and then to decide which pins to use in the device tree file. Here is the 40 pins connector on the PN7220: Here is the 40 pins connector on the i.MX95 FRDM board. According to the 40 pins connection between PN7220 EVK and the i.MX95 FRDM board, I decided to use the I2C6 and the GPIO2_20, GPIO2_21 and GPIO2_26. So, in the imx95-15x15-frdm.dts, I added: &lpi2c6 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpi2c6>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio2 26 0>; nxp,nxpnfc-ven = <&gpio2 21 0>; nxp,nxpnfc-mode_sw = <&gpio2 20 0>; }; }; And the IOMUX settings in the imx95-15x15-frdm.dts. pinctrl_nfc: nfcgrp { fsl,pins = < IMX95_PAD_GPIO_IO26__GPIO2_IO_BIT26 0x39e // IRQ IMX95_PAD_GPIO_IO21__GPIO2_IO_BIT21 0x39e // VEN IMX95_PAD_GPIO_IO20__GPIO2_IO_BIT20 0x39e // MODE_SW >; }; pinctrl_lpi2c6: lpi2c6grp { fsl,pins = < IMX95_PAD_GPIO_IO02__LPI2C6_SDA 0x40000b9e IMX95_PAD_GPIO_IO03__LPI2C6_SCL 0x40000b9e >; }; 3. Modify the imx95_gki.fragment File:  android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx95_gki.fragment Add the "CONFIG_NXP_NFC_I2C=m" into the imx95_gki.fragment 4. Add the settings in your corresponding board configuration files in Android - Go to the android_build/device/nxp/imx9/evk_95/  - Modify the BoardConfig.mk. # Add KVM support BOARD_BOOTCONFIG += androidboot.hypervisor.vm.supported=true + # ---- selinux permissive ---- + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive # -------@block_sepolicy------- BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx9/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc +include vendor/nxp/nfc/BoardConfigNfc.mk  - Add the "nxpnfc_i2c.ko" to the ShareBoardConfig.mk. Make sure the path and the filename are correct. ifeq ($(LOADABLE_KERNEL_MODULE),true) IMX_ANDROID_FIRST_STAGE_MODULES += \ $(KERNEL_OUT)/drivers/hwmon/hwmon.ko \ $(KERNEL_OUT)/drivers/hwmon/scmi-hwmon.ko \ .... .... .... $(KERNEL_OUT)/drivers/soc/imx/soc-imx9.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-adp5585.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-pca953x.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-vf610.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko .... .... BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/media/i2c/ap1302.ko \ $(KERNEL_OUT)/drivers/media/i2c/ox03c10.ko \ $(KERNEL_OUT)/drivers/media/i2c/max96717_lib.ko \ .... .... $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc-vf.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc4.ko \ $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/hwmon/pwm-fan.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko - Add the following to the compatibility_matrix.xml netutils-wrapper 1.0 android.hardware.emvco 1 IEmvco default - Add the INxpNfc and INxpEmvco to the device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.ele 1 ISecureEnclave default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default  - Add the following to the evk_95.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc2-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx - Add the nxpnfc_i2c in init.rc exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep - Add nxpnfc to ueventd.nxp.rc /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc 5. Apply the NXP AOSP patches I write a script to download the patches from the github. The script file and the android_build folder is on the same directory. Run the AOSP_adaptation.sh.  AOSP_adaptation.sh # nfcandroid_nfc_modules git clone "https://github.com/nxp-nfc-infra/nfcandroid_modules_nfc.git" cd nfcandroid_modules_nfc git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/packages/modules/Nfc cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_16_comm_infra_dev mkdir ../android_build/packages/modules/Nfc/framework cp -rf * ../android_build/packages/modules/Nfc/framework cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_16_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_16_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. Apply a patch. $ cd android_build/system/logging $ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch Add TDA Test support: # Clone repositories for test applications and TDA support # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_16_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_16_comm_infra_dev cp -rf nfc_tda/ ../android_build/packages/modules/Nfc/libnfc-nci/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/ cd .. 6. Put changes into hardwatre/interfaces/compatibility_matrices  File: hardware/interfaces/compatibility_matrices/compatibility_matrix.202504.xml android.hardware.audio.effect 1-3 IFactory default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default nxp.hardware.ele 1 ISecureEnclave default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default android.hardware.authsecret 1 IAuthSecret default 7. Add the firmware $ git clone https://github.com/NXP/nfc-NXPNFCC_FW.git $ cp -r nfc-NXPNFCC_FW/InfraFW/pn7220/64-bit-2.5/pn7220_64bits.so android_build/vendor/nxp/pn7220/firmware/lib64/libpn72xx_fw.so 8. Add the NXPAndroidDTA $git clone https://github.com/NXPNFCProject/NXPAndroidDTA.git $cd NXPAndroidDTA $git checkout br_ar_new_dta_arch cp -r NXPAndroidDTA android_build/vendor/nxp/ 9. Some fixes before build: $ cd android_build $ mv hardware/nxp/nfc/snxxx/Android.bp hardware/nxp/nfc/snxxx/_Android.bp $ mv hardware/nxp/nfc/snxxx/halimpl/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl/power-tracker/_Android.bp $ mv hardware/nxp/secure_element/snxxx/aidl/Android.bp hardware/nxp/secure_element/snxxx/aidl/_Android.bp $ cd hardware/nxp/nfc $ rm pn8x -rf Now, build the Android BSP again. Use "mm" to build the Android source code. After fixed all the errors of the AOSP build, use "imx-make.sh" to build the whole i.MX Android image.  When building the Android, there may have some errors during the build. I listed some errors and the workaround below for your reference. Error: error: packages/modules/Nfc/tests/cts/tests/Android.bp:20:1: "CtsNfcTestCases" depends on undefined module "CtsAppTestStubsShared". Workaround : Comment out "CtsAppTestStubsShared" in packages/modules/Nfc/tests/cts/tests/Android.bp Error: error: hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp:17:1: "power_tracker_v2" depends on undefined module "nfc_nci_nxp_snxxx_headers_v2". Workaround: mv hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/_Android.bp Error: error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/NfcNci/nci/jni:libnfc-nci-jni-tests which is not visible to this module You may need to add "//platform_testing" to its visibility error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/libnfc-nci/tests:libnfc-nci-tests which is not visible to this module You may need to add "//platform_testing" to its visibility Workaround: nano packages/modules/Nfc/NfcNci/nci/jni/Android.bp In cc_test {     name: "libnfc-nci-jni-tests", .. ..     visibility: [         "//platform_testing:__subpackages__",     ], Same in packages/modules/Nfc/libnfc-nci/tests/Android.bp Error: FAILED: out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system-stubs.srcjar out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_annotations.zip out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_api.txt out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_removed.txt out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:52: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.emulateNfcTechnologyATag(boolean,byte,byte,byte,byte[],byte,byte[]) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:64: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.overwriteRoutingTable(int,int,int,int,int) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:77: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_INTERNAL [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:78: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_NFC_NOT_ENABLED [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:79: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_OK [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:120: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.Callback.onRoutingChangeCompleted() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:160: error: Binary breaking change: Removed method android.nfc.RoutingStatus.getDefaultFelicaRoute() [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Comment out the lines 52,64,77,78,79,120,160 in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest Error: out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:77: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isExitFramesSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:80: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeEnabled() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:81: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:91: error: Binary breaking change: Removed method android.nfc.NfcAdapter.setPowerSavingMode(boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:196: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:197: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopPatternFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:202: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceScreenOnRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:203: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceUnlockRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:214: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceScreenOnForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:215: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceUnlockForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:248: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.NfcEventCallback.onOffHostAidSelected(String,String) [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Same as the previous workaround. Comment out the lines (error) in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest. Error: vendor/nxp/nfc/sepolicy/nfc/nfc.te:7:ERROR 'unknown type hal_emvco_service' at token ';' on line 24388: allow nfc hal_emvco_service:service_manager find; allow nfc nfc_vendor_data_file:file { create rename setattr unlink { { getattr open read ioctl lock map watch watch_reads } { open append write lock map } } }; checkpolicy:  error(s) encountered while parsing configuration Workaround: nano vendor/nxp/nfc/sepolicy/nfc/nfc.te # allow NFC process to call into the NFC HAL +type hal_emvco_service, hal_service_type, service_manager_type; +type hal_emvco_default, domain; allow nfc nfc_data_file:dir create_dir_perms; allow nfc nxpnfc_hwservice:hwservice_manager find; allow nfc nfc_vendor_data_file:dir { create_dir_perms add_name search read write create remove_name }; allow nfc nfc_vendor_data_file:file create_file_perms; allow nfc hal_emvco_service:service_manager find; allow nfc hal_emvco_default:binder call; allow nfc hal_emvco_default:binder transfer; allow nfc vendor_hal_nxpnfc_service:service_manager find; Error: FAILED: out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp if [ $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) = $(tail -1 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash') ]; then touch out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp; else cat 'system/tools/aidl/build/message_check_integrity.txt' && exit 1; fi ############################################################################### # ERROR: Modification detected of stable AIDL API file                        # ############################################################################### Above AIDL file(s) has changed, resulting in a different hash. Hash values may be checked at runtime to verify interface stability. If a device is shipped with this change by ignoring this message, it has a high risk of breaking later when a module using the interface is updated, e.g., Mainline modules. Workaround: echo $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) d9e99a62ff5ebed44083a79577ec7ed32d264775 Then,  nano hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash replace the value to d9e99a62ff5ebed44083a79577ec7ed32d264775 A runtime error: Problem: You will find the following failed about the permission in the log. java.lang.IllegalStateException: Signature|privileged permissions not in privileged permission allowlist: {com.android.nfc (/apex/com.android.nfcservices/priv-app/[email protected]😞 android.permission.OBSERVE_ROLE_HOLDERS} Workaround: Add :                 To the file : out/target/product/evk_95/system/etc/permissions/privapp-permissions-platform.xml 10. Download the image to the target board: - We use the tool UUU to download the image to the i.MX boards. Download the UUU from here : Releases · nxp-imx/mfgtools - Download the Android 16 BSP i.MX95 EVK demo image from the Android i.MX BSP web page first. There are UUU script and necessary image files already in the demo image package.  - Put the UUU executable file into the demo image folder. uuu_imx_android_flash.bat is the script also in the same folder. - After your Android BSP building is completed and succeed, copy the images to the demo image folder. The image files are located in android_build/out/target/product/evk_95/. - Switch the boot mode to "Download" mode on the i.MX95 FRDM board. - Run the UUU script to download the images to the FRDM board. uuu_imx_android_flash.bat -f imx95 -a -e -u 15x15-frdm -d 15x15-frdm Run the "TagInfo" on the board: - Download the TagInfo apk file from the NXP TagInfo App web page . - Use the "adb install" command to install the TagInfo to the FRDM board. C:\>adb install com.nxp.taginfo-6.2.0-play-release-protected.apk * daemon not running; starting now at tcp:5037 * daemon started successfully Performing Streamed Install Success After TagInfo installed, the TagInfo icon will be available on the GUI. Run the TagInfo, and then put a card on the board. The information of the card will be show on the TagInfo App. Reference: PN7160/PN7220 – Android 16 porting guide PN7220 NFC Frontend IC with Integrated Power Management | NXP Semiconductors Android OS for i.MX Applications Processors | NXP Semiconductors nxp-nfc-infra · GitHub
記事全体を表示
How to use Yocto Linux BSP - Summary page (Japanese blog) This page summarizes how to use NXP's "Yocto Linux BSP" x "i.MX" . The items are organized by category, so please refer to them. category article Development environment [Beginner's Guide] How to Build Yocto Linux BSP - i.MX FRDM Board Edition ← Start here [Beginner's Guide] How to Build Yocto Linux BSP - i.MX 8M Plus Edition ← Start here Yocto Linux BSP Building Tips - i.MX 8M Plus How to build a Linux BSP and write the generated image to the target board multimedia (General) i.MX 8M Plus EVK multimedia function operation check Introducing GoPoint, a demo repository for i.MX application processors Edge AI (Image recognition) [FRDM-IMX95] Introduction of the i.MX 95 Camera Application  [FRDM-IMX95] i.MX 95 Camera + AI - mobilenet example [FRDM-IMX95] i.MX 95 Camera + AI - YOLOv8m Example [FRDM-IMX95] i.MX 95 Camera + AI - Optimized with Multithreading [FRDM-IMX95] Installation of i.MX 95 Network Camera [FRDM-IMX95] Realization of the i.MX 95 AI Network Camera Edge AI (LLM) i.MX 95: LLM_RAG Implementation Hands-on -eIQ Gen AI Flow- security Secure Boot with i.MX 95 SPSDK i.MX 93 Processor: Explaining the Secure Boot Signature and Authentication Mechanism i.MX 93 Processor: How to Implement Secure Boot - Practical Guide Power Measurement Power measurement and low power consumption mode on i.MX EVK Cooperation with Cortex-M [Introduction] Running the i.MX 93 Cortex-M SDK Sample Code - [Part 1] Building a development environment and M core image [Introduction] Running the i.MX 93 Cortex-M SDK Sample Code - [Part 2] Running the M Core with U-Boot and remoteproc [Getting Started] Running the i.MX 93 Cortex-M SDK Sample Code - [Part 3] Automatically Starting the M Core with a Bootloader (Japanese Blog) For those who want to learn more about Yocto , our partners also offer training and support services. Lineo Solutions Co., Ltd. Yocto Concierge We will solve your Yocto development problems and concerns in various ways, such as support, training, and a Q&A site. *The Q&A site is available as Yocto BBQ (Yocto BitBake Question & answer) , so please feel free to refer to it. ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) This page summarizes how to use Yocto Linux BSP on i.MX. We have prepared a variety of content, from how to build the Yocto Linux BSP to evaluating multimedia features, power measurements, and AI evaluations. Please bookmark it! i.MX Processors SW | Downloads Japanese blog
記事全体を表示
Yocto Linux BSP 使用方法 - 概要页面(日语博客) 本页概述了如何使用 NXP 的“Yocto Linux BSP” x “i.MX” 。 物品已按类别整理,请参考这些类别。 类别 文章 开发环境 【新手指南】如何构建 Yocto Linux BSP - i.MX FRDM 开发板版← 从这里开始 【新手指南】如何构建 Yocto Linux BSP - i.MX 8M Plus 版← 从这里开始 Yocto Linux BSP 构建技巧 - i.MX 8M Plus 如何构建 Linux BSP 并将生成的镜像写入目标板 多媒体 (一般的) i.MX 8M Plus EVK 多媒体功能操作检查 隆重推出 GoPoint,一个用于 i.MX 应用处理器的演示存储库 边缘人工智能 (图像识别) [FRDM-IMX95] i.MX 95 相机应用简介  [FRDM-IMX95] i.MX 95 相机 + AI - mobilenet 示例 [FRDM-IMX95] i.MX 95 相机 + AI - YOLOv8m 示例 [FRDM-IMX95] i.MX 95 摄像头 + AI - 多线程优化 [FRDM-IMX95] i.MX 95 网络摄像机的安装 [FRDM-IMX95] i.MX 95 AI 网络摄像机的实现 边缘人工智能 (法学硕士) i.MX 95:LLM_RAG 实现实战 -eIQ Gen AI 流程- 安全 使用 i.MX 95 SPSDK 进行安全启动 i.MX 93 处理器:安全启动签名和认证机制详解 i.MX 93 处理器:如何实现安全启动 - 实用指南 功率测量 i.MX EVK 的功率测量和低功耗模式 与Cortex-M的合作 【简介】运行 i.MX 93 Cortex-M SDK 示例代码 - 【第一部分】构建开发环境和 M 内核镜像 【简介】运行 i.MX 93 Cortex-M SDK 示例代码 - 【第二部分】使用 U-Boot 和 remoteproc 运行 M 内核 【入门指南】运行 i.MX 93 Cortex-M SDK 示例代码 - 【第 3 部分】使用引导加载程序自动启动 M 内核(日语博客) 对于那些想要了解更多关于 Yocto 的信息的人,我们的合作伙伴也提供培训和支持服务。 Lineo Solutions Co., Ltd. Yocto礼宾服务 我们将通过各种方式解决您在 Yocto 开发方面遇到的问题和疑虑,例如提供支持、培训和问答网站。 *问答网站名为Yocto BBQ(Yocto BitBake 问答) ,欢迎随时访问。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接询问负责人。) 本页概述了如何在 i.MX 上使用 Yocto Linux BSP。 我们准备了各种内容,从如何构建 Yocto Linux BSP 到评估多媒体功能、功耗测量和 AI 评估。 请收藏! i.MX处理器 SW | 下载 日本博客
記事全体を表示
Yocto Linux BSPの利用方法 ~まとめページ~ (日本語ブログ) NXPの「Yocto Linux BSP」 x 「i.MX」の利用方法 をまとめたページです。 カテゴリ毎にまとめておりますので、是非ご参考ください。 カテゴリ 記事 開発環境 [入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 ←先ずはここから [入門] Yocto Linux BSPのビルド方法 - i.MX 8M Plus編←先ずはここから Yocto Linux BSPのビルド時におけるTIPS集 - i.MX 8M Plus編 Linux BSPをビルドして生成したイメージをターゲットボードに書き込む方法 マルチメディア (全般) i.MX 8M Plus EVKのマルチメディア機能の動作確認 i.MXアプリケーション・プロセッサ用デモ・リポジトリ GoPointの紹介 エッジAI (画像認識) [FRDM-IMX95] i.MX 95 カメラアプリケーションの導入     [FRDM-IMX95] i.MX 95 カメラ+AI - mobilenetの例 [FRDM-IMX95] i.MX 95 カメラ+AI - YOLOv8mの例 [FRDM-IMX95] i.MX 95 カメラ+AI - マルチスレッドによる最適化 [FRDM-IMX95] i.MX 95 ネットワークカメラの導入 [FRDM-IMX95] i.MX 95 AIネットワークカメラの実現 エッジAI (LLM) i.MX 95: LLM_RAG実装ハンズオン-eIQ Gen AI Flow- セキュリティ i.MX 95 SPSDK によるセキュアブート i.MX 93プロセッサ: セキュアブートの署名と認証の仕組みを解説 i.MX 93プロセッサ: セキュアブートの実装方法 - 実践編 電力測定 i.MX EVKで電力測定と低消費電力モード Cortex-Mとの連携 [入門] i.MX 93のCortex-M SDKサンプルコードの実行 -【第1回】開発環境構築とMコアイメージのビルド [入門]i.MX 93のCortex-M SDKサンプルコードの実行 -【第2回】 U-BootとremoteprocによるMコア実行 [入門] i.MX 93のCortex-M SDKサンプルコードの実行 -【第3回】ブートローダーによるMコアの自動起動(日本語ブログ) 「Yoctoをもっと深く知りたい!」という方には、パートナー様からも、トレーニングやサポートのサービスを提供しております。 リネオソリューションズ株式会社 Yocto コンシェルジュ お客様の Yocto 開発や悩み事を、サポート、トレーニング、*Q&A サイトなど様々な形で解決します。 *Q&Aサイトは、Yocto BBQ (Yocto BitBake Question & answer)として公開されていますので、是非ご参考ください。 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) Yocto Linux BSPをi.MX上で利用する方法 をまとめたページです。 Yocto Linux BSPのビルド方法から、マルチメディア機能の評価、電力測定、AI評価など、様々なコンテンツを準備しています。 是非ブックマークを! i.MX Processors SW | Downloads 日本語ブログ
記事全体を表示
デジタル信号の電圧変換ってどうやればいいの? (日本語ブログ) 0. 目次 0. 目次 1. 電圧レベル・トランスレータって? 2. デジタル信号 2.1 様々なデジタル信号 2.2 CMOSとTTL:単純な電圧のHIGHとLOWによる論理レベルの信号 2.3 入出力電圧の規定:VOH / VOL と VIH / VIL 2.3.1 出力電圧の規定:VOHとVOL 2.3.2 入力電圧の規定:VIHとVIL 2.3.3 VOH / VOL と VIH / VIL の関係 3. 基本的な電圧レベル変換の方法:片方向信号の変換 3.1 チップの電源電圧が違っても変換の必要がない例 コラム:TTLのVIH(min) = 2.0V,VIL(max) = 0.8Vはどうやって決まっている? 3.2 変換が必要な例 3.2.1 オープンドレイン出力による変換 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 4. 自動方向切り替えが必要な双方向信号の変換 4.1 単体MOSトランジスタによる双方向変換 4.2 専用品による双方向変換 4.2.1 I²C信号電圧変換チップ 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 4.2.3 双方向プッシュプル信号電圧変換チップ 4.2.4 I3C信号電圧変換チップ 4.2.5 バッファによる変換 5. まとめ 5.1 ブログ内で紹介した方式/品番の比較 6. 参考資料 1. 電圧レベル・トランスレータって? デジタル回路同士をつなぐとき,単純に信号線を直結すればいい… ということはなくて,「論理レベルの電圧」が合わないと,動作しなかったり,不安定になったり,最悪の場合チップを壊してしまうことがあります. そんなときに便利に使えるのが電圧レベル・トランスレータ(Voltage Level Translator.電圧レベル・シフタとも呼ぶ)です. 電圧レベル・トランスレータは,異なる電源電圧のデジタル回路間で信号をやり取りできるようにする回路です. 例えば,次のようなケースで必要になります. 3.3V マイコン ↔︎ 5V センサ の接続 1.8V FPGA ↔︎ 3.3V 周辺デバイス の接続 図1:信号電圧の違い   このブログでは,デジタル回路で使われる論理回路の種類(*TTL,*LVTTL,*CMOS)の電圧レベルの違いから,それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します.さらに様々な変換の方法の中から,どのような電圧レベル・トランスレータを選べばよいかを解説します. さらにこのブログでは信号の方向を自動で検出して変換を行う電圧レベル・トランスレータの具体例を見ていきます. NXPではSDカード/SIMカード向けや,*GTL↔︎TTLレベル変換のような特定用途向け電圧レベル・トランスレータもラインナップしていますが,このブログは汎用またはシリアル・バス用途をターゲットにした製品の解説となります. *TTL(Transistor-Transistor Logic) *LVTTL(Low Voltage Transistor-Transistor Logic) *CMOS(Complementary Metal-Oxide-Semiconductor) *GTL(Gunning Transceiver Logic) 2. デジタル信号   2.1 様々なデジタル信号 いわゆる「デジタル信号」は論理レベルの1と0を電気的に表現したものです.この論理レベルの1と0を扱う回路設計方法には歴史的に様々なものがあります.論理レベルを単純な電圧のHIGHとLOWで表現するものや,電圧の差を利用してHIGH/LOWを表現するものなど. 単純なHIGH/LOWを5V/0Vで表すTTL.さらにそのTTLを低電圧化し3.3V/0Vで表すLVTTLなどバイポーラ・トランジスタ回路を基準に電圧レベルが決められたもの. 同様にバイポーラ・トランジスタを使いながらも負電源を使い低振幅で差動で動作論理レベルを実装し,高速化が図られたECL.基準電圧を設けて低振幅のシングルエンド信号でHIGH/LOWを伝達するGTLなど... また単純なHIGH/LOWでの表現でも低消費電力化を目的に開発された4000シリーズと呼ばれるCMOS汎用ロジックでは,HIGHレベルとして3V〜18Vを使うことができました. https://en.wikipedia.org/wiki/Logic_family このブログでは,上記のような様々な論理レベルの中でも,単純なHIGHとLOWの電圧で論理を表現するTTL(LVTTL)とCMOSの電圧レベルの扱いについて解説します. その他の信号変換には専用チップが用いられるため,ここでは扱いません. このほか近年では半導体技術の微細化・高速化・低消費電力化が進むとともに,電源に使われる電圧は低くなってきています.このため信号電圧差を橋渡しする電圧レベル・トランスレータは特に重要になってきています. 図2:信号波形 - 電圧の高低(HIGH/LOW)で論理レベルを表す   2.2 CMOSとTTL:単純な電圧のHIGHとLOWによる論理レベルの信号 デジタル回路に使われる単純な電圧のHIGHとLOWによる論理レベルの信号には,HIGHを電源電圧で,LOWを0Vとするものが一般的です.電源電圧が異なってもHIGH/LOWの電圧レベルが同じであれば,そのまま信号をやり取りすることができます. たとえばTTL(LVTTL)は入力される信号が2.0V以上であればHIGH,0.8V以下であればLOWと解釈します.このような取り決めがあるため,TTL信号であれば互いに電源電圧が異なってもHIGH/LOWの電圧レベルは変わりません. いっぽう,CMOSは電源電圧の半分の電圧を基準にしてHIGH/LOWを定義します.このためCMOSは電源電圧が異なるとHIGH/LOWの電圧レベルも変わります. 図3:入力信号電圧の規定   2.3 入出力電圧の規定:V OH  / V OL  と V IH  / V IL デジタル回路ではHIGHとLOWとして出力される電圧と,入力される信号をHIGHとLOWに判断する電圧が規定されています.これらは使用する各チップの仕様で規定されているため,データシートで確認する必要があります. V OH  : HIGHレベル出力電圧 (HIGH-level output voltage) V OL  : LOWレベル出力電圧 (LOW-level output voltage) V IH  : HIGHレベル入力電圧 (HIGH-level input voltage) V IL  : LOWレベル入力電圧 (LOW-level input voltage) 2.3.1 出力電圧の規定:V OH とV OL 出力ではHIGH/LOWを出力する際の電流を考えておかねばなりません.電流は負荷により増減します. HIGH出力での最大流出電流時に保証できる電圧をV OH (min),LOW出力での最大流入電流時に保証できる電圧をV OL (max)と呼びます. V OH (min)は回路出力段の上側のトランジスタがONになったときに出力される電圧です.このトランジスタには「ON抵抗」と呼ばれる抵抗分があります. トランジスタから流れ出る電流が大きい場合,"トランジスタの抵抗分 x そこに流れる電流"で電圧が発生.すると出力はその電圧分だけ電源電圧から下がってしまいV OH が低くなってしまいます.このため,あらかじめ想定される最大流出電流のときに保証できる最小の電圧がV OH (min)となります. 図4:デジタル信号出力回路(プッシュプル)   図5:HIGH出力電圧は負荷によって変化する   V OL はこの逆となります.回路出力段の下側のトランジスタがONになったとき,流れ込む電流が大きいと,上記と同様にトランジスタのON抵抗によって発生する電圧によって,出力は0Vより上がってしまいます.これを考慮し,あらかじめ想定される最大流入電流のときに保証できる最大の電圧がV OL (max)となります. 図6:LOW出力電圧も負荷によって変化する   2.3.2 入力電圧の規定:V IH とV IL 入力にはHIGHとLOWを判断するための電圧レベルがあります.V IH (min)とV IL (max)です.電圧がV IH (min)以上であればHIGHと判断され,V IL (max)以下であればLOWと判断されます. CMOS入力では電源電圧の1/2がHIGHとLOWの基準となりますが,これをそのままV IH (min)とV IL (max)とはしていません.これはチップごとのバラツキなどによって閾値が上下するためです.また,遅く立ち上がる信号に乗ったノイズなどによるグリッチが出力に現れることを軽減するため,入力にはヒステリシスを持たせることが一般的です.このような理由によりV IH (min)とV IL (max)はある程度の電圧差を設けて規定されます. 2.3.3 V OH  / V OL  と V IH  / V IL  の関係 正常な信号のやり取りを行うには,出力と入力の関係は下式を満たす必要があります. HIGHレベル: V OH (min) > V IH (min) LOWレベル: V OL (max) < V IL (max) この関係が守られていれば,出力側の回路は,次の入力側の回路に対してHIGH/LOWを正しく伝えることができます.さらにこの互いの電圧差である「V OH (min) - V IH (min)」や「V IL (max) - V OL (max)」は「ノイズ・マージン」となり,ノイズ耐性を高く保つための目安になります. 図7:V OH (min) / V OL (max) と V IH (min) / V IL (max) 3. 基本的な電圧レベル変換の方法:片方向信号の変換   3.1 チップの電源電圧が違っても変換の必要がない例 『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立つ場合には基本的には電圧レベル変換は必要ありません.たとえばTTLとLVTTLはそれぞれのチップに使われる電源電圧は違うものの,入出力電圧の規定は同一です. TTL(5V)とLVTTL(3.3V)ではどちらも,V OH (min)は2.4V,V OL (max)は0.4Vです.V IH (min)/V IL (max)も,どちらも2.0V/0.8Vなので問題なく互いに接続できます. ただし出力電圧が入力側チップの電源電圧よりも高い場合には注意が必要です.出力側が5V,入力側が3.3V電源を使うチップである場合には,入力側は「5Vトレラント入力」に対応していなければなりません. 5Vトレラント入力とは,5VのHIGH信号を3.3Vの電源電圧で動作するチップの入力に接続しても問題なく動作する入力のことです.一般的なチップの入力には静電気対策のためのESD保護回路が入っていますが,このESD保護回路が次の図のような回路で構成されていると5Vを入力した際に入力から3.3Vの電源に電流が逆流してしまい,チップを破壊してしまうことがあります.このような問題を起こさないための対策が取られた入力が5Vトレラント入力です.トレラント入力にはESD保護がないわけではなく,電源電圧より高い信号が入力されても問題がないような構造を持つESD保護回路が組み込まれています. 図7のようなESD保護ダイオードは,入力側チップの電源が切られている時にも問題を引き起こします.チップごとに個別に電源のON/OFF管理を行うようなシステムの場合,入力側チップがOFFになっているにも関わらず出力側の信号が電源に回り込み,入力側チップを動作させてしまうことがあります. 図7:ESD保護ダイオード - 非トレラント入力 コラム:TTLのV IH (min) = 2.0V,V IL (max) = 0.8Vはどうやって決まっている? CMOSの入力閾値が電源電圧の中点(VCC/2)を基準にしているのに対し,TTLのV IH (min)/V IL (max)は2.0V/0.8Vという,電源電圧(5V)に対して特に綺麗な比率ではない値になっています.これには,TTLの入力段がバイポーラ・トランジスタで構成されていることが関係しています. 標準TTLロジックIC:SN7400(2入力NAND)の内部回路例 『最新汎用ロジック・デバイス規格表 1988』(CQ出版)に掲載されていたもの 標準的なTTLゲートの入力段は,多重エミッタの入力トランジスタと,その後段のフェーズスプリッタ・トランジスタが直列に重なった構造をしています.ゲートが実際に反応し始める「スイッチング・スレッショルド」は,この2段に重なったPN接合の順方向電圧で決まります.シリコンのPN接合1個あたりの順方向電圧はおよそ0.6〜0.7Vなので,2段重なると合計でおよそ1.3〜1.5V付近がTTLゲートの実質的なスイッチング・スレッショルドとなります. ただしこの約1.4Vという値はあくまで「典型値(typical)」であり,個体差や温度などのバラツキによってロットごと・条件ごとに変動します.そこでデータシート上の規定値であるV IH (min)とV IL (max)は,この約1.4Vの典型値に対して上下に十分なマージンを取り,「ここまで下がれば確実にLOWと判定できる(V IL (max)=0.8V)」「ここまで上がれば確実にHIGHと判定できる(V IH (min)=2.0V)」という,保証値として規定されています. さらにこの値は単独で決められているわけではなく,2.3.3節で説明したV OH /V OL との関係も踏まえて設計されています.標準TTLでは出力段の構成により,HIGH出力は電源電圧にはならず,少し低い(上記回路例では130Ωの抵抗,トランジスタとダイオードで発生する電圧分だけ低い)電圧になります(VOH(min)=2.4V).これとVOL(max)=0.4Vを組み合わせると, HIGH側ノイズ・マージン:V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V LOW側ノイズ・マージン:V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V のように,上下対称に0.4Vのノイズ・マージンが確保されるよう設計されています.つまりTTLの2.0V/0.8Vという「電源電圧に対して半端」に見える数字は,バイポーラ・トランジスタの接合電圧という物理的な実体と,ノイズ・マージン設計という2つの要請から導かれた,合理的な値だったということになります. SN7420(4入力NAND)の入力ピン3つをHIGH,1つに100kHzの三角波を入力(ch1)した様子 無負荷状態の出力(ch2)だがHIGHのとき4V未満の出力となっている(Vcc=5V) なお,本コラムで紹介した回路は無印(74LS00や74HC00のようにLS/HCなどの付かないもの.英語では“バニラTTL”と呼ばれることもある)標準TTLの例ですが,V IH /V IL の規定が同じ理由(入力段のバイポーラ接合特性)は74LSなど他のTTLファミリにも共通しています.   3.2 変換が必要な例   TTLやLVTTLでは電圧レベルが揃っているため上記のような接続が可能ですが,電源電圧の違うCMOSチップ同士や,CMOSとTTLチップの接続では論理レベルが合わない場合が多く発生します.前述の『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立たない,またはその差が小さくなってしまい,ノイズ・マージンが取れないような状況がそれにあたります. この問題を解決するのが電圧レベル・トランスレータです. 図9:論理レベルが合わない例(1):充分なHIGH電圧が入力されない   図10:論理レベルが合わない例(2):充分なLOW電圧が入力されない     3.2.1 オープンドレイン出力による変換 電圧レベル変換チップを用いなくても,簡単に電圧レベル合わせを行う方法はあります. 信号の方向が出力側チップ→入力側チップで固定され切り替わることがないのなら.HIGH側の出力をオープンドレイン出力にすることで,入力側の電圧に合わせる方法です.オープンドレインはデジタル回路の出力段の上側のトランジスタがない構成のもので,入力側チップの電源電圧に接続されたプルアップ抵抗によってHIGHの電圧を得ます. 図11:デジタル信号出力回路(オープンドレイン)   オープンドレインは単純で安価な方法ですが,いくつかの注意点があります. まず出力側がオープンドレイン出力が可能なものである必要があります.多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です. まず出力側がオープンドレイン出力が可能なものである必要があります.多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です.もしオープンドレイン出力に設定できないプッシュプル出力固定など場合には,外付けのトランジスタなどを使ってオープンドレイン出力に変換する必要があります. さらにプルアップ抵抗の選択も重要です. プルアップはHIGHの電圧を得るために必要な抵抗ですが,抵抗値が小さすぎるとLOW出力時に流れる電流が大きく(負荷が大きい状態に)なり,消費電力が増える上にV OL の上昇を招いてしまいます. 逆に大きすぎると配線とピンによる容量の影響を受け,LOWからHIGHへの立ち上がりが遅くなってしまい,通信速度の低下が起こります. 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 単純な電圧レベル変換であれば標準ロジックを用いる方法もあります.たとえばNexperia社の74AVCH4T245は4ビットの双方向レベル変換を行うことができるCMOS汎用ロジックチップです. このチップでは0.8V〜3.6Vの信号を変換することができ,信号の方向をDIRピンによって切り替えることもできます.信号速度は変換を行う電圧にも依存しますが,100M〜380Mbps程度に対応可能です. 図12:標準ロジックの例 - 74AVCH4T245 このチップを用いると高速な信号の双方向電圧変換が可能ですが,方向の制御は外部からの信号によって行わなければなりません.このような制御はパラレル・バスのREAD/WRITEのような信号によって可能ですが,プロトコルによって通信方向が切り替わるシリアル・バスのような通信には適用が困難です. 図13:標準ロジックの例.信号の方向を外部から指定しなくてはならない 4. 自動方向切り替えが必要な双方向信号の変換 これまでに紹介した"オープンドレイン出力"や"標準ロジックチップを用いた電圧変換方法"では,主に一方向のみの変換を行うもの,あるいは外部信号による方向の切り替えが必要なものでした. I²C,I3Cのような信号の方向がダイナミックに変化するような通信には,方向が自動で検出して切り替わる「双方向の電圧レベル変換」が必要です.このような信号の方向を外部から制御するのは難しく,前述のようなバッファ・チップで実現するのは困難です. さらにI²Cはオープンドレイン信号であるため,オープンドレインの標準ロジック・バッファを互いに違う向きに接続するようなことができません.図14はその例です.オープンドレイン・バッファを互いに反対方向に接続しています.バッファの両側がHIGHの時は問題ありませんが,どちらかが一旦LOWになると,バッファは互いの入力をLOWに引っ張ったままとなり,HIGHに戻すことができなくなります. 図14:通常のオープンドレイン・バッファでは双方向通信を自動切替できない   4.1 単体MOSトランジスタによる双方向変換   これまでI²Cの信号電圧変換には,単純な回路が用いられることがありました.その最も簡単なMOSトランジスタを使った方法をその例として挙げます. 図15:MOSトランジスタを使った変換の例   図15はI²Cの仕様書version2.1(2000年)から引用したもので,3.3Vと5Vの信号を2本の信号にそれぞれ1個のMOSトランジスタ(TR1, TR2)を用いる例です.このような単純なトランジスタ単体での変換例は,後述する問題点があるため現在のI²Cの仕様書からは削除されていますが,原理を理解するために紹介します. SDAとSCLと呼ばれるI²Cの信号線は,どちらもオープンドレイン出力の双方向信号となっています.3.3V側と5V側にそれぞれプルアップ抵抗が接続されています. この回路では3.3V側,5V側の信号がHIGHである場合,このトランジスタのゲート(g)とソース(s)間は同電位となるため,ソース(s)とドレイン(d)OFF状態となって互いの接続が切れた状態に置かれます.この状態で3.3VがLOWに変化すると,3.3V側のトランジスタ(のsとdの間)がONになり,5V側の信号もLOWになります. 3.3V側がHIGHで5V側がLOWに変化した場合には,まず3.3V側から5V側への寄生ダイオード(ボディ・ダイオード)がONになります.ダイオードがONになるとソース(s)の電圧が降下.その結果トランジスタがONになり,3.3V側の信号もLOWになります. このようにトランジスタをスイッチとして使う非常に単純な仕組みで電圧レベル変換ができるのですが,ここには問題もあります.トランジスタのバラツキが信号変換の閾値に影響すること.さらに今日ではより低い信号電圧を扱うことが増えてきており,たとえば信号電圧が1V程度では,このような回路では十分なゲート(g)とソース(s)間電圧(Vgs)が得られないため動作させることができません. 4.2 専用品による双方向変換   「電圧レベル・トランスレータ専用IC」を用いることで,I²C, I3Cのような双方向通信を行うバスの電圧レベル変換を容易に行うことができます. 4.2.1 I²C信号電圧変換チップ PCA9306,NVT20xxシリーズ(NVT2001/02, NVT2003/06, NVT2008/10)は双方向信号の変換に特化した電圧レベル・トランスレータです.これらのチップでは複数の信号線(複数ビットの信号線)をまとめて扱うことができます.これらはI²C信号の電圧変換チップとされていますが,信号の仕様が合えば他の目的(SPIやその他のプッシュプル信号など)にも使うことができます. PCA9306,NVT20xxシリーズは同じ内部構造を持ち,プルアップ抵抗は,変換する電圧差が1V以上であれば電圧の高い側だけに接続すれば良いようになっています. 図16はその内部構造と外部チップの接続を示したものです(アプリケーションノートAN11127:「Bidirectional voltage level translators NVT20xx and PCA9306」のFig.2から抜粋).このチップ内部には信号線数(ビット数)+1個のMOSトランジスタが内蔵されています.各トランジスタはソースとドレインが可換の構造となっています. 信号を伝達するための経路のトランジスタはパス・トランジスタと呼ばれ,残りの1個はリファレンス・トランジスタと呼ばれます. 図16:NVT20xx(PCA9306) - チップ動作の解説図   回路を見てみると,リファレンス・トランジスタのゲートとドレイン間はショートされており,200kΩの抵抗を介して高い電圧側の電源に接続されています.リファレンス・トランジスタの残りの端子:ソースは低電圧側の電源に接続されています.このような接続により,リファレンス・トランジスタは1個のダイオードとなっており,このゲート電圧は低電圧側の電源よりもダイオード1個分高い電圧となります. 残りのパス・トランジスタはドレイン側が高い電圧側の信号線と1kΩのプルアップ抵抗に,ソース側は低い電圧側の信号線,さらにゲートはリファレンス・トランジスタのゲートに接続されています.パス・トランジスタの高い側,低い側の信号がどちらもHIGHになっている時,高い側は1kΩによってプルアップされた電圧となります. パス・トランジスタはいわゆる「ソースフォロワ」と呼ばれる回路を構成しています.低い電圧側の端子(ソース端子)は,ゲートに印加されている電圧よりトランジスタをONにするために必要なVgs分だけ低い電圧が現れます.つまり低電圧側の電源と同じ電圧となります.トランジスタはONでもOFFでもない半分ONの状態(線形領域での動作)になっています. この状態で,高または低のどちら側かの信号がLOWになると,ゲートと信号端子の電圧差によりトランジスタがON(完全にONとなった飽和領域での動作)になり,反対側の端子もLOWになります. このシリーズで扱える信号速度は,プルアップと信号線の容量の影響を受けます.データシートでは,PCA9306は2MHzまで.NVT20xxシリーズでは192Ωのプルアップ抵抗を使用し,容量50pFの条件で最大33MHzまでの信号速度に対応可能とされています.1MHz程度の信号であれば,プルアップ抵抗や容量をあまり気にしなくても(通常I²Cで使うような範囲内を想定)で問題なく動作します.しかしこのチップをプッシュプルのより高速な信号を扱う場合には特製の把握と慎重な部品選択が必要になります. このタイプの電圧レベル・トランスレータ動作の詳細は,「PCA9306の中身と動作」の記事で紹介されています. 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 高速化を図った双方向オープンドレイン信号変換チップとして,NTS030xシリーズ(NTS0302JK, NTS0304E)を紹介します. このチップは2ビットまたは4ビットの双方向信号変換を行うことができ,オープンドレイン信号であれば2Mbps(1MHz),プッシュプル信号であれば20Mbps(10MHz)の信号に対応可能です.   図17:NTS030x - チップ内部ブロック図   図17はNTS030xの信号1ビット分の内部構造です. 図ではT3のトランジスタがパス・トランジスタとなっており,ゲート端子バイアス電圧がかけられているので,AとBと書かれた信号のどちらかがLOWとなった時にONとなります. AとBの両方がHIGHの時はT3がOFFになり,AとBはそれぞれの電源に比較的大きいプルアップ抵抗(10kΩ)で接続されているのでそれぞれの電圧となります. このチップにはT3のほかにT1とT2が存在しています.このT1とT2は「エッジレート・アクセラレータ」と呼ぶ機能のために使われます.このうちの片方,T1に注目しこの動作を解説します. T1はA側に置かれ,ソース端子はA信号に,ドレイン端子はA側電源に接続されています.ゲート端子はこれを制御する「ONE-SHOT AND SLEW RATE CONTROL」と書かれたブロックに接続されています. 「ONE-SHOT AND SLEW RATE CONTROL」ブロックは反対側のB信号に接続されていて,B側の信号のLOWからHIGHへの変化を検出.これを検出した時に一時的にT1をONにして,プルアップの10kΩ抵抗をバイパスして電流を流す事により,A側の信号のHIGHへの変化を加速します.このように信号の立ち上がりを速くすることで,より高速な信号を扱うことができるようにしています. ちなみに,このT1をONにする際のスルーレートは制御されていて,急な電流増加によるリンギング発生を抑えることも考慮されています. もういっぽうのT2はこの同じ仕組みが逆方向に作られており,B側信号にも適用されるようになっています. このNTSシリーズにはもう一つの使いやすい点があります. ここまで説明したMOSトランジスタ単体やPCA9306/NVT20xxの場合,どちらかの電源がOFFになった場合,他方の信号をLOWにしてしまうという問題がありました.NTS030xではこの問題を解決するために,両方の電源がONになっていない場合は,互いに影響が出ないように信号ピンをハイ・インピーダンス状態とするよう動作します.このような機能を使うことにより,システムの電源を部分的にON/OFF制御するような使い方が可能になります. NTS030xシリーズと同等品で,より高速の信号に対応するためスルーレート制御機能の無いNTS010xシリーズ(NTS0102, NTS0104)も用意されています. なお,NTS0304Eには,すぐに簡単な動作検証ができるように評価基板:NTS0304EUK-ARDが用意されています.NTS0304EUK-ARD基板の概要と動かし方はこちらの動画「NTS0304EUK-ARDの動かし方」をご参考ください. 4.2.3 双方向プッシュプル信号電圧変換チップ さらにこのNTS030xシリーズをプッシュプル信号だけで使う場合のより高速なオプションとしてNTB010xシリーズ(NTB0102, NTB0104)があります. HIGHまたはLOWで安定した状態では4kΩを通して信号を駆動.NTS030xシリーズ同様のワンショット機能をHIGHとLOW側の両側に持たせ,いずれかの端子で信号の変化があった場合にこれを用いて,反対側信号を変化させる機構を持っています. このような機構により,信号方向の自動検出機能を持ちながら70〜80Mbpsの速度の信号電圧変換が可能です.   図17:NTB010x - チップ内部ブロック図 4.2.4 I3C信号電圧変換チップ I3Cはオープンドレインとプッシュプルを切り替えながら通信を行う仕様を持ち,オープンドレインではI²Cと互換〜4MHzの周波数.プッシュプル時は12.5MHzのクロックが使われます.信号の電圧は通常1V〜3.3Vの範囲で使われるため,電圧差がある場合には,信号仕様に合わせた動作をする電圧レベル・トランスレータが必要になります. 図18はP3A1604の1ビット分の内部ブロック図です.このチップでは図の通り,LOW→HIGHだけでなくHIGH→LOWの変化を加速する仕組みとON/OFFの切り替えができるプルアップ抵抗が内蔵されています.   図18:P3A1604 - チップ内部ブロック図 P3A1604は4ビット用のI3C電圧レベル・トランスレータ.この他にも2ビット用のP3A9606も用意されています.   4.2.5 バッファによる変換 もう一つの双方向信号の変換方法として,専用品のバッファを使う方法があります. バッファの本来の目的は,駆動能力の増強や接続している信号線の容量の分離などですが,電圧の変換に対応した製品も存在します. 双方向のオープンドレイン信号を相互にバッファするには,このブログの中で説明したように単純なバッファでは実現できません.そのため双方向オープンドレイン信号用として様々な工夫がされたバッファ製品が用意されています. バッファについての詳細はまた次の機会に解説する予定です. 5. まとめ 電圧レベル・トランスレータは,異なる電源電圧を持つデジタル回路間で安全かつ確実に信号をやり取りするために不可欠な部品です.TTLやLVTTL,CMOSなど論理レベルの規定や,VOH/VOL/VIH/VILの関係を理解することで,適切な接続や変換方法を選択できます. 片方向の変換にはオープンドレイン出力や標準ロジックIC,双方向の変換にはMOSトランジスタや専用IC(PCA9306/NVT/NTS/NTB/P3Aシリーズなど)が利用できます. 特にI²CやI3Cなど双方向通信が必要なバスでは,信号方向の自動検出機能を持つ電圧レベル・トランスレータが有効です. また,近年の半導体技術の進化により,低電圧化・高速化が進み,より厳密な電圧レベル管理が求められるようになっています.電圧レベル変換の方法や選択肢は多岐にわたりますが,信号仕様や速度,システムの電源管理など用途に応じて最適な方法・部品を選ぶことが重要です. 5.1 ブログ内で紹介した方式/品番の比較 方式/品番 用途 ビット数 方向切替 オープンドレイン対応 低電圧側[V] 高電圧側[V] ビットレート[bps] オープンドレイン出力での変換 汎用 1 片方向 - - - - 標準ロジック(例:74AVCH4T245) 汎用(パラレルバスなど) 4 + 4 外部制御 非対応 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M 単体MOSトランジスタによる双方向変換 I²C, 汎用 1 自動 対応 トランジスタの仕様による ~ 1M PCA9306 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz.条件による) NVT2001 I²C, 汎用 1 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2002 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2003 I²C, 汎用 3 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2006 I²C, 汎用 6 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2008 I²C, 汎用 8 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2010 I²C, 汎用 10 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NTS0302JK I²C, SPI, 汎用 2 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0304E I²C, SPI, 汎用 4 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0102 I²C, SPI, 汎用 2 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTS0104 I²C, SPI, 汎用 4 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTB0102 SPI, 汎用 2 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, 汎用 4 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, 汎用 2 自動 対応 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, 汎用 4 自動 対応 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @オープンドレイン, 40M @プッシュプル 表1:ブログ内で紹介した方式/品番の比較   6. 参考資料 製品紹介ページ:電圧レベル変換器 NXP システム・マネジメントI2C, I3C, SPIセレクタ・ガイド I2C バス仕様およびユーザーマニュアル (Rev5.0 日本語版) I2C バス仕様およびユーザーマニュアル (Rev7.0 英語版) NXPコミュニティ・ブログ:I3Cバスの概要 ~次のシリアルバス~ 日本語ウェビナー動画:『【今知っておくべき】次世代インターフェース「I3C」の基礎』  Qiita @teddokano:PCA9306の中身と動作 変更履歴: 2025-08-28:初版 2025-08-28:NTS0304EUK-ARDの紹介と動画公開ブログへのリンクを追記 2026-04-10:表1の低電圧側[V],高電圧側[V]の訂正 2026-06-20:第3.1節「コラム:TTLのVIH(min) = 2.0V,VIL(max) = 0.8Vはどうやって決まっている?」を追加.標準TTLロジックIC:SN7400(2入力NAND)の内部回路例,SN7420の出力波形を追加 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) このブログでは,デジタル回路で使われる論理回路の種類(*TTL,*LVTTL,*CMOS)の電圧レベルの違いから,それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します. さらに様々な変換の方法の中から,どのような電圧レベル・トランスレータを選べばよいかを解説します. 特に特別な扱いが必要となる,双方向オープンドレイン信号の変換について詳しく見てみます Interface introduction 日本語ブログ
記事全体を表示
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 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. 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. 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. Figure 4: Digital signal output circuit (push-pull)   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. 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. 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. 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. 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. 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. Figure 9: Example of mismatched logic levels (1): Insufficient HIGH voltage input   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 . 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. 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. 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. 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. 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). 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 . 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.   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.   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.   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. ========================= 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. Interface Introduction Japanese Blog
記事全体を表示
如何转换数字信号的电压?(日语博客) 0. 目录 0. 目录 1. 什么是电压电平转换器? 2. 数字信号 2.1 各种数字信号 2.2 CMOS 和 TTL:使用简单的电压高电平和低电平表示逻辑电平信号 2.3 输入/输出电压规格:VOH/VOL 和 VIH/VIL 2.3.1 输出电压规格:VOH 和 VOL 2.3.2 输入电压规格:VIH 和 VIL 2.3.3VOH/VOL 与 VIH/VIL 之间的关系 3. 基本电压电平转换方法:单向信号转换 3.1 即使芯片的电源电压不同,也不需要进行转换的示例。 列:TTL 值 VIH(min) = 2.0V 和 VIL(max) = 0.8V 是如何确定的? 3.2 需要转换的示例 3.2.1 利用开漏输出进行转换 3.2.2使用标准逻辑(通用逻辑)芯片进行转换 4. 需要自动方向切换的双向信号转换。 4.1 使用单个MOS晶体管的双向转换 4.2 使用专用设备的双向转换 4.2.1 I²C信号电压转换芯片 4.2.2 高速双向开漏信号电压转换芯片 4.2.3 双向推挽式信号电压转换器芯片 4.2.4I3C信号电压转换器芯片 4.2.5 基于缓冲区的转换 5. 总结 5.1 博客中介绍的方法/零件编号的比较 6. 参考资料 1. 什么是电压电平转换器? 连接数字电路时,可以直接连接信号线…… 事实并非如此;如果“逻辑电平电压”不匹配,它可能无法工作、变得不稳定,或者在最坏的情况下,损坏芯片。 这时,电压电平转换器(也称电压电平移位器)就派上用场了。 电压电平转换器是一种允许不同电源电压的数字电路之间交换信号的电路。 例如,在以下情况下需要用到它: 3.3V 微控制器 ↔ 5V 传感器连接 将 1.8V FPGA 连接到 3.3V 外围设备 图 1:信号电压差异   本博客解释了数字电路中使用的各种逻辑电路类型(*TTL、*LVTTL、*CMOS)之间的电压电平差异,以及 VOH / VOL / VIH / VIL 在确定这些差异时的重要含义。此外,它还解释了在各种转换方法中如何选择合适的电压电平转换器。 此外,本博客将探讨电压电平转换器的具体示例,这些转换器可以自动检测和转换信号的方向。 NXP 还提供用于 SD 卡/SIM 卡的电压电平转换器和特定应用转换器,例如 GTL↔TTL 电平转换,但本博客将重点介绍面向通用或串行总线应用的产品。 *TTL(晶体管-晶体管逻辑) *LVTTL(低压晶体管-晶体管逻辑) *CMOS(互补金属氧化物半导体) *GTL(Gunning Transceiver Logic) 2. 数字信号   2.1 各种数字信号 所谓的“数字信号”是逻辑电平 1 和 0 的电信号表示。历史上,处理逻辑电平 1 和 0 有多种电路设计方法。这些方法包括用简单的电压高低来表示逻辑电平的方法,以及使用电压差来表示高低电平的方法。 TTL简单地用 5V/0V 表示高电平/低电平。进一步将 TTL 电压降低到 3.3V/0V,例如LVTTL ,这类系统的电压电平是根据双极型晶体管电路确定的。 类似地,ECL(电子分类)也使用双极型晶体管,但采用负电源来实现低幅度差分逻辑电平,从而获得更高的速度。GTL(全局晶体管叠层)则使用参考电压来传输高/低信号,以及低幅度单端信号等等。 此外,即使采用简单的高/低表示法,为降低功耗而开发的 4000 系列CMOS通用逻辑电路也允许使用 3V 至 18V 作为高电平。 https://en.wikipedia.org/wiki/Logic_family 本博客将解释如何处理 TTL (LVTTL) 和 CMOS 中的电压电平,它们使用简单的高电平和低电平来表示逻辑,以及上面提到的各种逻辑电平。 其他信号转换使用专用芯片,因此本文不予赘述。 此外,近年来半导体技术变得更小、更快、更节能,电源电压也随之降低。因此,用于桥接信号电压差的电压电平转换器变得尤为重要。 图 2:信号波形 - 电压电平(高/低)表示逻辑电平。   2.2 CMOS 和 TTL:使用简单的电压高电平和低电平表示逻辑电平信号 在数字电路中,简单的基于电压的逻辑电平信号通常使用高电平(HIGH)和低电平(LOW),高电平通常使用电源电压,低电平通常使用0V。只要高低电平的电压值相同,即使电源电压不同,信号也能传输。 例如,TTL(LVTTL)将2.0V或更高的输入信号解读为高电平,0.8V或更低的输入信号解读为低电平。由于这种约定,即使电源电压不同,TTL信号的高/低电平也不会改变。 另一方面,CMOS电路以电源电压的一半作为高/低电平的定义依据。因此,当电源电压变化时,CMOS电路的高/低电平电平也会发生变化。 图 3:输入信号电压规格   2.3 输入/输出电压规格:V OH /V OL 和 V IH /V IL 在数字电路中,高电平和低电平的输出电压以及用于判断输入信号是高电平还是低电平的电压都是有明确规定的。这些规定在每个芯片的规格书中都有明确说明,因此您需要查阅数据手册。 V OH :高电平输出电压 VOL : 低电平输出电压 V IH :高电平输入电压 VIL : 低电平 输入电压 2.3.1 输出电压规格:V OH 和 V OL 考虑输出时,必须考虑输出高/低信号所需的电流。电流会根据负载的变化而增大或减小。 在最大流出电流下,高输出时可保证的电压称为 VOH (最小值) ;在最大流入电流下,低输出时可保证的电压称为 VOL (最大值) 。 V OH (min) 是电路输出级中上方晶体管导通时的输出电压。该晶体管具有一个称为“导通电阻”的电阻。 当大电流流过晶体管时,会产生一个等于“晶体管电阻乘以流过电流”的电压。这会导致输出电压比电源电压低相应的数值,从而导致 VOH 值降低。因此, VOH (min)是指在达到预期最大输出电流时能够保证的最小电压。 图 4:数字信号输出电路(推挽式)   图 5:高输出电压随负载而变化。   VOL 则相反。当电路输出级中的低电平晶体管导通时,如果输入电流较大,由于晶体管导通电阻产生的电压,输出电压将高于 0V,如上所述。考虑到这一点, VOL (max) 是在预期输入电流最大时能够保证的最大电压。 图 6:低输出电压也会根据负载而变化。   2.3.2 输入电压规格:V IH 和 V IL 输入端有两个电压电平,用于判断高电平和低电平: V IH (最小值)和V IL (最大值) 。如果电压高于 V IH (最小值),则判定为高电平;如果电压低于 V IL (最大值),则判定为低电平。 在CMOS输入中,电源电压的一半用作高电平和低电平的参考电压,但这并不直接用作V IH (min) 和V IL (max) 。这是因为不同芯片之间的差异会导致阈值波动。此外,为了减轻输出端缓慢上升沿信号噪声引起的毛刺,通常会在输入端引入迟滞。基于这些原因,V IH (min) 和V IL (max) 被定义为具有一定的电压差。 2.3.3 VOH / VOL 与 VIH / VIL 之间的关系 要实现正常的信号交换,输出和输入之间的关系必须满足以下等式。 高水平:V OH (分钟)> V IH (分钟) 低水平: VOL (最大值)< VIIL (最大值) 如果保持这种关系,输出电路就能正确地将高/低信号传输到下一个输入电路。此外,它们之间的电压差“V OH (min) - V IH (min)”和“V IL(max) - V OL (max)”就成为“ 噪声容限”,并作为保持高抗噪性的指导原则。 图 7:V OH (min) / V OL (max) 和 V IH (min) / V IL (max) 3. 基本电压电平转换方法:单向信号转换   3.1 即使芯片的电源电压不同,也不需要进行转换的示例。 当“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”满足关系式时,通常不需要进行电压电平转换。例如,尽管TTL和LVTTL芯片使用的电源电压不同,但它们的输入和输出电压规格相同。 在 TTL (5V) 和 LVTTL (3.3V) 模式下, VOH (最小值) 为 2.4V, VOL (最大值) 为 0.4V。由于在两种情况下 VIH (最小值)/ VIL (最大值) 也均为 2.0V/0.8V,因此它们可以毫无问题地相互连接。 但是,如果输出电压高于输入芯片的电源电压,则需要格外小心。如果输出芯片使用 5V 电源,而输入芯片使用 3.3V 电源,则输入芯片必须支持“ 5V 耐受输入”。 5V 耐压输入是指即使将 5V 高电平信号连接到工作电压为 3.3V 的芯片的输入端,也能正常工作的输入端。虽然典型的芯片输入端都配备了静电放电 (ESD) 保护电路来防止静电损坏,但如果该 ESD 保护电路的配置如下图所示,5V 输入可能会导致电流从输入端反向流回 3.3V 电源,从而可能损坏芯片。5V 耐压输入的设计正是为了避免此类问题。耐压输入并非缺少 ESD 保护;它们内置了 ESD 保护电路,该电路能够处理高于电源电压的信号而不会造成任何问题。 如图 7 所示的 ESD 保护二极管,即使输入芯片断电,也可能导致问题。在独立控制每个芯片电源的系统中,即使输入芯片已关闭,输出信号也可能反馈到电源,导致输入芯片继续工作。 图 7:ESD 保护二极管 - 非容错输入 列:对于 TTL 电路,如何确定 V IH (min) = 2.0V 和 V IL (max) = 0.8V? CMOS的输入阈值基于电源电压的中点(VCC/2),而TTL的V IH (min) /V IL (max) 为2.0V/0.8V,相对于电源电压(5V)而言,这个比例并不十分理想。这与TTL的输入级由双极型晶体管构成有关。 标准 TTL 逻辑 IC 的内部电路示例:SN7400(2 输入 NAND)。 该信息包含在《1988 年最新通用逻辑器件规格表》(CQ 出版社)中。 典型的TTL门电路的输入级由一个多发射极输入晶体管和一个串联的相位分离晶体管组成。门电路开始响应的“开关阈值”由这两级中PN结的正向电压决定。由于单个硅PN结的正向电压约为0.6至0.7V,因此两级的总正向电压约为1.3至1.5V,这就是TTL门电路的有效开关阈值。 然而,约 1.4V 的值仅仅是一个“典型值”, 由于个体差异和温度变化,它会因批次和工况的不同而有所波动。 因此,数据手册中指定的 V IH (min) 和 V IL (max) 值被定义为保证值,在约 1.4V 的典型值上下留有足够的裕量,这意味着“如果电压降至此值,则可以可靠地判断为低电平 (V IL (max) = 0.8V)”,“如果电压升至此值,则可以可靠地判断为高电平 (V IH(min) = 2.0V)”。 此外,该值并非孤立地确定,而是根据 VOH 和 VOL 之间的关系设计而成,如第 2.3.3 节所述。在标准 TTL 电路中,由于输出级配置,高电平输出并非电源电压,而是略低的电压(比上述电路示例中的 130Ω 电阻、晶体管和二极管产生的电压低 2.4V)。当与 VOL(max)=0.4V 结合时, 高噪声容限:V OH (最小值)− V IH (最小值)= 2.4 − 2.0 = 0.4V 低侧噪声容限:V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V 如图所示,其设计旨在确保上下对称地提供 0.4V 的噪声容限。换句话说,TTL 的 2.0V/0.8V 数值相对于电源电压而言可能看起来“奇怪”,但实际上是合理的数值,其计算基于两个要求:双极型晶体管结电压的物理特性和噪声容限设计。 此图显示的是一个 SN7420(4 输入 NAND),其中三个输入引脚设置为高电平,一个引脚接收 100kHz 三角波(通道 1)。 当高电平 (Vcc=5V) 时,空载 (ch2) 输出小于 4V。 本专栏介绍的电路是一个没有指定型号的标准 TTL 电路示例(例如 74 LS 00 或 74 HC 00,没有 LS/HC 前缀;有时在英语中被称为“vanilla TTL”),但 V IH /V IL 规格相同的原因(输入级的双极结特性)与其他 TTL 系列(例如 74LS)相同。   3.2 需要转换的示例   虽然 TTL 和 LVTTL 连接由于电压电平匹配而可行,但当连接电源电压不同的 CMOS 芯片,或将 CMOS 芯片连接到 TTL 芯片时,逻辑电平不匹配的情况时有发生。这是因为上述关系“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”不成立,或者电平差过小,导致噪声容限不足。 电压电平转换器可以解决这个问题。 图 9:逻辑电平不匹配示例 (1):高电平输入电压不足   图 10:逻辑电平不匹配示例(2):输入的低电压不足。     3.2.1 利用开漏输出进行转换 无需使用电压转换芯片,也有简便的方法可以调节电压。 如果信号方向从输出芯片到输入芯片是固定的且不会切换,那么这种方法需要将高电平输出设置为开漏输出,以匹配输入电压。开漏输出是指数字电路输出级的上部晶体管缺失,高电平电压是通过连接到输入芯片电源电压的上拉电阻获得的。 图 11:数字信号输出电路(开漏)   明渠排水是一种简单且廉价的方法,但有几点需要注意。 首先,输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种类型的输出。 首先,输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种输出。如果输出固定为推挽输出且无法配置为开漏输出,则需要外部晶体管或类似器件将其转换为开漏输出。 此外,上拉电阻的选择也很重要。 为了获得高电压,需要使用上拉电阻,但如果电阻值太小,输出为低时流过的电流就会很大(类似于重负载),这将增加功耗,导致 电压 升高。 相反,如果该值过大,则会受到线路和引脚电容的影响,导致从低电平到高电平的上升时间变慢,从而降低通信速度。 3.2.2使用标准逻辑(通用逻辑)芯片进行转换 对于简单的电压电平转换,您也可以使用标准逻辑电路。例如, Nexperia 的 74AVCH4T245是一款通用 CMOS 逻辑芯片,可以执行 4 位双向电平转换。 该芯片可转换0.8V至3.6V的信号,并可通过DIR引脚切换信号方向。信号传输速度取决于转换电压,但可支持约100Mbps至380Mbps的速度。 图 12:标准逻辑示例 - 74AVCH4T245 该芯片能够实现高速双向电压信号转换,但转换方向必须由外部信号控制。虽然在并行总线上可以通过读/写等信号实现这种控制,但在串行总线等通信系统中,由于通信方向会根据协议而切换,因此难以应用这种控制方式。 图 13:标准逻辑示例。信号方向必须由外部指定。 4. 需要自动方向切换的双向信号转换。 迄今为止介绍的“开漏输出”和“使用标准逻辑芯片的电压转换方法”主要只能在一个方向上进行转换,或者需要通过外部信号来切换方向。 像I²C和I3C这样的通信方式,由于信号方向会动态变化,需要“双向电压电平转换”来自动检测并切换信号方向。外部控制这类信号的方向非常困难,而且使用上述缓冲芯片实现起来也很有挑战性。 此外,由于 I²C 是开漏信号,因此无法将标准的开漏逻辑缓冲器反向连接。图 14 展示了一个示例,其中开漏缓冲器反向连接。当缓冲器的两端均为高电平时,不会出现问题;但一旦其中一端变为低电平,缓冲器就会持续将另一端的输入拉低,并且无法恢复到高电平。 图 14:典型的开漏缓冲器不能自动在双向通信之间切换。   4.1 使用单个MOS晶体管的双向转换   迄今为止,I²C信号到电压的转换一直采用简单的电路。我们将以MOS晶体管为例,介绍一种最简单的方法。 图 15:使用 MOS 晶体管进行转换的示例   图 15 取自 I²C 规范 2.1 版(2000 年),展示了一个使用两个 MOS 晶体管(TR1、TR2)分别转换 3.3V 和 5V 信号的示例。尽管由于后文所述的问题,这种仅使用晶体管的简单转换示例已从当前的 I²C 规范中移除,但此处仍将其保留以帮助理解其原理。 I²C信号线,分别称为SDA和SCL,均为开漏双向信号。上拉电阻分别连接到3.3V和5V端。 在这个电路中,当3.3V和5V信号均为高电平时,该晶体管的栅极(g)和源极(s)处于同一电位,因此源极(s)和漏极(d)截止,它们之间的连接断开。当3.3V信号在此状态下变为低电平时,3.3V侧的晶体管(位于s和d之间)导通, 5V侧的信号也变为低电平。 当3.3V侧变为高电平,5V侧变为低电平时,连接3.3V侧和5V侧的寄生二极管(体二极管)首先导通。二极管导通后,电源电压下降。因此,晶体管导通, 3.3V侧的信号也变为低电平。 虽然这种使用晶体管作为开关的简单机制可以实现电压电平转换,但它也存在一些问题。晶体管的差异会影响信号转换的阈值电压。此外,随着处理更低信号电压的需求日益增长,例如在1V左右的信号电压下,这种电路无法工作,因为它无法获得足够的栅源电压(Vgs)。 4.2 使用专用设备的双向转换   通过使用 专用电压电平转换器 IC , 可以轻松实现 I²C 和 I3C 等双向通信总线的电压电平转换。 4.2.1 I²C信号电压转换芯片 PCA9306和NVT20xx系列( NVT2001/02 、 NVT2003/06 、 NVT2008/10 )是专为双向信号转换而设计的电压电平转换器。这些芯片可以同时处理多条信号线(多位信号线)。虽然它们被指定为 I²C 信号电压转换芯片,但如果信号规格匹配,它们也可以用于其他用途(例如 SPI 和其他推挽信号) 。 PCA9306 和 NVT20xx 系列具有相同的内部结构,只有当要转换的电压差为 1V 或更大时,才需要将上拉电阻连接到较高的电压侧。 图 16 显示了其内部结构以及与外部芯片的连接(摘自应用笔记AN11127的图 2:“双向电压电平转换器 NVT20xx 和 PCA9306” )。该芯片包含信号线(比特)数 + 1 个 MOS 晶体管。每个晶体管的源极和漏极可以互换。 信号传输路径中的晶体管称为传输晶体管,其余的晶体管称为参考晶体管。 图 16:NVT20xx (PCA9306) - 芯片工作原理示意图。   观察电路图,参考晶体管的栅极和漏极短接,并通过一个200kΩ的电阻连接到高压电源。参考晶体管的源极连接到低压电源。在这种连接方式下,参考晶体管相当于一个二极管,其栅极电压比低压电源高一个二极管电压。 剩余的传输晶体管的漏极连接到高压信号线和一个1kΩ的上拉电阻,其源极连接到低压信号线,其栅极连接到参考晶体管的栅极。当传输晶体管的高电平和低电平信号均为高电平时,高压侧的电压由1kΩ电阻上拉至高电平。 一个传输晶体管构成一个称为“源极跟随器”的电路。低压侧(源极)的电压比施加在栅极上的电压低,低的电压值等于晶体管导通所需的Vgs值。换句话说,源极的电压与低压电源的电压相同。此时晶体管处于半导通状态(工作在线性区),既非完全导通也非完全截止。 在这种状态下,当高电平或低电平信号变为低电平时,栅极和信号端之间的电压差会使晶体管导通(工作在完全导通的饱和区),另一个端也变为低电平。 该系列芯片可处理的信号速率受上拉电阻和信号线电容的影响。数据手册显示,PCA9306 最高可处理 2MHz 的信号速率。NVT20xx 系列芯片在上拉电阻为 192Ω、电容为 50pF 时,最高可处理 33MHz 的信号速率。对于 1MHz 左右的信号,即使不太在意上拉电阻和电容(假设其在 I²C 的常用范围内),也能正常工作。但是,如果要将该芯片用于推挽电路以处理更高速率的信号,则必须充分了解其特性并仔细选择合适的元件。 此类电压电平转换器的运行细节在文章“ PCA9306 的内部结构和运行”中进行了描述。 4.2.2 高速双向开漏信号电压转换芯片 我们推出NTS030x系列( NTS0302JK 、 NTS0304E )高速双向开漏信号转换芯片。 该芯片可执行 2 位或 4 位双向信号转换,可处理高达 2Mbps (1MHz) 的开漏信号和 20Mbps (10MHz) 的推挽信号。   图 17:NTS030x - 芯片内部框图   图 17 显示了 NTS030x 中一个信号比特的内部结构。 在图中,晶体管T3是一个直通晶体管,并对其施加了栅极偏置电压,因此当信号 A 或 B 变为低电平时,它会导通。 当 A 和 B 都为高电平时,T3 关闭,由于 A 和 B 通过相对较大的上拉电阻 (10kΩ) 连接到各自的电源,因此它们将具有各自的电压。 这款芯片包含T3以及T1和T2 。其中T1和T2用于一种名为“边沿速率加速器”的功能。我们将重点介绍其中一个T1,并解释其工作原理。 T1位于 A 侧,其源极连接到 A 信号,漏极连接到 A 侧电源。栅极连接到标有“单稳态和转换速率控制”的模块,该模块控制 T1。 “单次触发和转换速率控制”模块连接到另一端的 B 信号,用于检测 B 信号从低电平到高电平的变化。检测到此变化时,晶体管 T1 暂时导通,绕过 10kΩ 上拉电阻,允许电流通过,从而加速 A 信号从低电平到高电平的变化。通过这种方式加快信号的上升时间,可以处理更快的信号。 顺便一提,当 T1 打开时,其转换速率受到控制,以抑制电流突然增加引起的振铃。 另一个T2使用相同的机制,但方向相反,也应用于 B 面信号。 NTS系列还有另一个方便用户使用的功能。 对于前面提到的MOS晶体管和PCA9306/NVT20xx,存在一个问题:如果一个电源关闭,另一个电源的信号会被置为低电平。为了解决这个问题,NTS030x的设计使得当两个电源都未开启时,信号引脚会被置为高阻抗状态,从而避免相互影响。利用此功能,可以对系统的电源进行部分控制,使其处于开启/关闭状态。 NTS010x 系列( NTS0102 、 NTS0104 )与 NTS030x 系列等效,但缺乏处理高速信号的转换速率控制功能。 NTS0304E 配有评估板NTS0304EUK-ARD,可进行快速简便的运行验证。有关 NTS0304EUK-ARD 评估板的概述和操作方法,请参阅视频“如何操作 NTS0304EUK-ARD” 。 4.2.3 双向推挽式信号电压转换器芯片 此外,对于仅用于推挽信号的器件,还有NTB010x系列( NTB0102 、 NTB0104 ),它提供了一种更快的选择。 当信号稳定处于高电平或低电平状态时,信号会通过一个 4kΩ 电阻。与 NTS030x 系列类似,它在高电平和低电平两端都具有单稳态功能,并且具有一种机制,当任一端的信号发生变化时,该机制会改变另一端的信号。 该机制能够以 70-80 Mbps 的速度实现信号到电压的转换,同时还具有自动信号方向检测功能。   图 17:NTB010x - 内部芯片框图 4.2.4I3C信号电压转换器芯片 I3C规范允许在开漏和推挽通信模式之间切换。在开漏模式下,它与 I²C 兼容,工作频率最高可达4MHz 。在推挽模式下,则使用12.5MHz 的时钟频率。由于信号电压通常在 1V 到 3.3V 的范围内,因此当存在电压差时,需要一个符合信号规范的电压电平转换器。 图 18 显示了P3A1604一位的内部框图。如图所示,该芯片集成了一种机制,不仅可以加速低电平到高电平的转换,还可以加速高电平到低电平的转换,并且还集成了一个可以开关的上拉电阻。   图 18:P3A1604 - 芯片内部框图 P3A1604是一款 4 位 I3C 电压电平转换器。另有 2 位版本P3A9606可供选择。   4.2.5 基于缓冲区的转换 转换双向信号的另一种方法是使用专用缓冲区。 缓冲器的主要目的是增强驱动能力并隔离连接信号线的电容,但也有一些产品支持电压转换。 正如这篇博客中所述,简单的缓冲器无法相互缓冲双向开漏信号。因此,市面上出现了各种具有双向开漏信号专用功能的缓冲器产品。 我会在以后的场合详细解释缓冲区的问题。 5. 总结 电压电平转换器是安全可靠地在不同电源电压的数字电路之间交换信号的关键组件。了解 TTL、LVTTL 和 CMOS 等逻辑电平的定义,以及 VOH/VOL/VIH/VIL 之间的关系,有助于选择合适的连接和转换方法。 对于单向转换,可以使用开漏输出或标准逻辑集成电路;而对于双向转换,可以使用MOS晶体管或专用集成电路(例如PCA9306/NVT/NTS/NTB/P3A系列)。 具有自动信号方向检测功能的电压电平转换器对于需要双向通信的总线(例如 I²C 和 I3C)特别有用。 此外,半导体技术的最新进展带来了更低的电压和更高的速度,这就对电压电平控制提出了更高的要求。虽然电压电平转换的方法和方案有很多,但根据应用需求,并考虑信号规格、速度和系统电源管理等因素,选择最佳的方法和元件至关重要。 5.1 博客中介绍的方法/零件编号的比较 方法/部件编号 目的 位数 方向改变 开放式布线兼容 低压侧 [V] 高压侧 [V] 比特率 [bps] 具有开漏输出的转换器 通用 1 单向 - - - - 标准逻辑(例如,74AVCH4T245) 通用型(并行总线等) 4 + 4 外部控制 不支持 0.8 ~ 3.6 0.8 ~ 3.6 1亿~3.8亿 使用单个MOS晶体管进行双向转换 I²C,通用 1 自动的 一致 根据晶体管规格而定 约100万 PCA9306 I²C,通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz,视情况而定) NVT2001 I²C,通用 1 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NVT2002 I²C,通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NVT2003 I²C,通用 3 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NVT2006 I²C,通用 6 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NVT2008 I²C,通用 8 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NVT2010 I²C,通用 10 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz @ 开漏),66M(33MHz @ 优化条件) NTS0302JK I²C、SPI、通用 2 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口,20米@推拉式排水口 NTS0304E I²C、SPI、通用 4 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口,20米@推拉式排水口 NTS0102 I²C、SPI、通用 2 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTS0104 I²C、SPI、通用 4 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTB0102 SPI,通用 2 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 NTB0104 SPI,通用 4 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 P3A9606 I3C、I²C、SPI、通用 2 自动的 一致 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C、I²C、SPI、通用 4 自动的 一致 0.72 ~ 1.98 1.62 ~ 3.63 6.8米(明排水),40米(推拉式排水) 表 1:博客中介绍的方法/零件编号对比   6. 参考资料 产品介绍页:电压电平转换器 NXP系统管理I2C、I3C、SPI选型指南 I2C总线规范和用户手册(版本5.0)(日语版) I2C总线规范和用户手册(版本7.0)英文版) NXP社区博客: I3C总线概述——下一代串行总线 日本网络研讨会视频: “您现在需要了解的下一代接口‘I3C’基础知识” Qiita @teddokano: PCA9306 的内部运作和运行 变更历史记录: 2025年8月28日:第一版 2025-08-28:添加了有关 NTS0304EUK-ARD 的信息以及包含视频的博客链接。 2026-04-10:修正表 1 中的低压侧 [V] 和高压侧 [V]。 2026-06-20:第 3.1 节“列:TTL 的 VIH(最小值)”新增“如何确定 VIL(max) = 2.0V 和 VIL(max) = 0.8V?”。新增标准 TTL 逻辑 IC 的内部电路示例:SN7400(2 输入 NAND 门)和 SN7420 的输出波形。 ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 本博客解释了数字电路中使用的各种逻辑电路(*TTL、*LVTTL、*CMOS)之间的电压电平差异,以及 VOH 、 VOL 、 VIH 和 VIL 对于识别它们的重要含义。 此外,我们将解释在各种转换方法中应该选择哪种电压电平转换器。 我们将仔细研究双向开漏信号的转换,这需要特殊的处理方法。 界面 介绍 日本博客
記事全体を表示
Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT). 3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow. 4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.
記事全体を表示
Designing a CAN-Based Communication Hub with the S32N55 using Model Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement. 3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation. 4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent. Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate. 5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors 6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.
記事全体を表示
S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello, I am developing an application on the following platform: MCU: NXP S32K314 RTD 7.0.0 (AUTOSAR MCAL) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 During development, I encountered a deadlock related to high-priority interrupts and would like to ask whether my understanding is correct and whether there is a recommended solution. Background FreeRTOS specifies that ISRs with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY must not call FreeRTOS APIs. However, I found that many RTD MCAL APIs internally execute FreeRTOS critical section APIs through the following call chain: MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() and MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() This behavior exists even in APIs that only perform simple peripheral register accesses, such as DIO and GPT. Problem When a MCAL API is called from a high-priority ISR (priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY), the internal call to taskENTER_CRITICAL_FROM_ISR() causes the FreeRTOS interrupt masking state to become inconsistent. As a result, after taskEXIT_CRITICAL_FROM_ISR() returns, BASEPRI is not restored correctly, causing lower-priority interrupts such as SysTick and PendSV to remain masked. The scheduler eventually stops because xPortSysTickHandler() is no longer executed. I was able to reproduce this issue using APIs such as: Dio_FlipChannel() GPT (PIT) interrupt processing Other MCAL APIs that use SchM exclusive areas Current Workaround To avoid modifying RTD-generated source code directly, I used the GNU linker --wrap option to wrap the following functions: OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() The wrapper checks the current interrupt priority. Please refer to the attached WrapperExample.c. If the current ISR priority is higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, it skips the original function. Otherwise, it calls the original implementation. This workaround appears to resolve the deadlock while leaving the generated RTD source unchanged. Questions Is this behavior expected by design in the RTD MCAL? Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Is there an official or recommended solution for this problem that does not require modifying generated RTD source code? Any advice or recommendations would be greatly appreciated. Thank you.
記事全体を表示
2026 年顶级和最佳 IPTV 服务 2026年最好的IPTV服务是Nigma TV,这是一个优质的流媒体平台,以真正的4K/UHD质量提供51,000多个直播电视频道和16万多部电影和电视剧在线点播。它采用先进的防冻技术和高性能服务器设计,即使在大型体育赛事直播期间,也能确保超流畅的流媒体传输,正常运行时间高达 99.9% 。Nigma TV与所有主要设备 (Firestick、智能电视、安卓、iOS、PC、Mac) 完全兼容,在全球范围内 提供无缝的观看体验。计划起价仅为 13.99 美元/月,提供 24 小时免费试用,无需信用卡。截至 2026 年,数以千计的活跃用户将该服务评为全球最可靠的 IPTV 提供商之一。 官方网站: https://nigma.tv Re: Top and Best IPTV Service 2026 🔥 iptvhdlive.com — 您的全方位体育频道 如果您厌倦了寻找链接、切换应用程序或在大型比赛期间应对延迟,iptvhdlive.com 就是为您打造的平台。这项高级付费服务提供世界上所有主要体育赛事——全部采用高清、全高清和 4K 超高清画质,播放流畅稳定。 观看所有体育赛事高清/4K直播,尽在iptvhdlive.com 国际足联(世界杯) UFC(付费观看、格斗之夜、垫场赛) 拳击(Top Rank、Matchroom、PBC PPV) NBA(常规赛+季后赛) NFL(完整赛季+超级碗) 板球、网球、一级方程式赛车、MotoGP、WWE等等
記事全体を表示