手机OTG直连ESP32：Termux+Debian+esptool一键烧录固件实战

我一直有个习惯：出差时背包里永远塞一块ESP32开发板和一小包杜邦线。但上周在客户现场，设备固件需要打一个只有手机里存着的临时补丁，电脑电源适配器却坏在了酒店。那一刻我意识到，能随时烧录ESP32的设备，不应该只有电脑。

平时用电脑烧录ESP32太顺理成章了，插上USB线，打开esptool或Arduino IDE，一行命令跑完，谁都不会觉得这是件需要专门研究的事。但真到了没电脑的场景，很多人会卡在第一步：手机OTG插上开发板，根本不知道接下来怎么操作。这篇文章就是来解决这个问题的。我会用Termux在安卓手机上装一个Debian环境，通过OTG线直接连接ESP32开发板，用esptool完成从擦除Flash、烧录固件到验证芯片型号的完整流程，并且把所有命令封装成一个真正意义上的“一键烧录”脚本。

这套方案适合谁？经常出差调试设备的人、喜欢在户外或现场做硬件验证的玩家、手边只有手机但需要快速更新固件的嵌入式工程师。如果你已经有一台root过的安卓手机，那这套流程可以玩得很顺手；即使没有root，我也会在文末列出替代路线和它们的边界。准备好了，我们就从一次真实的现场翻车经历讲起。

1. 为什么非要在手机上烧录：一次没有电脑的现场翻车经历

1.1 我在现场是怎么被逼到用手机的

事情是这样的：客户临时改了需求，要在现有的ESP32网关上改几个参数并重新烧录固件。我带着开发板、USB转串口模块、杜邦线、便携烙铁都齐了，唯独笔记本留在酒店充电，结果充电器烧了。客户现场倒是有电脑，但那是人家的生产控制机，不能乱装软件，更不可能装串口驱动和esptool。

当时我唯一的希望就是手机。我的安卓手机里有Termux，长期跑着一个Debian的proot环境，里面装了Python和一些常用工具。我试着把OTG线插上，ESP32开发板的电源灯亮了，但Termux里ls /dev/ttyUSB0什么都没看到。那一刻我才意识到，手机烧录ESP32这件事，操作路径跟电脑上完全不是一回事。

后来我花了两个多小时，在工位上反复验证，把权限、设备节点、proot映射、串口参数这些坑一个个踩平，才终于做到了插上OTG线、输入一条命令、固件开始写入的效果。现在我把这套流程沉淀成了一套脚本，只要手机root过，整个过程不超过一分钟。

1.2 手机烧录ESP32的三种路线对比

真正动手之前，先横向对比一下目前手机上可行的几种烧录路线。别急着选，看完对比再决定哪条适合你。

三条路线里，浏览器Web Flasher其实是最省事的，手机Chrome直接打开网页就能烧，但它的局限性也明显：不能做read_flash备份，不能擦除整个Flash，不能自定义烧录地址参数，脚本化更无从谈起。手机上的esptool环境，基本等同于一个简化版电脑，能做的事就宽多了。

1.3 为什么我坚持用Termux+Debian这套组合

很多人问我，既然Web Flasher那么简单，为什么还要在手机上折腾Termux和Debian？

原因很简单：我需要的不只是“烧进去”，而是“可控”。esptool在终端环境里能拿到完整日志，能看到芯片信息、Flash ID、MAC地址，能读取固件备份，能指定任意烧录地址，还能把命令封装进脚本里做一键操作。Web Flasher做得再好，它也不能在烧录前自动执行一段Python脚本，更不可能在我出差期间远程连回来处理紧急固件。

Termux提供了安卓上的Linux用户空间，Debian则是熟悉的包管理生态。在proot里跑Debian，不需要重启手机、不需要刷第三方Recovery，apt装东西跟电脑上一模一样，这是这套方案最吸引人的地方。

2. 环境搭建：Termux和Debian在安卓上的正确安装姿势

2.1 安装Termux并完成基础配置

环境搭建这部分，顺序错了后面会各种别扭。先从Termux本体开始。

