EC20 4G模块TCP透传配置详解：从AT指令到稳定链路搭建

简介：面向STM32F4嵌入式开发者的EC20 4G模块TCP透传通信完整工程资源，采用MDK/KEIL工程结构，重点解决在Cortex-M4平台上通过AT指令配置EC20、完成串口对接并建立Socket数据通道的实际问题。无论刚开始接触4G透传开发，还是需要在现有项目中快速集成无线通信功能，都可以把这套代码作为直接参考模板。压缩包共174个文件，整体大小约4.06MB；核心为48个C源文件与46个头文件，覆盖芯片启动、标准外设库驱动、EC20模组控制和应用层逻辑，另外还提供uvproj工程、hex/axf可烧写文件、map/sct链接信息、批处理脚本与开发环境记录，方便直接导入工程、核对输出或完成固件下载。目前已有1347人学习浏览，适合正在做4G模块接入与透传开发的嵌入式工程师。研读源码时可以系统理解透传模式工作流程，包括PDP上下文配置、TCP连接建立、数据收发、错误监测、心跳保活与连接释放；工程内的UART调度和AT指令封装也能直接复用，有效降低重复调试成本，加快物联网透传功能落地。

1. 项目概述：拿到“EC20 使用TCP透传模式通讯.rar”之后要做什么

看到这个压缩包名字，估计不少做过4G联网设备的工程师都会心一笑：EC20模块的TCP透传配置，说难不难，但真要把它调通、调稳，邮件里翻来覆去的问题还真不少。我是做工业数据采集的，这几年用EC20做过DTU、做过远程PLC调试盒子，也帮客户处理过各种“连得上但传不了”“传几下就断”的怪问题。这份资料其实就是围绕一个核心需求展开的：怎么把EC20模块的串口数据，通过标准的TCP连接，原封不动地送到远端服务器上。

EC20是移远通信的LTE Cat 4模块，下行理论速率150Mbps、上行50Mbps，4G全网通，在工业场景里非常常见。传统做法是单片机里直接跑TCP/IP协议栈，但这对资源有限、又要快速上量的项目来说太不划算了。EC20自带协议栈，我们只要通过AT指令让它建立TCP连接，再开启透传模式，模块就成了一个“串口转TCP的透明管道”：串口收到的数据直接封包发出去，服务器下发的数据也直接吐到串口。代码里根本不需要关心TCP报文、重传、滑动窗口这些细节。

这篇内容适合谁呢？第一类是在做4G DTU、远程数采、工业网关的硬件工程师；第二类是给PLC、单片机设备加4G模块做远程调试的嵌入式开发；第三类是刚接触AT指令、被各种错误码搞到头疼的入门选手。整篇会把硬件接线、AT指令流程、透传机制原理、常见坑位一次讲清楚，照着做基本能把链路打通。

另外多说一句，这个压缩包里一般会有一个AT指令配置文档、一个串口调试截图，可能还有一小段MCU侧的示例代码。真正值钱的不是那些零碎的命令，而是理解透传模式的建立流程和排障逻辑，这也是我这篇想重点展开的东西。

2. 硬件连线、开机与基础参数准备

2.1 供电、天线和SIM卡，三个最常见的翻车点

EC20这颗模块看着不大，但千万别小看它的供电需求。典型工作电压3.4V-4.3V，推荐3.8V，但瞬时发射电流能冲到2A以上。我用过USB转TTL的3.3V输出直接供电，结果模块怎么都不开机，量电压才发现一发射就掉到2.8V。正确做法是用DC-DC降压芯片或者LDO，输出电流至少留3A余量，模块的VBAT引脚附近并一颗470uF以上的电解电容，再并几颗100nF去耦电容，扛住突发电流。

天线这块也是个隐形炸弹。EC20的主天线是必须接的，否则信号强度AT+CSQ查出来往往是99，也就是根本检测不到网络。注意天线馈线不能太长，不能跟电源线捆在一起，阻抗要匹配。我以前在样机里图省事，用一根裸线当天线，结果模块信号弱到只有2格，电话都拨不出去。

