通信协议与固件升级问答总集

📚 总集 📅 2026-09-04
#来源/立芯星球 #类型/问答总集

通信协议与固件升级问答总集

本总集合并了 Bootloader 与 OTA 问答合集固件加密与安全问答合集 两篇问答合集,并纳入目录内其余有内容的通信/升级散帖,按知识相关性重组。原帖均保留未动。

知识地图

章节 覆盖知识点
一、通信基础与选型 总线待机电平、I2C/SPI 仲裁、协议分层归属、多核 IPC
二、CAN 总线与机器人通信 EtherCAT+CAN 分层、OTA 换 CAN 通道
三、蓝牙 / WiFi / 无线模块 BLE 架构门槛、WiFi 延迟定位与优化、协议栈职业前景
四、USB 与串口通信 BC1.2 充电识别、USB 枚举漂移、双机串口协议设计
五、Bootloader 设计 标准库选型、跳转现场、启动信任链、Flash 分区
六、OTA 与升级策略 信任根与标志位、Ymodem、IAP、防回滚
七、加密签名与安全 加密方案、HSM/安全芯片、防超额生产、密钥存放

一、通信基础与选型

1. I2C/SPI/UART/SD 总线的待机电平

I2C 的 SCL/SDA 因上拉电阻待机皆为高电平;SPI 的 CLK 取决于 CPOL,CS 默认高、MOSI 保持最后一个 bit;UART 的 TX/RX 默认高;SD/SDIO 的 CLK 默认低(省功耗)、CMD 与 DATA 默认高。熟悉空闲状态,量波形查问题时才知道正常长什么样。

今天我们聊一下通信协议中大家容易忽略的点,I2C、SPI、UART、SD(Jason)

2. I2C 释放总线与数据位"1"的区分

从机靠时序区分:发送数据位时主机持续输出时钟、逐位收发;发完完整字节后主机停止发时钟、释放 SDA 并等待从机应答,此时从机才可能拉低总线。控制权归属由"谁在驱动时钟"决定。

老师,I2C通信的时候在发送完一个字节的数据后,需要把SDA置1(Jack)

3. 两个 SPI 主机共享一个从机:必须软仲裁

不能靠两边读 GPIO 电平来抢总线(会同时误判),需要两个主机之间建立一条 UART/CAN 软总线,协商当前谁持有 SPI 使用权。

老师,两个SPI主机如何和一个从机通信,软件方面有什么手段(Jack)

4. Ymodem/Modbus/PID 属于中间件,不进 BSP

BSP 只负责把串口收到的连续数据可靠组包放入缓冲区并通知上层;具体用什么协议解析(Ymodem、Modbus 或自定义)由 APP 调用中间件完成。串口协议无法穷尽,写死在 BSP 里必然失控。

问:和硬件强相关的通讯协议或者算法,比如ymodem协议、modbus协议(Jack)

5. 空闲中断收不定长数据断包怎么办

空闲中断可能被字节间空隙提前触发导致半包;正解是自定义协议、用包长度字段判断一帧是否完整,而不是依赖空闲超时。

需要自定义协议,通过包长度来确(不破不立 问,Jack 答)

6. 通信设备的主控芯片不是 MCU

射频单元、基站主控等高速通信设备用的是 FPGA 和 ASIC 专用射频处理前端芯片,处理速度以 G 为单位,MCU 只能做周边管理。

问个问题,通信设备里边的主控芯片不是mcu吧?比如说射频单元,基站主控单元啥(Jack)

7. 多核芯片跨核 IPC 偶发卡死:中断风暴

涂鸦 T5 双核案例:CP1 调音量经 IPC 同步 CP0 时偶发卡死。对策:CP1 本地先缓存、每 50–200ms 发送终值滤波;CP0 未回 ack 不许发新请求;中断里禁止硬件操作并实测中断耗时;全程插桩观察。

多核协作问题: 使用涂鸦T5芯(Jack)

8. 计组与计网是通信的底层地基

嵌入式的一切应用基础都在计算机组成原理和计算机网络上,属于"重要不紧急",要长期补。

需要,你的一切未来应用的基础都(??? 问,Jack 答)


二、CAN 总线与机器人通信

1. 机器人整机通信:EtherCAT + CAN 分层组合