Termux的安装来源有讲究，建议不要用Google Play商店的版本，那个版本老旧且长期不更新。推荐去F-Droid或者Termux的GitHub Releases页面下载最新版。装完之后打开App，第一件事是更新包管理器和基础组件：

pkg update && pkg upgrade -y

这两个命令会把Termux自带的软件包索引刷新一遍。升级完成后，执行：

termux-setup-storage

这个命令用来授权Termux访问手机内部存储。执行后会弹出系统文件权限弹窗，必须允许。后面我们要从手机存储里读取固件文件，没有这个权限，脚本就只能读取Termux自家目录里的文件，很不方便。

最后设置一个不太显眼但很关键的东西——保持Termux后台运行。因为proot里跑Debian本身是个持续进程，如果手机系统在锁屏后把Termux后台杀了，烧录到一半断线是非常无语的。在Termux里执行：

termux-wake-lock

这个命令让CPU保持唤醒状态。同时建议去手机设置里把Termux的“电池优化”改为“不优化”，这一步能省掉很多莫名其妙的断连问题。

2.2 用proot-distro部署Debian

Termux本身是一个精简的Linux用户空间，但它不能直接用apt装Debian的软件包，因为两者底层的库路径和文件系统布局不一样。所以我们需要在Termux里再套一层Debian，这里最省事的方式就是用proot-distro工具。

pkg install proot-distro -y proot-distro install debian

proot-distro会下载Debian的rootfs，并自动配置好proot运行环境。所谓proot，就是用用户态模拟的方式，在不需要真正修改Android系统分区的前提下，给Debian创建一个根文件系统视图。它比起chroot的最大好处是不需要root权限就能装能跑，但绕不开一个天然短板：访问硬件设备时，权限逻辑依然受限于Android宿主系统。

安装完成后，登录Debian：

proot-distro login debian

进入之后，你应该会看到shell提示符变成了类似root@localhost的样子，说明已经在Debian里了。先执行：

apt update && apt upgrade -y

然后安装后续需要的基础软件包：

apt install -y python3 python3-pip python3-venv git

这里尤其注意，Debian 12及以后版本的Python非常严格，直接用pip3 install装到系统目录会报externally-managed-environment错误。解决办法是创建虚拟环境，或者安装时加--break-system-packages参数。我推荐用虚拟环境，干净而且不污染系统Python。

2.3 在Debian内装好esptool

esptool是乐鑫官方的ESP系列芯片烧录工具，支持ESP32、ESP32-S2、ESP32-S3、ESP32-C3、ESP8266等。在Debian里装它很简单：

python3 -m venv ~/esptool-env source ~/esptool-env/bin/activate pip install esptool

装完验证一下：

esptool.py version

能输出版本号就说明工具没问题了。注意一下，esptool在较新版本里既可以用esptool.py也可以用python3 -m esptool调用，这两个等价，后者更保险，不容易受环境变量影响。

到这里，软件环境就算搭完了。但先别急着插开发板烧录，因为真正的拦路虎在硬件访问权限上，这也是所有人在手机上烧录时最容易栽跟头的地方。

3. 手机识别ESP32串口的底层逻辑与权限方案

3.1 Android和Linux对USB串口设备的不同处理

在普通Linux电脑上，插上一个基于CP2102或CH340芯片的USB转串口模块，系统内核会自动加载对应驱动，并在/dev目录下生成一个ttyUSB0或ttyACM0设备节点。之后esptool只要指定--port /dev/ttyUSB0就能通信。

但Android不是一个普通Linux，它在内核之上多了一层硬件访问管理。当一个USB串口设备通过OTG插入时，Android系统的USBManager会先看到它，然后根据设备的接口类型决定把它交给谁。如果USB调试开启，默认可能会把设备当作调试设备处理；如果插的是串口模块，部分手机会在通知栏弹一个“USB设备已连接”的提示，但普通App根本拿不到/dev/ttyUSB0这个路径。

这就是“插上没反应”的根本原因：内核确实识别到了设备，但设备节点没有暴露给普通用户空间的程序。

3.2 为什么直连不是插上就能用：两个核心障碍

在手机上用Termux+Debian直连ESP32，会遇到两个绕不开的障碍。

