EC200AEUV1 tcp问题

hellworld · 2026 年8 月 12 日 03:03

================================================================================

EC200A-EUV1 QuecPython 固件问题报告
提交日期：2026-08-12

共两个问题：
问题一：TCP 收到下行数据导致模块复位（2025-08-13 构建，版本回归）
问题二：QuecPython 固件下 USB 高速枚举失败，退化为全速

================================================================================

一、设备与版本信息

【模组】
型号 EC200A-EUV1-HA
IMEI 863819078464665
SN P1C26E3080026990P
USB VID/PID 2c7c / 6005

【固件包】
包名 QPY_OCPU_V0001_EC200A_EUV1_HA_FW
来源移远官网 QuecPython 下载区（EUV1 变体当前唯一可用版本）

【开机 Banner（DEBUG 口输出）】
EC200AEUV1HAR02A01M16_OCPU_QPY V02
Board info: 128 116 51 860641095 @ 1.057.067_#98918 Aug 13 2025 13:51:07
Bootloader: NezhaC/Falcon MIFI, Aug 18 2021 - 20:41:02

【uos.uname() 输出 —— 两个构建版本】

版本 A（有问题）
sysname = EC200A-EUV1HA
nodename = EC200A
release = 1.13.0
version = v1.12 on Wed_Aug_13_2025_2:57:54_PM
machine = EC200A with QUECTEL
qpyver = V0001

版本 B（正常）
sysname = EC200A-EUV1HA
nodename = EC200A
release = 1.13.0
version = v1.12 on Fri_May_9_2025_11:18:21_AM
machine = EC200A with QUECTEL
qpyver = V0001

注意：两版的 sysname / release / qpyver 完全相同，
仅 version 字段中的 build 日期不同，客户侧无法通过版本号区分。

================================================================================

二、问题一：TCP 收到下行数据导致模块复位

【影响版本】
版本 A（v1.12 on Wed_Aug_13_2025）复现
版本 B（v1.12 on Fri_May_9_2025）不复现

【现象】
TCP 连接建立后，只要有任何下行数据到达，模块立即崩溃并整体复位。
与应用层是否调用 recv() 无关 —— 即使全程不读取，数据到达协议栈即触发。

【最小复现代码】

import utime
import usocket
import checkNet

HOST = "tcpbin.com"     # 公开 echo 服务，收到什么回什么
PORT = 4242

checknet = checkNet.CheckNetwork("Min", "1.0.0")
stage, state = checknet.wait_network_connected(60)
print("network stage={} state={}".format(stage, state))

addr = usocket.getaddrinfo(HOST, PORT)[0][-1]
sock = usocket.socket(usocket.AF_INET, usocket.SOCK_STREAM)
sock.connect(addr)
print("connected")

sock.send("HELLO 1\r\n")     # 服务器会回显这一包
print("TX done, now idle")

n = 0
while True:                   # 注意：全程不调用 recv()
    n += 1
    print("alive {}s".format(n))
    utime.sleep(1)

【实际输出】

版本 A：
[MIN] connected
[MIN] TX 1 done, now idle
[MIN] alive 1s after tx
<模块复位，DEBUG 口输出完整开机日志>

版本 B（同一份代码、同一台设备、同一个服务器）：
[MIN] connected
[MIN] TX 1
[MIN] TX 2
…
[MIN] TX 11 ← 持续正常，服务器回包全部正常接收

【关键证据】
版本 A 复位后，DEBUG 口开机日志中出现：

5 Board info: 128 116 51 860641095 @ 1.057.067_#98918 Aug 13 2025 13:51:07
6 last thread: tcpip_th
7 Silent Reset: 0 0 0

“last thread: tcpip_th” 表明崩溃发生在 TCP/IP 协议栈线程内部。

【已排除的因素（均在版本 A 上测试）】

测试项结果

只建立连接，不发送任何数据稳定运行 60 秒以上，不复位
发送一包，全程不调用 recv() 服务器回包后约 1 秒复位
阻塞式 recv() 复位
非阻塞 setblocking(False) + 轮询复位
独立线程内阻塞 recv() 复位
自建服务器（115.171.216.233:9527）复位
公开 echo 服务（tcpbin.com:4242）复位
日志输出到 UART0 / 仅用 print 两者均复位，排除串口冲突
内存监控 gc.mem_free() 稳定在 458000 左右，无泄漏
信号质量 CSQ 22~27，信号良好
供电复位时机严格跟随下行数据到达，
非随机，不符合供电跌落特征

结论：复位由"下行数据到达协议栈"直接触发，与应用层写法、对端服务器、
串口日志、内存、信号强度、供电均无关，且在版本 B 上不复现。

【附带现象】
在版本 A 上，REPL 中按 Ctrl+C 中断正在运行的脚本（socket 未显式关闭）时，
模块同样复位。推测与 socket 资源释放路径有关，可能是同一问题的另一触发点。

================================================================================

三、问题二：USB 高速枚举失败，退化为全速

【影响范围】
QuecPython 固件下复现；同一硬件刷回正式版（非 OCPU）固件不复现。