整机通信收敛于分层网络而非单协议:运动控制层(0.25–1ms 周期,要求确定性>同步精度>抖动)用 EtherCAT,靠分布式时钟 DC 与 On-the-Fly 处理保证多轴同步;机身外设层(5–100ms,要求鲁棒性>成本>可维护性)用 CAN/CANopen 承载 BMS、IMU、IO、传感。单协议覆盖两层必然在性能或成本上折中。

— 机器人通信EtherCAT与CAN(刘子奇)

2. OTA 升级通道换成 CAN 怎么入手

先学会 OTA 本身,再把固件来源从串口换成 CAN 驱动即可;可参考 Ymodem 协议与 CAN 驱动写法。CAN 侧的负载率等行业约束另见 汽车电子问答总集

这个你可以先学习OTA,然后O(BasTard)

CAN 总线负载率、Bus-Off 等车载实践问题集中在 汽车电子问答总集 第二章。


三、蓝牙 / WiFi / 无线模块

1. 为什么没有好的零基础 BLE 教程

BLE 协议栈被迫做成通用平台架构:Nordic SDK 连点灯都是注册器模式、要跨四五个文件,还有 SoftDevice Observer 观察者模式、事件驱动、启动挂载 handler、策略模式。没学过架构三年摸不到边;学会架构则一劳永逸。

市面上为什么没有好的零基础BL(Jack)

2. USB 协议栈 vs 蓝牙协议栈的职业前景

两者都是细分领域、都有天花板(纯技术专家约 3–5w 月薪)。协议栈要熟悉,但赚大钱要围绕市场认可的产品;秋招以"熟悉"为宜,面试官未必深究。

老师,usb协议栈与蓝牙协议栈的职业发展前景对比,usb差很多(Jack)

3. WiFi ping 每 20s 周期性高延迟:逆向定位参数

Android wifi 框架周期扫描导致 500ms+ 延迟。思路:周期现象必有定死的参数——直接 grep -r "20000" frameworks/base/core/res/res/values,在 config.xml 中命中 config_wifi_associated_short_scan_interval,改参数验证后沿调用链补全逻辑梳理。

