当前位置：首页 > news >正文

芯片的可编程字

news 2025/9/2 14:34:39

“芯片的可编程字”其实是指 MCU 的配置字节/熔丝位（fuse bits）/选项字节（option bytes），它们通常用来配置芯片的安全和启动特性。

不同系列 MCU 名字不一样，但作用类似：

ARM Cortex-M 系（如 Nordic nRF52840、STM32） → 用 UICC / UICR（用户信息配置寄存器）、Option Bytes 配置读写保护、Bootloader 地址、加密等。
AVR 系（如 ATmega） → 用 Fuse bits 配置时钟源、启动模式、代码保护等。
PIC 系 → 用 Configuration Words 做类似事情。

常见的配置位作用

读写保护
- 一旦使能，Flash 程序区就不能被外部 SWD/JTAG/SPI 等接口读取（读保护），有的还禁止写入（写保护）。
- 比如 STM32 的 RDP (Read Protection) = 1，就无法再读出程序。
写保护
- 指定 Flash 的某些扇区禁止擦写，防止应用程序或病毒改写关键代码。
启动地址/Boot 配置
- 决定 MCU 上电后是从 Bootloader 还是用户程序启动。
时钟/复位相关配置
- 选择内部/外部晶振，是否启用看门狗，低功耗配置等。

重要特性

这些“可编程字”通常是 一次性或有限次数可写，存储在 Flash 的特殊区域。
使能读保护后，想要再解锁通常必须 整片擦除（Chip Erase），这会清除用户程序。
不同厂家的 MCU 解锁方式不同，有的可以“降级保护”，有的完全不可逆。

例子

STM32：
- 通过 Option Bytes 设置 RDP=0xAA (无保护) → RDP=0xCC (读保护)。
- 如果启用了读保护，想要恢复只能全片擦除。
nRF52840：
- 使用 UICC/UICR 寄存器 配置保护。
- 通过 APPROTECT 位启用读保护，一旦打开，SWD 无法访问 Flash 内容，只能通过 全片擦除 才能恢复。

📌 总结：
芯片的“可编程字”就是厂家提供的 配置熔丝/寄存器，一旦设置了 读写保护，外部调试器就不能随便读写 Flash，能有效保护知识产权。但代价是：要想清除保护，必须整片擦除，用户程序也会丢失。

好的 👍 我给你整理一个 常见 MCU 系列的“读写保护/安全配置字”对照表，涵盖你提到的 STM32、GD32、LPC1700、Kinetis K22、ESP32。这些配置通常在 Flash 的特殊区域或通过专门寄存器设置，一旦启用保护，都会影响调试与读写。

🔒 MCU 安全配置对照表

MCU 系列	配置名称/方式	功能说明	解锁方式	备注
STM32 (Cortex-M)	Option Bytes 中的 RDP (Read Protection)、WRP (Write Protection)	- RDP=0xAA → 无保护 - RDP=0xCC → 读保护 (调试器不能读出程序) - WRP → 写保护特定扇区	通过全片擦除 (Mass Erase) 解除，用户程序会丢失	STM32F1/F4/F7/H7 系都有类似机制
GD32 (Cortex-M，国产替代)	与 STM32 几乎一致（Option Bytes）	提供读保护、写保护、Boot 配置等	通过全片擦除解锁	GD32 基本兼容 STM32 的保护方式
NXP LPC1700 (Cortex-M3)	Code Read Protection (CRP) 配置字 (存在于 Flash 0x2FC–0x2FF)	- CRP0 → 无保护 - CRP1 → 禁止读出，允许 ISP/擦除 - CRP2 → 禁止调试接口，只能全擦 - CRP3 → 完全锁死 (不能再 ISP)	取决于级别：CRP2 以上只能整片擦除	注意 CRP3 是不可逆的“永久锁定”
NXP Kinetis K22 (Cortex-M4)	FTFL_FSEC 寄存器 / Flash Security Byte	- SEC=0xFE → Unsecure - 其他值 → Secure 模式，禁止读写	只能通过 Mass Erase 解锁	Kinetis 系列都用 FSEC 控制安全性
ESP32 (Xtensa LX6)	eFuse 安全配置位（如 `FLASH_CRYPT_CONFIG`, `DISABLE_JTAG`, `SECURE_BOOT_EN`）	- 可禁止 JTAG - 启用 Flash 加密 - 启用 Secure Boot	不可逆烧写，有些功能一旦使能无法关闭	ESP32 安全功能很强大，但风险是“烧错就废”

