基于TXS0104E的3.3V与5V系统电平转换实战：串口、IIC、SPI全覆盖

混合电压系统联调这件事，做嵌入式的朋友应该都不陌生。板子上3.3V主控配5V外设，或者反过来5V逻辑配3.3V外设，电平不匹配导致的通信失败、数据乱码、芯片发烫，几乎是每块混合电压板子都要过的坎。我之前在项目里用过不少方案，从最土的电阻分压、三极管搭电路，到后来的专用电平转换芯片，踩过不少坑，也积累了一些体会。这篇就围绕基于TXS0104E的3.3V与5V系统间电平转换方案，把串口、IIC、SPI三种常见总线的实现细节、电路设计、实测经验和排查技巧一次性讲透，给正在做混合电压系统联调的朋友一个可以直接抄作业的参考。

TXS0104E这颗芯片，本质上是一个4通道的自动方向感应电平转换器，专门用来处理开漏极和推挽输出这两种不同类型的信号。它内部集成了NMOS管和上拉电阻，通过检测外部驱动方向自动切换信号流向，不需要额外的方向控制引脚，这对IIC这种双向总线来说非常友好。不过正因为它是自动方向感应，很多人在使用中容易忽略它的驱动能力限制和上拉电阻特性，导致高速SPI场景下波形变形、通信不稳定，这些细节我会在后面的章节里重点展开。

这个方案适合谁来参考？如果你正在用STM32、ESP32、GD32这类3.3V主控去驱动5V的LCD屏、传感器模块、舵机控制板、老式串口设备，或者反过来用5V单片机去连接3.3V的模块，这篇文章的内容可以直接照搬。就算你手头没有TXS0104E，文章里关于电平转换原理、总线时序分析、波形测试排查的思路，对使用其他电平转换芯片或者自己搭分立器件方案同样适用。

1. 电平转换方案选型思路：为什么最终锁定TXS0104E

1.1 常见电平转换方案对比

混合电压系统里，电平转换的手段五花八门，各有各的适用场景。我先把用过的几种方案放在一起对比，大家根据自己的项目情况选择：

电阻分压看着省事，实际用起来限制很多。比如5V UART TX经过两个电阻分压到3.3V，如果对端芯片的输入阻抗不够高，分压比例会被拉偏，低电平可能抬到0.8V以上，直接超过逻辑低电平阈值，通信就挂了。我还遇到过用分压电阻驱动IIC总线的情况，上拉电阻和分压电阻纠缠在一起，总线根本拉不上去，调了半天才发现是阻抗匹配的问题。

三极管分立电路我也用过一段时间，尤其是在做简单单向电平转换的时候，两个三极管加几个电阻就能搞定，成本不到几毛钱。但问题在于，这种电路天然不适合双向总线。IIC的SDA和SCL都是开漏结构，信号是双向流动的，三极管方案处理起来非常别扭，常常需要额外加方向控制电路，复杂度上去了，可靠性反而下来了。

1.2 TXS0104E的核心优势

TXS0104E在我用过的电平转换芯片里，属于很省心的那种。第一，它有4个独立通道，一个芯片就能同时处理串口TX、RX、IIC的SDA、SCL，甚至SPI的MOSI、MISO、SCK、CS都勉强能覆盖大部分场景。第二，自动方向感应这个特性太重要了，省去了方向控制引脚，电路设计和软件配置都简单很多。第三，它集成了一边10KΩ、一边40KΩ的上拉电阻，对外围电路的要求很低，IIC这种开漏总线接上就能跑。

当然，TXS0104E也有明显的短板，最大的问题在于输出驱动能力和上拉电阻值是固定的，在高速推挽模式下，信号边沿会变缓，这对SPI这种高速总线是一个考验。我实测下来，在5V侧接上拉电阻到3.3V这种配置下，SPI时钟跑到几MHz以上时，波形上升沿就开始明显变缓，如果走线再长一点，误码率会显著上升。后面我会专门讲这个问题的处理办法。

