1. 拿到芯片先别急着焊：搞懂 RDP、CPUID 和 Bootloader version
上个月我在调一块 STM32F030C8T6 的最小系统板，ST-Link 连上去之后，STM32CubeProgrammer 的设备信息栏里蹦出了三个字段：RDP、CPUID、Bootloader version。说实话，刚入行那会儿我甚至以为 RDP 是远程桌面相关的东西，后来才搞清楚，在 STM32 的世界里，RDP 是 Read-out Protection，也就是读保护，跟远程桌面完全没有关系。这三个参数放在一起，其实就是在告诉你：这颗芯片能不能被外部调试器读走固件、内核是什么版本、出厂引导程序是什么版本。
很多人拿到一颗芯片，第一反应是直接点下载烧录。但如果你忽略了 RDP 级别，很可能遇到“连接成功但读不了 Flash”的怪现象；如果你忽略 CPUID 和 UID，后续做设备唯一标识、防盗版绑定、固件升级校验时又会踩坑。这篇文章我就以 STM32F030C8T6 这颗芯片为例，把这三个参数的原理、读取步骤、常见坑全部讲透。适合正在做 STM32 项目开发、量产烧录、或者二手芯片检测的工程师参考。
1.1 RDP 不是网络协议，而是芯片的“门禁权限”
STM32 的 RDP（Read-out Protection）是芯片内部选项字节（Option Bytes）里的一项配置，用来控制外部调试接口能否读取主 Flash 内容。它有三个级别：Level 0 完全不保护，调试器可以正常读写 Flash；Level 1 禁止通过调试口读取 Flash，但还能通过修改选项字节降级回 Level 0，代价是强制整片擦除；Level 2 则是永久性保护，调试口基本废掉，而且选项字节很难再改回。
这个机制的本质是防止固件被抄板。产品出厂时把 RDP 设成 Level 1 或 Level 2，别人用 J-Link、ST-Link 连接芯片时，读不出 Flash 内容，也就拿不到main函数的反汇编代码。但很多工程师自己给自己挖坑：开发阶段就把 RDP 设成 Level 2，结果下一轮调试时连不上 SWD，只好吹下芯片换一颗，这就是没搞懂门禁逻辑的典型后果。
1.2 CPUID 不等于序列号，更不等于唯一 ID
CPUID 是 ARM Cortex-M 内核里的一个只读寄存器，地址固定在0xE000ED00，它描述的是内核本身的属性。STM32F030C8T6 使用的是 Cortex-M0 内核，所以读出来通常是0x410CC200或者0x410CC201。其中0x41表示实现方是 ARM，0xC表示 ARMv6-M 架构，0xC20表示处理器型号是 Cortex-M0，最后的0是内核修订版本。
但要注意，CPUID 只对“内核算什么型号”负责，它不区分具体是哪一颗芯片。同批次一百颗 STM32F030C8T6，CPUID 读出来几乎完全一样。真正能区分每颗芯片的，是 STM32 出厂烧录的 96 位唯一设备标识符（Unique ID），在 F030 上位于0x1FFFF7AC。很多刚接触的朋友把这两者混为一谈，做设备证书或授权绑定时只用 CPUID，结果所有设备的授权码都一样，那你的授权体系基本就等于没做。
1.3 Bootloader version：出厂固件里藏着协议版本
STM32 在出厂前，会在系统存储器（System Memory）里预烧一段引导加载程序，也就是平时说的 System Bootloader。芯片可以通过 BOOT0 引脚跳转到这段程序运行，然后通过 USART、SPI、I2C 等接口接收上位机命令，完成 Flash 擦除和写入。STM32F030C8T6 的 System Bootloader 一般在地址0x1FFFEC00开始的位置，长度约 3KB 左右。
Bootloader version 就是这段出厂引导程序的版本号。版本号很重要，因为不同版本的引导程序支持的协议命令可能有细微差异。比如你要写一个 PC 端升级工具，通过 UART 连接芯片做 IAP，就必须先发 Get 命令拿回版本号和命令列表，才能确定后续哪些命令可用。版本号格式通常是0x31表示 V3.1，0x32表示 V3.2，高四位是主版本，低四位是次版本。
2. 动手前的准备：工具、接线和第一次连接的常见坑
2.1 工具链选型：ST-Link 和 USB 转 TTL 是标配
我平时最常用的工具就是 ST-Link/V2，不管是原装还是几十块的兼容版都够用。STM32CubeProgrammer 对 ST-Link 的支持最完整，识别芯片型号、读取 RDP、修改选项字节都直接在图形界面里操作。你如果手上只有 J-Link，也能通过 STM32CubeProgrammer 连接，但部分 F0 型号的选项字节操作兼容性不如 ST-Link 顺畅，所以我建议优先用 ST-Link。
除了调试器，还需要一根 USB 转 TTL 串口线。读取 Bootloader version 有两种方式：一种是在 STM32CubeProgrammer 里通过 ST-Link 的 “Bootloader” 功能去识别，另一种是直接进入 System Bootloader 后用串口协议发命令。第二种方式更底层，也能帮你验证整条 UART 链路是否正常，所以我后面会重点讲。串口芯片推荐 CH340 或 CP2102，注意有些板载串口模块的 TX/RX 电平是 5V 的，最好确认一下是否兼容 3.3V，避免给 STM32 的引脚灌入过高电压。
2.2 SWD 接线和 BOOT0 状态别搞反
STM32F030C8T6 是 LQFP48 封装，SWD 调试只需要四根线：SWDIO（PA13）、SWCLK（PA14）、GND、VDD。如果你的板子有独立 3.3V 电源，就共地连接；如果是纯最小系统板，可以用 ST-Link 的 3.3V 输出直接给目标板供电，省得再找电源。我的习惯是调试时同时测量一下 VDD 引脚电压，确认是 3.3V 而不是 5V，因为 ST-Link 的 3.3V 输出能力有限，如果板子外围电路电流大，电压会被拉低，导致连接不稳定。
BOOT0 引脚的状态决定了芯片复位后从哪里启动。STM32F030 只有一个 BOOT0 引脚，拉低时从主 Flash 启动，拉高时从 System Bootloader 启动。所以普通调试烧录时 BOOT0 必须保持低电平；想进 Bootloader 时再把 BOOT0 拉高并复位。曾有朋友把 BOOT0 悬空，结果芯片上电后跑进了系统引导程序，主程序没运行，按键重启都没反应，最后查了半天才发现是 BOOT0 没有接下拉电阻，这个问题在批量做板时特别常见，一定要在原理图上留一个 10kΩ 下拉。
2.3 第一次连不上，先怀疑这三件事
如果你第一次用 ST-Link 连接 STM32F030C8T6 失败，不要急着怀疑芯片坏了，按下面的顺序排查。第一，检查 SWDIO 和 SWCLK 是不是接反了，这两根线接反的故障率极高。第二，检查目标板供电，用万用表量 VDD 对 GND 的电压，不足 3.0V 时调试器经常无法建立稳定连接。第三，检查芯片当前 RDP 状态，如果别人把 RDP 设成了 Level 1 或 Level 2，ST-Link 连接时可能会直接报“读取保护已使能”之类的错误，这个问题我在文章后面会专门讲。
3. 实操第一步：用 STM32CubeProgrammer 读出 RDP、CPUID 和 UID
3.1 连接 ST-Link，先看设备信息面板
打开 STM32CubeProgrammer，右上角选择 ST-Link，接线方式选 SWD，然后在连接模式里我一般选 “Under reset”，也就是复位期间连接，这样能提高成功率。点击 Connect 之后，软件左侧的 “Device information” 面板会显示一长串信息。我在 F030C8T6 上看到的结果大概是这样的：
Device name : STM32F030C8 Device ID : 0x440 Revision ID : 0x1000 Flash size : 64 KB CPU ID : 0x410CC200 Unique ID : XXX XXX XXX XXX Read Protection : 0x00Device ID0x440意味着 STM32CubeProgrammer 把这个芯片识别为 STM32F030C8 系列。CPU ID0x410CC200就是 ARM Cortex-M0 的标准 ID，用来确认内核。Read Protection 显示0x00表示当前是 Level 0，没有读保护。这里有个很容易忽略的细节：Revision ID 会随芯片批次不同而变化，比如0x1000、0x1008、0x2000都有可能出现，它只表示硅片版本，不代表芯片新旧或好坏。
3.2 从 Option Bytes 里确认 RDP 实际状态
设备信息面板里的 Read Protection 显示的是软件解析后的结果，真正存放 RDP 配置的是 Option Bytes，也就是芯片内部一块独立于主 Flash 的配置区。在 STM32CubeProgrammer 左侧点击 “Option Bytes”，就能看到 RDP 一栏。
STM32F030 的 RDP 选项字节典型值是：0xAA对应 Level 0，0xBB对应 Level 1，0xCC对应 Level 2。你不需要手动记住这些十六进制值，软件会直接以下拉框形式显示 Level 0/1/2。改这个下拉框并点击 Apply，软件就会写入新的选项字节。但这里要特别提醒：从 Level 1 回到 Level 0 时，芯片会先执行整片擦除，主 Flash 里的程序会被清空。如果你不想内容被擦掉，千万不要随意点 Apply。第一次接触这个功能的人，十有八九会在这一步误操作，把我的经验总结成一句话就是：改 RDP 之前，先备份整个 Flash。
3.3 读取 96 位唯一 ID，记好地址和字节顺序
需要读取芯片的唯一 ID 时，可以在 STM32CubeProgrammer 的“Memory”视图里直接跳到地址0x1FFFF7AC，然后读取三个 32 位数据。比如：
0x1FFFF7AC : 0x00350026 0x1FFFF7B0 : 0x33333934 0x1FFFF7B4 : 0x34353737这三个地址组合起来就是芯片的 96 位唯一 ID。但要注意，ST 官方文档里说得很清楚，UID 的位序可能因 STM32 系列不同而有差异，有的系列直接按顺序拼接，有的系列需要做字节反转之后才是最终使用的序列号。我在做产品授权生成器的时候，专门写了一段 Boot 程序把 UID 打出来和包装上的标签对照，发现 F030 上要按字内字节反转拼接才和标签一致。所以，如果你想用 UID 做设备唯一标识，第一步不能直接照抄手册示例，而是先读取自己芯片的 UID 出厂标签，确认拼接规则，否则后面每个设备的授权码都可能错位。
4. 实操第二步：进入系统 Bootloader 读取 Bootloader version
4.1 通过 BOOT0 跳转到 System Memory
读取 Bootloader version 最可靠的方法是让芯片进入系统 Bootloader，然后通过 USART 发命令查询。STM32F030C8T6 支持从 USART1 启动引导流程，USART1 的默认引脚是 PA9（TX）和 PA10（RX）。操作步骤是：把 BOOT0 引脚拉高，按住复位或者重新上电，芯片就会从0x1FFFEC00开始执行出厂引导程序。
此时你把 USB 转 TTL 串口的 TX 接到 PA10，RX 接到 PA9，GND 共地。STM32F030 的 System Bootloader 在 USART1 上默认波特率是 115200，数据格式是 8 位数据、偶校验、1 位停止位，也就是很多程序员不熟悉的 8E1。如果你用串口助手默认的 8N1 去发数据，同步永远不会成功，这是我见过最多人踩的坑。
4.2 手动发送同步命令和 Get 命令
System Bootloader 的协议基于主从问答方式。主机上电后先发一个同步字节0x7F，如果引导程序收到并校验通过，就会回应0x79（ACK）。然后主机发送 Get 命令，命令码是0x00，后面紧跟它的反码0xFF，引导程序再次回应0x79，随后返回一个版本字节、支持命令的长度以及支持的命令列表。
我用 Python 和 pyserial 写过一段很简单的测试脚本，贴在这里供你直接使用：
import serial ser = serial.Serial( port='COM3', baudrate=115200, bytesize=8, parity='E', stopbits=1, timeout=1 ) # 发送同步字节 ser.write(b'\x7F') ack = ser.read(1) print('sync ACK:', ack.hex()) # 发送 Get 命令 0x00 和反码 0xFF ser.write(b'\x00\xFF') ack = ser.read(1) print('get ACK:', ack.hex()) # 读取版本字节 ver = ser.read(1)[0] print('bootloader version raw: 0x%02X' % ver) print('parse version: V%d.%d' % ((ver >> 4) & 0x0F, ver & 0x0F)) # 读取支持命令数量 n = ser.read(1)[0] cmds = ser.read(n + 1) print('supported commands:', cmds.hex())在我手头这颗 STM32F030C8T6 上，脚本输出类似：
sync ACK: 0x79 get ACK: 0x79 bootloader version raw: 0x31 parse version: V3.1 supported commands: 0x00 0x01 0x02 ...版本号0x31就代表 V3.1。不同批次的芯片可能读到0x30或更高版本，这是正常现象，因为 ST 会根据生产时间更新引导程序。
4.3 串口命令协议里容易忽略的 CRC 校验
上面这个脚本能跑通，是因为 Get 命令本身比较简单。但在实际 IAP 升级工具里，写 Flash、擦除 Flash、跳转地址这些命令都需要带 CRC 校验。STM32 System Bootloader 使用的 CRC 是标准的 CRC-32，多项式是0x04C11DB7，和 zlib 的算法一致。很多人第一次用 Python 写升级工具，直接拿binascii.crc32或者zlib.crc32去做校验，结果发现 bootloader 一直回 NAK，问题就出在字节序上：bootloader 要求先发送校验值的低字节，然后依次是高字节。
如果你只是查询版本，用上面的短脚本就够了，但如果你打算扩展成完整的上位机下载工具，一定要提前把 CRC 的字节序和命令帧格式按照 AN2606 的说明对齐。否则你会陷入“命令看起来对，但设备就是不执行”的调试泥潭。
5. RDP 级别的升降级、全片擦除和那些容易“锁死”的操作
5.1 三个级别对照表
我整理了一张 RDP 级别的速查表，做量产和返修时可以直接参考：
| RDP 级别 | 调试口读取 Flash | 修改选项字节 | 回到 Level 0 的条件 | 适用场景 |
|---|---|---|---|---|
| Level 0 | 允许 | 允许 | 无需额外条件 | 开发调试阶段 |
| Level 1 | 禁止 | 允许 | 执行整片擦除后可降级 | 产品试产、保护固件 |
| Level 2 | 禁止 | 基本禁止 | 恢复难度极大，视型号而定 | 极少使用 |
这里面最关键的是 Level 1 的“降级必须擦除”。很多刚接触量产的朋友，把 RDP=1 理解成“下次还能随便读”，等到真需要回读固件时才发现必须先擦除，数据早就没了。
5.2 从 Level 1 降回 Level 0 的标准操作
如果你手里的芯片是 Level 1，想恢复成可自由读写状态，第一步是确保你不需要保留当前 Flash 里的内容，因为降级必然擦除。然后在 STM32CubeProgrammer 的 Option Bytes 页面，把 RDP 从 Level 1 改成 Level 0，点击 Apply。软件会弹窗提示“将执行整片擦除”，确认后芯片复位并完成擦除，之后 RDP 就变成 Level 0。
我在实际维修中遇到过一种情况：板子的 RDP 是 Level 1，但用户想保留一小段开机校准数据。这种情况下我会先想办法通过应用层接口读出来，而不是直接降级，因为降级同时把校准参数也擦掉了。如果你在产品设计阶段就知道后期要返修，建议把关键参数放在独立的 EEPROM 或者备份扇区里，别让它们和 RDP 降级绑定在一起。
5.3 为什么我不建议你轻易尝试 Level 2
Level 2 在很多 STM32 型号上意味着彻底锁定调试口，SWD 连不上，选项字节也基本改不动。虽然部分型号还能通过系统 Bootloader 做整片擦除从而间接恢复，但并不是所有型号都支持这条路径，而且具体恢复流程因芯片批次而异。我见过有人为了“彻底保护固件”，把一板子的 STM32F030C8T6 全部设成 Level 2，结果测试发现问题后整批板子都变成了“黑盒”。
对于普通产品，RDP Level 1 已经足够阻挡绝大多数抄板行为。真正的安全不应该只依赖 RDP，还需要配合固件加密、外部加密芯片、启动校验等手段。如果你没做过这些，先把 Level 1 用好，别盲目追求 Level 2。至少我自己的项目里，除非客户明确要求，否则我默认只开到 Level 1，并且会在量产烧录流程里保留“降级授权”的串口命令，方便售后处理。
6. 常见问题排查：快查表与避坑指南
6.1 典型故障现象和处理方法
我把这几年在 STM32F030C8T6 上遇到的高频问题整理成了表格，遇到问题时可以按图索骥：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| ST-Link 连接报“Read Protection is enabled” | 芯片处于 RDP Level 1/2 | 在 STM32CubeProgrammer 中执行整片擦除并降级 |
| UART 发送 0x7F 无 ACK | 串口格式用了 8N1，或 TX/RX 接反 | 改为 8E1，交换 TX/RX |
| CPUID 读出来是 0x410CC201 而不是 0x410CC200 | 内核修订版不同，属正常现象 | 查验 ARM 文档确认修订值 |
| UID 与包装标签不一致 | 字节序未反转 | 按字内字节反转后再拼接 |
| 程序正常运行但 SWD 无法连接 | 代码里禁用了调试端口，或 RDP 被改高 | 进入 Bootloader 恢复选项字节 |
| 上电后程序不运行 | BOOT0 悬空或拉高 | 确认 BOOT0 下拉到 GND |
6.2 量产烧录时的三条经验
批量烧录时，我建议把流程分成两步：第一步先用 ST-Link 批量烧录固件，此时 RDP 保持 Level 0，方便产测程序读取 UID 并写入校准信息；第二步所有测试通过后，再统一把 RDP 设置为 Level 1。这样既保证了固件安全，又不会让产测流程卡在“连不上调试口”。
第二，量产记录一定要保存 UID 和 CPUID。很多工厂烧录程序只记录“烧录成功数量”，不记录芯片唯一标识，后期产品出问题根本没法追溯是哪一批芯片。好的做法是在每片芯片烧录完成后，自动读一次 UID，和烧录时间、烧录工位一起存进数据库，返修时扫一下板子上的二维码就能定位。
第三，不要在生产线上把 RDP 直接升到 Level 2。如果你真想用 Level 2，建议先小批量验证恢复流程。按照我自己的经验，恢复流程的复杂度往往被低估，真到了售后需要读日志时，你会发现完全没有后悔药。用 Level 1 加应用层授权验证，已经能在绝大多数场景达到同样的防护效果。
6.3 别忘了把 RDP 和 Bootloader 版本写进产品文档
最后一个建议可能不起眼，但很实用：把每一批产品的 RDP 级别、Bootloader version、UID 记录方式写进产品规格书或者内部维护文档。RDP 级别决定了返修时要准备哪种烧录器、要不要提前通知客户擦除数据；Bootloader version 决定了远程升级工具要适配哪一套命令；UID 记录方式决定了序列号生成逻辑是否兼容。这三样东西看着只是几个数字，但它们贯穿了芯片从开发、量产到售后的整个生命周期。如果你在项目一开始就养成记录习惯，后面会省下大量返工时间。我个人的体会是，最容易被忽略的往往不是复杂的算法和电路，而是这些一屏就能显示完的基本参数。
