企业官网建设流程全解析

最近在弄一个基于 ST 意法半导体 TESEO-LIV3F 多星座 GNSS 模块的定位项目，第一件事就是要把它的默认配置改成我们需要的输出格式和刷新率。这个模块 UART 和 I2C 都支持，但出厂默认只有 UART 在跑，所以“TESEO-LIV3F configuration over UART”就成了整个项目开发的第一步。这篇博文我打算把整个配置过程完整拆开：从硬件接线、驱动准备，到官方工具、手动串口命令，再到用 Python 脚本批量配置，最后把实际踩过的坑和排查思路一并整理出来。如果你刚拿到 TESEO-LIV3F 正不知道怎么下手，或者已经连上了但配置总不生效，这篇文章应该能帮上忙。

1. 项目背景与整体设计思路

1.1 TESEO-LIV3F 是什么，为什么需要 UART 配置

TESEO-LIV3F 是意法半导体 Teseo 系列里非常经典的一颗 GNSS 接收模块，支持全球多个定位星座，包括 GPS、Galileo、Glonass、北斗和 QZSS。封装很小，功耗也低，内置了一块可编程 Flash，所以很多车载定位器、无人机、共享单车定位模块、资产追踪器都用它做核心定位芯片。

模块出厂时会有默认的 UART 配置，一般是 9600 波特率、8 数据位、无校验、1 停止位，每秒输出一整套 NMEA 语句，比如 GGA、RMC、GSA、GSV 这些。但实际项目里很少会把整套 NMEA 语句全部用起来：有的只要 GGA 和 RMC 两个语句，有的需要把刷新率提到 5Hz 或 10Hz，有的需要调整卫星星历输出、降低功耗，甚至有的要改成 115200 波特率来配合主控侧的资源调度。这部分个性化配置就都落在了“configuration”这一步上。

为什么偏偏用 UART 来做配置？理由很直接：第一，模块默认就把 UART 作为一个可用的配置和定位数据输出通道，不需要额外拉 I2C 地址；第二，连接方式非常简单，用 USB 转 TTL 串口线就能在电脑上操作，也适合在主控代码里通过串口发送配置指令；第三，UART 调试时信息直观，模块上电后不断输出的 NMEA 数据可以作为“模块是否活着”的最快判断依据。

1.2 UART 配置的几种路径与选型

把 TESEO-LIV3F 接到 UART 之后，配置方式大致有三条路：

一是用 ST 官方提供的 Teseo Data Center 工具，连接串口后在图形界面上改参数。这种方式适合前期验证和小批量生产，我能直观看到每个配置项，比如输出语句、刷新率、相位、定位模式等，点一下设置就能生成对应的命令，不会因为手写命令格式出错。

二是用串口调试助手直接发送 NMEA 私有配置命令，比如$PSTM开头的一类指令。这种方式适合需要验证某一条命令是否生效，或者手头没有官方工具的临时调试环境。缺点是必须熟悉命令格式和校验算法，一旦命令写错，模块可能回一个 ERROR 或者干脆没响应。

三是在主控 MCU 里写一段 UART 配置代码，让模块每次上电后由主控自动下发配置。这条在我这个项目里最实用，因为要批量组装很多块板子，不能每块都插在电脑上手动点，代码里把配置命令数组编好，上电后延时几百毫秒，等模块 UART 初始化完成再逐条发送，发完再保存，整套流程就自动完成。

三条路并不互斥。我实际开发时先用官方工具在 PC 上把配置项跑通，然后把工具生成的命令抄下来，写进 Python 脚本做批量验证，最后再把同样的命令整理成 C 语言数组，固化到 STM32F103 的启动配置代码里。这样既保证了命令正确，又兼顾了生产效率。

1.3 我的配置方案与技术栈

这次项目的硬件链路是：STM32F103 主控的 USART1 接 TESEO-LIV3F 模块的 UART，同时模块的 TXD、RXD 通过一个拨码开关切换到 USB 转 TTL 调试器，方便 PC 直接连接模块做配置和排查。USB 转 TTL 调试器用的是 FT231X 芯片的方案，这是因为 FT231X 原生支持 3.3V TTL 电平，和模块的 I/O 电平匹配，不用再串电平转换板。

PC 端我用的是 Python + pyserial 写自动化脚本。为什么不直接用官方工具？因为官方工具虽然功能全，但一次只能配置一块模块，而且日志输出量很大，量产时需要人工确认每一条命令是否回复正常。用 pyserial 脚本我可以在几秒钟内完成对一个模块的配置、保存、复位，然后比对回传的 ACK 字符串做自动判断，效率高很多。