1.3 方案适用边界

我在项目里用TXS0104E处理过串口、IIC、SPI三种总线，整体感受是：对不同协议的适配性有明显差异。

串口场景最稳。UART本身是点对点、全双工的，信号速率通常不高（115200bps到几Mbps），TXS0104E跑起来毫无压力，而且双向同时转换的特性让RX和TX可以共用一个芯片的两个通道，接法对称，非常规整。

IIC场景最省心。IIC是开漏结构，TXS0104E内部集成的上拉电阻正好可以充当IIC总线的上拉，省掉了外部上拉电阻。标准模式100KHz、快速模式400KHz都能稳定工作，高速模式我没敢往上冲，因为内部40KΩ的上拉对上拉速度有限制，1.7MHz以上的快速模式Plus规格可能就比较勉强了。

SPI场景最需要谨慎。SPI是推挽输出，TXS0104E的自动方向感应能力在处理MOSI和MISO同时双向传输时会面临挑战。我之前用TXS0104E跑STM32的SPI驱动5V屏，时钟频率超过8MHz就开始偶发数据错误，降到4MHz就稳了。如果项目对SPI速度要求高，我建议考虑TXS0108E或者带方向控制引脚的TXB系列。

2. TXS0104E芯片核心细节解析：看懂内部结构才能用好它

2.1 芯片内部架构与工作原理

TXS0104E的内部结构可以简化理解成4个独立的电平转换通道，每个通道由一对NMOS管和上下拉电阻组成。A侧接3.3V电源，B侧接5V电源，当A侧输入高电平时，内部NMOS截止，B侧通过上拉电阻被拉到5V；当A侧输入低电平时，NMOS导通，B侧被拉低到接近GND。

这个工作方式决定了TXS0104E的一个重要特性：它本质上是基于导通和截止逻辑来判断信号方向的，所以不需要额外的方向引脚。芯片内部通过一个边沿检测器来感应总线上哪个设备在驱动信号，从而自动建立正确的传输路径。这个设计对IIC这样的双向总线非常友好，但也带来了一个代价——每次方向切换都有一定的建立时间，这就是为什么它在高频推挽信号下表现不如带方向控制的芯片。

我特意画了一个简化数据流来帮助理解：

3.3V侧设备 <-> A侧引脚 (内部NMOS+10K上拉) <-> 电平判断电路 <-> B侧引脚 (内部NMOS+40K上拉) <-> 5V侧设备

A侧和B侧上拉电阻值不一样，这是TXS0104E特有的设计，目的是让两侧的信号摆幅都能被正确识别，同时避免在方向切换时出现总线冲突。

2.2 OE引脚与上拉电阻的正确使用

TXS0104E的OE引脚（输出使能）经常被忽略，但实际上在系统设计中非常重要。OE引脚内部下拉到GND，默认情况下芯片是关闭的，所有引脚处于高阻态。你必须把OE引脚接高电平（通常直接接到VCCA）才能让芯片正常工作。

我之前有一个板子就是因为OE悬空，导致芯片输出全高阻，串口怎么调都收不到数据，排查了半天才发现是这个原因。OE引脚在调试的时候还能派上大用场——如果系统中多个设备共享一条总线，可以通过控制OE引脚来隔离某个设备的信号，避免总线冲突。

关于上拉电阻，有一点需要特别注意：TXS0104E内部已经集成了上拉，外部一般不需要再额外接上拉电阻。但在某些特殊场景下，比如IIC总线上挂了多个设备，总线上拉电阻可能会因为并联而阻值过小，导致信号边沿过陡，此时可以考虑增大外部上拉电阻来补偿。反过来，如果发现上拉能力不足、信号低电平拉不下去，可以适当在外部并联上拉电阻，但要计算好总阻值不要太小，否则功耗上去了，信号质量也会变差。

2.3 典型电路连接参考

下面是我在一款产品上实际验证过的连接方案，主控是3.3V的STM32F103，外部设备是5V的LCD屏（使用IIC接口）和一个5V的串口传感器：