【测试环境】
主机侧为客户 SoC，Linux 4.9.227，Sstar/Mstar EHCI 控制器。
模块 USB 直连 SoC，无 HUB。

【对比结果】

项目正式版固件 QuecPython 固件

枚举结果一次成功失败 20 次以上
设备编号 device number 2 编号递增至 30
协商速度 high-speed (480Mbps) 退化为 full-speed (12Mbps)
枚举出的接口 1.0 / 1.2 / 1.3 / 1.4 额外出现 1.32
ttyUSB 数量 3 个 4 个
内核报错无 error -71 反复出现

【正式版固件日志（正常）】

usb 1-1: new high-speed USB device number 2 using Sstar-ehci-1
usb 1-1: New USB device found, idVendor=2c7c, idProduct=6005
usb 1-1: Product: EC200A-EU
cdc_ether 1-1:1.0 usb0: register ‘cdc_ether’ at usb-mstar-1
option 1-1:1.2: GSM modem (1-port) converter detected → ttyUSB0
option 1-1:1.3: GSM modem (1-port) converter detected → ttyUSB1
option 1-1:1.4: GSM modem (1-port) converter detected → ttyUSB2

【QuecPython 固件日志（异常，节选）】

usb 1-1: new high-speed USB device number 23 using Sstar-ehci-1
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
hub_port_disable: 1 hub->err: 0
usb usb1-port1: attempt power cycle
… 以上过程重复约 20 次 …
usb usb1-port1: unable to enumerate USB device
##[USB] bad dev is going into Full Speed, retry 6 ##
usb 1-1: new full-speed USB device number 30 using Sstar-ehci-1
usb 1-1: not running at top speed; connect to a high speed hub
usb 1-1: config 1 has an invalid interface number: 32 but max is 5
usb 1-1: config 1 has no interface number 5
usb 1-1: config 1 interface 1 altsetting 1 endpoint 0x83 has invalid
maxpacket 512, setting to 64
usb 1-1: New USB device found, idVendor=2c7c, idProduct=6005
option 1-1:1.32: GSM modem (1-port) converter detected → ttyUSB3

【分析】
error -71 (EPROTO) 出现在"读取设备描述符"阶段，早于配置描述符解析，
属于 USB 底层传输错误。
配置描述符异常（bNumInterfaces=5 却包含编号 32 的接口、
全速下 maxpacket=512）是降速枚举后的结果，为现象而非原因。

由于同一硬件在正式版固件下可稳定高速枚举，可排除 SoC 侧驱动、
USB 走线、阻抗匹配等硬件因素，问题指向 QuecPython 固件的
USB PHY 参数或上电时序。

【尝试过的规避手段】
AT+QCFG=“usbcfg” 返回 +CME ERROR: 4（Operation not supported），
无法调整 USB 复合配置
Python 侧 import usb ImportError: no module named ‘usb’

================================================================================

四、诉求

请确认 2025-08-13 构建引入的 TCP 收包复位缺陷，并提供修复版固件。
请确认 QuecPython 固件下 USB 高速枚举失败的原因，
该问题在正式版固件上不存在。
需要的是 EUV1 变体固件。
已知 QPY_OCPU_V0009_EC200A_EUHA_FW 为 EUHA 变体，
刷入 EUV1 模组会导致 LTE 驻网能力丢失，不能作为替代方案。

================================================================================

报告结束

auto_reply_bot · 2026 年8 月 12 日 03:04

已收到该 EC200A-EUV1HA QuecPython 固件问题报告。
从现象对比看，TCP 下行触发复位与 USB 高速枚举失败均具有明确的版本差异特征，且您已提供了较完整的复现代码、DEBUG 日志、Linux USB 枚举日志及排除项，适合由官方技术人员进一步定位固件侧原因。

当前建议如下：

TCP 收包复位问题
建议暂时避免使用 v1.12 on Wed_Aug_13_2025 构建版本进行 TCP 下行业务测试。
如已有 v1.12 on Fri_May_9_2025 构建且业务验证正常，可先作为临时回退版本使用。
是否属于 2025-08-13 构建引入的固件缺陷，需要官方技术人员基于相同 EUV1HA 固件分支复现确认。
USB 高速枚举失败问题
您提供的日志显示异常发生在设备描述符读取阶段，且同一硬件在正式版固件下可高速枚举，问题更适合由固件侧进一步核查 USB 枚举参数、复合接口描述及上电/初始化时序。
QuecPython 应用层通常无法通过 import usb 方式规避此类底层枚举问题。
固件诉求
已注意到您需要的是 EC200A-EUV1HA 变体固件，不建议使用 EUHA 变体固件替代，以免造成网络能力异常。
如需官方对接修复版或验证版固件，请提供邮箱地址，以便技术人员后续发送对应资料或进一步对接。

当前知识库及公开资料暂未查询到该构建版本对应的已公开修复说明，请等待技术工程师为您解答。

本回答仅供参考。若问题已解决，可标记为解决方案；若仍有疑问，请等待官方技术人员回复，最终请以专业解答为准。

Jun.Yuan-QuecPython · 2026 年8 月 14 日 11:17

如沟通，已解决