STM32F407+移远EC20基站定位实战：从AT指令到坐标输出

简介：一份面向嵌入式开发者的STM32F407加移远EC20基站定位项目源码，定位场景包括车载追踪、远程监控、资产定位等物联网应用。工程完整展示MCU通过串口与EC20模块交互的流程：发送AT指令完成信号测量，解析基站ID、信号强度与到达时间差，随后运用三角定位或TDOA算法计算设备经纬度，并对外输出位置结果。代码覆盖通信状态机、异常重试等实用逻辑，适合有STM32标准库或HAL库基础的学习者移植参考。压缩包共220个文件，核心为63个头文件与51个C源文件，同时附有Keil工程、编译生成的HEX与AXF固件、MAP映射以及CRF、O等中间文件，便于对比查看编译链接全过程，包体仅10.9MB。已有435人学习下载，若正面临4G模块基站定位落地难题，可从中获取AT指令交互、信令解析和定位算法的具体实现，也可复用其中的应答解析框架，快速迁移至其他单片机或通信模组。 _项目管理笔记：STM32F407 + 移远EC20 基站定位，从AT指令到坐标输出

做物联网设备的定位功能时，GPS在室内和城市峡谷里经常拉胯，所以我在这套方案里直接用4G模组自带的基站定位能力。前两天刚把STM32F407和移远EC20这套组合调通，从发AT指令到解析基站数据再到把经纬度算出来，整条链路我已经跑通了。今天把源代码思路、关键AT指令、解析流程和踩过的坑整理出来，给需要在STM32上做基站定位的朋友一个参考。

这套方案特别适合三类人：一是刚接触4G模组AT指令开发，想看看完整闭环做法的嵌入式新手；二是手头项目本来就用了移远模组，想在现有硬件上白嫖一个定位功能的工程师；三是做资产追踪、共享设备、户外采集这类不需要高精度定位的产品的开发者。基站定位精度通常在几十米到几百米级别，但胜在室内能工作、冷启动快、不额外增加硬件成本。

1. 项目整体设计与方案选型

1.1 为什么用EC20做基站定位

先说说方案选型。EC20是移远的4G全网通模组，支持LTE Cat 4，理论下行150Mbps。它本身不带GPS（EC20有带GPS的版本，比如EC20-CE，但我们这次用的是标准版），可是它可以从网络侧拿到当前服务小区的基站信息。这个能力是模组在正常入网通信时就天然具备的，Baseband处理器在和基站交互信令时，RRC层就会维护一份小区广播信息，所以不需要额外硬件，只需要通过AT指令把内部的小区参数读出来即可。

STM32F407这边，主频168MHz，Cortex-M4内核，配置了512KB Flash和192KB RAM，拿来跑AT指令解析和协议栈绰绰有余。其实用F103也能干这活儿，但F407的串口数量更多，USART1到USART6一共6个，而且有硬件流控支持，后面如果还要挂GPS模块、LoRa、WiFi模块，接口充足。

对比一下几种常见定位方式的适用场景：

EC20基站定位的精度虽然不如GPS，但优势在于：不需要额外焊接有源天线、不需要等待星历下载、在地下室和隧道里也能报位置（只要有2G/4G信号）。用在共享单车电子围栏、物流资产追踪这些场景，这个精度完全够了。

1.2 基站定位的原理

基站定位的核心思路很简单：收集模组当前驻留的小区信息，包括MCC（移动国家码）、MNC（移动网络码）、LAC（位置区码）和Cell ID（小区编号），然后到基站经纬度数据库里查表，找到这个小区对应的位置坐标。

单个小区定位的误差较大，因为一个宏基站的覆盖半径可能从几百米到几公里不等。所以实际工程中，通常还会通过AT指令主动扫描邻区，拿到邻区的小区ID和信号强度，然后做加权平均——简单来说就是距离近的基站权重高，距离远的权重低。这就好比你在一栋楼里，只看你连上的WiFi名字判断楼层容易出错，但如果同时看到周围好几个WiFi的信号强度，就能大致判断自己所在的位置。

MCC、MNC、LAC、CellID这四个字段就是基站数据库的"主键"，缺一不可。MCC+MNCS唯一确定一个运营商网络，LAC是位置区编号，CellID是小区唯一编号。需要在云端做一个四元组到经纬度的映射查询，这也是整个方案里唯一依赖外部服务的地方。

1.3 系统架构和数据流

整体数据流这样走：