VCCA接3.3V，VCCB接5V，VCCA和VCCB都要加0.1uF去耦电容 OE引脚接VCCA A1接MCU的IIC_SDA，B1接5V设备的IIC_SDA A2接MCU的IIC_SCL，B2接5V设备的IIC_SCL A3接MCU的UART_TX，B3接5V设备的UART_RX A4接MCU的UART_RX，B4接5V设备的UART_TX

这里有个经验之谈：串口的TX和RX交叉接，这个很多人容易搞混。A3接MCU_TX则B3接对方RX，A4接MCU_RX则B4接对方TX，接反了数据完全不通。我甚至遇到过接反后芯片不发烫但通信完全无响应的奇怪现象，郁闷了很久才发现是交叉接错了位置。

对于SPI，如果信号数量超过4路（SCK、MOSI、MISO、CS），一片TXS0104E就不够用了，需要两片。这里我提一个建议：对于SPI的CS信号，如果设备支持软件片选，也可以不用电平转换，直接在3.3V的GPIO上配置为开漏输出加上拉电阻，也能兼容5V设备。不过更稳妥的做法还是老老实实走一片转换芯片，通道不够就加一片，成本也就几块钱。

3. 串口电平转换实操：最常用也最容易踩坑的场景

3.1 串口电平转换的接线方式

串口（UART）在电平转换场景里是最常见的，因为老式传感器模块、蓝牙模块、GPS模块很多还是5V逻辑。使用TXS0104E转串口，接线非常简单：

3.3V MCU TXD -> TXS0104E A3 5V 设备 RXD -> TXS0104E B3 3.3V MCU RXD <- TXS0104E A4 5V 设备 TXD -> TXS0104E B4

这里要注意，串口的空闲电平是高电平，起始位是低电平。TXS0104E转换过程中，高电平通过上拉实现，低电平通过NMOS导通实现，所以转换后的信号逻辑是完全一致的，不会出现反相问题。我实际测试过很多次，波形在逻辑分析仪上看，除了边沿稍微有点变缓之外，时序关系保持得很好。

3.2 波特率与信号质量的实测验证

串口通信的速率单位是波特率，常见的有9600、115200、460800等。我实测了TXS0104E在不同波特率下的表现：

从测试结果来看，对于常规的串口应用，TXS0104E的转换能力绰绰有余。但有一个容易忽略的问题是地线回路。如果3.3V系统和5V系统分别用独立的电源供电，而两个电源的地没有连在一起，电平转换芯片根本无法工作，因为信号是参考地的，地电位不一致，转换出来的电平完全是乱码。我遇到过几次这种情况，排查到最后都是地线问题。

3.3 串口调试中的压线细节

实际调试串口通信时，有四个小细节值得注意：

第一，串口调试助手的参数设置要匹配，数据位、停止位、校验位都要一致。我见过很多次配置不对导致乱码的情况，还以为是电平转换的问题。第二，如果你用的是USB转串口模块，保证CH340或CP2102这类芯片的驱动已经正确安装，不然设备管理器里看不到COM口，白折腾半天。第三，排除法定位问题——先临时把TX和RX短接做回环测试，如果自发自收正常，说明MCU和串口助手这边没有问题，再去查电平转换链路。第四，示波器测量信号质量时，探头接地线要尽量短，悬空的接地线会引入大量噪声，测量出来的波形不能反映真实情况。

4. IIC总线电平转换实操：开漏结构下的天然适配

4.1 IIC电平转换的特殊性

IIC总线最大的特点是开漏结构，SDA和SCL两条线都通过上拉电阻接电源，设备通过拉低总线来发送信号。这种结构决定了IIC对电平转换芯片有一个特殊要求：转换芯片必须支持双向传输，而且不能锁存总线状态。