问题模型(wifi驱动ping(🌶)

4. WiFi 延迟速率优化:从框架参数到驱动速率算法

改扫描间隔后平均延迟仍 50–200ms。继续分层:/proc/net/.../rx_signal 发现 RSSI -45 很好却选了最低速率 CCK_1M,指向速率自适应 RA 与抗干扰 DOM 算法;在 HAL 层 RateMask 剔除 CCK_1M 后速率大幅提升。无效手段也记录:关节能模式影响不大、信道锁 HT20 无效。

问题模型:wifi延迟速率优化出现各类优化方法(🌶)

5. WiFi 驱动 ping 延迟无规律抖动:排查清单

优先级排序:① adb 双 console 查 top/ps 高占用进程、清 logcat 验证日志轮询影响;② 换原厂基线驱动 KO 对比;③ dmesg 过滤 usb/irq/tx timeout/suspend 关键字;④ 关 wifi 休眠策略与驱动省电参数;⑤ 对标同平台官方案例、微调队列长度与 USB 带宽。

问题模型(wifi驱动ping(🌶)


四、USB 与串口通信

1. BC1.2 充电识别规范全景

USB2.0 限流(挂起 2.5mA/未枚举 100mA/配置后 500mA)满足不了充电,BC1.2 补充端口分类:SDP(电脑口,D+/D- 下拉,500mA)、DCP(充电器,D+/D- 短接,1.5A+,无数据)、CDP(数据+大电流)。识别四步由充电 IC 硬件完成:VBUS 检测 → DCD(可选 900ms)→ 首检分 SDP/充电类 → 二检分 CDP/DCP;异常时抓 D+/D- 波形定位。快充分两派:高压路线(QC/PE)与低压大电流(VOOC,需定制线材,注意线损压降);演进终点是 Type-C PD(CC 引脚数字协商,至 240W)。注意 Type-C 主机用 CC 上拉,与 A 口 D+/D- 下拉勿混。

— USB BC1.2充电规范解析(Jason)

2. USB 多设备枚举号漂移:根因常在供电

多 USB 设备(立体相机+深度相机+外设)随上电顺序枚举号漂移、偶发不识别:先排除软件(单设备正常),再对比不同上电顺序与总线电流,外接独立供电后恢复稳定——根因是总线供电满足不了多设备启动峰值电流。lsusb 记录枚举状态是基本手段。

— 问题模型(防跌落立体视觉相机掉(🌶)

3. MCU 与 RK3588 之间的双机通信协议设计

物理层用 USB 虚拟串口时传输本身稳定,难点在协议层:帧格式定界、校验、双边协议版本匹配(两边往往是两个团队)、是否重发;追求吞吐可用滑动窗口多次发送一次应答。这块写进简历很稳,面试常问。

老师我目前是在一家公司做四足机器狗 实习一个月了 目前还是在搭平台的阶段(Jack)


五、Bootloader 设计

1. Bootloader 为什么用标准库而不用 HAL

Bootloader 是整个项目基本不动的部分,要做外部 Flash 拷贝等精细操作,对体积和效率敏感;HAL 冗余大。Bootloader 越小,留给 APP 的空间越大。

为什么写Bootloader需要使用标准库(Jack)

2. 跳转 APP 前后的现场处理

Bootloader 里跑了 FreeRTOS 时,跳转前必须关 SysTick、关中断并清除外设/中断标志;进 APP 后先反向初始化(外设、时钟),再重新初始化、开中断。目的:防止跳转过程中产生中断导致卡死。

Bootloader跳转APP时需要注意什么(Jack)
老师 我问一下Bootloader的编写为何要关闭RTC和禁用中断(Jack)

3. Bootloader 常见翻车点汇总

三个高频问题:① CubeMX 配时钟 HAL_RCC_OscConfig 卡死——检测标志前缺延时,误入空 Error_Handler 死循环;② 跳 APP 卡死——未修改 SCB->VTOR 中断向量表偏移到 APP 偏移量;③ 带 FreeRTOS 的 APP 跳转后一直跑在 tim2 中断——Bootloader 用的外设和中断标志未清除(其 systick 也要关)。

BootLoader 程序问题(Jack)

4. 上电启动流程与信任链的根

上电后 bootrom 按 BOOT0/BOOT1 选择从 RAM 或主 Flash 0x08000000 启动;若该处是 Bootloader 则先跑它再跳 APP。信任链的根在硬件:启动地址由 bootrom 出厂写死、无法修改,第一条指令永远从 0x08000000 运行。

老师,上电的时候,boot引脚选择 user flash启动(Jack)
老师,再请教一个问题。bootloader启动app会对app进行验签(Jack)

5. 跳转后 SRAM 不会被永久浪费

APP 启动文件会把 MSP 重指到 SRAM 最高地址,覆盖 Bootloader 的栈,脏数据被启动流程覆写,不存在"永久弃用"的 SRAM。

老师,在BootLoader跳转函数中会设置app的栈顶指针(Jack)

6. F407 内部 Flash OTA 分区规划

F407 只能按 Sector 擦除,配置区优先用最小 16KB 且 A/B 互为备份;升级 flag 频繁变化,放 64KB 大扇区会擦得很久,同样按 16KB 处理(甚至与 config 共用一套 A/B);校验信息/固件头/CRC 单独 16KB 即可。APP/新固件/回滚区各 128KB。

Jack哥我有一个问题,我这边有一个项目需要用到STM32F407ZET6或者是ST(Jack)

7. 多板系统的升级职责划分

一主两扩、串口互联:主板升级自己的固件放主板 Boot;给扩展板升级优先放主板 APP。Boot 越小越稳定、越简单越可靠,不要把扩展逻辑塞进 Boot。

老师,我想请问一个场景,现在有三块板子,一块主板,两块扩展板(Jack)

8. AI 写的 Bootloader 为什么不能直接量产

AI 一遍生成可用不代表可交付:量产产品一半以上代码是冗余与 Corner case 处理,只有实际测试才能暴露。AI 生成后仍要全面分析漏洞,这一步逃不掉(验证方法另见 AI工程化问答总集)。

老师,今天让ai写了一个bootloader程序,一遍生成可以使用(Jack)


六、OTA 与升级策略

1. 更新标志位必须由 Bootloader 掌握

从安全角度看,信任锚/信任根由 Bootloader 掌握,App 本身是被验证对象。若 App 能改 Flash 更新标志,恶意程序就能打断信任链。正确做法:下载完成后由 Bootloader 确认固件完整可信,再由它写标志;App 只能标记"已下载完",不等于"可启动"。

OTA,一定要bootloader负责刷写flash更新标志位(盛夏的时光 问,Jack 答)

2. Ymodem 起始帧的文件大小从哪来

加密工具加密时读出文件大小,写到起始帧的固定字节位置;解密端按固定偏移读取,不依赖文件名长度。

Q:老师 这里我有个疑惑,这里是出自OTA升级专题(Jack)

3. IAP:不停机在应用编程

IAP 允许设备主程序不停止运行,通过高速通信协议对 Flash 编程更新;ST 有官方 IAP 手册(基于 STM32Cube 以太网 IAP)可作参考实现。

这本手册主要介绍了STM32Cube 固件通过以太网实现 :在应用中编程:(立芯嵌入式)

4. OTA 要防"旧固件攻击"(回滚)

除了验签,升级机制还要考虑版本防回滚:攻击者可能刷入有漏洞的旧版本固件进行攻击。

嵌入式OTA其中一个问题,别人可能刷入旧固件攻击你(Jack)


七、加密签名与安全

1. 行业内单片机加密怎么做

固件加解密即课程方案(密文存储+解密执行);通信加密更注重防重放与中间人。行业里也有 HSM 芯片方案:明文交给 HSM 加密后回传。

行业内单片机加密是怎么做的:(Jack)

2. 为什么还要上硬件加密芯片

软件加密无法彻底杜绝中间人攻击;硬件加密同样不能彻底杜绝,但破解难度大得多——为每个产品定制一批芯片并刻入特定密钥。防抄板硬件方案流行,软件加密之外要扩展到硬件。

为什么要用硬件加密芯片? 以(Jack)

3. 一套典型 STM32 固件加密方案

STM32 极易被读出固件,思路是"读出来也没用":APP 密文存储;下载时 Bootloader 用密钥混合芯片 ID+产品序列号+随机数生成每颗芯片唯一的密钥(密钥存云端);Bootloader 解密 B 分区时按芯片 ID 混合出密钥再解密;OTA 时服务器按序列号找到对应密钥下发加密固件。

stm32固件加密的一些问题(Jack)

4. AES 加密防客户不防工厂:防超额生产三方案

生产阶段工厂拿到 Bootloader+App 完整版和密钥逻辑,AES 防不了工厂;对客户可防篡改反编译。要防第三方贴牌厂超额生产:① 自研在线下载工具,按芯片 UUID 作盐现场生成固件并上传云端跟踪;② 每台设备证书/密钥对写入 OTP,Bootloader 启动验签;③ Bootloader 交一家供应商做混淆、防篡改、反调试,整装交给另一家。

老师,对于Bootloader中仅仅使用AES解密APP中的固件(Jack)

5. 密钥存片上 Flash 的真实风险

即便设置读保护 level 1,片上 Flash 密钥仍可能被读出。极高价设备(如蔡司飞秒机器)不会用普通 MCU 存固件,而是用安全版特供芯片,同时防超额生产。

关于固件加密的相关提问: 提(Lili_iliLX 问,Jack 答)

6. 生产环境的加密发布流程

CMake 构建后自动调用 Python 脚本做加密打包,无需人工逐个处理。

如果是在实际生产当中是自己进行文件加密再发(Jack)

车规 MCU 的 eFuse/OTP 密钥与 XIP 硬件解密见 汽车电子问答总集 第六章。


补遗:散帖收录

Bootloader 跳转前后时钟问题

跳转前后的时钟配置时序图解(图答帖),与本总集第五章"Bootloader 设计"的跳转三篇(跳转 APP / 关 RTC 中断 / 跳转前后时钟)互为补充,配图见溯源层。

Bootloader跳转前后时(Jack)

电赛 BLE 快速上手路径

备战电赛选了 STM32WBA55、BLE 零基础:看 ST 官方 WB 系列 BLE 培训视频够不够?——够了,遇到问题到星球问。保留作学习路径参考:官方培训视频是可以依赖的起点

够了,有问题可以来这问(Jack 答)

来源笔记