企业官网建设流程全解析

"展讯SPRD AT指令"这块资料，圈里流传的大多是零散截图或者某一平台的定制版文档，真正能跨平台通用的、讲清楚"为什么"的资料其实很少。这篇把我这些年在不同展讯方案上实际验证过的命令和排障经验整理出来，覆盖基础查询、私有扩展、脚本解析和实战坑点，给后面接手展讯平台的工程师省点时间。

1. 展讯平台的AT指令生态：标准命令、私有命令和版本坑

1.1 两条主线：3GPP标准命令与展讯私有扩展

展讯（SPRD，现在并入紫光展锐）平台的AT指令体系，本质上由两部分组成：一部分是3GPP TS 27.007和V.25ter定义的通用命令，比如AT+CSQ（信号强度）、AT+CREG（网络注册）、AT+CPIN（SIM卡状态）；另一部分是展讯自己定义的私有扩展命令，比如AT+NVRAM（NV存储读写）、AT+SPFM（FM相关）、AT+EFUN（工厂模式）。这两部分的可靠程度和文档完整度差距非常大——标准命令几乎每个平台都一致，但私有扩展命令在不同芯片平台、不同软件版本上经常改名或者改变参数含义。

我自己的体会是：标准命令是"保底口粮"，私有扩展命令才是展讯平台真正值钱、也最需要小心的地方。原因在于展讯给功能机、智能机、IoT模组提供的是整体交钥匙方案，很多工厂测试、产线校准、运营商定制功能都要靠私有AT通道完成，所以这些命令数量巨大，而且很多时候是方案商根据客户需求现加的。这意味着你拿到的文档只代表"该版本固件"支持的命令，换一个项目、换一版固件，命令集就可能变。

建议：拿到新平台的第一件事不是翻命令，而是先跑一遍AT+CLAC（列出所有支持的命令），把当前固件的真实命令集拉出来，再去跟手头的文档比对差异。这一步能省掉后面大量的"为什么文档和实际对不上"的困惑。

1.2 指令入口不只有UART：USB、蓝牙和AT通道的区别

展讯平台的AT指令入口，远比很多人以为的要复杂。最常见的是UART串口，这也是绝大多数开发板、模组的默认调试通道。但展讯的智能手机方案（比如UMS系列）和部分4G模组，AT指令还可以通过USB虚拟串口、蓝牙SPP，甚至通过内部共享内存接口来访问。重点在于：这些不同入口不等价。

以USB为例，展讯平台在正常开机后一般会枚举出多个端口，其中可能有/dev/ttyUSB0、/dev/ttyUSB1甚至更多，分别对应不同的业务通道（比如AT命令口、日志口、诊断口）。如果脚本连错了口，发送AT不会有任何回复，非常耽误排查。此外，展讯还有一个特殊的"下载模式"（Download Mode），在这个模式下USB枚举出的设备是下载口（通常用FDL工具和烧录工具通信），不能用来发AT指令。很多新人会把下载模式下的端口当成AT口，结果怎么发都没反应。

实操时的判断方法很简单：正常开机后，先用工具（串口助手或者ls /dev）观察所有枚举出的端口，然后逐个发AT\r\n，只有能返回OK的那个才是AT指令口。不要靠文档猜，因为不同项目的USB配置可能完全不同。

1.3 网上文档为什么经常对不上：平台代号、软件版本与文档版本

展讯平台的代号很杂，老一点的SC6531（2G功能机）、SC9820/SC9832（低端智能机）、再到后来的UMS9117/UMS9230等。不同平台之间的AT指令集差异，比同平台不同版本固件的差异还要大。尤其是一些偏底层的私有命令，比如NV读写命令AT+NVRAM，不同平台的NV项编号完全不同，你在SC6531上验证过的AT+NVRAM=xxx参数，拿到UMS系列上可能直接报ERROR。