TXS0104E的自动方向感应特性正好满足这个要求。A侧接3.3V上拉，B侧接5V上拉，信号在两条线上都能自由流动。我曾经用TXS0104E驱动一个5V的IIC接口OLED屏，OLED屏的地址是0x3C，用STM32的硬件IIC和软件模拟IIC都试过，通信都很稳定。

4.2 IIC上拉电阻取值分析

IIC总线的上拉电阻取值是一个老生常谈的话题，在TXS0104E场景下又有一些新的考量。TXS0104E内部A侧集成10KΩ上拉，B侧集成40KΩ上拉，这个阻值在标准模式和快速模式下够用，但如果总线上挂了多个设备，或者总线长度较长，可能需要额外调整。

上拉电阻的选择有一个经验公式：上拉电阻最小值取决于总线上拉电流上限，最大值取决于总线电容和上升时间要求。举个具体的例子，如果IIC总线电容为200pF，上升时间要求为1us（400KHz快速模式），那么上拉电阻最大值为Rmax = 1us / (0.8473 * 200pF) ≈ 5.9KΩ。也就是说，如果总线电容偏大，TXS0104E内部40KΩ的上拉可能不够快，需要外部并联一个较小的上拉电阻来加快上升沿。

4.3 IIC多设备挂载的注意事项

实际项目中，IIC总线上往往不只有一个设备。我在一个采集板卡上同时挂了5V的温湿度传感器、5V的OLED屏、3.3V的EEPROM，用一片TXS0104E接到了3.3V主控上。这样一来，3.3V侧的设备不受影响，5V侧的设备全部通过TXS0104E转换，通信都正常。

但多设备挂载时，有一个坑必须提醒：IIC地址冲突。如果总线上有两个设备地址相同，通信数据分析起来非常痛苦，数据看起来正常，但读取的值就是不对。我常用的排查方法是先用IIC扫描程序把所有设备的地址列出来，确认没有冲突再继续。另外一个容易被忽略的是设备的工作电压范围，有些所谓5V设备实际电压范围很宽，比如3.3V到5.5V都能工作，这种情况下如果5V侧设备功耗不大，直接用3.3V供电反而能省掉电平转换，前提是芯片数据手册明确写了支持3.3V供电。

4.4 IIC时钟频率与电平转换的配合

IIC的时钟频率决定了总线的数据吞吐率。标准模式100KHz、快速模式400KHz是最常用的，TXS0104E在这两种模式下都能稳定工作。但如果你使用1MHz以上的高速模式，要注意TXS0104E的自动方向感应电路需要一定的切换时间，在高速模式下可能出现信号竞争现象。

我在IIC高速模式下遇到过一个问题：数据采集偶尔出错，用示波器看SDA波形，发现上升沿有回勾，看起来像是因为电平转换芯片内部NMOS关断不及时导致的。后来在5V侧SDA和SCL上额外并联了2.2KΩ的上拉电阻，把上升沿加快了一些，问题就消失了。这说明TXS0104E内部的40KΩ上拉在高速场景下确实有点力不从心，外部补充上拉是一个有效的优化手段。

这里还有一个小技巧：TXS0104E支持把多个通道并联使用来增强驱动能力，比如把两个通道同时接到同一条IIC线上，相当于内部上拉电阻并联，阻值减半，驱动能力翻倍。不过这样做会占用额外的通道资源，设计时要提前规划好通道分配。

5. SPI总线电平转换实操：高速场景下的性能边界

5.1 SPI电平转换的挑战

SPI和IIC不同，它是推挽输出结构，信号由设备主动驱动，不需要上拉电阻。这种结构在电平转换时带来的挑战是：推挽信号在方向切换时需要更快的响应速度，TXS0104E的自动方向感应在这种场景下会显得力不从心。

以SPI最常见的四线制为例：SCK（时钟）、MOSI（主出从入）、MISO（主入从出）、CS（片选）。其中SCK和MOSI是由主控单向输出的，MISO是由从设备单向输出的，CS通常也是主控输出的。严格来说，SPI并不是双向总线，每条信号线的方向是固定的。这就造成了TXS0104E的资源浪费——它明明支持双向，但SPI场景下每条线只需要一个方向的转换能力。