SIM卡方面，EC20支持1.8V和3V的SIM卡，大多数开发板有卡座，但要注意接触是否良好。最关键的是运营商物联卡。普通手机卡默认APN能用，但很多物联卡有专门APN，比如某些卡要设成公共APN或者企业定制APN，这个建议直接问运营商要。APN配错了，模块能注册上网络（CREG返回1或5），但上不了网，TCP连接自然建不起来，这是新手最容易卡住的地方。

2.2 串口接线与波特率确认

EC20的UART电平是1.8V，不是常见的3.3V。如果你的MCU是3.3V系统，直接接线存在电平不匹配的风险，严谨的方案是加TXS0108之类的电平转换芯片。很多现成开发板已经内置了电平转换，但自己做板子时容易忽略这一点。串口至少要接TXD、RXD、GND三根线，调试时USB转串口模块要选支持1.8V的，或者用开发板上的串口调试电路，否则收不到模块的任何回显。

波特率默认值因固件版本而异，常见的是115200和9600。上电后用AT指令和模块对齐波特率，如果串口助手一通乱码，就换个常用波特率试试。实测下来115200最稳妥，传输大数据包时不容易成为瓶颈。模块上电后可以先发一个不带回车换行的“AT”，很多模块对纯回车符响应不确定，建议用“AT\r\n”的格式。收到OK，说明串口通路没有问题。

2.3 先用基础AT指令确认模块活着

开机之前先确认引脚上电时序：VBAT先供电，等稳定后PWRKEY拉低至少500ms再松开，模块才会启动。上电后可以用NET_STATUS引脚判断状态，指示灯按固定周期闪烁：如果灯以64ms周期快速闪，说明模块还没注册上网络；如果变成1.8s周期的慢闪，说明已经入网。这个状态灯比任何调试信息都直观。

模块正常启动后，先跑一轮基础AT指令，避免后面连不上时分不清是配置问题还是网络问题：

这里特别说一下AT+CSQ的读数。一般要求返回至少10以上才敢开始建TCP，如果只有3以下，就算连上也是秒断。AT+CGDCONT的设置建议开机就确认一遍，尤其是换SIM卡之后。比如默认卡APN是cmnet，你就要发AT+CGDCONT=1,"IP","cmnet",然后等着PDP激活，再继续下一步操作。

3. EC20 TCP透传模式核心机制拆解

3.1 模块侧协议栈与AT直连方式的区别

先理解一个概念：EC20内部自带TCP/IP协议栈，所有网络层、传输层的脏活累活都交给了模块，MCU只需要通过串口跟模块对话。对话方式有两种，一种是传统的AT指令直连模式，发一次数据要AT+QISEND，再等模块返回确认，接收数据还要解析URC上报，同时还要处理缓冲区满、ACK等待等状态；另一种就是本篇主角透传模式。

直连模式适合数据交互复杂的场合，因为每一包数据都有明确的指令层反馈，但代价是MCU侧要写不少逻辑。透传模式则简单粗暴得多：你提前配好远端服务器IP和端口，建立好TCP连接，然后给模块发一条指令进入透传状态。从这一刻起，模块的串口就像一根网线，MCU把业务数据往串口一丢，模块自动帮你打包成TCP包发出去；服务器发来的数据也自动从串口吐出来。对于Modbus RTU采集、PLC远程上下载程序这类场景，这种透明管道是最省事的方案。

选TCP而不是UDP的原因也得想清楚。EC20也支持UDP，但工业远程控制、PLC远程调试这类业务对可靠交付要求高，TCP的三次握手、确认重传、拥塞控制都是现成的保障机制，模块固件已经把TCP/IP协议栈调教得很稳了，没必要自己在上层补一套可靠传输方案。

3.2 透传模式的进入、退出与判定机制

进入透传模式，不同固件版本的命令略有差异。老版本EC20（以及早期的UC20）常用这样的组合：

AT+QICSET=1,"TCP","服务器IP",8080 AT+QIMODE=1 AT+QIOPEN=1

先通过QICSET把拨号参数配置好，把模式设置成透传，再发起连接。连接一旦建立，模块自动进入透传状态。而新固件推荐的流程是先建连接再开透传：