还有一个很隐蔽的问题：展讯文档版本落后于固件版本。产线和新项目拿到的一般是预发布固件，里面可能已经加了新命令，但对外文档还是旧版；反过来也一样，文档里写了某条命令，新固件因为安全策略或功能调整把它删了，文档却还没更新。所以文档只能当参考，最终解释权在"当前固件实际行为"上。

我的做法是：每接手一个新项目，先固化一套"基线验证命令集"（大概20条左右，覆盖模块信息、SIM卡状态、网络注册、信号、电话本、短信、数据拨号），全部跑一遍并记录返回结果，作为后续所有工作的对照基准。

2. 基础查询命令组：拿到模组或板子之后必跑的检查清单

2.1 最小验证集：AT、ATE0、AT+CGMI/AT+CGMM/AT+CGMR

不管是用展讯模组还是整机板子，上电后第一件事永远是发AT确认通信链路通不通。链路通了之后，紧接着建议做两件事：发ATE0关闭命令回显，然后依次查询厂家、型号、版本信息。

• AT：通信握手，正常返回OK。
• ATE0：关闭回显。这个操作很重要，否则脚本解析时会把输入的AT+CGMI和返回的\r\nAT+CGMI\r\n...混在一起，增加解析难度。
• AT+CGMI：厂商信息，展讯平台通常返回UNISOC或Spreadtrum（老版本返回Spreadtrum）。
• AT+CGMM：具体型号，通常是模组型号或者芯片方案代号。
• AT+CGMR：软件版本号，这个字段在后续固件问题排查里非常关键，报bug给原厂或者方案商时，第一件事就是提供AT+CGMR的返回内容。

查询版本还有一个容易被忽略的点：直接发AT+CGMR可能只返回主版本号，有些展讯平台需要发AT+CGMR=?才能列出完整的版本信息，包括编译时间、GIT提交号等。包含编译时间这个信息在对比新旧固件时特别有用，排查"为什么固件升级了但问题还在"时，可以靠它确认固件是否真的刷进去了。

2.2 SIM卡、信号与网络状态检查

基础查询里，SIM卡和网络相关的命令是使用频次最高的，我列一组实际跑过的组合：

需要说明的是，AT+ICCID不是3GPP标准命令，但展讯平台基本都支持，很方便用来做整机测试时确认SIM卡是否插好、有没有读卡异常。AT+CSQ返回的第二个参数是误码率（一般恒为0），第一个参数才是信号强度，范围0-31。实测中，功能机平台通常在10-20之间属于正常弱信号地区，20以上算良好；低于10基本处于弱覆盖区域。

AT+CREG?的第二位参数是重点：0表示未注册、1表示已注册到本地网络、5表示已注册但处于漫游状态。排障时如果发现一直返回0，说明天线、SIM卡或者网络参数（比如频段配置）有问题，而不是AT指令本身的问题。

2.3 用AT+CLAC摸清当前固件的命令边界

AT+CLAC是我每到一个新平台必跑的第一条私有扩展命令（它也出现在标准V.25ter中）。它会列出当前固件支持的全部命令名，输出格式一般是+CLAC: AT+CGMI,AT+CGMM,...。因为展讯平台的私有命令太多，文档又不一定跟得上，这条命令就是"固件自身最权威的命令清单"。

实际使用中有三个经验：

1. 输出可能很长，串口工具要设置足够大的接收缓冲区，否则容易丢数据。建议用支持日志保存的工具，直接把返回内容存成文件。
2. AT+CLAC列出的只是命令名，不是参数说明。所以它帮你确定了"固件支持哪些命令"，但不能告诉你每条命令的具体参数格式。私有命令的参数还得靠文档、原厂FAE或者反推测试。
3. 个别展讯固件的AT+CLAC可能不列私有扩展命令（只列标准命令），这时可以尝试AT+CLAC=?。如果都不行，说明固件关闭了这个接口，只能靠文档和抓modem日志来补全了。

3. 展讯扩展命令里真正有价值的配置功能

3.1 AT+SP家族：厂商信息与工厂自检

