NOR Flash 块保护与 OTP 安全寄存器

写保护机制、OTP 一次性区域与唯一标识的配置、验证与工程实践 —— 一份以「数据写不坏、升级不锁死」为主线的电路设计参考 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

结论： NOR Flash 的写保护是分层体系——块保护位管区域、写保护引脚管总闸、OTP 管一次性数据；配置铁律只有一条：先验证、再配置、后锁定。 两类典型事故都源于顺序错误：该保护的没保护（被误擦）、不该锁的锁死（无法升级）。把「上电读状态、规划分组、逐级配置、读回验证、最后锁定」五步走完，两类事故都可消除； 而 OTP 写错不可逆，所以一次性区域的写入验证必须比块保护严格一个量级。所有位号、分组、容量与方向口径，以器件 datasheet 与 JEDEC 正式规范为准。

读者路径

• 想先建立全景：第 1 章（问题本质与威胁模型）+ 第 2 章（块结构与寻址基础）。
• 要配块保护位：第 3 章（机制）+ 第 7 章（设计流程）+ 附录 B（检查单）。
• 要接写保护引脚：第 4 章（硬件保护的电气行为与边界）。
• 要写 OTP 与唯一标识：第 5、6 章 + 附录 A（参数速查）。
• 固件升级与保护冲突：第 8 章（固件侧管理）+ 第 9 章（失效案例与定位）。
• 要做验证与测试：第 10 章；换料兼容性：第 11 章。
• 只想要结论：第 12 章（要点汇总与强度分级）+ 附录 C（术语）。

前言

这份文档回答一个在 NOR Flash 电路设计里反复被问、又反复被做错的问题：写保护到底怎么配、按什么顺序配、配完怎么验证、配错了会怎样。问题被做错，不是因为机制难——块保护位、写保护引脚、OTP 三样东西的机制都不复杂——而是因为 datasheet 只讲「器件支持什么」，不讲「你的产品该怎么排」。本文补的正是后者：把机制翻译成配置顺序、验证方法与检查单。

范围上，本文覆盖 SPI 接口 NOR Flash 的三类保护机制：块保护位（状态寄存器内的非易失配置）、写保护引脚（WP#，硬件总闸）、OTP 安全寄存器（一次性区域与唯一标识）。不覆盖的内容同样要划清：加密引擎、安全启动、认证签名等系统级安全设计超出本文范围；NOR 之上的文件系统磨损均衡属于固件层话题，本文只在接口处提一句。

写作口径上，全文遵守三条约束：不写寄存器地址、位域位置与命令码数值（随型号而变，以 datasheet 为准，标准命令名可以出现）；不写商业数据（不涉及任何厂商比较与价格）；引图只用文字（按章与图号引用，不做超链接）。文中所有容量、组数、比例均为量级示意，落到设计里的一笔一画，一律以器件 datasheet 与 JEDEC 正式规范为准。

1. 问题本质：NOR 为什么需要写保护

这一章把「写保护」还原成机制：它要防的是什么、保护对象分几层、块保护与 OTP 怎么分工、以及据此建立的威胁模型与设计假设。后面所有章节的判断，都是这一章四条原理在具体配置流程上的投影。

图 1 把三层防护并排摆开。三层的设计角色完全相反，这是全篇最重要的一个判断：块保护位管运行期，必须留后门（未锁定时可改，否则没法升级）；OTP 管一辈子，不许有后门（写错即定格，所以验证要严）；写保护引脚是硬件总闸，它的价值不在「常用」而在「兜底」——软件全线失灵时，还有一根线能把整片按住。把任何一层的角色派错（比如指望 OTP 做运行期禁区、或指望块保护位锁一辈子），都会以第 9 章案例的形式回来。

1.1 写保护要防住的四类风险

NOR Flash 的擦写靠浮栅电荷实现：编程把电荷注入浮栅、擦除把电荷抽走，每经过一次擦写循环，浮栅的物理状态就变一点。这个「磨损不可逆」的物理背景，决定了所有写保护讨论的出发点——保护的目的是让「不该发生的擦写」根本不发生，而不是靠事后恢复。数据被误擦之后，没有任何机制能把它找回来，备份与冗余只能减少损失，不能消除损失。

按发生频率从高到低，写保护要防住的风险可以归成四类：

1.2 保护对象的三个层级

保护对象分三个层级，对应三种完全不同的机制载体。区分层级是配置设计的第一步：层级选错，后面全错——拿区域机制去管一次性数据，或拿一次性机制去管运行期禁区，都是常见错配。