EC20模组 <---AT指令---> STM32F407 <---解析四元组---> 基站ID查询 <---返回经纬度---> STM32F407 <---串口/网络---> 业务终端

STM32F407通过USART3和EC20连接，波特率115200，通过AT指令集控制模组。STM32发送AT指令查询服务小区和邻区信息，EC20返回的ASCII字符串由串口中断逐字节接收，F407在内存里做字符串解析，提取MCC/MNC/LAC/CellID四元组，再组装成HTTP协议请求发给云端的基站数据库服务，从HTTP响应里解析出经纬度，最后把结构化的定位结果输出给主控业务逻辑。

这里有个关键设计决策：基站数据库查询放在模组内做还是放在F407上做？我的方案是让F407通过EC20的TCP/IP透传能力，直接以HTTP POST形式请求云端API。这样做的好处是，F407端不用维护庞大的基站数据库，Flash只有512KB，装不下全网的基站信息，固件升级也方便。EC20做TCP连接配合HTTP协议是完全够用的。

2. 硬件连接与AT指令基础

2.1 引脚连接与电路设计

EC20模组是LGA封装，需要自己打板或使用官方转接板。核心引脚如下：

• VCC：3.4V~4.3V，推荐4V供电，峰值电流2A，需要大电容稳压
• USIM：接SIM卡，需要ESD保护器件
• UART_RX（Pin 17）/UART_TX（Pin 18）：默认3.3V电平，和STM32F407的USART3对接
• PWRKEY：开机脉冲信号，拉低500ms触发开机
• RESET：复位信号
• VDD_EXT：1.8V电平输出，不要和3.3V系统直接混用

这里重点提醒一下：EC20默认串口电平是3.3V，虽然和STM32F407的IO电平兼容，但最好在TX/RX线上串联33欧姆电阻，防止模组上电瞬时电流冲击MCU引脚。PWRKEY建议用MCU的GPIO通过一个NMOS管来控制，不要直接推挽驱动，因为模组内部PWRKEY寄存器是1.8V域，直接灌3.3V可能损坏。

我当时用的正点原子探索者STM32F407开发板，板上已经引出了USART3的PB10和PB11，刚好可以接EC20。别光看丝印号，我踩过一次坑——F407探索者开发板的V2和V3不同版本，USART3排针的位置不一样，接线之前用万用表量一下PB10和PB11导通到哪根排针，或者看板子背面的丝印标识。

2.2 EC20的AT指令体系

EC20支持标准的3GPP TS 27.007指令，外加移远自定义的增强指令（以+Q开头）。对基站定位来说，用到的是这一组核心指令：

特别注意，EC20有两个指令序列，旧版本用AT+Cxxx，新版本固件推荐用AT+Qxxx。我用的EC20 R2.1版本固件，官方最新版AT指令手册里主推AT+QENG指令，如果你手里的模组固件版本太老不支持，可以刷固件或者用旧的AT+QCELLLOC等指令代替。

2.3 串口通信设计

STM32F407和EC20之间的串口通信，我选择用DMA+空闲中断的方式接收不定长数据。相比最简单的逐字节中断接收，DMA方式有两个好处：一是CPU不用每条指令都在中断里进出，数据到了内存之后只需要在空闲中断里一次性处理，CPU占用率从直接收发模式下的10%降到不到1%；二是不容易丢数据，只要DMA接收缓冲区够大（我设置的是2048字节），EC20一次返回的几百字节AT响应完全塞得下，不会因为中断服务函数处理耗时导致溢出。

硬件连接表：

我在代码里把串口初始化的波特率设为115200，8N1格式。这个波特率对EC20来说很稳，太高（如921600）对布线要求高，太低（如9600）在大量AT响应时延时会拖慢整体响应速度，115200是实际工程里用得最多的值。

3. 核心代码逻辑与实现

3.1 串口驱动与数据接收

串口驱动的核心是用DMA把EC20发来的数据搬运到内存，然后通过USART空闲中断（IDLE Line Interrupt）判断一帧数据接收完毕。这段代码是整个项目的地基，必须跑得稳。

