简介面向ESP32-S3开发者的BLE OTA升级代码包配套博文完整讲解从硬件与软件准备、BLE服务初始化、固件分包传输、数据校验写入到重启生效的无线更新流程精准解决物联网设备远程固件升级中的开发与调试难题。包体非常精简共3个文件主要包含HTML格式的说明文档、inscode工程配置以及gitignore版本管理规则压缩包仅5KB无需冗长下载等待。目前已有109人学习下载适合智能硬件、可穿戴设备等项目中需要掌握低功耗蓝牙无线升级能力的初中级嵌入式开发人员。资源核心价值在于既给出了BLE服务初始化与OTA数据处理的关键代码示例又提供了分块大小调整、错误恢复机制、超时处理及电源管理等部署优化建议配合清晰的流程图和逐行注释能够帮助开发者深入理解底层原理有效规避升级失败风险快速落地稳定可靠的OTA升级功能。1. 为什么 ESP32-S3 还要走 BLE 做 OTA 升级ESP32-S3 BLE OTA 升级这件事第一次听起来像个伪需求——WiFi 快得多为什么非要用蓝牙传固件但真做过设备的都知道大量量产产品根本没有 WiFi也没有网口设备装进密封壳体后只剩一根天线伸出来手机 App 是唯一能和它对话的通道。穿戴手环、传感器节点、某些医疗小设备、工业现场的便携采集器全是这个形态。在这种场景里BLE OTA 不是备选方案而是唯一方案。它解决的问题非常具体手机通过 BLE 连接设备把新固件分包传进去设备收到完整镜像后校验、切换分区、重启完成升级。整个过程不需要拆机、不需要数据线、不需要网络环境。这篇文章就围绕「ESP32-S3 BLE OTA升级[代码]」这个标题把从分区表设计到 GATT 服务实现、再到断点续传和安全校验的完整落地路径拆开讲适合正在做量产固件升级功能的嵌入式开发者也适合第一次接触 BLE 无线升级、想评估方案可行性的硬件工程师。2. 拆解 ESP32-S3 BLE OTA 升级GATT 服务、分区表与协议栈选型2.1 分区表里必须放得下两套固件ota_0、ota_1 与 ota_data 的作用BLE OTA 和 WiFi OTA 在 ESP32-S3 上的底层机制完全一样都是走 esp_ota 接口写 flash区别只在上层数据传输方式。既然是 OTA分区表就不是默认的单 factory 分区而是至少要划分出两个 app 分区和一个 ota_data 分区。两个 app 分区的作用是让设备永远有一个「当前可用固件」兜底正在跑的固件在 app0新收到的固件写到 app1写完校验通过后把启动标记指向 app1重启就进入新固件。如果校验失败或者新固件起不来引导程序还能根据 ota_data 里的信息回退到旧固件。分区表用 ESP32-S3 常见的 CSV 方式配置关键是把 SubType 写成 ota_0 和 ota_1并且给 ota_data 留出独立空间。我一般会这样划分# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, ota_data, data, ota, 0xd000, 0x2000, app0, app, ota_0, 0x10000, 0x400000, app1, app, ota_1, 0x410000, 0x400000,这里有两处值得注意。第一ota_data 的 SubType 是 ota不是 nvs引导程序和 esp_ota 接口靠这个类型识别它第二app0 和 app1 的 Offset 必须按 flash 擦除块对齐上面这个布局里每个 app 分区 4MB如果你的固件实际只有 1MB也不要为了省空间把两个分区贴着放留给后续固件膨胀的余量很关键。Size 一栏如果不填默认按偏移自动推算但显式写出来更稳。从原理上讲这种双分区结构牺牲了一半 flash 容量换来的是升级失败不砖机的保障。对于 BLE OTA 这种传输速度慢、中间容易断连的升级方式双分区几乎是必须的——单分区模式下一旦写入一半断电设备就变砖只能靠串口救量产现场根本没有这个条件。2.2 GATT 服务设计Write 特征收数据控制特征才能做完整状态机BLE 本身不关心你传的是什么它只提供 GATT 服务和特征Characteristic。做 OTA 时我们需要在设备端自定义一个 GATT Service里面至少放两个特征一个用于接收固件分片数据的 Write 特征一个用于传输控制命令的 Control 特征。为什么不能只用一个特征因为固件传输过程不是「把数据写进去」这么简单它需要完整的握手手机端先发「开始升级」命令设备回复「准备就绪」并告知当前版本然后手机开始分包发数据数据发完后设备做校验再回报「校验结果」最后手机发「重启」命令。这些状态切换如果和数据混在同一个特征里每次交互都要解析包头代码会变得很脆弱调试时也分不清是数据问题还是状态问题。我实际工程里用的服务定义是这样的static const ble_gatt_svc_def_t ota_svc_defs[] { { .type BLE_GATT_SVC_TYPE_PRIMARY, .uuid ota_svc_uuid, .characteristics (ble_gatt_chr_def_t[]) { { .uuid ota_ctl_char_uuid, .access_cb ota_ctl_access, .flags BLE_GATT_CHR_F_WRITE | BLE_GATT_CHR_F_NOTIFY, }, { .uuid ota_data_char_uuid, .access_cb ota_data_access, .flags BLE_GATT_CHR_F_WRITE_NO_RSP | BLE_GATT_CHR_F_WRITE, .val_handle ota_data_handle, } } }, { 0 } };Control 特征带 Notify 权限是为了设备能主动给手机发升级进度和结果Data 特征用 WRITE_NO_RSP是为了减少 BLE 协议层的应答开销提升吞吐。这里有一个性能细节如果用普通 WRITE手机每发一包都要等设备返回 ATT Write Response一来一回至少多一个连接间隔的延迟用 WRITE_NO_RSP手机可以连续发包设备端在回调里逐个处理吞吐能提升接近一倍。代价是协议层不保证送达所以应用层必须靠序列号机制补可靠传输这个后面展开。2.3 选 NimBLE 还是 Bluedroid内存、吞吐与开发成本ESP32-S3 的官方 SDK 里默认集成了两套蓝牙协议栈Bluedroid 是传统选择功能全但内存占用大服务发现流程复杂NimBLE 是后来引入的轻量协议栈专为资源受限设备设计API 风格更简洁启动速度也快。做 BLE OTA 我建议直接用 NimBLE。原因有三。第一OTA 场景里设备是被动方不需要复杂的 GATT Client 逻辑NimBLE 完全够用Bluedroid 里大量我们用不到的外设、A2DP 等协议栈代码白白占着 RAM。第二NimBLE 的 GATT 事件模型更直接写特征的数据通过回调一次性送到应用层不需要像 Bluedroid 那样处理多层消息转发。第三NimBLE 支持动态 MTU 协商配合较大的 ATT MTU 能把单包数据量顶上去这对传输效率至关重要。Bluedroid 也能做到但配置项更绕。还有一个实际痛点Bluedroid 在做长时间大数据量写入时偶尔会出现协议栈内部缓冲堆积表现为「连接正常但数据收发越来越慢」这种问题很难查。NimBLE 在这类长传输场景下的稳定性经验值更好。如果你是从零开始的项目别犹豫直接选 NimBLE如果已经有 Bluedroid 的存量代码除非你对现有传输稳定性很有把握否则迁移成本也值得花。3. 用 NimBLE 落地 ESP32-S3 BLE OTA从分区配置到分片写入3.1 最小分区表与 menuconfig 开关BLE 相关配置项怎么开动手写代码之前先确认项目配置里开了 NimBLE 并关掉不需要的蓝牙协议。这一步错了后面所有代码都白写。在项目根目录执行idf.py menuconfig按下面路径设置Component config → Bluetooth → Bluetooth → [x] Enable Bluetooth Component config → Bluetooth → Bluetooth Controller → [x] BLE 5.0 Component config → Bluetooth → NimBLE Options → [x] Enable NimBLE这几个开关是基础。另一个容易被忽略的选项在NimBLE Options → Enable advertising和Enable scanningOTA 场景里设备通常只需要广播和连接不需要扫描别的外设关掉扫描能省一点 RAM。还有一项Max number of BLE connections默认 3做 OTA 时改成 1 就够多连接不会让升级更快反而增加协议栈负担。接着在 CMake 里加上 NimBLE 组件依赖REQUIRES nimble esp_ota esp_partition nvs_flash这一步确保链接器能把 NimBLE 协议栈和 OTA 相关库都打进来。编译时如果报ble_gatts_*找不到符号大多数情况就是这句 REQUIRES 没写全。分区表用上一章那份 CSV在menuconfig → Partition Table → Partition Table里选择Custom partition table CSV并指定文件路径。这里有个常见翻车点改了分区表之后第一次烧录必须用idf.py erase-flash擦掉整片 flash再烧新固件。因为旧分区表里的 ota_data 区域可能残留脏数据引导程序读到非法 ota 信息会启动异常。这不是玄学是分区变更后没擦 flash 导致的真实问题烧录顺序错了排错能排一下午。3.2 注册 GATT 服务与写特征回调分片数据进来自动落盘NimBLE 的服务注册流程是先注册 GATT 回调再添加服务定义最后通过ble_gatts_start()让服务生效。完整初始化代码大致如下static uint8_t ota_svc_uuid[16] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }; static uint16_t ota_data_handle; static int ota_data_access(uint16_t conn_handle, uint16_t attr_handle, struct ble_gatt_access_ctxt *ctxt, void *arg) { if (ctxt-op BLE_GATT_ACCESS_OP_WRITE_CHR) { uint16_t len OS_MBUF_PKTLEN(ctxt-om); if (ota_ctx.state ! OTA_STATE_DATA) { return BLE_ATT_ERR_INVALID_ATTR; } // 从 mbuf 里把数据拷到线性缓冲区 uint8_t *buf malloc(len); if (!buf) return BLE_ATT_ERR_INSUFFICIENT_RES; os_mbuf_copydata(ctxt-om, 0, len, buf); esp_err_t err esp_ota_write(ota_ctx.handle, buf, len); free(buf); if (err ! ESP_OK) { return BLE_ATT_ERR_UNLIKELY; } ota_ctx.offset len; return 0; } return BLE_ATT_ERR_UNSUPPORTED; }这段代码的逻辑是数据特征收到写入时先检查 OTA 状态是不是「正在收数据」不是就直接拒绝——这能挡住没发开始命令就硬写数据的异常手机端然后把 NimBLE 协议栈里的 mbuf 数据拷到线性缓冲区再调用esp_ota_write写入 flash。这里有个必须强调的点os_mbuf_copydata之前ctxt-om指向的数据只在回调期间有效回调返回后协议栈会回收这个 mbuf所以千万不能把指针存下来异步处理。数据拷贝是必须的不是额外开销。回调里ota_ctx是一个全局结构体保存着当前升级会话的状态、写句柄和已写入偏移。用全局变量不是因为优雅而是因为 GATT 回调本身拿不到自定义上下文用全局变量是最直白的做法。生产级代码可以改成按 conn_handle 查表但单连接场景下全局变量完全够用。3.3 固件分片写入 OTA 分区esp_ota_write 与校验切换控制特征的回调负责整个升级状态机。开始升级命令到达时要做三件事读当前运行分区、计算目标分区、调用esp_ota_begin拿到写句柄。伪代码如下static int ota_ctl_access(uint16_t conn_handle, uint16_t attr_handle, struct ble_gatt_access_ctxt *ctxt, void *arg) { if (ctxt-op BLE_GATT_ACCESS_OP_WRITE_CHR) { uint8_t cmd; os_mbuf_copydata(ctxt-om, 0, 1, cmd); switch (cmd) { case OTA_CMD_START: { const esp_partition_t *running esp_ota_get_running_partition(); const esp_partition_t *target esp_ota_get_next_update_partition(running); esp_ota_begin(target, OTA_SIZE_UNKNOWN, ota_ctx.handle); ota_ctx.offset 0; ota_ctx.state OTA_STATE_DATA; break; } case OTA_CMD_FINISH: { esp_ota_end(ota_ctx.handle); esp_ota_set_boot_partition(esp_ota_get_next_update_partition( esp_ota_get_running_partition())); ota_ctx.state OTA_STATE_IDLE; break; } case OTA_CMD_REBOOT: esp_restart(); break; } } return 0; }esp_ota_begin的第一参数是目标分区但第二参数有个细节如果不知道固件大小传OTA_SIZE_UNKNOWN库内部会按整个分区大小做擦除准备如果手机端在开始命令里附带固件字节数就传那个数字能省掉多余擦除时间。BLE OTA 本身已经很慢能省的擦除时间不要浪费。esp_ota_end返回ESP_OK不代表升级完成它只代表镜像写入和校验通过。真正让设备下次启动进入新固件的是esp_ota_set_boot_partition这一步设置 ota_data 里的启动标记。很多第一次做的人漏掉这一句结果升级完重启还是旧固件还以为是写入失败。另外esp_ota_end传入的 handle 用完就失效了后面不要再碰。OTA_CMD_FINISH和OTA_CMD_REBOOT拆成两条命令是刻意的手机端收到 FINISH 的应答后可以先提示用户「升级完成即将重启」让用户有个心理预期而设备端在收到 REBOOT 前也保留着最后反悔的机会。如果校验失败手机端不发 REBOOT设备继续跑旧固件一切如常。4. BLE OTA 避坑实录5 个让我返工的问题4.1 问题一MTU 没协商一次写 512 字节直接被拒现象手机端明明把 MTU 请求到了 512数据特征也声明了 512 字节的最大长度但设备端回调里len永远只有 20 字节发大包直接返回错误。原因NimBLE 的默认 ATT MTU 是 23 字节扣除 ATT 头后有效载荷 20 字节。手机端请求 512 只是「希望」设备端必须在ble_gap_event里响应 MTU 更新事件把实际 MTU 抬上去。这个响应不是自动的。解决在 GAP 事件回调里加上BLE_GAP_EVENT_MTU分支调用ble_att_set_preferred_mtu(512)并返回 0 接受。注意这个值是设备端愿意接受的上限手机端最终取两者较小值。如果设备端只设 256手机再想传 512 也没用。做吞吐优化时这一项排在最前面。4.2 问题二分片序号丢了写入位置错乱导致镜像损坏现象传输途中偶尔断连重连后手机端从断点继续发但设备端已经不知道当前写到哪了恢复后写入的数据错位镜像校验失败。原因最初版本只依赖oto_ctx.offset累计长度但断连后这个全局变量没复位而手机端可能已经从自己记录的断点重新开始发两边的偏移对不上。解决在 BLE 断开连接事件里把 OTA 状态机复位到 IDLE手机端每次重连后先发一条查询命令设备端返回当前已写入偏移手机端从该偏移续传。这个交互不能省它是断点续传成立的前提。只靠「断开就重传整个固件」虽然简单但 BLE OTA 传一半断一次就得重来一小时用户会疯的。4.3 问题三在回调里做 flash 擦写触发看门狗重启现象传输过程中设备无缘无故重启串口日志最后一条是WDT timeout。原因BLE 写特征回调运行在协议栈任务上下文里esp_ota_write内部会做 flash 擦除擦一个 4KB 扇区在 ESP32-S3 上要几十毫秒到上百毫秒。单次回调擦一次没事但连续快速写入时协议栈任务被长时间占用系统任务IDLE 任务里的喂狗得不到调度看门狗就咬人了。解决不能直接把大块数据在回调里写入。常见做法是把回调收到的分片先放进一个环形缓冲区由一个专门的 OTA 写任务负责从缓冲区取数据并调用esp_ota_write同时在该任务里喂狗。缓冲区大小要根据 MTU 和写入速度匹配我常用的配置是 16 个 512 字节槽位。另一个办法是每次写入后主动vTaskDelay(1)让出 CPU但这会拖慢吞吐治标不治本。4.4 问题四升级完成后没设置 ota_data重启进不了新固件现象esp_ota_end返回ESP_OK手机端也收到了成功应答但设备重启后还是跑旧版本反复升级都一样。原因esp_ota_end只做了镜像校验并没有把启动分区切到新固件。引导程序启动时读 ota_data 决定进哪个 app 分区ota_data 里没写新分区信息自然还是进旧固件。解决在esp_ota_end成功之后立刻调用esp_ota_set_boot_partition把目标分区设为下一次启动分区。更稳妥的做法是写完新固件后先不切分区重启后由引导程序或应用层做「新固件自检」确认能正常启动后再通过esp_ota_mark_app_valid_cancel_rollback把这次启动标记为有效。这样如果新固件起不来下次重启还能自动回退。量产固件建议用后者开发调试期用前者更省事。4.5 问题五蓝牙断开后再次连接服务句柄对不上现象第一次连接能正常收发 OTA 数据断开重连后手机端找到的服务特征句柄和之前一样但写入时设备端没有响应。原因NimBLE 在连接断开后如果没有重新注册服务句柄理论上不变但实际工程里如果 GATT 服务注册是在某个初始化函数里做的而该函数又被连接事件触发了多次就会重复注册句柄漂移。解决把ble_gatts_count_cfg和ble_gatts_add_svcs放到系统初始化阶段只执行一次不要在连接事件里调用。另外手机端重连后应该重新执行discover services不要缓存旧句柄。这两个习惯能避免九成以上的重连问题。排查时如果发现服务注册了两次在日志里搜服务 UUID 出现的次数一目了然。5. 传输参数与断点续传把 BLE OTA 调稳的关键设置5.1 MTU 协商把单包从 128 提到 512吞吐差 4 倍BLE 的物理层速率上限在理想条件下约 1Mbps但实际有效吞吐受 MTU、连接间隔、事件长度三重约束。ESP32-S3 支持 BLE 5.0连接间隔可以最小到 7.5ms单次连接事件内可以传多个包。如果你只看默认配置吞吐往往只有十几 KB/s而调好参数后能到 60~100 KB/s差距就在这三项。MTU 协商这一步放在连接刚建立后做手机端发起exchangeMTU请求时设备端在 GAP 事件里响应代码里这样处理case BLE_GAP_EVENT_MTU: // mtu 参数包含在 event-mtu 里 ble_att_set_preferred_mtu(512); return 0;ble_att_set_preferred_mtu设置的只是设备端的偏好值实际生效的 ATT MTU 是双方协商后取较小者。所以手机端如果只请求 256实际 MTU 就是 256。设备端把值设到 512 是为了不成为瓶颈。MTU 提上去后还要同步改两个配置数据特征声明的最大长度要匹配缓冲区大小要匹配。我见过 MTU 协商成功但数据特征最大长度还写着 128 的配置结果数据被协议栈截断回调里收到的永远是 128 字节。连接参数也值得调。NimBLE 里设置连接间隔和从机延迟的常用接口是ble_gap_update_params在连接建立后主动发起更新static void update_conn_params(uint16_t conn_handle) { struct ble_gap_upd_params params { .itvl_min 8, // 10ms单位 1.25ms .itvl_max 8, .latency 0, .supervision_timeout 400, }; ble_gap_update_params(conn_handle, params); }连接间隔 10ms、从机延迟 0意味着每个连接间隔设备都参与通信。把间隔拉长到 30ms 可以省电但 OTA 期间省电没有意义越快传完才是真省电。supervision_timeout 建议不小于 400单位 10ms即 4 秒这个值如果太小手机锁屏导致几个连接间隔没响应连接就被判超时断开。5.2 超时与重传策略GATT 层没有 ACK协议层要自己补BLE GATT 的 WRITE_NO_RSP 不保证数据送达这意味着设备端可能漏包。设计 OTA 协议时最稳妥的方案是给每个分片加一个 16 位序列号放在分片数据的前两个字节。设备端收到后检查序列号是否连续不连续就回 NAK手机端从断点重传。序列号方案落地时有一个细节设备端回复 NAK 本身也可能丢所以不能只做「收到 NAK 才重传」还要加超时机制。手机端每发完一个窗口比如 32 包就停一下等设备端的 ACK 或 NAK超时未收到就整体重发这个窗口。窗口大小和 MTU 有关MTU 512、每包有效载荷 510 字节时32 包一个窗口大约 16KBACK 往返 10ms吞吐和可靠性比较平衡。另一个容易踩的坑是设备端写入 flash 的速度跟不上 BLE 接收速度。esp_ota_write在连续写入时flash 擦写时间会周期性拖慢处理速度。手机端如果无视设备端的接收能力猛发缓冲区满了之后回调会返回错误造成连锁丢包。解法是在控制特征的回调里设备端主动上报「缓冲区剩余空间」手机端据此调整发送节奏。这个字段不复杂但对长时间传输稳定性帮助很大。5.3 断点续传记录已写入长度重连后从断处继续BLE OTA 传一半断连是常态不是异常。设计时就要接受这个现实把断点续传做成默认能力。设备端在每次esp_ota_write成功后更新ota_ctx.offset这个值在 OTA 进行中写入 NVS这样即使设备断电重启也能恢复上次进度。恢复流程是这样手机端重连后先读设备端当前固件版本确认确实需要继续升级再读已写入偏移recorded_offset然后从该偏移的下一个分片开始发。设备端收到「续传」命令后用esp_ota_begin重新打开同一个目标分区并把内部写偏移设置到recorded_offset之后正常接收数据。这里有一个坑esp_ota_begin总是从分区头部开始写不管之前写到哪。要实现从中途接着写不能直接用esp_ota_write的顺序模式需要在开始命令里把断点偏移传给esp_ota_write的写位置。常见的做法是分片数据自带绝对偏移设备端用esp_ota_write_with_offset接口指定写入位置esp_err_t err esp_ota_write_with_offset(ota_ctx.handle, buf, len, ota_ctx.offset);用绝对偏移还有一个好处即使手机端发的分片到达顺序乱了设备端也能按偏移写到正确位置。不过顺序乱了会导致 flash 反复擦写同一区域性能变差所以协议层还是应该尽量保证顺序。把断点偏移存 NVS 时要注意NVS 写入次数有限不能每个分片都写一次我一般是每接收 4KB 或每个窗口完成后才落一次盘。5.4 升级验证清单从编译到真机刷机上电一个完整可交付的 BLE OTA 功能验证不是「升级一次成功」就够了。我每次测试会按下面这张表逐项过验证项操作通过标准首次升级从 v1.0 升到 v2.0重启后版本号变为 v2.0降级升级从 v2.0 升到 v1.0允许降级且启动正常断电中断传输到 50% 时直接断电重新上电仍运行旧固件可重新升级断连续传传输中断开蓝牙重连后续传从断点继续最终升级成功校验失败手机端发送篡改后的固件包设备拒绝重启旧固件保持运行电量低保护电量低于阈值时发起升级设备拒绝开始或提示充电循环升级连续升级 20 次期间无变砖、无异常重启最后一列不是走过场。BLE OTA 里最常见的隐性故障就是「前 5 次都成功第 6 次开始重启后卡死」这类问题往往来自 flash 磨损或 ota_data 状态残留只有循环测试才能暴露。我在某个智能锁项目里就是第 9 次升级时翻的车排查了两天才定位到是 ota_data 里的旧校验值没清干净。6. 进阶加密固件、版本回滚与 OTA 失败兜底6.1 固件加密与签名校验堵住升级包被替换的口子BLE 升级包在空气中传输任何人都能抓包如果固件没有签名校验攻击者可以构造一个恶意固件推给设备。ESP32-S3 官方 SDK 提供了一套镜像签名机制固件编译时用私钥签名设备端烧录公钥启动和 OTA 校验时验签。签名校验放在esp_ota_end之前验签失败直接丢弃镜像不切分区。对于不做加密的产品至少要有签名如果做加密固件还要在签名基础上对固件做 AES 加密防止镜像被直接 dump 出来逆向。6.2 版本号比对与回滚升级失败不要让设备变砖新固件能启动不等于新固件没问题。更稳的做法是升级完成后先不切分区重启后新固件自检检查外设初始化、关键任务创建、网络连接等通过后再把自身标记为有效。如果自检失败调用esp_ota_mark_app_invalid下次启动引导程序会自动回退到旧分区。这个机制要求应用层在初始化早期就完成自检和标记标记晚了崩溃发生在标记之前下次启动还是会进坏固件。版本号比对也放进控制流程手机端读设备当前版本低于目标版本才允许升级避免把旧固件传上去把新设备「降级」到有 bug 的版本。6.3 收尾我最早做 BLE OTA 时以为难点在蓝牙后来发现蓝牙只是管道真正的复杂度在状态机、断点续传和失败兜底。后来每次接新项目我都先问三个问题设备有没有第二通道能救砖升级失败能不能自动回退断连后能不能续传这三个问题答不上来的方案我不会让它进量产。如果你准备在自己的 ESP32-S3 项目里加 BLE OTA建议先按第 3 章把最小链路跑通再一项项补校验和断点不要一开始就追求完整协议链路通了再叠加功能排错会容易很多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 16:28:59 · 阅读 1.2k ESP32-S3 BLE OTA升级实战：GATT服务、分区表与断点续传
简介面向ESP32-S3开发者的BLE OTA升级代码包配套博文完整讲解从硬件与软件准备、BLE服务初始化、固件分包传输、数据校验写入到重启生效的无线更新流程精准解决物联网设备远程固件升级中的开发与调试难题。包体非常精简共3个文件主要包含HTML格式的说明文档、inscode工程配置以及gitignore版本管理规则压缩包仅5KB无需冗长下载等待。目前已有109人学习下载适合智能硬件、可穿戴设备等项目中需要掌握低功耗蓝牙无线升级能力的初中级嵌入式开发人员。资源核心价值在于既给出了BLE服务初始化与OTA数据处理的关键代码示例又提供了分块大小调整、错误恢复机制、超时处理及电源管理等部署优化建议配合清晰的流程图和逐行注释能够帮助开发者深入理解底层原理有效规避升级失败风险快速落地稳定可靠的OTA升级功能。1. 为什么 ESP32-S3 还要走 BLE 做 OTA 升级ESP32-S3 BLE OTA 升级这件事第一次听起来像个伪需求——WiFi 快得多为什么非要用蓝牙传固件但真做过设备的都知道大量量产产品根本没有 WiFi也没有网口设备装进密封壳体后只剩一根天线伸出来手机 App 是唯一能和它对话的通道。穿戴手环、传感器节点、某些医疗小设备、工业现场的便携采集器全是这个形态。在这种场景里BLE OTA 不是备选方案而是唯一方案。它解决的问题非常具体手机通过 BLE 连接设备把新固件分包传进去设备收到完整镜像后校验、切换分区、重启完成升级。整个过程不需要拆机、不需要数据线、不需要网络环境。这篇文章就围绕「ESP32-S3 BLE OTA升级[代码]」这个标题把从分区表设计到 GATT 服务实现、再到断点续传和安全校验的完整落地路径拆开讲适合正在做量产固件升级功能的嵌入式开发者也适合第一次接触 BLE 无线升级、想评估方案可行性的硬件工程师。2. 拆解 ESP32-S3 BLE OTA 升级GATT 服务、分区表与协议栈选型2.1 分区表里必须放得下两套固件ota_0、ota_1 与 ota_data 的作用BLE OTA 和 WiFi OTA 在 ESP32-S3 上的底层机制完全一样都是走 esp_ota 接口写 flash区别只在上层数据传输方式。既然是 OTA分区表就不是默认的单 factory 分区而是至少要划分出两个 app 分区和一个 ota_data 分区。两个 app 分区的作用是让设备永远有一个「当前可用固件」兜底正在跑的固件在 app0新收到的固件写到 app1写完校验通过后把启动标记指向 app1重启就进入新固件。如果校验失败或者新固件起不来引导程序还能根据 ota_data 里的信息回退到旧固件。分区表用 ESP32-S3 常见的 CSV 方式配置关键是把 SubType 写成 ota_0 和 ota_1并且给 ota_data 留出独立空间。我一般会这样划分# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, ota_data, data, ota, 0xd000, 0x2000, app0, app, ota_0, 0x10000, 0x400000, app1, app, ota_1, 0x410000, 0x400000,这里有两处值得注意。第一ota_data 的 SubType 是 ota不是 nvs引导程序和 esp_ota 接口靠这个类型识别它第二app0 和 app1 的 Offset 必须按 flash 擦除块对齐上面这个布局里每个 app 分区 4MB如果你的固件实际只有 1MB也不要为了省空间把两个分区贴着放留给后续固件膨胀的余量很关键。Size 一栏如果不填默认按偏移自动推算但显式写出来更稳。从原理上讲这种双分区结构牺牲了一半 flash 容量换来的是升级失败不砖机的保障。对于 BLE OTA 这种传输速度慢、中间容易断连的升级方式双分区几乎是必须的——单分区模式下一旦写入一半断电设备就变砖只能靠串口救量产现场根本没有这个条件。2.2 GATT 服务设计Write 特征收数据控制特征才能做完整状态机BLE 本身不关心你传的是什么它只提供 GATT 服务和特征Characteristic。做 OTA 时我们需要在设备端自定义一个 GATT Service里面至少放两个特征一个用于接收固件分片数据的 Write 特征一个用于传输控制命令的 Control 特征。为什么不能只用一个特征因为固件传输过程不是「把数据写进去」这么简单它需要完整的握手手机端先发「开始升级」命令设备回复「准备就绪」并告知当前版本然后手机开始分包发数据数据发完后设备做校验再回报「校验结果」最后手机发「重启」命令。这些状态切换如果和数据混在同一个特征里每次交互都要解析包头代码会变得很脆弱调试时也分不清是数据问题还是状态问题。我实际工程里用的服务定义是这样的static const ble_gatt_svc_def_t ota_svc_defs[] { { .type BLE_GATT_SVC_TYPE_PRIMARY, .uuid ota_svc_uuid, .characteristics (ble_gatt_chr_def_t[]) { { .uuid ota_ctl_char_uuid, .access_cb ota_ctl_access, .flags BLE_GATT_CHR_F_WRITE | BLE_GATT_CHR_F_NOTIFY, }, { .uuid ota_data_char_uuid, .access_cb ota_data_access, .flags BLE_GATT_CHR_F_WRITE_NO_RSP | BLE_GATT_CHR_F_WRITE, .val_handle ota_data_handle, } } }, { 0 } };Control 特征带 Notify 权限是为了设备能主动给手机发升级进度和结果Data 特征用 WRITE_NO_RSP是为了减少 BLE 协议层的应答开销提升吞吐。这里有一个性能细节如果用普通 WRITE手机每发一包都要等设备返回 ATT Write Response一来一回至少多一个连接间隔的延迟用 WRITE_NO_RSP手机可以连续发包设备端在回调里逐个处理吞吐能提升接近一倍。代价是协议层不保证送达所以应用层必须靠序列号机制补可靠传输这个后面展开。2.3 选 NimBLE 还是 Bluedroid内存、吞吐与开发成本ESP32-S3 的官方 SDK 里默认集成了两套蓝牙协议栈Bluedroid 是传统选择功能全但内存占用大服务发现流程复杂NimBLE 是后来引入的轻量协议栈专为资源受限设备设计API 风格更简洁启动速度也快。做 BLE OTA 我建议直接用 NimBLE。原因有三。第一OTA 场景里设备是被动方不需要复杂的 GATT Client 逻辑NimBLE 完全够用Bluedroid 里大量我们用不到的外设、A2DP 等协议栈代码白白占着 RAM。第二NimBLE 的 GATT 事件模型更直接写特征的数据通过回调一次性送到应用层不需要像 Bluedroid 那样处理多层消息转发。第三NimBLE 支持动态 MTU 协商配合较大的 ATT MTU 能把单包数据量顶上去这对传输效率至关重要。Bluedroid 也能做到但配置项更绕。还有一个实际痛点Bluedroid 在做长时间大数据量写入时偶尔会出现协议栈内部缓冲堆积表现为「连接正常但数据收发越来越慢」这种问题很难查。NimBLE 在这类长传输场景下的稳定性经验值更好。如果你是从零开始的项目别犹豫直接选 NimBLE如果已经有 Bluedroid 的存量代码除非你对现有传输稳定性很有把握否则迁移成本也值得花。3. 用 NimBLE 落地 ESP32-S3 BLE OTA从分区配置到分片写入3.1 最小分区表与 menuconfig 开关BLE 相关配置项怎么开动手写代码之前先确认项目配置里开了 NimBLE 并关掉不需要的蓝牙协议。这一步错了后面所有代码都白写。在项目根目录执行idf.py menuconfig按下面路径设置Component config → Bluetooth → Bluetooth → [x] Enable Bluetooth Component config → Bluetooth → Bluetooth Controller → [x] BLE 5.0 Component config → Bluetooth → NimBLE Options → [x] Enable NimBLE这几个开关是基础。另一个容易被忽略的选项在NimBLE Options → Enable advertising和Enable scanningOTA 场景里设备通常只需要广播和连接不需要扫描别的外设关掉扫描能省一点 RAM。还有一项Max number of BLE connections默认 3做 OTA 时改成 1 就够多连接不会让升级更快反而增加协议栈负担。接着在 CMake 里加上 NimBLE 组件依赖REQUIRES nimble esp_ota esp_partition nvs_flash这一步确保链接器能把 NimBLE 协议栈和 OTA 相关库都打进来。编译时如果报ble_gatts_*找不到符号大多数情况就是这句 REQUIRES 没写全。分区表用上一章那份 CSV在menuconfig → Partition Table → Partition Table里选择Custom partition table CSV并指定文件路径。这里有个常见翻车点改了分区表之后第一次烧录必须用idf.py erase-flash擦掉整片 flash再烧新固件。因为旧分区表里的 ota_data 区域可能残留脏数据引导程序读到非法 ota 信息会启动异常。这不是玄学是分区变更后没擦 flash 导致的真实问题烧录顺序错了排错能排一下午。3.2 注册 GATT 服务与写特征回调分片数据进来自动落盘NimBLE 的服务注册流程是先注册 GATT 回调再添加服务定义最后通过ble_gatts_start()让服务生效。完整初始化代码大致如下static uint8_t ota_svc_uuid[16] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }; static uint16_t ota_data_handle; static int ota_data_access(uint16_t conn_handle, uint16_t attr_handle, struct ble_gatt_access_ctxt *ctxt, void *arg) { if (ctxt-op BLE_GATT_ACCESS_OP_WRITE_CHR) { uint16_t len OS_MBUF_PKTLEN(ctxt-om); if (ota_ctx.state ! OTA_STATE_DATA) { return BLE_ATT_ERR_INVALID_ATTR; } // 从 mbuf 里把数据拷到线性缓冲区 uint8_t *buf malloc(len); if (!buf) return BLE_ATT_ERR_INSUFFICIENT_RES; os_mbuf_copydata(ctxt-om, 0, len, buf); esp_err_t err esp_ota_write(ota_ctx.handle, buf, len); free(buf); if (err ! ESP_OK) { return BLE_ATT_ERR_UNLIKELY; } ota_ctx.offset len; return 0; } return BLE_ATT_ERR_UNSUPPORTED; }这段代码的逻辑是数据特征收到写入时先检查 OTA 状态是不是「正在收数据」不是就直接拒绝——这能挡住没发开始命令就硬写数据的异常手机端然后把 NimBLE 协议栈里的 mbuf 数据拷到线性缓冲区再调用esp_ota_write写入 flash。这里有个必须强调的点os_mbuf_copydata之前ctxt-om指向的数据只在回调期间有效回调返回后协议栈会回收这个 mbuf所以千万不能把指针存下来异步处理。数据拷贝是必须的不是额外开销。回调里ota_ctx是一个全局结构体保存着当前升级会话的状态、写句柄和已写入偏移。用全局变量不是因为优雅而是因为 GATT 回调本身拿不到自定义上下文用全局变量是最直白的做法。生产级代码可以改成按 conn_handle 查表但单连接场景下全局变量完全够用。3.3 固件分片写入 OTA 分区esp_ota_write 与校验切换控制特征的回调负责整个升级状态机。开始升级命令到达时要做三件事读当前运行分区、计算目标分区、调用esp_ota_begin拿到写句柄。伪代码如下static int ota_ctl_access(uint16_t conn_handle, uint16_t attr_handle, struct ble_gatt_access_ctxt *ctxt, void *arg) { if (ctxt-op BLE_GATT_ACCESS_OP_WRITE_CHR) { uint8_t cmd; os_mbuf_copydata(ctxt-om, 0, 1, cmd); switch (cmd) { case OTA_CMD_START: { const esp_partition_t *running esp_ota_get_running_partition(); const esp_partition_t *target esp_ota_get_next_update_partition(running); esp_ota_begin(target, OTA_SIZE_UNKNOWN, ota_ctx.handle); ota_ctx.offset 0; ota_ctx.state OTA_STATE_DATA; break; } case OTA_CMD_FINISH: { esp_ota_end(ota_ctx.handle); esp_ota_set_boot_partition(esp_ota_get_next_update_partition( esp_ota_get_running_partition())); ota_ctx.state OTA_STATE_IDLE; break; } case OTA_CMD_REBOOT: esp_restart(); break; } } return 0; }esp_ota_begin的第一参数是目标分区但第二参数有个细节如果不知道固件大小传OTA_SIZE_UNKNOWN库内部会按整个分区大小做擦除准备如果手机端在开始命令里附带固件字节数就传那个数字能省掉多余擦除时间。BLE OTA 本身已经很慢能省的擦除时间不要浪费。esp_ota_end返回ESP_OK不代表升级完成它只代表镜像写入和校验通过。真正让设备下次启动进入新固件的是esp_ota_set_boot_partition这一步设置 ota_data 里的启动标记。很多第一次做的人漏掉这一句结果升级完重启还是旧固件还以为是写入失败。另外esp_ota_end传入的 handle 用完就失效了后面不要再碰。OTA_CMD_FINISH和OTA_CMD_REBOOT拆成两条命令是刻意的手机端收到 FINISH 的应答后可以先提示用户「升级完成即将重启」让用户有个心理预期而设备端在收到 REBOOT 前也保留着最后反悔的机会。如果校验失败手机端不发 REBOOT设备继续跑旧固件一切如常。4. BLE OTA 避坑实录5 个让我返工的问题4.1 问题一MTU 没协商一次写 512 字节直接被拒现象手机端明明把 MTU 请求到了 512数据特征也声明了 512 字节的最大长度但设备端回调里len永远只有 20 字节发大包直接返回错误。原因NimBLE 的默认 ATT MTU 是 23 字节扣除 ATT 头后有效载荷 20 字节。手机端请求 512 只是「希望」设备端必须在ble_gap_event里响应 MTU 更新事件把实际 MTU 抬上去。这个响应不是自动的。解决在 GAP 事件回调里加上BLE_GAP_EVENT_MTU分支调用ble_att_set_preferred_mtu(512)并返回 0 接受。注意这个值是设备端愿意接受的上限手机端最终取两者较小值。如果设备端只设 256手机再想传 512 也没用。做吞吐优化时这一项排在最前面。4.2 问题二分片序号丢了写入位置错乱导致镜像损坏现象传输途中偶尔断连重连后手机端从断点继续发但设备端已经不知道当前写到哪了恢复后写入的数据错位镜像校验失败。原因最初版本只依赖oto_ctx.offset累计长度但断连后这个全局变量没复位而手机端可能已经从自己记录的断点重新开始发两边的偏移对不上。解决在 BLE 断开连接事件里把 OTA 状态机复位到 IDLE手机端每次重连后先发一条查询命令设备端返回当前已写入偏移手机端从该偏移续传。这个交互不能省它是断点续传成立的前提。只靠「断开就重传整个固件」虽然简单但 BLE OTA 传一半断一次就得重来一小时用户会疯的。4.3 问题三在回调里做 flash 擦写触发看门狗重启现象传输过程中设备无缘无故重启串口日志最后一条是WDT timeout。原因BLE 写特征回调运行在协议栈任务上下文里esp_ota_write内部会做 flash 擦除擦一个 4KB 扇区在 ESP32-S3 上要几十毫秒到上百毫秒。单次回调擦一次没事但连续快速写入时协议栈任务被长时间占用系统任务IDLE 任务里的喂狗得不到调度看门狗就咬人了。解决不能直接把大块数据在回调里写入。常见做法是把回调收到的分片先放进一个环形缓冲区由一个专门的 OTA 写任务负责从缓冲区取数据并调用esp_ota_write同时在该任务里喂狗。缓冲区大小要根据 MTU 和写入速度匹配我常用的配置是 16 个 512 字节槽位。另一个办法是每次写入后主动vTaskDelay(1)让出 CPU但这会拖慢吞吐治标不治本。4.4 问题四升级完成后没设置 ota_data重启进不了新固件现象esp_ota_end返回ESP_OK手机端也收到了成功应答但设备重启后还是跑旧版本反复升级都一样。原因esp_ota_end只做了镜像校验并没有把启动分区切到新固件。引导程序启动时读 ota_data 决定进哪个 app 分区ota_data 里没写新分区信息自然还是进旧固件。解决在esp_ota_end成功之后立刻调用esp_ota_set_boot_partition把目标分区设为下一次启动分区。更稳妥的做法是写完新固件后先不切分区重启后由引导程序或应用层做「新固件自检」确认能正常启动后再通过esp_ota_mark_app_valid_cancel_rollback把这次启动标记为有效。这样如果新固件起不来下次重启还能自动回退。量产固件建议用后者开发调试期用前者更省事。4.5 问题五蓝牙断开后再次连接服务句柄对不上现象第一次连接能正常收发 OTA 数据断开重连后手机端找到的服务特征句柄和之前一样但写入时设备端没有响应。原因NimBLE 在连接断开后如果没有重新注册服务句柄理论上不变但实际工程里如果 GATT 服务注册是在某个初始化函数里做的而该函数又被连接事件触发了多次就会重复注册句柄漂移。解决把ble_gatts_count_cfg和ble_gatts_add_svcs放到系统初始化阶段只执行一次不要在连接事件里调用。另外手机端重连后应该重新执行discover services不要缓存旧句柄。这两个习惯能避免九成以上的重连问题。排查时如果发现服务注册了两次在日志里搜服务 UUID 出现的次数一目了然。5. 传输参数与断点续传把 BLE OTA 调稳的关键设置5.1 MTU 协商把单包从 128 提到 512吞吐差 4 倍BLE 的物理层速率上限在理想条件下约 1Mbps但实际有效吞吐受 MTU、连接间隔、事件长度三重约束。ESP32-S3 支持 BLE 5.0连接间隔可以最小到 7.5ms单次连接事件内可以传多个包。如果你只看默认配置吞吐往往只有十几 KB/s而调好参数后能到 60~100 KB/s差距就在这三项。MTU 协商这一步放在连接刚建立后做手机端发起exchangeMTU请求时设备端在 GAP 事件里响应代码里这样处理case BLE_GAP_EVENT_MTU: // mtu 参数包含在 event-mtu 里 ble_att_set_preferred_mtu(512); return 0;ble_att_set_preferred_mtu设置的只是设备端的偏好值实际生效的 ATT MTU 是双方协商后取较小者。所以手机端如果只请求 256实际 MTU 就是 256。设备端把值设到 512 是为了不成为瓶颈。MTU 提上去后还要同步改两个配置数据特征声明的最大长度要匹配缓冲区大小要匹配。我见过 MTU 协商成功但数据特征最大长度还写着 128 的配置结果数据被协议栈截断回调里收到的永远是 128 字节。连接参数也值得调。NimBLE 里设置连接间隔和从机延迟的常用接口是ble_gap_update_params在连接建立后主动发起更新static void update_conn_params(uint16_t conn_handle) { struct ble_gap_upd_params params { .itvl_min 8, // 10ms单位 1.25ms .itvl_max 8, .latency 0, .supervision_timeout 400, }; ble_gap_update_params(conn_handle, params); }连接间隔 10ms、从机延迟 0意味着每个连接间隔设备都参与通信。把间隔拉长到 30ms 可以省电但 OTA 期间省电没有意义越快传完才是真省电。supervision_timeout 建议不小于 400单位 10ms即 4 秒这个值如果太小手机锁屏导致几个连接间隔没响应连接就被判超时断开。5.2 超时与重传策略GATT 层没有 ACK协议层要自己补BLE GATT 的 WRITE_NO_RSP 不保证数据送达这意味着设备端可能漏包。设计 OTA 协议时最稳妥的方案是给每个分片加一个 16 位序列号放在分片数据的前两个字节。设备端收到后检查序列号是否连续不连续就回 NAK手机端从断点重传。序列号方案落地时有一个细节设备端回复 NAK 本身也可能丢所以不能只做「收到 NAK 才重传」还要加超时机制。手机端每发完一个窗口比如 32 包就停一下等设备端的 ACK 或 NAK超时未收到就整体重发这个窗口。窗口大小和 MTU 有关MTU 512、每包有效载荷 510 字节时32 包一个窗口大约 16KBACK 往返 10ms吞吐和可靠性比较平衡。另一个容易踩的坑是设备端写入 flash 的速度跟不上 BLE 接收速度。esp_ota_write在连续写入时flash 擦写时间会周期性拖慢处理速度。手机端如果无视设备端的接收能力猛发缓冲区满了之后回调会返回错误造成连锁丢包。解法是在控制特征的回调里设备端主动上报「缓冲区剩余空间」手机端据此调整发送节奏。这个字段不复杂但对长时间传输稳定性帮助很大。5.3 断点续传记录已写入长度重连后从断处继续BLE OTA 传一半断连是常态不是异常。设计时就要接受这个现实把断点续传做成默认能力。设备端在每次esp_ota_write成功后更新ota_ctx.offset这个值在 OTA 进行中写入 NVS这样即使设备断电重启也能恢复上次进度。恢复流程是这样手机端重连后先读设备端当前固件版本确认确实需要继续升级再读已写入偏移recorded_offset然后从该偏移的下一个分片开始发。设备端收到「续传」命令后用esp_ota_begin重新打开同一个目标分区并把内部写偏移设置到recorded_offset之后正常接收数据。这里有一个坑esp_ota_begin总是从分区头部开始写不管之前写到哪。要实现从中途接着写不能直接用esp_ota_write的顺序模式需要在开始命令里把断点偏移传给esp_ota_write的写位置。常见的做法是分片数据自带绝对偏移设备端用esp_ota_write_with_offset接口指定写入位置esp_err_t err esp_ota_write_with_offset(ota_ctx.handle, buf, len, ota_ctx.offset);用绝对偏移还有一个好处即使手机端发的分片到达顺序乱了设备端也能按偏移写到正确位置。不过顺序乱了会导致 flash 反复擦写同一区域性能变差所以协议层还是应该尽量保证顺序。把断点偏移存 NVS 时要注意NVS 写入次数有限不能每个分片都写一次我一般是每接收 4KB 或每个窗口完成后才落一次盘。5.4 升级验证清单从编译到真机刷机上电一个完整可交付的 BLE OTA 功能验证不是「升级一次成功」就够了。我每次测试会按下面这张表逐项过验证项操作通过标准首次升级从 v1.0 升到 v2.0重启后版本号变为 v2.0降级升级从 v2.0 升到 v1.0允许降级且启动正常断电中断传输到 50% 时直接断电重新上电仍运行旧固件可重新升级断连续传传输中断开蓝牙重连后续传从断点继续最终升级成功校验失败手机端发送篡改后的固件包设备拒绝重启旧固件保持运行电量低保护电量低于阈值时发起升级设备拒绝开始或提示充电循环升级连续升级 20 次期间无变砖、无异常重启最后一列不是走过场。BLE OTA 里最常见的隐性故障就是「前 5 次都成功第 6 次开始重启后卡死」这类问题往往来自 flash 磨损或 ota_data 状态残留只有循环测试才能暴露。我在某个智能锁项目里就是第 9 次升级时翻的车排查了两天才定位到是 ota_data 里的旧校验值没清干净。6. 进阶加密固件、版本回滚与 OTA 失败兜底6.1 固件加密与签名校验堵住升级包被替换的口子BLE 升级包在空气中传输任何人都能抓包如果固件没有签名校验攻击者可以构造一个恶意固件推给设备。ESP32-S3 官方 SDK 提供了一套镜像签名机制固件编译时用私钥签名设备端烧录公钥启动和 OTA 校验时验签。签名校验放在esp_ota_end之前验签失败直接丢弃镜像不切分区。对于不做加密的产品至少要有签名如果做加密固件还要在签名基础上对固件做 AES 加密防止镜像被直接 dump 出来逆向。6.2 版本号比对与回滚升级失败不要让设备变砖新固件能启动不等于新固件没问题。更稳的做法是升级完成后先不切分区重启后新固件自检检查外设初始化、关键任务创建、网络连接等通过后再把自身标记为有效。如果自检失败调用esp_ota_mark_app_invalid下次启动引导程序会自动回退到旧分区。这个机制要求应用层在初始化早期就完成自检和标记标记晚了崩溃发生在标记之前下次启动还是会进坏固件。版本号比对也放进控制流程手机端读设备当前版本低于目标版本才允许升级避免把旧固件传上去把新设备「降级」到有 bug 的版本。6.3 收尾我最早做 BLE OTA 时以为难点在蓝牙后来发现蓝牙只是管道真正的复杂度在状态机、断点续传和失败兜底。后来每次接新项目我都先问三个问题设备有没有第二通道能救砖升级失败能不能自动回退断连后能不能续传这三个问题答不上来的方案我不会让它进量产。如果你准备在自己的 ESP32-S3 项目里加 BLE OTA建议先按第 3 章把最小链路跑通再一项项补校验和断点不要一开始就追求完整协议链路通了再叠加功能排错会容易很多。希望帮到你。本文还有配套的精品资源点击获取