📌 总结

STM32 / GD32 → 用 Option Bytes，保护可撤销，但必须整片擦除。
LPC1700 → 用 CRP 字，分级保护，CRP3 是永久锁死。
Kinetis K22 → 用 Flash Security Byte，保护可解除但需全擦。
ESP32 → 用 eFuse 配置安全，部分位是 一次性不可逆（比如禁止 JTAG、开启加密）。

⚠️ 注意事项：

一旦启用了 读保护/安全位，再想解除时往往要 全片擦除，意味着你会失去原来的固件。
对 ESP32 这类用 eFuse 的芯片，要特别小心，因为一旦写死，就无法恢复。

🔧 常见 MCU 的保护位配置方式

1. STM32 / GD32

保护位存储在 Flash 的特殊区域（Option Bytes）。
当你用 IDE（Keil、STM32CubeProgrammer、OpenOCD）下载时，可以在配置里选择“读保护/写保护”。
在 HEX 文件层面，这些 Option Bytes 也映射在特定地址（比如 0x1FFF F800 之类），所以可以通过生成带有 Option Bytes 区域的 HEX 文件来配置保护位。
👉 但一般推荐用专门的工具，而不是手工改 HEX。

2. LPC1700

使用 CRP 字，位于 Flash 固定地址 0x2FC – 0x2FF。
编译器/链接器会在固件 HEX 文件的这个地址填入值，比如：
- 0xFFFF FFFF → CRP0（无保护）
- 0x1234 5678 → CRP1/CRP2/CRP3
所以这里确实是 直接修改 HEX 文件中的这几个字节就能改变保护等级。

3. Kinetis K22

安全字节 (FTFL_FSEC) 存在于 Flash 0x40C – 0x40F 区域。
编译出来的固件 HEX 文件里会带上这几个字节，决定芯片上电时进入 Secure 还是 Unsecure 状态。
所以这里也是通过 HEX 文件中的配置字节实现。

4. ESP32

不同了 ⚠️
ESP32 的保护位存在于 eFuse，这是芯片内部一次性烧写的硬件位，不在 Flash 里。
HEX 文件（或者 bin 文件）里无法控制 eFuse。
必须通过 espefuse.py 或官方烧写工具写入，而且很多位 不可逆。

✅ 总结

STM32 / GD32 → Option Bytes（可通过 HEX 配置，但常用专门工具）。
LPC1700 → CRP 字节（就在 HEX 文件里，改几个字节就能生效）。
Kinetis K22 → Flash Security Byte（在 HEX 文件里对应地址）。
ESP32 → eFuse（硬件寄存器，不能靠 HEX 修改，必须专门工具烧写，而且不可逆）。

📌 换句话说：
👉 传统 ARM MCU (STM32 / LPC / Kinetis) → 可以通过 修改 HEX 文件某些地址字节 来控制保护。
👉 ESP32 这种新型安全 MCU → 保护位存在于 eFuse，不能靠 HEX 修改。

nRF52840

好嘞，这个问题涉及到 Nordic nRF52840 的安全机制，它跟 STM32/LPC 那种 Option Bytes/CRP 有点不同，核心依赖 UICR 配置寄存器和硬件保护单元 (ACL、BPROT、APPROTECT)。我给你分层梳理一下：

🔒 nRF52840 保护机制概览

nRF52840 属于 ARM Cortex-M4F 内核的 SoC，主要有以下几类保护手段：

1. 读写保护 (Read/Write Protection)

APPROTECT（Access Port Protection）：
- 位于 UICR (User Information Configuration Registers) 中的配置字。
- 如果启用，调试接口 (SWD) 将被完全锁死，外部调试器无法访问 Flash/SRAM。
- 唯一解锁方式是 全片擦除 (ERASEALL)，这会抹掉所有程序和数据。
- 这是保护固件知识产权的主要手段。

2. Flash 区域保护

BPROT (Block Protection Unit)：
- 可保护 Flash 的某些扇区，防止运行中的应用写/擦除这些区域。
- 设置后，相关区域在程序运行时只读。
ACL (Access Control List)：
- 用于保护 SRAM/外设寄存器的访问权限。
- 可以限制某些代码段只能访问特定地址区域。