// USART3初始化配置，挂在APB1上，时钟84MHz // 波特率115200，8N1，开启DMA接收 void EC20_USART3_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; USART_InitTypeDef USART_InitStructure; DMA_InitTypeDef DMA_InitStructure; NVIC_InitTypeDef NVIC_InitStructure; // 使能时钟: GPIOB, USART3, DMA1 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART3, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_DMA1, ENABLE); // Pin PB10: USART3_TX, Pin PB11: USART3_RX GPIO_PinAFConfig(GPIOB, GPIO_PinSource10, GPIO_AF_USART3); GPIO_PinAFConfig(GPIOB, GPIO_PinSource11, GPIO_AF_USART3); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10 | GPIO_Pin_11; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; GPIO_Init(GPIOB, &GPIO_InitStructure); // USART3配置 USART_InitStructure.USART_BaudRate = 115200; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_1; USART_InitStructure.USART_Parity = USART_Parity_No; USART_InitStructure.USART_Mode = USART_Mode_RX | USART_Mode_TX; USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_Init(USART3, &USART_InitStructure); // DMA1 Stream1 Channel4是USART3_RX的DMA请求通道 DMA_InitStructure.DMA_Channel = DMA_Channel_4; DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)&USART3->DR; DMA_InitStructure.DMA_Memory0BaseAddr = (uint32_t)ec20_rx_buf; DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory; DMA_InitStructure.DMA_BufferSize = EC20_RX_BUF_SIZE; DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte; DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte; DMA_InitStructure.DMA_Mode = DMA_Mode_Circular; DMA_InitStructure.DMA_Priority = DMA_Priority_High; DMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Disable; DMA_Init(DMA1_Stream1, &DMA_InitStructure); DMA_Cmd(DMA1_Stream1, ENABLE); // 使能USART3空闲中断 USART_ITConfig(USART3, USART_IT_IDLE, ENABLE); NVIC_InitStructure.NVIC_IRQChannel = USART3_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 2; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); USART_DMACmd(USART3, USART_DMAReq_RX, ENABLE); USART_Cmd(USART3, ENABLE); }

DMA配置成循环模式很关键。这意味着模组连续往串口丢数据时，DMA会自动回绕到缓冲区头部继续写入，CPU不用管。我们只需要在空闲中断里统计新收到的数据长度即可。如果配置成Normal单次模式，数据一多就得反复重启DMA，稍有不慎就丢数据。

空闲中断的处理逻辑如下：

// USART3空闲中断处理函数 void USART3_IRQHandler(void) { if (USART_GetITStatus(USART3, USART_IT_IDLE) != RESET) { // 清除IDLE标志位：先读SR再读DR USART_ReceiveData(USART3); // 关闭DMA，计算当前收到多少数据 DMA_Cmd(DMA1_Stream1, DISABLE); uint16_t remaining = DMA_GetCurrDataCounter(DMA1_Stream1); ec20_rx_len = EC20_RX_BUF_SIZE - remaining; // 重新开启DMA DMA_SetCurrDataCounter(DMA1_Stream1, EC20_RX_BUF_SIZE); DMA_Cmd(DMA1_Stream1, ENABLE); ec20_rx_complete_flag = 1; } }

这里有个细节必须注意：清除USART_IDLE中断标志位的方法是先读SR寄存器再读DR寄存器。我最初调试时直接在USART_GetITStatus后调用USART_ClearITPendingBit，结果中断一直在触发、CPU被打满。原因是在某些固件库版本里这个标志位不能用软件写清，必须用读寄存器的方式清除。同样的坑也出现在DMA传输完成中断上，但空闲中断这个最隐蔽。

3.2 AT指令交互层

AT指令交互的套路是"发指令-等响应-判断结果"。我设计了一个简单的同步阻塞式接口，主要用状态机维护，避免在主循环里因为等待AT响应而死等。

// 发送一条AT指令并等待预期响应，返回0表示成功 // timeout_ms 最大等待毫秒数 uint8_t EC20_SendATCmd(const char* cmd, const char* expect, uint32_t timeout_ms) { uint32_t tick_end = HAL_GetTick() + timeout_ms; // 清空接收缓冲区和完成标志 memset(ec20_rx_buf, 0, EC20_RX_BUF_SIZE); ec20_rx_len = 0; ec20_rx_complete_flag = 0; // 通过USART3发送指令 uint16_t len = strlen(cmd); for (uint16_t i = 0; i < len; i++) { while (USART_GetFlagStatus(USART3, USART_FLAG_TXE) == RESET); USART_SendData(USART3, (uint8_t)cmd[i]); } // 等待串口空闲中断把响应收完，或者超时 while (HAL_GetTick() < tick_end) { if (ec20_rx_complete_flag) { // 在缓冲区中查找期望字符串 if (strstr((char*)ec20_rx_buf, expect) != NULL) { return 0; // 成功 } else { return 1; // 响应内容不符 } } // 喂一下看门狗（如果开了的话） } return 2; // 超时 }