AT+QIOPEN=1,0,"TCP","服务器IP",8080,0,0 // 返回 CONNECT OK 后，再执行 AT+QIMODE=1

如果你的模块执行AT+QIMODE=1返回ERROR，不要慌，大概率是固件版本不支持这个命令或者语法有差异。这时候可以用AT+QISEND=0进入“批量发送模式”，虽然命令名不叫透传，但配合服务器端的数据下发，实际体验也很接近。我建议拿到模块后先发ATI查一下固件版本，去移远官网下载对应的AT指令手册，以手册为准，不要硬套网上的老教程。

退出透传模式的固定密码是+++。在透传状态下，连续发送三个加号，模块会退出透传回到AT模式，等待你的下一条指令。这里有几个细节必须注意：

• +++前后各留出至少300ms的空闲时间，如果紧跟着数据发送，模块会把这几个加号当成业务数据发出去
• 退出透传后原TCP连接不会断开，你可以执行AT+QIMODE=1再次进入透传，不需要重新QIOPEN
• 想完全断开TCP就执行AT+QICLOSE，或者直接AT+QIDEACT关闭PDP上下文

判定当前是否处于透传状态，可以发AT+QIMODE?查询，返回0表示AT模式，返回1表示透传模式。这个命令在排查“为什么我发了数据服务器没收到”的时候特别有用，很多问题是模块某次误触发了+++早就退出了透传。

3.3 关键参数：APN、端口、Keepalive与缓存

透传模式看似是把串口数据“无脑”发出去，但底下有几个参数直接决定了链路稳不稳。

第一个是APN。APN不对，PDP上下文激活不了，TCP就无从谈起。设备重启后模块的APN配置会丢失，所以MCU初始化代码里必须包含AT+CGDCONT的设置，不能指望手动配置一次永久生效。

第二个是连接参数。服务器IP、端口必须写对；如果用域名，部分固件支持AT+QIDNSG或类似命令解析域名，但为了稳定，我通常建议直接填IP，省去DNS解析环节。DNS出问题会导致connect超时，且不好排查。

第三个是Keepalive。运营商NAT会回收长时间无流量的连接，所以模块和服务器之间需要保活机制。两条路并行：模块侧开启TCP Keepalive，配置空闲检测周期，比如每30秒发一个探测包；同时在业务层设计心跳，比如每20秒发送一个简短的心跳帧，服务器端超时60秒没收到心跳就判定连接失效并关闭。双保险的效果最好，单靠哪一边都不太够。

第四个是串口缓存。模块内部的TCP发送缓冲区是有限的，串口来数据的速度大于网络发送速度时，缓冲区会满。这时候继续灌数据就会丢。解决思路很简单：控制上位机或MCU的发送节奏，按帧发送，帧与帧之间留出间隔；或者直接把波特率提到230400、460800，降低数据堆积概率。硬件流控CTS/RTS也能缓解，但很多设备根本没接这两个引脚。

4. 实操配置流程：从透传准备到业务数据打通

4.1 模块初始化：找网、查信号、注册

这里给一套我自己一直在用的初始化流程，按顺序往下走，一般不会出问题。

第一步，上电等待模块开机，AT指令有回显后，先检查SIM卡：

AT+CPIN? +CPIN: READY OK

如果返回ERROR或者提示SIM卡未插入，先检查卡座接触和卡的方向。接着查信号和网络注册：

AT+CSQ +CSQ: 18,0 AT+CREG? +CREG: 1,1

CSQ的第一个数值18代表信号强度，0-31之间，越大越好。CREG返回1表示注册上网络。这两个条件满足后，再配置APN：

AT+CGDCONT=1,"IP","cmnet" OK

有的固件还需要激活PDP上下文：AT+CGACT=1,1，返回OK后可以用AT+CGACT?查询激活状态。这里有个容易被忽略的点：如果换了一张SIM卡，尤其从普通手机卡换成物联卡，原来的PDP上下文可能还在但APN不对，最好先执行AT+CGACT=0,1去激活，再重新配置APN并激活，避免旧配置残留。

4.2 配置远端地址并建立TCP连接