不过实际上，TXS0104E用在SPI上问题也不大，只要速度控制得当。我用STM32F103的硬件SPI配合TXS0104E驱动5V SPI接口的Flash芯片，时钟频率设为4.5MHz时，读写都正常，波形也符合预期；把频率提高到9MHz，读数据的MISO信号就开始出现偶发错误，主要表现为时序亚稳态。

5.2 硬件SPI与软件模拟SPI的选择

SPI的实现方式有两种：硬件SPI和软件模拟SPI。硬件SPI使用的是芯片内部的SPI外设，时钟频率可控、时序精准，但信号边沿很陡，对电平转换的要求更高。软件模拟SPI用GPIO翻转产生时序，边沿相对较缓，但灵活性高，速率上限取决于代码执行效率。

在TXS0104E的场景下，我的经验是：如果对速度要求不高（1MHz以下），用软件模拟SPI更稳，因为信号边沿缓，电平转换芯片有充足的时间响应；如果要用硬件SPI的高速率，建议前期就做好波形验证，确认TXS0104E在目标频率下还能保证充分的数据建立时间和保持时间。

还有一点关于SPI的DMA：很多人用STM32CUBEMX配置SPI DMA接收数据，配合电平转换芯片时，要注意DMA触发时机与CS片选信号的配合。我遇到过DMA接收的数据整体错位一个字节的情况，排查后发现是CS信号拉低的时刻和DMA启动的时刻之间有一个微小的时间差，SCK的第一个边沿采到的是无效数据。解决方法是先拉低CS，等待一小段时间后再启动DMA接收。

5.3 SPI时钟极性与相位（CPOL/CPHA）的配置

SPI协议中有两个非常重要的参数：时钟极性CPOL和时钟相位CPHA。CPOL决定空闲时时钟是高电平还是低电平，CPHA决定数据是在时钟上升沿还是下降沿采样。这两个参数与电平转换芯片无关，但一旦配置错误，通信就会莫名其妙地出错，而且问题表现和电平转换故障非常相似。

我记得有一次调试SPI接口的5V触摸屏控制器，读到的ID总是不对，波形看起来也对，折腾了很久才发现是CPOL和CPHA配置反了。所以建议大家在使用SPI设备时，先仔细阅读设备数据手册，确认它支持的SPI模式，再在MCU端做相应配置。硬件SPI通常可以直接配置CPOL和CPHA，软件模拟SPI更需要自己控制时序，千万不要凭感觉瞎猜。

5.4 高速SPI下的TXS0104E替代方案

如果你的SPI应用场景确实需要很高的时钟频率，比如超过10MHz，我建议放弃TXS0104E，改用TXB0104（单端推挽专用电平转换）或者更高速的SN74AVC4T245这类带方向控制的电平转换芯片。TXB系列采用不同的内部架构，更适合快速边沿信号。

我有一次给客户升级一个基于SPI的5V屏幕显示方案，客户要求刷新率达到30fps，SPI时钟至少需要20MHz。当时手里只有TXS0104E，实测20MHz下MISO信号完全没法看，后来换用了SN74AVC4T245，用GPIO控制方向引脚，SPI时钟轻松跑到了24MHz，信号质量依然很好。这个经历让我明白了一个道理：芯片选型一定要结合具体应用场景，电平转换芯片的“性能边界”不是书本上写的几MHz，而是由信号边沿质量、走线长度、负载电容共同决定的。

6. 实测波形分析与信号完整性优化

6.1 示波器测试的准确方法

评估电平转换效果，最直接的方法是用示波器看波形。我测试时通常会用两个通道同时测量：一个通道挂A侧输入信号，一个通道挂B侧输出信号，这样可以直观地看到电平转换前后的对比。