第一个是权限障碍。Android系统的App默认跑在u0_aXXX用户下，/dev/ttyUSB0这样的设备节点通常只有root或dialout组才能读写。Termux进程没有这个权限，即便proot里模拟了root身份，它也是用户态模拟，底层的实际用户还是u0_aXXX，内核不认proot的root。

第二个是proot的设备节点映射问题。proot-distro启动Debian时，会绑定一部分/dev目录，但新增的USB设备节点不一定在proot启动时就已经存在。如果插上OTG之后才启动proot，有时会看不到ttyUSB0。这两个问题叠加，就造成了“手机OTG灯都亮了，Termux里却一无所有”的尴尬。

3.3 实操：在root手机上解锁串口

先说推荐路线：手机需要root权限。这一步在环节上是逃不掉的，至少现在没有任何一个无root方案能像电脑一样稳定地操作原生串口节点。有root之后，操作变得非常直接。

插上OTG线和ESP32开发板，在Termux中先确认内核是否识别到了设备：

su -c 'lsusb'

如果输出里有类似10c4:ea60（CP2102）或1a86:7523（CH340）的ID，说明USB层已经识别到了。接着看内核生成的串口节点：

su -c 'ls /dev/ttyUSB* /dev/ttyACM*'

正常情况下会看到/dev/ttyUSB0或/dev/ttyACM0。此时修改设备节点权限：

su -c 'chmod 666 /dev/ttyUSB0'

改完之后，再进入proot里的Debian：

proot-distro login debian

进入后检查设备节点：

ls -l /dev/ttyUSB0

如果能看到，就说明proot环境继承了Android宿主上创建的设备节点。如果看不到，通常是因为proot启动时没有绑定这个节点，退出proot、重新执行proot-distro login debian往往就能解决。实测绝大多数情况这样操作后就能在Debian里正常读到串口。

3.4 没有root的备选方案

如果你的手机没有root，也不是完全没有办法。Termux官方有一个termux-usb工具，可以申请系统USB权限并把USB文件描述符传递给Termux内的程序。但这条路有个前提：esptool和pyserial本身是基于设备路径打开串口的，不是基于文件描述符，所以要让termux-usb配合esptool工作，中间还缺一层适配。

目前社区里更常见的无root做法是直接跳开esptool，用浏览器版Web Serial烧录。这个方法在我的对比表里排第一，原因是它真的太省事了，也真心推荐给没有root的玩家。只要手机Chrome浏览器支持Web Serial API，打开对应烧录页面，选择设备、选择固件、点击烧录，剩下交给浏览器。

但无root的Web Flasher方案有一个硬伤：无法读取Flash备份，无法自由指定烧录地址。所以如果你想做更底层的操作，root仍然是移动烧录的最优解。

4. 一键烧录脚本设计：从硬记参数到一条命令搞定

4.1 esptool参数拆解：芯片、端口、波特率、Flash参数

工具能跑起来之后，面临的下一个问题是参数。esptool的命令行参数不少，但核心常用的就是几个，我把它们拆开说明白。

一个典型的烧录命令是这样的：

python3 -m esptool --chip esp32 --port /dev/ttyUSB0 --baud 460800 \ write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect \ 0x1000 bootloader.bin \ 0x8000 partitions.bin \ 0xe000 boot_app0.bin \ 0x10000 firmware.bin

如果你手里的是合并好的单一固件，比如MicroPython的ESP32_GENERIC-20240602-v1.23.0.bin，那就简单很多，直接写到一个地址即可：

python3 -m esptool --chip esp32 --port /dev/ttyUSB0 --baud 460800 \ write_flash 0x1000 ESP32_GENERIC-20240602-v1.23.0.bin

这里面的0x1000是bootloader所在的起始地址，MicroPython发布版已经内置了完整的启动链，所以一个文件从0x1000写入就行。

4.2 一键脚本的骨架和关键实现

理解了参数，封装脚本就顺理成章了。我看网上很多“一键烧录”脚本都喜欢用Python写，但我更喜欢纯Bash，理由是依赖更少、在任意Linux环境上都能跑，手机和电脑通吃。

下面是我实测过的一个脚本核心骨架：