展讯的私有命令里，AT+SP开头是一个庞大的命令族，不同命令用AT+SP...的完整命令名区分（类似AT+SPFM、AT+SPCAM这种命名方式），而不是统一加参数区分。这里说几个我在项目里真正用过的，以及它们的位置：

• AT+SP?：部分平台支持，返回软件版本、硬件版本、芯片版本等综合信息。不同于AT+CGMR，它更偏向硬件和方案层信息。
• 音频测试类命令：不同项目名称不同，常见的是AT+SPAUDIO、AT+SPSETVOICE，用于设置音频通路、音量、回音消除参数，常用于音频产线测试。
• 工厂自检类命令：一些定制方案会有AT+SPLCD（屏检测）、AT+SPTP（触摸检测）、AT+SPCAM（摄像头检测）这类一次性自检命令，产线通过它们快速判断硬件是否正常。

这里的核心建议是：不要试图背下所有AT+SP*命令，因为不同方案差异太大了。正确做法是先在AT+CLAC返回结果里搜索AT+SP开头的命令，再结合你手头项目的产线测试规范去理解。这类命令的参数格式没有统一规律，有些用十六进制传参数，有些直接传ASCII，务必以实测为准。

3.2 AT+EFUN、AT+CFUN、AT+NVRAM：功能模式与NV存储

展讯平台的AT+CFUN和标准平台类似，用来设置功能模式：AT+CFUN=0进入飞行模式，AT+CFUN=1恢复全功能。但展讯还有一个比较特殊的AT+EFUN，它和CFUN不是一回事——EFUN通常用于工厂模式切换，在某种情况下会关闭RIL（智能机平台上）或关闭协议栈的部分功能，导致电话短信不可用，但AT指令本身还能回。这类命令在量产测试中用来隔离其他业务、保证测试环境纯净，但普通调试时候千万别乱开。

AT+NVRAM是展讯平台一个非常底层、也非常危险的命令，用于读写NV（Non-Volatile，非易失性）存储项。NV项保存了RF校准参数、IMEI、MAC地址、运营商配置等信息。展讯平台的G2D（2G？）和智能机方案上NV项编号是完全不同的体系，同一个编号在不同平台可能代表完全不同的参数。

针对AT+NVRAM，我的经验是：

• 千万别靠猜。写NV项之前必须确认你查到的NV编号确实来自当前平台文档，最好先在另一台设备上备份所有NV值。
• 写完后不要立刻断电或者重启，等几秒钟再操作。NV写入实际是有中间过程的，有些项写完后需要soft reset（AT+CFUN=0再AT+CFUN=1）才能生效，直接断电可能只写了一半。
• 如果是为了改IMEI，AT+NVRAM并不是唯一途径，AT+EGMR（如果固件支持）才是相对标准的命令，而且改IMEI本身需要确认每个国家地区的法规合规性，别在生产环境里乱测。

3.3 音频、FM收音机与双卡相关的私有命令

展讯在功能机时代深度做音频和FM方案，所以相关命令特别多。音频层面，AT+CLVL是标准命令（设置通话音量），但展讯平台音频通路切换回音消除、麦克风增益等，往往靠AT+SPSETVOICE这类私有命令。如果做音频产测或者整机测试，拿到设备的音频校准规范是最快的路径，命令细节以规范为准，不要自己造参数。

FM收音机方面，展讯平台老方案有AT+SPFM相关命令，用于开关FM、调频、搜台等。实测中FM命令的返回比较慢，搜台操作可能需要好几秒，调试脚本时不要把AT超时时间设得太短。

双卡双待是展讯方案的一大特色。智能机平台一般不用AT命令管理双卡（走RIL内部接口），但功能机或IoT方案上，你可能需要用AT+CSIM（通用SIM访问）或者平台私有命令切换SIM卡槽、读取副卡状态。据我见过的情况，双卡相关私有命令在展讯各平台之间也不统一，而且和Modem配置（双卡单待还是双卡双待）强相关。如果是做整机或者模组方案，建议先确认当前固件的SIM卡方案，再去看对应的私有命令，不然很容易出现"主卡一切正常、副卡命令全部报错"的情况。