3. 安全启动 (Secure Boot)

nRF52840 支持 Secure Bootloader，配合 签名校验 (ECDSA, SHA256)，保证固件来源可信。
搭配 NRF_UICR.NRFFW[0] 等寄存器，可以指定启动地址（Bootloader vs 应用）。

4. 信任根与加密支持

内置 CryptoCell 310 安全模块，支持 AES、SHA、ECC、随机数生成。
可用来实现安全固件升级（DFU over BLE/USB），保证代码不被篡改。

⚙️ 配置方式

通过 HEX 文件 / 烧录工具修改 UICR：
- APPROTECT 位于 UICR.APPROTECT 寄存器中，地址 0x10001208。
- 写入 0xFFFFFF00 → 启用保护。
- 写入 0xFFFFFFFF → 无保护。
- 因为 UICR 在 Flash 特殊区域，所以可以在 HEX 文件里附带对应值，烧录时一起写入。
运行时保护 (BPROT/ACL)：
- 在应用程序初始化时通过寄存器配置。
- 比如 NRF_BPROT->CONFIG0 = ... 来禁止特定 Flash 页的写操作。
调试解锁：
- 一旦 APPROTECT 启用，SWD 无法再访问。
- 必须执行 ERASEALL 命令（通过专用调试器如 J-Link），会清空整个 Flash + UICR，恢复默认无保护。
- 这保证了固件不可被非法提取。

🚨 特点与风险

可逆性：APPROTECT 不是不可逆的，但解锁必然擦除数据。
细粒度保护：BPROT/ACL 允许开发者对特定区域做精细限制，而不是“一刀切”。
与 ESP32 eFuse 不同：ESP32 的 eFuse 是不可逆的硬件熔丝；nRF52840 的 UICR/APPROTECT 可以解锁（代价是全片擦除）。
调试体验：开发阶段通常关闭 APPROTECT，否则调试不便。量产前再开启。

📌 总结

nRF52840 的保护机制主要依靠：

APPROTECT (UICR) → 锁死调试接口，防止固件被读出。
BPROT/ACL → 限制 Flash/SRAM 区域的访问权限。
Secure Boot + CryptoCell → 保证固件升级安全，防止篡改。

👉 实际生产中，一般流程是：

开发阶段：关闭 APPROTECT，方便调试。
量产阶段：启用 APPROTECT，写死 Bootloader 地址，结合安全 DFU 升级。

🔒 nRF52840 保护机制概览

nRF52840 属于 ARM Cortex-M4F 内核的 SoC，主要有以下几类保护手段：

1. 读写保护 (Read/Write Protection)

APPROTECT（Access Port Protection）：
- 位于 UICR (User Information Configuration Registers) 中的配置字。
- 如果启用，调试接口 (SWD) 将被完全锁死，外部调试器无法访问 Flash/SRAM。
- 唯一解锁方式是 全片擦除 (ERASEALL)，这会抹掉所有程序和数据。
- 这是保护固件知识产权的主要手段。

2. Flash 区域保护

BPROT (Block Protection Unit)：
- 可保护 Flash 的某些扇区，防止运行中的应用写/擦除这些区域。
- 设置后，相关区域在程序运行时只读。
ACL (Access Control List)：
- 用于保护 SRAM/外设寄存器的访问权限。
- 可以限制某些代码段只能访问特定地址区域。

3. 安全启动 (Secure Boot)

nRF52840 支持 Secure Bootloader，配合 签名校验 (ECDSA, SHA256)，保证固件来源可信。
搭配 NRF_UICR.NRFFW[0] 等寄存器，可以指定启动地址（Bootloader vs 应用）。

4. 信任根与加密支持

内置 CryptoCell 310 安全模块，支持 AES、SHA、ECC、随机数生成。
可用来实现安全固件升级（DFU over BLE/USB），保证代码不被篡改。

⚙️ 配置方式