#!/data/data/com.termux/files/usr/bin/bash set -e PORT="${PORT:-/dev/ttyUSB0}" CHIP="${CHIP:-esp32}" BAUD="${BAUD:-460800}" FIRMWARE="${1:-firmware.bin}" FLASH_ADDR="${FLASH_ADDR:-0x1000}" echo "[1/4] 检查串口设备 ${PORT} 是否存在..." if [ ! -e "${PORT}" ]; then echo "[错误] 没有检测到串口设备: ${PORT}" echo "请检查OTG线、USB转串口模块，以及是否已执行 chmod 666 ${PORT}" exit 1 fi echo "[2/4] 读取芯片信息，确认通信正常..." python3 -m esptool --chip "${CHIP}" --port "${PORT}" --baud "${BAUD}" chip_id echo "[3/4] 擦除Flash..." python3 -m esptool --chip "${CHIP}" --port "${PORT}" --baud "${BAUD}" erase_flash echo "[4/4] 烧录固件 ${FIRMWARE} 到地址 ${FLASH_ADDR}..." python3 -m esptool --chip "${CHIP}" --port "${PORT}" --baud "${BAUD}" \ write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect \ "${FLASH_ADDR}" "${FIRMWARE}" echo "[完成] 烧录成功!请复位ESP32设备运行新固件。"

保存为flash.sh，加执行权限：

chmod +x flash.sh

使用时只需要：

./flash.sh firmware.bin

脚本里的环境变量设计是为了适应不同场景：默认烧录地址是0x1000，但如果你要烧合并固件到0x0000，可以这样覆盖：

FLASH_ADDR=0x0000 ./flash.sh merged.bin

芯片类型变了也一样，比如烧ESP32-S3：

CHIP=esp32s3 PORT=/dev/ttyACM0 ./flash.sh s3_firmware.bin

4.3 让脚本更聪明：自动探测端口、自动进入下载模式、掉线重试

上面这个骨架能跑，但还不够“一键”。现场环境中至少有三个突发情况要处理：设备节点可能不是ttyUSB0而是ttyACM0；开发板可能没进入下载模式导致esptool一直报超时；烧录中途因为安卓系统休眠导致串口断了。

针对端口不确定的问题，我加了一段自动探测逻辑：

detect_port() { for dev in /dev/ttyUSB* /dev/ttyACM*; do if [ -e "${dev}" ]; then echo "${dev}" return 0 fi done return 1 } PORT="${PORT:-$(detect_port)}"

针对下载模式的问题，esptool本身支持通过RTS/DTR引脚自动复位进入下载模式，但有部分开发板需要手动按住BOOT键。我们在脚本里加一个提示和重试机制：

MAX_RETRY=3 RETRY=0 while [ ${RETRY} -lt ${MAX_RETRY} ]; do if python3 -m esptool --chip "${CHIP}" --port "${PORT}" --baud "${BAUD}" chip_id; then break fi RETRY=$((RETRY + 1)) echo "[提示] 芯片连接失败，请按住BOOT键后按一下EN键复位，然后松开BOOT键..." sleep 3 done

这一小段真金白银地节省过我的时间。现场调试时，开发板放在密封箱里，手指按不到复位键，脚本每隔3秒自动重试，给了足够时间来调整，比手动输命令高效得多。

最后一个关键点是解决手机休眠断连。单纯在Termux里运行脚本，锁屏后大概率会断。除了前面提到的termux-wake-lock，我在脚本开头也加了一句提醒：

termux-wake-lock 2>/dev/null || true

这样即使之前忘了执行，跑脚本时也会自动把CPU唤醒锁打开。

4.4 把“一键”做得更彻底：在手机上选择固件

真正成熟的“一键”，是连固件路径都不用手工敲。我平时会把编译好的固件放在手机的Download/firmware目录，然后配合Termux的termux-storage-get命令调出系统文件选择器。

get_firmware() { if [ -n "${1}" ]; then FIRMWARE="${1}" else echo "[提示] 请选择要烧录的固件文件..." FIRSTMWARE="$(termux-storage-get)" fi }

这样整个流程就变成了：

./flash.sh

然后手机弹出一个文件选择框，随便点选一个bin文件，脚本自动完成“探测端口、连接芯片、擦除Flash、烧录固件”全套动作。从插上OTG线到烧录完成，全程手都不用碰键盘。