注意这个函数里有个隐含要点：串口发送不能直接调用HAL_UART_Transmit阻塞发送。EC20有一个很小的串口接收FIFO，如果一次性把所有字符连续写入DR寄存器，中间某些字可能被覆盖。正确做法是每发一个字节都等TXE标志位置1后再发下一个。这就是上面代码里为什么在USART_SendData前后都要检查TXE标志的原因。用HAL_UART_Transmit默认也是这么做的，但底层用阻塞方式会占用CPU，我直接用寄存器操作省去HAL层开销。

在使用AT指令之前，建议先发"AT"确认链路。调试阶段我都是先跑一轮完整的初始化流程：

AT -> OK ATE0 -> OK (关闭回显，减少解析干扰) AT+CPIN? -> +CPIN: READY AT+CREG? -> +CREG: 0,1 (已注册网络)

3.3 基站定位数据解析

基站定位的核心数据来源是AT+QENG="servingcell"。这条指令的返回格式在EC20 R2.1版本下长这样：

+QENG: "servingcell","NOCONN","LTE","FDD",460,01,2F0A,1A2B3C,15,17,-85,0,3,7,49,3

各字段含义如下：

代码解析时，我用的是逗号分隔+索引定位的方式，不依赖固定的字符串偏移量，这样模组固件升级返回格式微调时，只需修改索引号，不用重写解析逻辑。

// 基站信息结构体 typedef struct { uint16_t mcc; // 移动国家码 uint16_t mnc; // 移动网络码 uint16_t lac; // 位置区码 uint32_t cell_id; // 小区ID int16_t rsrp; // 参考信号接收功率 } cell_info_t; // 在缓冲区中查找指定序号逗号分隔的字段起始位置 static char* find_field(char* buf, uint8_t index) { char* p = buf; uint8_t cur = 0; while (p != NULL && cur < index) { p = strchr(p, ','); if (p != NULL) { p++; // 跳过逗号 cur++; } } return p; } // 解析QENG servingcell返回结果 // 返回0表示解析成功 uint8_t ParseServingCell(char* buf, cell_info_t* cell) { char* p; // 找到 "LTE" 之后，从第4个字段（MCC）开始 p = strstr(buf, "\"LTE\""); if (p == NULL) return 1; p = strchr(p, ','); // 跳到逗号 p++; // 跳到MCC cell->mcc = (uint16_t)atoi(p); p = strchr(p, ',') + 1; cell->mnc = (uint16_t)atoi(p); p = strchr(p, ',') + 1; cell->lac = (uint16_t)strtol(p, NULL, 16); // LAC是十六进制 p = strchr(p, ',') + 1; cell->cell_id = (uint32_t)strtol(p, NULL, 16); // CellID是十六进制 p = strchr(p, ',') + 1; p = strchr(p, ',') + 1; p = strchr(p, ',') + 1; p = strchr(p, ',') + 1; p = strchr(p, ',') + 1; p = strchr(p, ',') + 1; cell->rsrp = (int16_t)atoi(p); return 0; }

注意LAC和CellID在AT指令里返回的是十六进制字符串，必须用strtol(p, NULL, 16)转换，而MCC和MNC是十进制字符串，直接atoi即可。这个坑我一开始就踩了——直接全部用atoi解析，结果LAC和CellID全部变成0，排查了好半天。你要是复现时发现LAC是0，先检查是不是这里转换错误。

邻区信息通过AT+QENG="neighbourcell"获取，返回多条邻区记录，格式类似：

+QENG: "neighbourcell","LTE","FDD",460,01,2F0A,1A2B3D,16,-90,......

每条邻区记录的结构和服务小区基本一致。我解析邻区数据时用循环逐条读入缓冲区，提取每个邻区的CellID和RSRP值，构造多基站数据上报给云端。

3.4 定位结果的输出与上报

拿到四元组之后，下一步就是上报到基站数据库服务获取经纬度。这一步我直接利用EC20的TCP/IP功能向云端API发起HTTP POST请求。EC20建立TCP连接和发送HTTP数据，使用的是AT+QIOPEN和AT+QISEND指令序列。大致流程：