确认网络通路正常之后，开始建立TCP连接。新固件用QIOPEN命令，比如连一台IP为47.100.20.30、端口为8080的服务器：

AT+QIOPEN=1,0,"TCP","47.100.20.30",8080,0,0 OK CONNECT OK

等模块返回CONNECT OK，说明TCP三次握手已经完成。这里要注意，模块和服务器之间消息交互可能稍微慢，发送命令后要给足等待时间，不要急着发下一条。

如果一直不返回CONNECT OK，要么是服务器端端口没监听，要么是中间防火墙把SYN包丢了。排查方法可以用AT+QPING=服务器IP命令，一发就能看出能不能ping通。能ping通但连接不上，基本就是端口问题或者服务器防火墙策略问题。之前我碰到过一个云服务器案例，端口明明监听了，TCP连接就是建不起来，最后查出来是云平台的安全组没放行入方向端口。这个跟模块没关系，但很容易伪装成“模块连不上”的假象。

4.3 开启透传模式并验证双向数据

连接建立后，执行AT+QIMODE=1，返回OK，模块就进入透传模式了。为了验证链路是否真正通透，我习惯先在服务器端开一个网络调试助手监听端口，然后再从MCU侧发一串测试数据。注意网络调试助手的编码格式要选对，比如发Hex的01 03 00 00 00 01 84 0A，服务器端要能原样收到这一帧。

反向验证也很重要。在服务器端的调试助手里发一串ASCII或Hex数据，观察模块串口有没有吐出来。如果串口没有输出，先按+++退出透传，看看模块是不是还活着，再用AT+QICLOSE关闭连接重新来一遍。很多看起来是“透传不正常”的问题，其实是模块早掉线了或者退出了透传，而设备端状态机没有发现。

双向数据确认没问题后，可以把串口接到实际设备上，比如接一个RS485转UART模块，后面挂一个走Modbus RTU协议的PLC。这时候整个链路就是PLC的裸串口数据，经由RS485、UART、EC20模块、4G网络、TCP、服务器，最后服务器端再解析帧。整个过程不需要在MCU里做任何协议转换，这就是透传最爽的地方。

4.4 与服务器端配合：端口监听与报文协议设计

透传模式只保证数据“原样到达”，不保证业务含义。服务器端要自己设计监听程序，市面上常用的有C#写的TCP服务端、工业级网口通讯助手、SocketTool等，调试阶段先用现成工具验证链路，再上自己的服务程序。我见过不少项目才写几行服务端代码就开始调试，出了问题根本分不清是上层的bug还是底层链路的问题。

报文协议设计建议参考Modbus的风格，尽量“短帧、多帧、带校验”。比如一条完整帧包括帧头、设备ID、功能码、数据长度、数据体、CRC校验。原因很简单：TCP是字节流，没有消息边界，服务器必须靠帧格式自己分包；同时4G网络存在延迟抖动，超时重发策略要设计合理，超时时间按最坏链路延迟来设定，不要按局域网那套几十毫秒的阈值。

更进一步，如果服务器端支持Modbus TCP，而现场设备是Modbus RTU，需要在服务器侧做协议转换网关，把收到的Modbus RTU帧剥掉CRC，加上MBAP头变成Modbus TCP帧，再转发给上层的SCADA系统。这是4G DTU接入工业网络最常见的架构，我经手过的项目里至少有一半是这么做的。

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

5.1 模块能注册网络但TCP connect一直超时

这个现象太典型了：AT+CSQ信号挺好，AT+CREG?返回1，但AT+QIOPEN等半天没有CONNECT OK，最后直接返回超时错误。排查顺序我排一下，按这个顺序来基本都能定位：

1. 先用AT+QPING=服务器IP，检查网络层通不通。ping不通说明PDP上下文没激活或者APN有问题，检查AT+CGACT?和AT+CGDCONT?。
2. 能ping通，但端口连不上，检查服务器端端口是否在监听。在服务器本机执行netstat -an | grep 端口号就能确认。
3. 云服务器要同时检查系统防火墙和云平台安全组，两者都要放行入方向的TCP端口，缺一不可。
4. 确认模块使用的是公共IP而非内网IP，如果服务器在NAT后面，模块自然连不上内网地址。