三个层级有一个共同前提：保护状态本身必须非易失——掉电重启后，块保护位还在、OTP 内容还在、引脚电平由硬件重新建立。这正是 NOR Flash 相对于易失存储的优势：保护配置不需要每次上电重写，也就不存在「上电初始化还没跑完、保护先被抹掉」的窗口。这个窗口在固件侧仍然以另一种形式存在（初始化代码本身就在被保护或待保护的区域内），第 8 章会专门处理。

1.3 块保护与 OTP 的分工

块保护位与 OTP 长在同一颗器件、同一类存储介质上，但设计角色完全相反：块保护管运行期，要留后门；OTP 管一辈子，不许有后门。这句话是第 5、7 章全部配置流程的总纲。

1.4 威胁模型与设计假设

图 2 把四类风险与三层防护的对应关系画成了矩阵。读这张图要带着两个「不」：写保护不防读——读操作永远放行，「防读」从来不是块保护的职责（第 6 章讲只读区域时再收口这个边界）；写保护不防断——掉电写一半靠软件重试与校验兜，保护位只负责掉电之后不继续被误写。

矩阵里「中」字最多的两列值得多说一句。写保护引脚看起来是「强」最少的机制，那是因为它的定位是总闸而非日常手段：拉低一次全片禁写，误伤面太大，不适合运行期频繁动作；但正因为它在硬件层、绕过全部软件栈，它在「软件已经失灵」的场景里价值最大。OTP 列的两个「中」则提醒另一件事：一次性区域的内容是可读的，锁定只挡住「改」，挡不住「看」——把明文密钥直接写进 OTP 而不做任何封装保护，是第 6 章要讨论的可信边界问题。

1.5 本文主线与读法

本文的主线只有一句话：把「数据写不坏、升级不锁死」翻译成可执行的三层配置与五步流程。三层配置对应第 3~6 章（块保护位、写保护引脚、OTP、唯一标识）；五步流程对应第 7 章（上电读状态、规划分组、逐级配置、读回验证、最后锁定）；第 8 章讲固件侧怎么配合，第 9 章用三个失效案例反推设计规则，第 10 章给验证方法，第 11 章处理标准与换料，第 12 章收口。

读法上，三类读者三条路径。硬件工程师重点走第 2~5 章加第 11 章：块结构决定分组，分组决定保护位，引脚决定硬件闸门，标准决定换料风险。固件工程师重点走第 3、7、8 章：写使能锁存、保护检查、临时解锁与异常中断处理。测试与产线工程师重点走第 7、9、10 章加附录 B：配置工位怎么设计、失效怎么定位、验证怎么覆盖。三类路径在第 12 章汇合。

2. NOR Flash 块结构与寻址基础

讲保护之前，先看保护作用在什么上面。这一章建立三样东西：块的组织（保护粒度的物理来源）、寻址与访问方式（保护判断的地址依据）、状态轮询机制（保护状态与写完成的观测手段）。不建立这三样，后面讲的块保护位、OTP 区域都会变成没有坐标的抽象概念。本章所有容量与组数均为量级示意，以型号 datasheet 为准。

2.1 扇区与块的组织

NOR Flash 的地址空间是一条自顶向下的直线，但这条直线不是均质的。按擦除单位的大小，可以分成两到三段：顶部是小扇区区（引导块与参数块，扇区容量在 4KB 量级）、底部是大扇区区（主块区，扇区容量在 64KB 量级）。前者存在的理由很实际：引导程序体积小但更新频繁，用大扇区放它，改一行代码就要擦掉几十KB；后者反过来，主体数据体积大、批量更新，用大扇区减少擦除次数、提高编程效率。

在「统一架构」的型号上，全部扇区同一大小；在「混合架构」的型号上，大小扇区分段排布。两种架构对保护设计的影响是直接的：混合架构天然给出了「引导 / 参数 / 主体」的分区骨架，保护分组顺着它排即可；统一架构下所有扇区等大，分组只能按数量切，切完还要人工标注每组的用途。

2.2 统一寻址与访问方式

SPI NOR 对外是一条总线：片选、时钟、四条数据线（单线模式下一进一出）。地址空间线性连续，读操作可以按字节随机访问——这是 NOR 相对于 NAND 的根本优势，也是「代码原地执行」的前提。但写侧的约束完全不同，一句话概括：读是自由的，写是带刻度的。