// 上报基站信息到定位服务，获取经纬度 uint8_t EC20_GetLocationByAPI(cell_info_t* serving, float* lat, float* lon) { char http_buf[512]; // 构造HTTP POST请求数据 sprintf(http_buf, "POST /v1/cell_location HTTP/1.1\r\n" "Host: api.example.com\r\n" "Content-Type: application/json\r\n" "Content-Length: %d\r\n" "\r\n" // 回车空行区分HTTP头和body "{\"mcc\":%d,\"mnc\":%d,\"lac\":%d,\"cellid\":%ld}\r\n", strlen(body_json), serving->mcc, serving->mnc, serving->lac, (long)serving->cell_id); // 建立TCP连接 EC20_SendATCmd("AT+QIOPEN=1,0,\"TCP\",\"api.example.com\",80\r\n", "OK", 5000); // 发送HTTP请求 EC20_SendATCmd(http_buf, "SEND OK", 3000); // 读取响应，解析经纬度字段 // ... 响应中的经纬度提取逻辑 }

云端API的选择是个灵活决定。你自建服务的话，可以用nginx+MySQL搭建基站数据库查询接口，或者用PostGIS做小区经纬度空间查询；图省事的话，直接用第三方基站定位服务，比如百度定位API、极海定位之类的现成服务，它们都支持HTTP POST传MCC/MNC/LAC/CellID返回经纬度。API key需要你自己申请，不方便写进代码里硬编码的，可以做成编译期宏，或者通过配置区管理。

需要注意的是，HTTP请求必须先发请求头、再发请求体，headers和body之间必须有一个空行（\r\n\r\n）。很多第一次做AT指令HTTP的同学容易漏掉这行空行，导致服务器一直返回400错误。另外，HTTP响应也走的是串口，响应内容可能很长，必须保证DMA缓冲区足够大（至少2KB），不然响应被截断，解析失败。实测下来比GPS的NMEA解析步骤要繁琐不少，但逻辑上其实是同一套思路——就是切割字符串、提取字段、按规则计算。

4. 常见问题与调试技巧实录

4.1 EC20发AT指令一直无响应

排查思路分三步走。

第一，查电源。EC20在LTE制式下瞬间功耗可以到2A，如果用的开发板USB线供电或者面包板飞线，电压跌落会导致模组反复重启。我在调试时用稳压电源单独给EC20供电，电流峰值监控显示开机瞬间确实冲到1.8A左右。供电不足表现为AT指令偶尔有响应、偶尔完全没响应，而且时间间隔有随机性，和正常死机表现区分度很高。

第二，查开机时序。EC20开机需要拉低PWRKEY至少500ms。有的同学以为PWRKEY拉低一下就行，实际我给PWRKEY拉低的时间是800ms到1秒，确保模组BootROM稳定完成。开机后需要等2秒左右再发AT，刚上电的模组处于BOOT阶段，此时串口不发任何数据、也不响应AT，等待时间不够会误判为硬件故障。

第三，查串口波特率。EC20默认波特率是115200，但如果模组被前一个使用者修改过，比如改成9600或460800，那么默认的115200自然无法通信。在SIM卡未注册或者模组进入特殊模式时，AT指令也可能不回应。这类情况建议用USB转TTL，配合移远的QFlash工具强行恢复出厂设置，或者用官方串口调试助手扫一遍常见波特率，找到正确值后再改回115200。

4.2 串口收到的数据有乱码

乱码问题的根源，90%是硬件接线上TX和RX接反了，或者电平不匹配。EC20的UART_RX连接MCU的TX，UART_TX连接MCU的RX，交叉连接，同轴连接会导致自己发自己收，永远是乱码。电平方面，EC20系统电源3.3V，但UART逻辑电平是1.8V，虽然大多情况下主控3.3V的IO能直接被识别，但长时间交叉使用3.3V往1.8V引脚灌电平有损伤风险。稳妥做法是加电平转换芯片，或者用一个电阻分压电路把MCU的TX从3.3V降到1.8V再进EC20。

还有一种情况只出现在老版本固件上——EC20默认回显（ECHO）。如果AT指令发出后返回的是"AT"开头的回显，需要在解析前用ATE0关闭回显。尤其当你用strstr搜索"OK"时，如果回显里有"AT..."恰好包含OK的尾字符，会误判为成功。调通AT指令之后第一时间发ATE0，后面所有解析都省心。

4.3 LAC和CellID解析出来是0

这是典型的十六进制字符串被当十进制处理的问题。EC20返回的LAC是4位十六进制，CellID是6位十六进制，比如2F0A对应十进制的12042。如果用atoi去转"2F0A"，得到的结果只有开头的2，或者直接得到0。必须用strtol(p, NULL, 16)或者sscanf(p, "%x", &lac)。

同样道理，MCC和MNC是十进制字符串，用atoi没问题。如果你发现MCC和MNC正常，LAC和CellID全为0，百分之百是进制转换写错了。用波形分析仪抓串口数据也能看到，返回字符串确实是带字母的十六进制，不是数字。