整套方案下来，感觉最核心的一点是：先把配置协议和数据流搞清楚，再上工具。如果你一上来就只知道用鼠标点官方工具，真到了需要批量配置或者排查“为什么模块重启后配置丢失”的时候，会很被动。

2. 硬件连接与驱动准备

2.1 引脚定义与接线要点

TESEO-LIV3F 的引脚不算多，但接线时我会反复核对几个关键点：模块的 VCC 供电、GND 地线、TXD 发送、RXD 接收，以及复位脚 nRST。第一次接线时最容易犯的错就是把模块的 TXD 接到调试器的 TXD 上，以为“同名就是对口”，实际上 UART 必须交叉连接：模块 TXD 接 USB 转 TTL 的 RXD，模块 RXD 接 USB 转 TTL 的 TXD。

供电要特别注意，TESEO-LIV3F 的工作电压范围我印象里是支持 3.3V 左右的单电源，但不同版本的外围电路可能对 VCC_IO 有要求。我做的这块板子直接用了 3.3V 给 VCC 和 I/O 供电，实测通信稳定性很好。如果你不是自己画的板子，用的是现成的评估板，那一般不需要额外处理电压问题；但如果你自己设计外围电路，一定要去看数据手册里的最大额定值，特别是 I/O 电平，尽量不要在没确认的情况下直接把 5V 串口接到模块 RXD 上。

除了电源和地，天线也不能忘。GNSS 模块要拿到有效定位数据，得有源天线或无源天线接在 RF 输入上。配置命令本身不依赖定位，但如果你在测试时把天线悬空，模块会因为卫星信号差而不断输出噪声相关的 NMEA 信息，容易干扰你对配置响应回文的判断。

接线完成后，我习惯先做一次“上电看输出”测试：模块上电后，用示波器或逻辑分析仪看 TXD 引脚，应该能看到一串 9600 波特率的串行数据。如果没有，先别急着配命令，优先排查电源和 TXD 是否接对。

2.2 USB转UART驱动排查（FT231X/FT232R/CP2102N）

很多人在配置 TESEO-LIV3F 之前，先被 USB 转 TTL 工具的驱动卡住了。这个模块本身不挑 USB 转串口芯片，但你在电脑上打开串口工具之前，必须确认设备管理器里已经枚举出了正确的 COM 口。USB 转 UART 芯片常见的有 FTDI 的 FT231X、FT232R，Silicon Labs 的 CP2102N 等，它们各自有对应的 VCP 驱动。下面是我整理的一个速查表，方便你拿手头工具直接对号入座：

驱动问题的典型现象是：板子插上后设备管理器里看不到新端口，或者端口多了个黄色感叹号。处理方式一般是先在电脑上安装对应厂商的 VCP 驱动，再重新插拔 USB 线，不要偷懒只插一半等待系统搜索；如果系统还在联网搜索驱动，很容易装成通用的串口驱动，导致设备名变成“USB Serial Port”但实际功能不正常。更稳妥的做法是安装时在设备管理器里手动选择驱动文件路径，而不是让系统自动匹配。

如果手头没有标准调试器，用开发板自带的板载 USB 转串口也可以，但查驱动时需要注意芯片型号。比如 STM32 Nucleo 板上用的通常是 ST-LINK 虚拟串口，对应的是 STSW-LINK009 驱动，而很多独立 USB 转 TTL 模块用的是 CH340。不同芯片驱动不一样，排查时先确认芯片型号再找驱动，会少走很多弯路。

2.3 用示波器或逻辑分析仪确认UART信号

如果你和我一样属于“不见波形不放心”的人，那配置之前可以先拿示波器或者逻辑分析仪看一眼 UART 信号。具体做法是：模块上电后，把探头夹在模块 TXD 引脚和 GND 之间，抓取单帧波形，电脑上设置波特率为 9600，观察起始位和停止位是否正常。如果看不到波形，可能是模块没有启动、供电异常，或者 TXD 引脚根本没有数据输出。

用逻辑分析仪更直观，可以直接解码出 NMEA 字符串内容。我会把逻辑分析仪通道接到模块的 TXD 上，采样率设到 1MHz 以上，然后打开串口解码器，选择 9600 8N1，就能在软件里看到一排字符串。这样有个好处：可以确认模块输出的 NMEA 语句到底是哪些，就能反推当前配置是否已经被改过。比如厂家可能把默认波特率改成 115200 卖给你，你却以为还是 9600，这种情况下打开串口工具全是乱码，用逻辑分析仪一抓就能看到真实波特率。