通过 HEX 文件 / 烧录工具修改 UICR：
- APPROTECT 位于 UICR.APPROTECT 寄存器中，地址 0x10001208。
- 写入 0xFFFFFF00 → 启用保护。
- 写入 0xFFFFFFFF → 无保护。
- 因为 UICR 在 Flash 特殊区域，所以可以在 HEX 文件里附带对应值，烧录时一起写入。
运行时保护 (BPROT/ACL)：
- 在应用程序初始化时通过寄存器配置。
- 比如 NRF_BPROT->CONFIG0 = ... 来禁止特定 Flash 页的写操作。
调试解锁：
- 一旦 APPROTECT 启用，SWD 无法再访问。
- 必须执行 ERASEALL 命令（通过专用调试器如 J-Link），会清空整个 Flash + UICR，恢复默认无保护。
- 这保证了固件不可被非法提取。

🚨 特点与风险

可逆性：APPROTECT 不是不可逆的，但解锁必然擦除数据。
细粒度保护：BPROT/ACL 允许开发者对特定区域做精细限制，而不是“一刀切”。
与 ESP32 eFuse 不同：ESP32 的 eFuse 是不可逆的硬件熔丝；nRF52840 的 UICR/APPROTECT 可以解锁（代价是全片擦除）。
调试体验：开发阶段通常关闭 APPROTECT，否则调试不便。量产前再开启。

📌 总结

nRF52840 的保护机制主要依靠：

APPROTECT (UICR) → 锁死调试接口，防止固件被读出。
BPROT/ACL → 限制 Flash/SRAM 区域的访问权限。
Secure Boot + CryptoCell → 保证固件升级安全，防止篡改。

👉 实际生产中，一般流程是：

开发阶段：关闭 APPROTECT，方便调试。
量产阶段：启用 APPROTECT，写死 Bootloader 地址，结合安全 DFU 升级。

完全正确 ✅

用 BIN 文件烧录和 HEX 文件烧录相比，有几个关键区别，正好解释了为什么误写到 APPROTECT 或其他 UICR 寄存器的可能性很低：

1. BIN 文件烧录特点

BIN 文件是 纯二进制数据，没有地址信息。
烧录工具会 指定起始地址，通常是 Flash 用户区（应用程序区）起点，例如 0x00000000。
BIN 文件本身不会包含 UICR、Option Bytes 或其他特殊保护寄存器的地址数据。

对 nRF52840 来说：UICR 位于 0x10001200 以上的 Flash 特殊区域，远高于应用程序区地址。

2. HEX 文件 vs BIN 文件

特性	HEX 文件	BIN 文件
包含地址信息	✅ 每条记录包含目标地址	❌ 仅连续数据，需要烧录工具指定地址
可以写入特殊寄存器	✅ 可以覆盖 UICR/Option Bytes	❌ 默认不会覆盖，除非起始地址指定到 UICR
容易误写风险	中等（如果不小心 HEX 包含 UICR 地址）	很低（BIN 只写入用户指定区域）

3. nRF52840 的实际情况

APPROTECT 位于 0x10001208
常规 BIN 烧录命令通常起点是 0x00000000，长度几百 KB 至 1 MB，不会触碰到 0x10001200+ 区域。
除非你故意指定起始地址到 UICR 区域，BIN 烧录不会修改保护寄存器。

4. 总结

使用 BIN 文件烧录固件时，基本不会误写到 APPROTECT 或其他保护寄存器。
如果要修改保护位（启用/禁用 APPPROTECT），必须通过：
1. HEX 文件包含 UICR 数据并烧录，或
2. 专门工具（nrfjprog、nRF Connect Programmer）写入 UICR。
BIN 文件更安全，适合 普通固件升级或量产烧录，不会破坏调试/保护配置。

好的，我给你画一个 ASCII 示意图，展示 BIN 文件烧录 vs HEX 文件烧录 对 nRF52840 UICR（APPROTECT）寄存器的影响：

地址空间示意 (nRF52840)
┌───────────────┐
0x00000000      │ <- Flash 起始地址 (用户程序区)
│               │
│   用户程序    │
│   （BIN/HEX） │
│               │
│               │
│               │
│               │
└───────────────┘
0x10001200      │ <- UICR 特殊区域 (APPROTECT 等)
│  UICR寄存器   │
│  APPROTECT    │
│  BPROT ...    │
└───────────────┘---------------------------------------
BIN 文件烧录示意
┌───────────────┐
0x00000000      │ <- BIN起始地址
│  用户程序数据 │ <- 烧录区
│  ......       │
└───────────────┘
0x10001200      │ <- UICR区
│  不会被修改   │ <- 安全
└───────────────┘HEX 文件烧录示意
┌───────────────┐
0x00000000      │ <- 用户程序区
│  用户程序数据 │
│  ......       │
└───────────────┘
0x10001208      │ <- UICR.APPROTECT
│  可能包含数据 │ <- 如果HEX文件中包含，烧录后启用保护
└───────────────┘