3.4 数据业务和TCP/IP协议栈：从NETOPEN到CIP系列

展讯平台在数据业务上的AT命令体系比较有特色。老一些的2G/3G模组方案里，常见的是AT+NETOPEN打开TCP/IP协议栈，然后用AT+CIPOPEN、AT+CIPSEND、AT+CIPCLOSE这组命令做TCP/UDP连接和数据收发；新一些的4G智能机方案则基本不走AT数据通道，而是用NDIS/RNDIS/ECM这种虚拟网卡方式拨号，AT指令只负责查询状态。

如果做IoT数据传输项目，我建议先确认模组是"AT指令直接承载TCP/IP"还是"AT+虚拟网卡拨号"模式。这两种模式的调试方法完全不同：

• 直接AT承载TCP/IP的模式：需要重点测协议栈稳定性，比如长时间AT+CIPSEND大数据包传输是否丢数据、TCP重连逻辑是否正常。
• 虚拟网卡模式：AT指令只用来做拨号和状态查询（类似AT+CGACT=1激活PDP），实际的TCP/IP业务跑在操作系统协议栈里。这种情况下，AT层的稳定性重点在拨号、断线重拨、APN配置，业务层问题反而要从系统网络侧排查。

实测中还遇到过一个坑：展讯部分平台对AT+CGDCONT（设置APN/PDP上下文）的参数有严格的字符集限制，APN内容不能带大写字母和特殊符号，否则会返回ERROR或者设置无效。排查数据业务不通时，如果AT+CGACT=1一直失败，先检查APN字符串是否跟运营商开通资料完全一致，再检查大小写。

4. 命令格式、回复解析和URC处理：脚本能写稳的关键

4.1 AT指令语法细节与缓冲区限制

AT指令从语法上分几种：无参数命令（如AT）、带参数命令（如AT+CPIN=1234）、查询命令（如AT+CPIN?）、测试命令（如AT+CPIN=?）。这个分类在基础文档里都有，但展讯平台实际处理时有几个细节值得注意：

• 命令行结尾是回\r（CR）而不是\n（换行），大多数串口工具会自动处理，但写脚本时如果发的是\n，展讯Modem可能不认。
• 命令行的最大长度因固件而异，一般不超过128字节或者256字节。长参数（比如写长短信、设置长APN）时要特别小心，超过缓冲区长度会直接ERROR。
• 展讯平台对命令输入大小写不敏感（at+csq和AT+CSQ一样），但返回的中间信息（如+CSQ: 18,0）通常是固定格式，解析时按实际返回处理。

我见过不少脚本问题都出在"串口工具显示正常，但脚本解析失败"上。原因往往是脚本把"\n"或"\r\n"当成命令结束符发送，而协议栈只认"\r"结尾。正确做法是命令行统一用"\r\n"结尾，虽然展讯对多余的LF通常不报错，但统一格式能避免特殊固件下的意外行为。

4.2 三类回复：OK/ERROR、+CME ERROR和URC

展讯平台对AT指令的回复可以分成三类：

第一类是简单结果码，OK表示成功，ERROR表示通用失败。这类最简单，但信息量少，出错时很难直接定位原因。

第二类是带错误码的返回，格式为+CME ERROR: <err>或者+CMS ERROR: <err>。要看到这类详细错误码，通常需要先发AT+CMEE=2开启详细错误信息。展讯平台对AT+CMEE=2的支持比较稳定，建议脚本初始化序列里固定加上。常见错误码比如+CME ERROR: 13（SIM卡故障）、+CME ERROR: 10（SIM未插入）等，排障效率比只看到ERROR高很多。