还有一个非常管用的硬件回环测试：如果你要验证整条 USB 转 UART 链路是否正常，可以把调试器的 TXD 和 RXD 直接短接，然后在串口调试助手发送一段字符，如果能够原样收到，说明 USB 转 TTL 的链路是通的。把模块接回来之后，如果发配置命令没回应，就能快速定位问题是出在链路还是模块自身。

3. 配置协议解析与操作步骤

3.1 Teseo NMEA配置协议基础

TESEO-LIV3F 的 UART 配置协议是在标准 NMEA-0183 基础上扩展出来的私有命令协议，ST 把它统称为 Teseo NMEA Messages。标准 NMEA 语句大家都见过，比如$GPGGA,...*AA，Teseo 的私有配置命令也是同样的格式，只是命令头以$PSTM开头，后面跟不同的指令字和参数。所有配置命令必须以回车换行\r\n结尾，并且最后要带*和两个十六进制字符的校验和，这个校验和是从$之后到*之前所有字符的异或结果。

比如你要修改一个参数，命令结构大概是：

$PSTMSETPAR,<参数ID>,<参数值>*<校验和>

这里的<参数ID>是模块内部定义好的，不同参数对应不同的编号。这些编号在《Teseo-LIV3F NMEA Messages User Manual》里有完整表格，我不会在这里直接列一个完整的列表，因为版本不同可能会不一致，而且有些参数 ID 是厂家保留的。正确做法是先打开官方手册，搜索你要改的那个参数名称，然后核对具体 ID 和取值范围。手边没有手册时，我会用 ST 的工具先生成命令，再把命令贴到串口助手里看，这不失为一个快速学格式的办法。

校验和计算是最容易出错的点。我自己的习惯是直接用 Python 写一个函数帮算校验和，而不是手动 XOR。给你一段简单的校验和函数：

def nmea_checksum(sentence): body = sentence[1:].split('*')[0] cs = 0 for ch in body: cs ^= ord(ch) return f"{cs:02X}"

有了这个函数，我随便写一条语句，比如$PSTM...，把sentence传进去，返回的两位十六进制就是需要放在*后面的校验字节。实际发送时，最后再拼上\r\n。

3.2 使用ST Data Center工具配置

如果不想在命令行和协议细节上花太多时间，官方 Teseo Data Center 工具是最快的上手方式。第一次打开这个工具时，我需要确认三个动作：第一，选择正确的串口端口和波特率；第二，点击“连接”后观察有没有持续的 NMEA 数据滚动上来；第三，工具界面里的信号列表和时间日期是否在更新。

连接成功之后，工具的“Configuration”面板会列出很多下拉框和文本框，比如 NMEA 语句启停、输出频率、卫星系统选择、定位模式、波特率设置等。我只需要在界面上把参数改成项目要求，然后点写入或应用，工具会自动帮我把界面配置翻译成对应的$PSTM命令并通过串口发出去。

需要注意的是，工具里的“设置”和“保存”经常是两个不同按钮。界面上的设置项很多只临时生效，模块一旦重启就会恢复默认；只有我明确点了“保存到 Flash”或类似的持久化操作，配置才会写入模块内部 Flash。我在第一次用这个工具的时候就踩过这个坑：改了刷新率，也看到工具提示发送成功，但断电重启之后还是 1Hz，后来才发现是因为没有保存。所以用工具时，要养成“设置完必须点保存，保存后重启验证”的习惯。

工具还有一个很实用的功能，就是把当前配置导出为配置文件。这个文件可以保留备份，也可以用于批量配置。对于生产来说，可以先用工具在某一个模块上调好所有参数，导出配置文件，然后在上位机脚本里调用工具的命令行或通过文件导入方式复现配置，效率会比每次手动点界面高很多。

3.3 通过串口调试助手手动发送配置命令

如果你只能用一个串口调试助手来配置模块，那整个流程可以拆成四步。第一步，打开串口，选择正确的波特率和串口参数；第二步，把模块上电，观察串口调试助手是否滚动输出 NMEA 数据；第三步，在发送区输入一条配置命令，并以\r\n结尾，点击发送；第四步，观察模块是否有 ACK 或 ERROR 回复。

