4、烧录工具与BootROM握手：烧录工具如何检测目标芯片、握手协议（ACK/NACK机制）、通信速率协商
大家好，我是你们的嵌入式调试讲师。今天咱们聊聊烧录过程中最刺激的一环——握手。
你想想看，烧录器刚连上一颗芯片，芯片里可能还是空的，或者跑着一段出厂固件。这时候烧录器怎么知道对面是谁？怎么确认能跟它说话？这就是握手协议要解决的问题。
我当年刚入行时，第一次调烧录流程，芯片死活没反应。折腾了两天，最后发现是握手阶段速率没对上。嗯，从那以后，我对握手协议就特别上心。
4.1 烧录工具如何检测目标芯片
烧录器上电后，第一件事不是发数据，而是「探路」。说白了，就是先确认目标芯片是否存在、是否活着。
常见的检测手段有几种：
- 电平检测：烧录器拉高某个IO，看芯片有没有回应。比如SWD接口的SWCLK/SWDIO，上电后芯片会输出一个特定的IDCODE。
- 时序探测：烧录器发送一串同步序列，比如连续几个0x55或0xAA，看芯片是否按协议回复。
- ID读取：很多芯片的BootROM里固化了一个设备ID寄存器。烧录器发一条读ID指令，芯片回复一串固定字节。对上了，就说明芯片在线。
我个人习惯，在调试阶段会先用逻辑分析仪抓一下芯片的回应波形。如果波形对，但软件读不到，那多半是时序窗口没对准。
4.2 握手协议：ACK/NACK机制
握手协议的核心，就是「你发一句，我回一句」。烧录器发一个命令帧，芯片必须回复ACK（确认）或NACK（否认）。
典型的握手流程是这样的：
- 烧录器发送同步头（比如0x5A 0xA5）
- 芯片收到后，回复ACK（比如0x79）
- 烧录器收到ACK，继续发命令+数据
- 芯片执行完毕，再回复ACK
- 如果芯片发现命令错误或校验失败，回复NACK（比如0x1F）
为什么会用ACK/NACK？说白了，就是为了容错。烧录环境往往有干扰，线缆长一点、电源纹波大一点，都可能丢包。有了ACK/NACK，烧录器就能知道哪一步失败了，可以重试。
我见过一个项目，量产时烧录良率只有92%。排查下来，是握手阶段NACK重试次数设得太少。把重试次数从3次改成5次，良率直接提到99.5%。
4.3 通信速率协商
握手完成后，下一步就是商量「咱们跑多快」。芯片的BootROM通常支持多种速率，比如1MHz、5MHz、10MHz。烧录器需要找到双方都能接受的最高速率。
速率协商的常见做法：
- 降速启动：烧录器先以最低速率（比如100kHz）发送握手命令。确认芯片在线后，再逐步提速。
- 速率探测：烧录器发送一个速率测试帧，芯片回复时带上自己支持的最高速率。
- 固定速率：有些芯片的BootROM只支持一种速率，烧录器必须按这个速率来。比如某些STM32的ISP模式，固定为115200bps。
我记得有一次调试，芯片在低速下握手正常，一提到高速就断连。查了半天，发现是烧录器线缆太长，信号反射严重。换成屏蔽线、缩短到15cm以内，问题就解决了。
4.4 核心握手流程示意图
下面这张图，是我自己画的握手流程。你看一眼，基本就能明白整个交互过程。
4.5 实战中的坑与对策
说了这么多理论，咱们来点实际的。我在调试握手协议时，踩过几个坑，分享给大家：
| 常见问题 | 现象 | 对策 |
|---|---|---|
| 芯片无回应 | 烧录器发同步头后，一直收不到ACK | 检查芯片供电、复位引脚、BOOT模式选择。有些芯片需要拉高BOOT0才能进入烧录模式 |
| ACK时序不对 | 偶尔能握手成功，但大部分失败 | 用示波器看ACK回应的延迟时间。我一般把超时设成芯片典型延迟的3倍 |
| 速率协商失败 | 低速能握手，高速就断 | 缩短线缆、降低速率、加终端电阻。我曾经用100kHz烧录过一整批货，虽然慢但稳 |
| NACK频繁出现 | 每次握手都要重试好几次 | 检查校验和计算是否正确。我见过有人把CRC算法搞反了，导致每帧都NACK |
4.6 小结
握手协议，说白了就是烧录器和芯片之间的「对暗号」。暗号对上了，才能开始干活。对不上，一切免谈。
我个人觉得，调试握手阶段最需要的是耐心。别急着上高速，先确保低速下能稳定通信。速率协商时，留点余量。量产环境复杂，线缆、电源、干扰都可能影响握手成功率。
嗯，这一章就到这里。记住：握手成功是烧录的第一步，也是最重要的一步。
- 检测芯片：电平检测、时序探测、ID读取
- 握手协议：同步头 → ACK/NACK → 命令执行 → 再次ACK
- 速率协商：降速启动、逐步提速、留有余量
- 常见坑：供电不足、线缆过长、时序超时、校验错误
可可精品资料库