示波器探头要设置成10X衰减档，因为1X档位下探头输入电容太大（通常几十到几百皮法），会严重影响被测信号，尤其是SPI这种高频信号。另外，测试时要使用接地弹簧或者尽量短的接地线，避免用那种长长的鳄鱼夹地线，那会把几纳亨的电感引入测量回路，高频下会产生振铃。

6.2 典型波形解读

我实测的IIC波形（400KHz快速模式）如下：SCL和SDA的高电平在5V侧接近5V，低电平接近0V，边沿陡峭，几乎没有过冲和振铃。3.3V侧的波形也正常，高低电平都在TTL标准范围内。这说明TXS0104E在IIC场景下工作非常理想。

串口波形（115200bps）同样很典型：起始位、数据位、停止位层次分明，电平摆幅符合预期。我特别注意观察了TX和RX同时传输时的交叉干扰情况，发现TXS0104E的通道间隔离做得不错，没有明显的串扰信号。

SPI波形（4.5MHz）的表现就要差一些了：时钟信号有轻微的上升沿变缓，MISO数据的建立时间有所缩短，但还在可接受范围内。当我把频率提高到9MHz时，MISO信号的边沿明显变缓，出现了台阶状波形，这就是NMOS管开关速度不够的表现了。

6.3 信号完整性优化手段

针对TXS0104E在高速场景下信号变差的问题，我总结了几种优化手段，按效果排序：

调整走线长度和布局。电平转换芯片尽量靠近信号接收端，减少PCB走线长度。我在改版时把TXS0104E从原来的板边移到了MCU旁边，走线长度缩短了一半，波形改善明显。

在B侧（5V侧）信号线上串联一个小阻值电阻，比如22Ω或33Ω，可以抑制过冲和振铃。这个方法尤其适用于5V侧信号反射比较大的情况。在B侧并联外部上拉电阻，减小内部40KΩ上拉的影响。这个方法对于IIC总线尤其有效，能明显加快上升沿。

如果系统允许，适当降低通信速率。有时候为了追求高速而上各种优化措施，不如干脆降低到芯片能稳定保证的速率，可靠性才是第一位的。我在量产项目中，SPI速率稳定在4MHz，IIC速率400KHz，串口115200bps，都是经过长时间老化测试验证的参数。

6.4 电源去耦的正确做法

VCCA和VCCB的电源去耦是保证电平转换信号质量的基础，很多信号完整性问题追根溯源其实是电源问题。TXS0104E的VCCA和VCCB引脚旁边各放一个0.1uF的陶瓷电容，且必须尽量靠近芯片引脚放置，过孔的距离也要短。

我以前有一块板子，把去耦电容放在了芯片背面，过孔绕了很长一截，结果5V侧的波形在切换瞬间出现明显的电压跌落，SCL的高电平有过冲和回勾。后来把电容挪到芯片同一面、紧贴引脚，波形就干净多了。电源走线也要注意，VCCA和VCCB的走线不要共用，避免通道切换时的瞬态电流互相干扰。

7. 常见问题与排查技巧实录

7.1 电平转换后通信完全无响应

这是最让人头疼的问题，但往往原因很简单。按我排查的经验，优先级从高到低依次是：OE引脚是否为高、VCCA和VCCB是否都正常供电、信号线是否接反（尤其是串口TX/RX交叉）、地线是否连通、目标设备地址是否冲突。

我在调试中习惯先用万用表量一下各引脚的电压状态，再用逻辑分析仪或示波器确认电平转换芯片的输入侧有无信号。如果输入侧有信号、输出侧没有，问题大概率在芯片本身或者供电；如果两侧都没有信号，那就往前查MCU的配置和接线。

7.2 串口乱码问题排查

串口乱码是混合电压系统中非常常见的问题。先区分是电平转换导致还是串口参数导致。正常情况下，电平转换不会改变数据的逻辑内容，只是改变电平幅度，所以如果串口参数（波特率、数据位、停止位、校验位）配置正确，乱码大概率不是电平转换引起的。