• 读：任意地址、任意长度、随时发起。保护机制不拦截读——「防读」从来不是块保护的职责。
• 编程（写）：以页为单位（页容量在 256B 量级），且只能把位从 1 改成 0。所以写之前必须确认目标区域允许写，且目标位置已经是擦除态（全 1）。
• 擦除：以扇区（或块、整片）为单位，把整块恢复成全 1。这是破坏性最强的操作，也是保护机制的首要拦截对象。

2.3 擦除粒度与编程粒度

把「带刻度的写」展开成一张表。三种操作的粒度差异，是后面所有保护规则的物理来源：保护为什么按组不按字节、为什么不可能保护半个扇区、为什么写使能是「一次一授权」，答案都在这张表里。

2.4 状态轮询机制

块保护配得对不对、写操作有没有完成，都不靠猜——全部通过状态寄存器观测。状态寄存器是 NOR Flash 的仪表盘，按用途分三类信息：操作进度（忙位，标记编程 / 擦除正在进行）、写使能状态（标记当前是否允许一次写操作）、保护配置（块保护位，标记哪些组被保护）。块保护配置掉电后保持（非易失）；忙位与写使能状态反映当前操作状态，操作结束或上电后回到基态（写使能为易失锁存）。

2.5 保护粒度与块结构的对应

图 3 左栏是块组织、右栏是保护粒度，两栏叠起来读，得到保护设计的第一条硬约束：保护边界永远与扇区边界对齐。块保护位按「块组」划界，一个组覆盖若干连续扇区，不可能出现「半个扇区被保护」的状态。这不是设计选择，是物理约束：擦除的最小单位是扇区，保护如果比扇区还细，被保护的半个扇区既不能擦也不能写，器件状态机无法处理。

第二条约束关于方向：多数器件的块保护位支持两种划界方向——从顶部往下数组、或从底部往上数，部分型号通过一个附加配置位切换。方向配错的效果是「保护了数据区、放开了引导区」：看起来保护生效了，实际最关键的引导程序裸露在外，而且这种错误在「读回验证」时看不出来——位确实配成你想要的样子了，只是数的方向反了。方向与分组的对应关系必须以型号 datasheet 为准，这是第 11 章兼容替换风险的第一个检查点。

本章小结：NOR Flash 的块组织给出保护粒度的物理上限（扇区），寻址方式给出保护判断的地址依据（地址到组的映射），状态轮询给出保护状态的观测手段（读回与忙位）。带着这三样东西，第 3 章进入块保护机制本身：写使能锁存、分级结构、方向性与验证方法。

3. 块保护机制

这一章讲透块保护位的四个侧面：写使能锁存怎么与它配合、分级结构怎么划分禁区、方向性怎么决定数的方向、以及配完之后怎么读回验证。核心结论：块保护是运行期的主力，但它的全部价值建立在「读回验证」这个动作上——没验证的配置等于没配置。

图 4 上半是写使能的状态机，下半是它与块保护位的正交关系。两个要点。其一，写使能是易失的：一次一授权，用完（或掉电）即失效，所以每次写操作前都要重新发 Write Enable——这条命令的成本是几百纳秒量级，换来的是误触发的窗口最小化。其二，块保护位是非易失的：它住在状态寄存器里，掉电重启后还在，这才是「保护配置不需要每次上电重写」的原因。把这两者的掉电行为混为一谈（比如指望写使能跨掉电保持、或指望块保护位随写操作自动失效），是固件侧最常见的一类误解。

3.1 写使能锁存与保护状态

写使能锁存（Write Enable Latch）是器件内部的一个易失位：为「开」时，紧随其后的一条编程或擦除命令会被执行；为「关」时，写命令被直接忽略。标准命令集用两条命令控制它——Write Enable 打开、Write Disable 关闭——另外编程 / 擦除完成、掉电、复位也都会让它回到关闭态。

这个设计常被新手当成累赘：「反正每次都要开，不如默认开着」。但默认开着意味着任何一条误触发的总线操作都可能改写数据——地址线毛刺、DMA 跑飞、调试器误点，在写使能常开的器件上都是真实事故。一次一授权把所有「非预期命令」挡在门外，只放行「明确打算写」的那一次。块保护位守第二道门：地址对不对；写使能守第一道门：意图真不真。

3.2 块保护位的分级结构