第三类是主动上报的URC（Unsolicited Result Code），它不需要你发命令就会自动过来，比如+CIEV: 5,1（信号强度变化）、+CREG: 1（网络注册状态变化）、+CMTI: "SM",1（新短信到达）、RING（来电）等。URC是脚本里最容易被忽略的干扰源——你发一条AT+CSQ，回复还没到，突然先来了一条+CIEV的URC，解析程序如果没有处理URC的逻辑，就会把数据对错位。

我的建议是：任何解析引擎都要先按"是否包含+CME ERROR、是否包含已知URC前缀"做一次分流，再进入正常回复解析流程。不要假设"发了命令之后，收到的所有内容都只属于这条命令"。

4.3 从查询到解析的完整脚本逻辑示例

下面是一段简单但可用的Python串口AT交互逻辑，重点不是代码本身多复杂，而是处理顺序能覆盖上面提到的三种回复类型：

import serial import time ser = serial.Serial("/dev/ttyUSB0", 115200, timeout=3) def send_at(cmd, wait_ms=500): ser.reset_input_buffer() ser.write((cmd + "\r\n").encode()) time.sleep(wait_ms / 1000.0) return ser.read_all().decode(errors="ignore") # 初始化 send_at("ATE0") send_at("AT+CMEE=2") # 查询信号强度，并处理可能混入的URC resp = send_at("AT+CSQ") for line in resp.splitlines(): if line.startswith("+CSQ:"): csq = line.split(":")[1].strip().split(",")[0] print("CSQ =", csq) elif line.startswith("+CME ERROR") or line == "ERROR": print("命令返回错误：", line) else: # 到达这里的可能是URC或命令回显，记录即可 print("其他内容：", line)

这段代码里用了reset_input_buffer()清空输入缓冲，避免上一次命令的残留数据干扰，这是一个实操中很有用的细节。timeout=3也很关键，展讯平台某些命令（比如网络注册查询在弱信号下）响应可能很慢，超时设短了会把正常命令误判为失败。实际项目中，我会建议把每条命令的超时做成可配置参数，和命令本身绑定：普通查询500ms-1s，网络操作和搜网、FM搜台这类操作给3-5s。

5. 实战踩坑记录：展讯平台AT调试里最难发现的问题

5.1 改波特率导致的"永久失联"

展讯平台多数支持AT+IPR动态修改UART波特率。听起来很方便，但这个命令非常容易坑人。我之前在调试一块展讯4G模组时，想从115200改成460800提速，发了AT+IPR=460800，返回OK后串口助手还没来得及切换波特率，驱动就把波特率改了，结果就是两边速率不一致，终端上再也看不到任何回复，只能断电重启。

正确流程是：先把后面要用的大批量操作的波特率策略定好，在整机初始化配置阶段一次性设置，并且设置完要立即在同一个环节把串口工具或脚本的波特率同步切换掉。如果只是临时调试大数据量日志，建议不要改波特率，而是用其他方式（比如抓USB日志或者文件日志）来规避。另外，展讯平台改波特率后是否自动保存到NV，不同固件行为也不一样，有的重启后会恢复默认值，有的会一直保持。千万不要在产线流程里依赖"改完波特率就永久生效"这个假设。

5.2 NVRAM写入后立刻重启，配置丢失

前面提到AT+NVRAM写入后不能立刻断电重启，这里展开说一下原因和现象。我在一次产线调试中遇到一个间歇性bug：写入RF校准参数后，接着执行自动重启，重启后参数时有时无。后来抓Modem日志发现，NV写入实际是先写缓存再落盘，重启指令如果在落盘动作完成前触发，缓存数据会丢失。

规避方法很简单：AT+NVRAM写入后，先发一条AT+CFUN=4（如果支持）或者延时2-3秒，确认没有异常再触发重启。也可以用上一章节提到的方式，通过查询命令把刚写入的NV项读回来确认一遍，读回来一致再继续下一步。这条"写后必读、确认再重启"的经验，在整个展讯平台的NV和校准参数调试里几乎是通用法则。

5.3 URC上报时机与命令时序冲突