这个排查清单帮我把“看起来是模块问题”的case缩减了至少一半。TCP connect超时的大部分原因在链路中间，根本到不了模块协议栈。

5.2 连接建立了，跑一段时间就掉线

掉线问题在4G场景里是高频故障，主要原因有三个。第一，运营商NAT空闲超时，长时间没有数据流量的TCP连接会被网络设备回收。解决方法是业务层心跳加模块Keepalive双保险，心跳间隔建议小于30秒。第二，信号不稳定，尤其移动场景或者天线位置不对造成的临时性网络中断。第三，服务器端主动断开，比如服务程序设置了超时回收，或者程序重启导致旧连接失效。

模块掉线后，被动等它自动重连是不现实的。EC20的透传模式本身没有内置自动重连策略（至少我用的固件版本是这样），需要MCU侧做状态监测。我的做法是设计一个简单的状态机：正常情况下每5秒发一个心跳帧，服务器侧超过60秒没收到就标记失联；MCU侧如果发出数据后一段时间内没有收到业务响应，就尝试发送+++退出透传，然后执行AT+QICLOSE，重新走QIOPEN流程。重连间隔做成递增退避，比如第1次立即重试，第2次等5秒，第3次等30秒，避免频繁重连把服务器打挂。

5.3 透传模式下串口收到乱数据或者丢数据

透传模式下，模块把服务器下发数据直接送给MCU，不会做协议约束。如果你的服务器端误发了一些二进制控制字符，比如0x1A,0x03这些，MCU走串口中断接收时可能会被干扰。我遇到过数据里包含回车符号，把单片机串口接收缓冲区搞出了歧义的情况。

排查手段是先用一段已知字节序列做环回测试：服务器下发固定的Hex数据包，看MCU收到的字节数对不对，顺序对不对。丢字节通常不是模块问题，而是串口缓冲区和CPU处理不及时的问题，建议把MCU串口接收改成DMA+FIFO，不要让字节一个个丢失。还有一个常见坑：MCU发送端在进入透传模式后，可能会因为误发了“+++”而意外退出透传。这是一个很恶心的问题，解决办法是MCU在组帧时注意转义，或者发送数据前确保帧内容里没有连续三个加号，如果业务数据确实可能出现，就拆分两段发送，中间加一个极短延时，让模块不认为这是退出序列。

5.4 模块重启之后连不上，要手动重新配置

EC20的AT命令配置大多不保存到flash，掉电即失。所以设备上电后必须由MCU重新执行一遍初始化流程：检查SIM卡（AT+CPIN?）、查信号（AT+CSQ）、注册（AT+CREG?）、配APN、激活PDP、QIOPEN建连、再进入透传。整套流程建议固化成一个联网状态机函数，按顺序调用，每一步都有返回判断，失败就重试相应的上一步，不要从头盲目跑一遍，也不要无脑延时等待。

我在自己的项目里是这么安排的：上电后先AT+CPIN?等待READY，再等CREG返回1或5，然后激活PDP，之后用一个循环尝试QIOPEN。如果连续5次都失败，把错误码通过日志打印出来，方便现场定位。这个状态下重启模块的操作我特意留了，实际干活时你会感谢这个功能的——很多莫名其妙的问题，重启一次模块就恢复了。

写在最后的一点个人体会

调EC20透传模式这些年，我最大的感触就是：透传模式本身不复杂，真正的技术含量全在“链路健壮性”上。模块只是把数据搬过去，但要不要保证不丢、断了怎么重连、异常了怎么恢复、改了运营商卡怎么适配——这些才是产品能不能稳定交付的关键。建议不要被网络上那些零散的AT命令教程带偏，先从通链路开始，再逐步把状态监测、心跳、重连机制补起来。

最后再分享一个我自己的习惯：每个项目我会做一张AT指令排查速查表，按“初始化—注册—拨号—建连—透传—异常处理”六个阶段列出当前状态的预期返回值，现场调试时对着表看，比翻PDF快得多。这个习惯救过我很多次，也建议你试试。

本文还有配套的精品资源，点击获取