手动发送时必须注意：在串口助手的发送框里不要直接用键盘输入回车，因为不同软件对\r\n的处理不一样。我习惯在要发送的命令后面直接粘贴文本形式的回车符，或者使用软件提供的“追加回车换行”选项，确保命令末尾是\r\n，而不是只有\n或者什么都没有。很多命令没响应，问题就出在缺少回车换行，模块根本不认为这是一条完整语句。

举个例子，假设我要把模块配置为只输出 GGA 和 RMC 两条语句，我需要根据手册找到控制输出语句的指令字，然后把相应参数拼接起来。由于具体指令字在不同固件里可能变化，不建议你在网上复制一段别人写死的命令直接发，因为参数含义很可能对不上。更可靠的办法是先用官方工具在测试板上生成命令，然后把工具输出的原始字符串存下来，再用串口助手复现。这样做的好处是，你发出去的每条命令都是模块真实支持的，排除了自己猜指令字的低级错误。

3.4 用Python脚本自动化配置

当我需要反复配置多块模块时，手动在串口助手点击发送显然不是好办法。用 Python 的 pyserial 库，我可以把配置命令做成一个列表，按顺序发送，并且自动校验模块回复，整个过程不需要人工盯着屏幕。下面这段代码是我实际用过的简化版本：

import serial import time def nmea_checksum(sentence): body = sentence[1:].split('*')[0] cs = 0 for ch in body: cs ^= ord(ch) return f"{cs:02X}" def send_config_cmd(ser, cmd): line = f"${cmd}*{nmea_checksum(cmd)}\r\n" ser.write(line.encode('ascii')) time.sleep(0.3) resp = ser.read(ser.in_waiting or 200) return resp ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1) # 先清空缓冲区 ser.reset_input_buffer() config_cmds = [ "PSTMSETPAR,<参数ID1>,<值1>", "PSTMSETPAR,<参数ID2>,<值2>", "PSTMSAVEALL", ] for cmd in config_cmds: resp = send_config_cmd(ser, cmd) print(f"cmd: {cmd}, resp: {resp!r}") ser.close()

这段代码里的<参数ID1>等等，需要根据你手上的手册替换成实际值。整个脚本的逻辑很直白：定义一条命令，计算校验和，拼上$*\r\n，发送后读取模块的回复。如果模块回ERROR，脚本也可以进一步做告警，比如打印出错的命令，方便定位是哪一条配置项有问题。

在实际批量操作里，我还会在脚本里增加一个“配置后重启并检查版本”的步骤。也就是配置完成并保存后，让脚本主动拉低复位脚或通过命令重启模块，然后重新打开串口读取模块输出的 NMEA 语句，验证输出内容是否和预期一致。这一步非常重要，可以防止“配置时显示成功，实际重启后并未生效”的尴尬。

4. 常见问题与排查实录

4.1 串口无响应 / 乱码

串口无响应或者乱码，是 TESEO-LIV3F UART 配置里出现频率最高的问题。无响应的常见原因有：接线错误、模块没供电、串口工具选错了 COM 口、模块 TXD 和 RXD 接反了。乱码则基本都是波特率不对，或者电平不匹配导致信号畸变。

排查顺序，我一般会从链路开始：先用逻辑分析仪看模块 TXD 引脚有没有波形；有波形但电脑串口收到乱码，就说明硬件链路是通的，问题在波特率或接地；没有波形就先检查 VCC 和 GND，再看模块有没有处于复位状态。如果模块用的是有源天线，也要确认天线供电引脚有没有正确配置，否则模块虽然能输出 NMEA，但没有定位数据，容易被误判成“模块坏了”。

另外要注意的是，模块上电后 UART 会持续输出 NMEA 语句，当你在串口助手里发送配置命令时，这些持续的 NMEA 包可能会混在响应数据里。不要因为看到很多非相关的语句就以为模块没有回复 ACK，可以把串口工具的显示暂停，或者把配置命令发送后的几秒内的数据抓下来过滤分析。

4.2 配置命令返回ERROR或无ACK

如果配置命令能正常发送，但模块回了 ERROR，或者干脆没有 ACK，问题往往出在命令本身。第一条要查的是校验和是否正确，$后面的内容如果被看错一个字符，计算出来的校验和就是错的，模块会直接丢弃这条命令。第二条要查的是是否以\r\n结尾，很多串口调试助手默认发送行尾只带\n，模块不会响应。第三条是参数 ID 和参数值是否超出范围，比如你要设置波特率，却写了一个模块不支持的数值，模块同样会报错。