块保护位是状态寄存器内的若干位，它们的组合值决定一个「档位」，每个档位对应一片受保护区域。档位数量由位数决定：两位就是四档、三位八档（量级示意，具体以型号 datasheet 为准）。受保护区域随档位单调增大——从顶部一个小组，一路扩展到几乎整片。

图 5 左栏把状态寄存器里的保护字段摊开：忙位与写使能位属于「操作维度」，块保护位、方向配置位与锁定位属于「保护配置维度」，两组字段互不干涉——这也是图 4 正交关系的来源。右栏是档位阶梯：注意它画的是量级示意，真实器件的每档覆盖多少组、组内多少扇区，必须查 datasheet 的分组表。

分级结构有两个工程含义。其一，档位是「组合值」不是「位数」：块保护位作为一个整体编码档位，不是每一位独立开关一个区域——所以「我想多保护一组」不是加一，而是把组合值抬到对应档位，沿途的组会被一起保护。配置前必须把「目标档位会连带保护哪些组」列清楚。其二，部分型号的档位只升不降：降档要先解除全部保护（回零）再重配，而回零这个动作本身可能被锁定位拒绝——一旦锁定，档位就永久固定了。

3.3 保护锁定的方向性

本节讨论的是保护边界的方向参数（TB 位），不是保护锁定操作。方向性是块保护里最容易被忽视、后果最直接的一个维度。数组有两个方向：从地址顶部往下数（保护区域从高端往下吞）或从底部往上数（从低端往上吞），部分型号用一个附加配置位切换，部分型号把方向与取反模式编进同一组配置位。档位数值完全相同的一行配置，在两个方向下保护的是完全不同的区域。

方向错误的症状有两个特点，都让它格外危险。其一，读回验证看不出来：位确实配成了你想要的值，状态寄存器读回来一模一样——错的不是值，是值的解释方式。其二，它在「该保护的地方」看起来完全正常：引导区被锁定时读写全拒、升级必失败（案例二）；数据区被锁定时引导读写正常、只是应用升级失败——两种症状都会先被怀疑成固件或硬件问题，转一圈才回到方向配置。唯一的对策是把「方向 + 档位 + 区域」三者的对应关系写进配置表，逐项核对：

• 读回方向配置位当前值，与配置表记录的方向一致
• 按 datasheet 分组表，把「当前档位 + 当前方向」翻译成实际受保护组清单
• 用引导区首地址做试写验证（小样片上做），预期结果为禁止写
• 用应用区（升级窗口）做试写验证，预期结果为允许写
• 把上述两条的「预期结果」写进测试记录，不靠现场判断

3.4 保护状态的读取与验证

读回（Read Back）是配置闭环的最后一环，也是块保护机制从「器件功能」变成「工程可信」的那一步。标准命令集里的 Read Status Register 是唯一入口，但它回答的不只是「配上了吗」——它同时回答「器件现在认为的保护状态是什么」，这中间隔着静默拒绝、方向解释、锁定位约束三层不确定性。

图 6 把读回验证落成了流程：三次读回（上电、写入后、锁定前）+ 影子副本预演 + 失败分支处置。三个设计要点。影子副本：目标配置先在内存里组装成完整的状态寄存器镜像，与当前读回值做差异对比，差异项逐条过「这是我要改的吗」——它能挡住九成以上的手误，包括把档位配高一级、把方向配反。失败分支要先查硬件再查固件：WP# 电平与锁定位状态是写入被拒的两大硬件原因，查完这两样再怀疑命令时序。锁定前最后一次读回是不可逆操作前的最后一道闸，任何不一致都不锁定（第 7 章展开）。

3.5 保护机制的边界与例外

把块保护的边界集中列清，是为了防止「配了保护就万事大吉」的预期错位。六条边界，每一条都对应一类真实事故：

本章小结：块保护位的四个侧面——写使能锁存（第一道门，易失、一次一授权）、分级结构（第二道门，非易失、按档位划区）、方向性（档位的解释方式，最易误配）、读回验证（让配置可信的唯一动作）。下一章讲硬件总闸：写保护引脚。

4. 写保护引脚与硬件保护

这一章讲硬件总闸：写保护引脚（WP#）的电气行为、上电默认状态、与主控 GPIO 的配合、强度边界与失效原因。核心结论：WP# 是唯一不经过软件栈的保护层，它的价值在「软件全线失灵时还能按住整片」；而它最常见的失效原因不是设计错，是「以为接了其实没接」。

4.1 写保护引脚的电气行为