但是有一种情况是电平转换导致乱码：当通信速率高、信号边沿过缓时，接收端的采样点可能落在不稳定的信号区间，导致采样错误。这种情况在115200bps以上速率、走线较长时可能出现。解决方法是降低波特率，或者优化信号边沿（比如在B侧信号线上串联小电阻）。另外还要检查串口调试助手的设置，我见过不少人在XCOM或友善串口助手里把波特率设置错了，和代码里配置的不一致，数据自然全是乱的。

7.3 IIC通信偶发失败的排查

IIC偶发失败，排查起来比完全不通更麻烦，因为问题不总是在同一个点复现。我用过的排查思路是：先在示波器上同时抓SCL和SDA波形，观察是否有总线冲突（SDA被异常拉低后释放不了）、是否有应答位缺失、是否有数据位错误。

然后检查总线上所有设备的上拉配置。如果总线上的多个上拉电阻并联导致总等效上拉电阻过小，会使得信号低电平拉不下去；如果上拉电阻过大，又会导致上升沿过缓。TXS0104E内部已经有上拉，外部再并联上拉时一定要计算等效阻值在合理范围内。

7.4 SPI读取数据错位的排查

SPI读取数据错位的问题，我在多个项目中都遇到过，尤其是使用DMA接收时更容易出现。这类问题的本质是采样时序不正确，数据在SCK的哪个边沿被采样，以及CS片选信号和SCK的时序配合。

排查方法：用示波器同时抓取CS、SCK、MISO三个信号，结合逻辑分析仪看数据位的采样点和数据线的对应关系。如果发现CS拉低后第一个SCK边沿采到的数据是无效的，建议在代码中先拉低CS，延时一小段时间（比如1us），再启动SPI传输。如果发现MISO信号本身没有问题但数据错位，检查SPI的CPOL/CPHA配置是否与从设备要求一致。

7.5 芯片发热问题

TXS0104E在正常工作时发热量很低，但如果芯片本体有明显发热，就要检查是不是有信号冲突或者电源异常。最典型的情况是把3.3V接到了VCCB或者5V接到了VCCA，导致芯片内部保护二极管导通，电流异常增大。还有一种情况是总线上的设备同时驱动一条信号线，比如两个设备都尝试把SDA拉高或拉低，造成信号冲突，芯片内部的NMOS在这种异常状态下会消耗较多电流。

遇到过芯片轻微发烫，摸上去温温的但不烫手，用热成像仪看了下，温度在45度左右。检查发现是5V侧IIC总线的上拉电阻取值太小（外部并联了1KΩ），导致平时总线上就有较大的静态电流。把外部上拉电阻去掉或者换成10KΩ后，温度恢复正常。所以如果芯片发热，别急着换片子，先检查外围电路。

7.6 常见问题速查表

8. TXS0104E以外的另一种思路：NMOS分立电平转换电路

8.1 NMOS电平转换电路原理

如果手头没有TXS0104E，或者项目对成本非常敏感，可以用两个NMOS管搭一个经典的双向电平转换电路。这个电路在嵌入式圈子流传很广，原理简单，成本很低。核心是两个NMOS管，每个通道需要两个管子加两个上拉电阻。

电路原理如下：3.3V侧信号通过一个10KΩ电阻上拉到3.3V，5V侧信号通过一个10KΩ电阻上拉到5V。两个NMOS管交叉连接，其中一个管子的栅极接3.3V，源极接3.3V侧信号，漏极接5V侧信号，另一个管子则反向连接。当3.3V侧信号拉低时，对应的NMOS导通，5V侧信号被拉低；当5V侧信号拉低时，另一个NMOS导通，3.3V侧信号被拉低。这样就实现了双向电平转换。

8.2 与TXS0104E的对比

NMOS分立电路的优势是成本低、电路透明、可以根据需要灵活调整参数，但它有一个明显的问题：工作速度受限于MOS管开关速度和栅极电容。我实测过，这种分立电路在100KHz以下工作时问题不大，但到了400KHz的IIC快速模式就开始吃力，信号边沿变得很缓，甚至有振铃现象。