如果以上都排除了，还有可能是模块正处于忙碌状态。比如刚上电时模块内部还在初始化，或者刚执行过“保存到 Flash”操作，此时立即再发其它配置命令，模块可能暂时不处理。我习惯在发送每条命令之间增加 200ms 到 500ms 的延时，并且在读取响应之前清空缓冲区，避免把之前的 NMEA 数据当作配置响应。

4.3 配置文件语法错误

在使用 ST 官方工具或者第三方配置工具导入配置文件时，大家可能遇到过类似这样的报错：the configuration file contains a syntax error on line 14; [eparseerror] no。这通常是配置文件里某一行的 NMEA 命令格式不对，工具解析不通过。我遇到过的具体情况是：我手写了一个配置文件，第 14 行是一条设置输出频率的命令，但没写全参数，工具在解析时找不到逗号后的内容，于是直接报语法错误。

解决思路很简单：一行一行检查报错行附近的格式，尤其是逗号数量、命令头是否完整、参数值是否合法。如果你不熟悉配置文件的语法，最保险的办法不是手写，而是先用官方工具在界面上点好配置并导出，拿到一份语法肯定正确的模板，然后基于模板做少量修改。这样能避免大多数由于手写导致的语法错误。报错信息里提到的行号是一个非常好的定位线索，直接把报错文件用文本编辑器打开跳到那行，通常一眼就能看出问题。

4.4 驱动安装失败（FT231X/FT232R）

USB 转 UART 芯片驱动的坑，我在项目前期也踩过。FT231X 的 USB 转 TTL 调试器插上后，设备管理器里偶尔会显示一个未知设备，甚至直接没有反应。这种情况多半是系统没有正确安装 FTDI VCP 驱动。我处理的办法是：从 FTDI 官网下载对应 Windows 版本的驱动压缩包，解压后打开设备管理器，在未知设备上右键“更新驱动程序”，“浏览我的电脑以查找驱动程序”，然后手动指定解压后的驱动目录，强制安装。

FT232R 的情况也类似，但老芯片在某些系统上还会遇到驱动数字签名问题。如果安装时提示缺少签名或无法安装，就需要进入高级启动选项，禁用驱动程序强制签名后再安装。这个操作只在当前系统会话内有效，装完驱动后恢复正常启动也不会影响使用。如果你是第一次接触这些芯片，看到设备管理器里出现“USB Serial Port”这个设备名，先不要慌，它大概率就是 FTDI 芯片识别成功了，但还需要手动分配 COM 口号或安装完整 VCP 驱动。

CP2102N 则推荐直接去 Silicon Labs 官网下载 CP210x Universal Windows Driver，它的安装相对顺利，但如果插上后还是没反应，也要检查 USB 线是否支持数据，而不是纯充电线。这种事看似低级，但实际发生频率很高。

4.5 配置保存失败注意事项

最后再说说保存失败。配置命令发送成功，模块也回了 ACK，但断电重启后配置全部恢复默认，这种问题基本可以判定为没有执行“保存到 Flash”操作，或者保存时序不对。TESEO-LIV3F 的 Flash 保存操作和我们平时写 EEPROM 一样，写入期间不能掉电，否则轻则保存失败，重则可能影响 Flash 里的其它配置区域。

我在批量脚本里会这样做：在所有参数配置完成后，单独发送一条保存命令，等待保存完成的响应，再延时 500ms 以上，然后断开模块电源。这里不要设置完一条就保存一条，因为模块内部 Flash 的擦写寿命有限，频繁保存会缩短器件寿命。正确的做法是“全部改完，统一保存”。

另外还要提一个细节：保存到 Flash 之后，如果有条件，建议给模块做一次完整的冷启动或者复位，然后重新读取配置，确认配置确实已经生效。我见过有同事配置流程全走完了，但还是偶尔出现几个模块重启后丢失配置，排查半天才发现是保存命令之后立刻断电，Flash 写入没有完成。加一个延时往往就能解决。

根据我个人这段时间调 TESEO-LIV3F 的体会，UART 配置并不可怕，核心在于把命令格式和保存机制吃透。只要你在工具里把配置跑通一次，再把命令提取出来用脚本固化，批量生产就会非常省心。如果以后模块配置丢失或者需要换主控，那段固化在启动代码里的配置流程也可以直接复用，不用再重新去翻手册。这就是我这次项目里最大的一条经验：把一次性操作做成可以重复执行的自动化流程，效率提升是肉眼可见的。