5. 完整实测：从插OTG到固件跑起来的全过程

5.1 硬件准备、接线和进入下载模式

理论说了这么多，现在开始完整实测一遍。我使用的硬件如下：

• 安卓手机：一台root过的老款OnePlus，Android 12，支持OTG
• OTG转接头：Type-C转USB-A母头
• 开发板：ESP32 DevKitC V4，板载CP2102串口芯片
• 固件：MicroPython官方ESP32_GENERIC-20240602-v1.23.0.bin

接线其实很简单：开发板通过一根Micro USB线连接到OTG转接头，再把OTG转接头插到手机Type-C口。不需要额外接GPIO，因为DevKitC板载了USB转串口芯片，烧录信号已经通过板子内部连到了正确的GPIO。

如果你的板子没有板载USB转串口，比如是裸ESP32模块，那就需要单独一个USB转TTL模块，接线方式是：

进入下载模式的方法很简单：按住开发板上的BOOT键（也就是IO0），然后按一下EN键复位，复位完成后再松开BOOT键。这样ESP32就会以下载模式启动，固件里的用户程序不会运行。

如果你用的是带自动下载电路的板子（比如NodeMCU、ESP32-DevKitC），esptool会自动通过DTR/RTS控制复位进入下载模式，不需要手动按键。但手动方式永远是最可靠的兜底方案。

5.2 第一次烧录：日志逐行解读

OTG插好后，在Termux中进入Debian环境，执行：

source ~/esptool-env/bin/activate ./flash.sh select

或者直接走完整命令。烧录过程中的日志输出大概是这样的：

[1/4] 检查串口设备 /dev/ttyUSB0 是否存在... [2/4] 读取芯片信息，确认通信正常... esptool.py v4.7.0 Serial port /dev/ttyUSB0 Chip is ESP32-D0WD-V3 (revision v3.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 30:ae:a4:xx:xx:xx Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed.

看到Chip is ESP32-D0WD-V3就说明芯片连接成功了。紧接着：

[3/4] 擦除Flash... Erasing flash (this may take a while)... Chip erase completed successfully in 4.3s

擦除Flash花了4.3秒，属于正常范围。如果这一步超过20秒，很可能是USB线质量太差或者波特率过高，可以降低波特率再试。

然后是烧录：

[4/4] 烧录固件 firmware.bin 到地址 0x1000... Compressed 1493560 bytes to 943720... Writing at 0x001000... (12 %) Writing at 0x002000... (24 %) ... Hash of data verified. Leaving... Hard resetting via RTS pin... [完成] 烧录成功!请复位ESP32设备运行新固件。

这里有三个信息值得关注：第一，Compressed表示固件在传输前先做了压缩，会显著缩短烧录时间；第二，Hash of data verified表示烧录完成后esptool自动做了数据校验，传输没有问题；第三，Hard resetting via RTS pin表示开发板已经自动复位，新固件马上开始运行。

5.3 烧录完成后的验证

烧录成功不等于固件一定能跑起来。最常见的翻车点是：开发板复位后，串口日志里什么都没有，或者反复进入下载模式。

最直接的验证方法是读取串口日志。在Debian里装一个终端工具：

apt install -y picocom picocom /dev/ttyUSB0 -b 115200

如果你烧的是MicroPython，打开串口后按一下开发板的EN键复位，应该能看到类似这样的输出：

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) ... MicroPython v1.23.0 on 2024-06-02; ESP32 module with ESP32 Type "help()" for more information. >>>

能进入>>>提示符，说明固件已经正常启动。picocom退出快捷键是Ctrl+A然后再按Ctrl+X，这个快捷键比较容易忘，我每次都要查，干脆记在这里。

如果不想进Debian，也可以在Termux里直接用microcom：

pkg install microcom microcom -p /dev/ttyUSB0 -s 115200

效果类似，只是交互方式略有区别。

另外，还可以用esptool读取Flash内容来验证：

python3 -m esptool --port /dev/ttyUSB0 read_flash 0x1000 0x1000 verify.bin