✅ 结论：

BIN 文件只写指定起始地址的连续 Flash 区域，不会触碰 UICR，误写几率几乎为 0。
HEX 文件包含地址信息，如果 UICR 地址出现在 HEX 中，烧录时会修改保护寄存器。

启动选项

1. STM32 系列 (Cortex-M)

启动选项引脚：有
- 引脚名：BOOT0 / BOOT1
- 功能：
  - BOOT0=0 → 从主 Flash 启动（用户程序）
  - BOOT0=1 → 从系统内置 ROM 启动（System Bootloader，用于 USART/SWD/DFU）
- BOOT1 有些型号用来扩展 ROM/Flash 启动选项
特点：
- 上电电平决定启动源
- 支持外部硬件选择启动模式

2. GD32 系列（STM32 类国产芯片）

启动选项引脚：类似 STM32
- BOOT0 / BOOT1
- 功能和 STM32 相同，决定启动 ROM / Flash /其他模式

3. NXP LPC 系列 (LPC17xx, LPC54xx)

启动选项引脚：有
- ISP / Boot 配置引脚（通常是 P0.x 或其他特定引脚）
- 功能：
  - 上电检测这些引脚状态 → 决定进入 ISP / UART / USB / Flash 启动模式
特点：
- 引脚组合决定启动源
- 软件也可通过寄存器修改启动地址

4. Kinetis 系列 (NXP, Cortex-M4/M0+)

启动选项引脚：部分有
- BOOTCFG / FOPT 寄存器 +硬件引脚
- 功能：
  - 上电检测引脚电平 + 配置寄存器决定启动 ROM / Flash
特点：
- 可通过硬件引脚覆盖启动寄存器配置
- 常用于进入 Factory Bootloader

5. ESP32 系列

启动选项引脚：有
- IO0 / IO2 / EN
- 功能：
  - IO0 低电平 + EN 拉高 → 进入 UART 下载模式（Flash Download Boot）
  - IO0 高 → 正常启动应用程序
特点：
- 硬件上电检测 IO0 实现启动模式选择
- 用户可方便通过按钮操作进入下载模式

6. 总结对比

MCU 系列	硬件启动引脚	功能描述	软件辅助
STM32 / GD32	BOOT0 / BOOT1	ROM / Flash 启动	可配 Option Bytes
LPC17xx	ISP / Boot pin	Flash / UART / USB 启动	Boot寄存器可修改
Kinetis	BOOTCFG / FOPT	ROM / Flash 启动	软件可覆盖
ESP32	IO0 / EN	UART 下载 / 应用启动	无需额外寄存器
nRF52840	无专用引脚	Bootloader / DFU 软件检测按钮	UICR 配置启动地址

📌 结论：

大部分 MCU（STM32、GD32、LPC、Kinetis、ESP32）都有 硬件启动引脚，用于选择 ROM / Flash / Bootloader 等启动模式。
nRF52840 是例外，没有专用启动引脚，启动模式通过 软件检测 GPIO + UICR 配置寄存器 实现。

nRF52840 没有专用启动选项引脚
启动模式选择依靠：
1. Bootloader 内部软件检测 GPIO（如按钮）
2. UICR 配置寄存器中的启动地址和标志
用户可以通过 硬件按钮 + Bootloader 软件逻辑 实现上电进入 DFU 模式，或者直接启动应用程序

1. nRF52840 启动机制概览

nRF52840 没有专门的“硬件启动选择引脚”，启动模式主要依靠 Bootloader 和 UICR 配置寄存器控制：

用户应用程序区（默认启动）
- 上电或复位后，MCU 会读取 启动地址（通常从 0x00000000 或 UICR 配置的地址）执行应用程序。
Bootloader / DFU 模式
- 进入 DFU 或 UF2 模式的方式主要有两种：
  1. 软复位触发：Bootloader 通过应用程序内部指令触发跳转到 DFU 镜像。
  2. 硬件复位 + 检测：Bootloader 可以检测某些条件（例如特定按键按下、或 UICR 配置标志），进入 DFU 模式。