4.4 定位结果偏差过大或返回无效坐标

基站定位结果的偏差可能来自三个方面。

一是使用的基站数据库覆盖不全。有些小众城市或农村区域的LAC/CellID在数据库里没有收录，云端API返回空结果。这种可以换多个服务商试，或者自建数据库收集从车端上报的基站样本，慢慢扩充覆盖度。

二是上报的基站数据太旧。EC20驻留的基站信息是实时更新的，但如果代码频率太低，比如10分钟才查询一次，车辆已经从小区的边缘移动到别的基站覆盖区域，上报的还是旧小区。建议根据业务场景设置合理的查询周期：实时追踪3~5秒一次，静态挂载设备10~30秒一次。注意查询太频繁会损耗SIM卡的信号和数据流量，每次查询也就几百字节，但对接入网信令的频率有影响，过度频繁会影响模组驻网的稳定性。

三是没有利用邻区信息。只用服务小区单个小区定位，误差当然大。联通、电信的宏基站密度不如移动那么高，城区单小区定位误差可能直接到2公里以上。把AT+QENG="neighbourcell"获取的邻区信息也上报上去，云端按信号强度加权，定位误差就能从公里级降到两三百米级别，效果立竿见影。

4.5 HTTP请求返回400错误

HTTP 400错误最常见的原因前面提过——漏掉了请求头结束的两根换行符。HTTP协议规定headers和body之间必须有一个空行，即\r\n\r\n。在字符串拼接时最容易写成\r\n。另外检查一下Content-Length字段，这个数值必须等于HTTP请求body的实际字节数，多了少了服务器都会直接拒绝。我在调试时写了一个小工具函数，专门打印HTTP请求的实际字节数，对照Content-Length检查，很快就定位到问题。

4.6 SIM卡认证失败，返回+CME ERROR: 10

这个错误提示SIM卡不存在或者未就绪。排查流程：先物理检查SIM卡座弹片是否压紧，触点氧化用橡皮擦；再用AT+CPIN?查询PUK状态。还有可能是EC20的卡座使用了1.8V/3V自适应，SIM卡槽被设成了固定电压后与卡不兼容。最省事的方法是换一张新卡试试，如果新卡能注册，那就是SIM卡磨损严重导致接触不良。

5. 项目回顾与调试心得

把整套代码从零调通耗时大约一周，实际在STM32F407端写代码的时间反而不长，大头全部花在排查硬件飞线和AT指令返回格式上了。关于这套方案，我最后再分享几条实操经验。

第一，调试EC20的时候，第一步一定要接一个USB转TTL模块，用PC上的串口助手先把AT指令全部手动跑通，确认模组没问题再接入单片机。如果直接从单片机端调试，一旦不行，你会同时怀疑硬件连接、代码逻辑和模组状态三个环节，排查效率非常低。我现在做任何模组相关项目都是这套打法。

第二，善用日志输出。我在代码里加了一个DEBUG开关，开启后把所有通过USART3收发EC20的数据镜像转发到板载的USB串口（USART1），在PC端可以实时看到F407和EC20的完整交互过程。这个技巧帮我解决了AT时序错乱的问题——原来代码里发邻区查询指令时，服务小区查询的响应还没收完，就把缓冲区覆盖了，导致解析结果全是垃圾数据。

第三，代码层面建议把AT指令发送和响应解析做成一个独立模块，结构化如下：上层业务不需要关心AT指令细节，只调用cell_info_result_t get_cell_location(void)即可。这样后续如果要替换成其他模组（例如广和通L610、中移ML307），只需要重写这个模块的API实现，上层业务代码完全不用动，这是嵌入式系统开发里最基本的模块化思路。

最后说一下这套方案还能怎么扩展。当前我只实现了单次查询+主动上报的模式。如果你做的是实时追踪设备，可以在此基础上加入低功耗逻辑：平时EC20休眠、STM32也进入STOP模式，定时唤醒后查询基站信息并上报，然后再休眠。F407在STOP模式下功耗可以做到几十微安，模组在eDRX模式下的待机功耗能做到3mA左右，这样一套设备靠锂电池跑几个月不成问题。另外，把邻区加权定位算法从云端挪到本地MCU上，结合已知基站经纬度表，离线也能算位置，只是数据库容量受限于Flash的大小，需要单独设计压缩方案。定位这条路，做进去之后能玩的花样还挺多的。

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