这个命令会把Flash里从0x1000开始的一小段内容读取出来保存到verify.bin，如果文件大小和预期一致，说明Flash读写通道正常。

5.4 实测数据：不同波特率下的烧录耗时

烧录耗时和波特率强相关，我顺便做了一个简单的对比实测。同一个固件（约1.4MB的MicroPython），同一根OTG线，同一块开发板，结果如下：

这个数据仅供参考，不同手机、不同USB转串口芯片、不同OTG线材都会影响结果。但结论是比较通用的：460800是稳定性和速度之间的最佳平衡点。

6. 高频踩坑清单与移动烧录的边界

6.1 我踩过的坑和排查链路

整个流程从零到能跑，我在路上踩了不少坑。挑几个最典型的，每个都写清楚和分析路径，这样你遇到类似问题可以直接对号入座。

第一个坑：插上OTG后lsusb能看到设备，但/dev/ttyUSB0不存在。这种情况通常是Android的USBManager没有把设备释放给用户空间。排查链路是：先确认lsusb是否能看到CP2102或CH340的ID；能看到说明硬件正常；再看手机是否存在“USB配置”选项，部分手机需要把USB模式从“仅充电”切换成“传输文件”或“MIDI”才能挂载串口设备。

第二个坑：设备节点存在，但esptool报Permission denied。这个没什么玄学的，就是权限不够。执行：

su -c 'chmod 666 /dev/ttyUSB0'

再试。如果每次拔插后权限都会重置，就把这条命令写进一键脚本的开头。

第三个坑：烧录进行到一半，进度条停在某个百分比不动，然后报Failed to write to target RAM。多数情况是USB供电不稳，ESP32在写入时瞬时电流大，手机OTG口供电能力不够。解决办法有三种：换一个供电能力更强的OTG转接头；用Y型OTG线给开发板单独供电；或者降低波特率到115200，减少电流波动的影响。

第四个坑：proot里看不到设备节点。这跟proot启动时的设备绑定时机有关。我实测有效的方法是在Termux外层先确认节点存在，再启动proot；如果还是看不到，就退出Debian、重新执行proot-distro login debian，大部分情况下第二次就能看到。

6.2 这些问题背后的共同规律

踩完这一圈坑，我发现这些问题看似五花八门，实际上都绕不开三个关键点：权限、电源、下载模式。

权限问题就是Android的设备节点访问限制，root后加一行chmod就能解决；电源问题考验的是OTG转接头的供电能力和开发板功耗，想稳就别买最便宜的那根线；下载模式问题则考验对ESP32启动流程的理解，无论什么板子，手动按住BOOT键再复位永远是通用答案。

只要把这三点刻在脑子里，遇到任何新的烧录报错，你都能按这条思路快速定位。

6.3 移动烧录的适用边界和更远的扩展

说得乐观，但也要泼盆冷水。手机Termux烧录虽然方便，但不适合量产场景。量产几十块板子一件件用OTG线烧，效率太低，那种场景更应该用烧录夹具加电脑批量工具。手机烧录的定位是“灵活”，不是“产能”。

另外，这套流程还可以有更远的扩展。比如在Termux里跑一个SSH服务，出差时从平板远程连接到手机上的Debian，直接执行烧录脚本；也可以借助Termux:Widget，把一键烧录脚本放到手机桌面，点一下图标就开始烧录。我目前的日常流程就是桌面Widget触发烧录脚本，彻底告别了打开Termux敲命令的步骤。

如果你玩的是ESP32-S3这类原生USB接口芯片，烧录端口会变成/dev/ttyACM0，脚本里的自动探测逻辑依然有效。如果你手里同时有ESP32和ESP8266，或者跟LAN8720以太网模块一起搞通信测试，这套移动烧录思路也照样适用，只是芯片型号参数要相应调整。

写到最后，说点真心话。这套流程我最频繁使用的场景，其实不是客户现场，而是周末在咖啡厅改玩具固件的时候。手机放在桌上，OTG线连着开发板，点一下脚本，喝着咖啡等进度条跑完。硬件开发的乐趣本来就该这么轻量。如果你也经常被困在“手边有板子但没电脑”的处境里，希望这篇文章能帮你把最后那根绊脚线剪断。