相比之下，TXS0104E的优势在于集成了边沿加速电路和合理的上拉电阻，信号质量在同等条件下明显优于分立电路。如果项目对成本不敏感，或者对可靠性要求高，建议直接用TXS0104E，省心很多。如果只是做一个简单的实验，或者产品对BOM成本敏感，NMOS分立电路也是一个可以接受的方案。

8.3 分立电路的实际调试经验

我用NMOS分立电路做过一次方案验证，用的2N7002小信号MOS管。当时测试的是IIC总线，3.3V主控接5V传感器，通信速率为100KHz标准模式。实测下来，信号转换功能是正常的，裸板调试也都能通信，但波形边沿明显不如TXS0104E那么干净，尤其是在低温环境下，MOS管阈值电压漂移会导致信号质量进一步下降。

如果要用分立电路方案，有几点建议：选择导通电阻小的MOS管（如2N7002的Rds(on)在几百毫欧级别，对信号影响不大）；上拉电阻可以先用10KΩ，再根据波形调整；PCB走线尽量短，避免寄生电容和电感影响高速信号。当然，如果你在这个方案上遇到波形振铃或边沿过缓，用示波器确认是前级驱动能力不够还是MOS管开关速度不够，判断准确再动手优化。

9. 项目实战经验与最终建议

9.1 一个典型的混合电压项目复盘

我去年做的一个环境监测终端，主控用的是3.3V的GD32F303，需要同时驱动一个5V的串口GPS模块、一个5V的IIC温湿度传感器和一个5V的SPI Flash芯片用于数据存储。一开始我打算每个接口各用一种电平转换方案，后来发现太乱了，干脆统一用了一片TXS0104E，8个通道分配如下：串口TX/RX用了通道1和2，IIC的SDA/SCL用了通道3和4，SPI的SCK/MOSI/MISO/CS用了另一片TXS0104E的4个通道。

调试过程中最折腾的是SPI Flash的读写速度。5V Flash存储芯片的读指令速度可以达到几十MHz，但经过TXS0104E后速度上不去，我测了4MHz、8MHz、16MHz几个档位，最后稳定在4MHz才确保数据不出错。虽然不是最快，但在这个项目里存储数据的写入量不大，4MHz已经够用了。后来我反思了一下，其实可以选用3.3V供电的SPI Flash，这样根本不需要电平转换，但当时手头只有5V的库存，只好将就了。这个教训就是——方案设计阶段先把所有器件的电压域梳理清楚，能统一电压就统一，省掉电平转换这层环节，系统可靠性会更高。

9.2 电平转换芯片选型建议

根据我这几年做混合电压系统的经验，把常用场景的选型建议整理如下，供大家参考。

另外提醒一句，选型时不要只盯着芯片手册上标的最大速率，还要考虑信号完整性、走线长度、负载电容等因素。芯片手册上的参数是理想环境下的测试值，实际工程中打个对折比较稳妥。

9.3 关于电平转换方案的个人心得

第1次要求我重新整理语言。经过前面这些项目的反复折腾，我对电平转换这件事有了更深的理解。电平转换看起来是个很基础的功能，但在实际系统中，它往往是通信可靠性的瓶颈。我见过太多项目因为电平转换没做好，导致数据偶发错误、系统复位、通信超时，排查起来极其痛苦。

关于电平转换，我有三点体会最深刻。第一，优先从系统层面解决电压兼容问题，能统一供电电压就不要引入电平转换，减少一个环节就减少一分风险。第二，如果必须做电平转换，优先选用专用芯片而不是自己搭分立电路，信号完整性有保证，调试也省心。第三，无论用什么方案，示波器测量验证必不可少，不要相信“理论上应该没问题”，实测波形是衡量方案是否可行的唯一标准。

这些经验的积累都来自实际项目的踩坑和复盘，希望能帮正在做混合电压系统设计的你少走一些弯路。如果你正在调试电平转换电路，不妨按上面的思路先排查一遍，大概率能找到问题所在。