展讯Modem的URC上报没有严格的和命令回复强制隔离。最典型的场景是做自动化测试时，脚本发ATD10086;拨号，结果在等待拨号结果的过程中，突然收到一条+CIEV: 3,0的URC（当前通话状态变化），如果脚本这时还在等待完整的OK或+CME ERROR，就容易超时误判。

处理思路不是去禁用URC（很多URC关不掉），而是把超时时间放宽，并在解析逻辑中单独处理URC。如果自动化测试对时序非常敏感，可以考虑在测试前通过AT+CSVM?（语音邮箱）、AT+CLIP?（来电显示）这类命令将非必要通知关掉，但这只对部分URC有效。最重要的一点是：不要在每次命令发送前直接sleep固定时间然后读串口，而是应该"读串口直到等到目标响应或超时"。

5.4 选错AT通道，连上了却收不到任何回复

我在文章开头提过展讯设备可能同时存在多个串口。这里再说一个更隐蔽的变体：有些展讯智能机方案的"AT命令口"和"AGPS数据口"复用同一个USB端口，需要特定的打开方式（比如先发一个特殊转义序列）才能进入AT模式。我遇到过一次：设备枚举出一个ttyUSB2，打开后能正常收到日志，但发AT指令完全没有响应，后来看了方案商文档才知道这个口当前是日志模式，需要通过特定指令切换。这种情况靠AT+CLAC是测不出来的，只能靠查方案文档或者找原厂FAE确认。

给一个新项目的排查建议：上电开机后，把枚举出的每个口都试一遍，把"哪个口对应AT"记录下来，不要想当然认为ttyUSB0就一定是AT口。

6. 可复用的AT排障链路：从异常日志倒推根因

6.1 按顺序排查，不要跳步

展讯平台AT层出问题，绝大多数根因是以下五类之一，而且排查顺序特别重要，跳步容易浪费时间：

1. 通信链路问题：串口接线、波特率、通道选择。先用最基础的AT握手确认链路，链路不通什么都别谈。
2. 固件状态问题：设备是否处于飞行模式、是否注册网络、SIM卡是否识别。按AT+CPIN?、AT+CFUN?、AT+CREG?的顺序依次检查。
3. 参数配置问题：APN、频段、运营商配置。这类问题在数据业务和网络注册异常时优先排查。
4. 业务逻辑问题：电话、短信、数据连接时序。这类问题需要结合日志分析，不是单纯AT交互能解决的。
5. 硬件/RF问题：天线、射频校准、SIM卡接触。当AT+CSQ持续为99（无法读取信号）或AT+CPIN?一直NO SIM时，优先怀疑硬件。

这套顺序听起来像废话，但实际项目里我见过太多人一上来就怀疑固件版本，刷了好几个版本才发现是串口波特率设错了。建议把上面五个层次做成一个检查表，每次排障都按表格走一遍，避免被直觉带偏。

6.2 把AT日志固化成标准检查单

我个人习惯是：每次项目进入系统联调前，先固化一份AT标准检查单，包含以下内容：

• 软件版本信息（AT+CGMR、AT+CGMM）
• SIM卡状态和ICCID
• 网络注册状态和当前运营商
• 信号强度
• 关键业务路径（拨号、短信收发、数据拨号各来一轮）
• 异常场景的AT日志保存（比如断网重连、SIM卡热插拔）

这样做的好处是，当现场报"设备无法联网"这类模糊问题时，我可以直接让现场按检查单跑一遍，把结果发回来。比起远程反复指导、让对方到处试，这种方法几乎能手到病除。而且这些检查记录长期积累下来，还能作为固件版本升级后的回归基线，判断新固件到底有没有引入兼容性问题。

另外建议在日志保存上统一格式：每行带上时间戳，命令前加-->，回复前加<--。这个习惯能让你在翻日志时一眼看出命令时序和URC插入点，排障效率会提升很多。简单地说，不要只在出问题时才开始记录AT日志，把它变成日常调试的标准动作。