写保护引脚是器件上的一个硬件输入，电平语义以型号 datasheet 为准（多数型号低电平为保护态，但不排除例外，接反的效果比不接更危险）。保护态下，器件拒绝两件事：写状态寄存器（块保护位改不了）与一切数据写操作（编程、擦除被拒）。读操作不受影响——这再次印证第 3 章的边界：写保护体系从头到尾不管「读」。

不同型号在细节上有差异，常见变体包括：WP# 为低时 Write Enable 命令是否也被拒绝、WP# 是否参与锁定位的置起条件、以及是否只有「保护字段」被禁写而其他状态寄存器字段仍可写。这些细节全部以型号 datasheet 为准，本节只讲共通的机制骨架。

图 7 的三种接法覆盖了绝大多数产品形态。直接接地最简单，适合「烧录后不再改」的产品——保护是默认态，不需要固件参与，也不存在固件忘了配的窗口。接主控 GPIO 把总闸交给软件日程表：平时拉低保护，升级窗口期拉高允许写；代价是上电默认电平由复位电路决定，固件初始化前有一段「硬件说了算」的窗口。上拉电阻 + 开漏输出是前两者的合体：上拉保证默认保护（断电、复位、固件跑飞都回到保护态），开漏输出保留临时拉低的能力——安全敏感场景的首选。

4.2 上电默认状态与不可变性

WP# 的保护价值很大程度上来自「默认」二字：不依赖任何软件正确性，上电那一刻就是安全的。但这个「默认」不是器件的单向承诺，而是器件内部上下拉与外部电路共同决定的结果——多数型号内部有弱上下拉（以 datasheet 为准），外部设计可以加强它，也可以无意中破坏它。

真正需要设计介入的是主控复位期间的那段窗口：主控 GPIO 在复位期间默认输入高阻，此时 WP# 的电平完全由外部电路决定。如果既没有外部上下拉、主控又没及时驱动，WP# 在这段时间是悬空的——而悬空意味着行为不可预期。这段窗口通常有几十毫秒量级（以主控复位时序为准），足够一次误写发生。

4.3 与主芯片 GPIO 的配合

接主控 GPIO 时，有三个设计细节决定这个方案成不成立。其一是驱动方式：推荐开漏输出加上拉电阻——开漏保证「主控不驱动时上拉生效」（回到保护态），推挽输出在固件跑飞时可能输出任意电平，把总闸交给一个不可信的源头。上拉阻值在几十千欧量级（以双方 datasheet 的漏电流与沿率要求为准），阻值太大抗噪差，太小则开漏灌电流超出 GPIO 能力。

其二是电平兼容：主控 IO 电压与器件工作电压不一致时（比如 1.8V 器件接 3.3V 主控），要确认 WP# 的输入高低门限在对方的输出电平范围内——这类跨电压配合问题在电源轨设计中常见，落到 WP# 上的症状是「电平看着对、器件不认」。

其三是默认极性：GPIO 复位默认值（部分主控可配）要保证「上电即保护」——如果主控支持「复位期间 GPIO 保持上次状态」，还要防止上次状态恰好是允许写的电平被带上来。

4.4 硬件保护的强度与边界

先讲强度。WP# 是保护体系里唯一不经过软件栈的一层：它不需要固件参与判断、不依赖总线时序正确、不受固件 bug 影响。绕过它需要物理动作——割线、飞线、拆器件。在「板卡在位上、软件可能出错」这个最常见的威胁场景里，它是最后一道也是最可靠的一道闸。

再讲边界，两条，都必须记住。其一，WP# 不防读——与块保护位完全一致，读永远放行。其二，WP# 不防「离板」：器件从板上拆下来、用编程器直连时，WP# 被编程器按它自己的默认值驱动（通常是允许写），防护链在离板那一刻就断了。硬件保护防的是「板上的误操作与误触发」，不防「离板的攻击」——后者的兜底只有 OTP 锁定与内容加密（第 5、6 章）。

4.5 硬件保护失效的常见原因

硬件保护的失效几乎不发生在「设计正确但器件坏了」这条路上，而是集中在「设计有洞、洞里平时看不见」这条路上。五类根因，按出现频率排：

本章小结：写保护引脚是硬件总闸——上电默认安全、不经过软件栈、强度来自物理；边界是不防读、不防离板。下一章进入 OTP 安全寄存器：一次性不可逆数据怎么定位、怎么写入、怎么与块保护组合。