复位系统与看门狗设计

复位来源与判决、看门狗纪律、软件配合、测试验证与核查清单 —— 一份从机制落到检查单的电路设计参考 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

报告总结

前言

做硬件的人迟早会遇到同一个噩梦：样片阶段明明好好的板子，到试产或现场开始「偶发复位」。事后复盘时，往往发现所有「该做的」都做了——复位引脚上了拉电阻、看门狗也开了、固件里也在喂狗——唯独没有回答一个问题：这次复位到底是谁触发的、判决条件是什么、释放时机对不对、软件知不知道发生了什么？

这个问题问的不是某一个器件，而是系统：复位源之间的仲裁、复位树的分配顺序、释放与时钟的配合、看门狗的喂狗纪律、软件侧的原因记录与安全收敛，每一环都合格，链路才合格；任何一环只满足「典型值」不满足「最坏值」，失效就会以间歇性的形式留给量产。这份文档把这条链路拆开，逐环给出机制、设计动作、测试方法与检查项。

结论： 复位系统的全部设计动作可以概括成两句话——判决要严：每一类复位源都有明确的判决条件（阈值、脉宽、时钟就绪、同步释放），任何一道不过就不释放；纪律要硬：看门狗的喂狗点、超时动作分级、复位原因记录必须写进设计文档并逐项测试。 所有数值为量级性示意，具体参数以正式 datasheet / 规范为准。

读者路径

• 想先建立整体图景：第 1 章（问题本质与判决条件）+ 第 2 章（复位架构总览）。
• 正在画原理图、选监控方案：第 3 章（上电复位与电压监控）+ 第 5 章（外部复位与监控芯片）+ 附录 A。
• 正在配看门狗、写喂狗逻辑：第 4 章（看门狗机制）+ 第 7 章（软件配合）+ 附录 B。
• 板子出问题要定位：第 9 章（故障速查）+ 第 11 章（案例）+ 第 8 章（测试方法）。
• 关心释放时序与多时钟域：第 6 章（复位时序与释放）。
• 只想要结论：第 10 章（设计建议）+ 第 12 章（核查清单）+ 附录 A~D 模板。

1. 问题本质：复位的来源与判决

这一章不涉及任何具体电路，只把「复位」还原成三个问题：复位从哪里来、凭什么判决、判决之后发生什么。后面所有章节的判断，都是这一章几条原理在具体器件与具体系统上的投影。

1.1 上电复位、欠压复位与外部复位

按来源划分，系统里的复位可以归纳成三类：上电复位（电源从无到有的过程触发）、欠压复位（运行中电源跌落触发）、外部复位（人为或外部器件驱动复位引脚触发）。三类的共同点是「把系统拉回已知初态」，不同点在于判决条件——凭什么认定「这是一次有效的复位」。

• 上电复位（POR）：判决依据是 VCC 穿越上电阈值。阈值是一个窗口而不是一条线，穿越窗口的瞬间复位开始释放，并起算一段上电延时。
• 欠压复位（BOD / BOR）：判决依据是「跌落深度」与「持续时间」同时满足——只看深度会被电源噪声误触发，只看时长会在真跌落时反应太慢。高位阈值通常还配一个早期预警（中断而非复位）。
• 外部复位：判决依据是复位引脚的电平稳定并持续过消抖时间。按键、外部监控芯片、另一个主芯片都可以是驱动源。

三类的响应也有差别：上电与欠压复位由硬件电路自主完成，软件只能「等」；外部复位可以做到「立即进入、尽快释放」，是三类里唯一可由外部主动掌握节奏的。三类复位源在同一个系统里并存时，还需要仲裁——这是第 2 章的内容。

图 1 把三类复位源和四道判决画在了一起：上方三张卡片是「谁在拉复位」，下方四道判决是「凭什么放复位」。拉复位是容易的，放复位才是设计的重点——放早了，系统在半就绪状态启动；放晚了，只是慢一点，不会出事。这也是全篇反复出现的非对称性：判决可以严，释放必须稳。

1.2 复位阈值与迟滞

复位阈值首先是一个窗口而不是一条线：受工艺偏差与温度影响，同一型号不同批次、不同温度下，比较器的翻转点会分布在一个区间内。数据手册通常给出阈值的最小值与最大值，系统设计要按窗口核算，不能按标称值核算。

比窗口更容易出问题的是迟滞。没有迟滞（或迟滞不足）的监控电路，在 VCC 缓慢穿过阈值时会出现「 chatter 」——反复翻转、反复复位，表现就是系统在某个电压点附近「抽搐」，永远起不来。迟滞的判据很简单：释放阈值与再次拉复位的阈值之间要留出足够间距，间距要大于电源在该电压附近的正常波动幅度。间距不够，噪声就替你「判决」。

1.3 复位脉冲宽度

复位拉下去之后，要拉多久？答案是至少让所有受复位控制的寄存器都完成归位。触发器从「复位沿」到「稳定在复位态」需要时间，时钟沿与复位释放沿靠得太近还会遇到亚稳态（第 6 章展开）。工程上把「最短可靠复位时间」归纳成三个来源：

• 电路保证的宽度：正规 POR / 监控芯片会在手册里给出「保证的最小复位脉冲宽度」，这是设计的下限依据。
• RC 延迟的宽度：用阻容延时保持复位的电路，宽度由放电时间常数决定，还要考虑开关漏电流、温度漂移与批次分散——低温下电容容量变化、高温下漏电流增大，都会把宽度拉偏。
• 人为操作的宽度：按键复位的宽度取决于人——几十毫秒量级，通常远大于电路需要，真正要处理的是消抖（第 5 章）。

宽度不足的后果是「部分复位」：大部分寄存器归位了，个别触发器停在旧值，系统带着一个不一致的初态启动——这类故障的表现是偶发的、与上电时刻相关的，极难复现。宽度的核算原则：取手册保证值、RC 电路按最坏时间常数核算、宁宽勿窄。宽了只是启动略慢，窄了就是潜伏故障。

1.4 复位释放与时钟稳定

复位有两个沿，两个沿的安全性完全相反：拉低沿是异步安全的——不管时钟处于什么相位，拉低复位总是能把系统带入已知态；释放沿是危险沿——释放瞬间，所有触发器同时「活过来」，如果此时时钟还没稳定，第一次时钟沿就可能采到未定义的中间态。

由此得到复位分配的第一条铁律：「异步拉低、同步释放」。拉低可以用异步方式（任何源有效立即拉低），释放必须经过同步链——确认时钟已稳定、再经过至少两级同步触发器、以「干净」的时钟沿释放。违反这条铁律的系统，故障形态是「大部分上电正常、偶尔一次启动后行为怪异」，而且怪异的形态每次都不一样，因为亚稳态的结果本身就是随机的。

1.5 存储系统的复位画像

存储系统的复位对象比「处理器 + 内存」复杂：除了主芯片自身，还有存储控制器、物理层（PHY）、缓存与在写状态、以及可能独立供电的编程电压轨。把复位对象列全，是第 2 章复位树的设计输入；把每个对象的复位后果想清楚，才能定义哪些复位源可以碰它、哪些场景必须避开。

• 主芯片数字逻辑：复位即归零，无状态损失，是最「耐复位」的部分。
• 存储控制器与命令状态机：归零是安全的，但归零时机要紧——如果有命令在途、写在飞，一次不合时宜的复位会把「一次未完成的写」留在介质里。
• 缓存与脏数据：写回型缓存里的脏数据是复位最怕的东西——复位不等人，脏数据不会因为「系统要重启了」就自动落盘。
• 物理层与训练状态：高速接口（如 eMMC / UFS 一类）的链路训练状态归零后需要重新训练，这是启动时间的一部分，不是故障。
• 独立供电轨（如编程电压轨）：上电与关断有顺序要求，复位序列要避开「轨在写中途被撤」的组合。

本章小结：复位的本质是「判决 + 释放」两件事——三类复位源各有判决条件，阈值要看窗口与迟滞，脉宽要按最坏值核算，释放要等时钟并过同步链，而存储系统的特殊之处在于：复位对象里藏着会丢数据的缓存与写在飞的状态。下一章把视角从单个复位源拉到系统级：多源怎么仲裁、复位树怎么分。

2. 复位架构总览

这一章把复位从「一个引脚」展开成「一张树」：复位源怎么仲裁成一个复位根、树怎么按域分配、释放顺序怎么定、不同规模的系统怎么选架构。核心观点：复位架构的目标不是「有复位」，而是「任何一个源都能让系统去已知态，且释放时机唯一」。

2.1 复位树与复位分配

复位树是复位架构的骨架，自顶向下分四层。根层：仲裁输出，任何源有效即拉低，是系统里唯一的「复位总闸」。分配层：从根分出若干分支，每个分支对应一个时钟域或一个功能域。同步层：每条分支末端是同步链（至少两级触发器），把「释放」变成目标域时钟的干净沿。叶层：最终消费者——寄存器、状态机、总线接口。

复位树的设计动作可以概括成「一根、分域、逐叶命名」：一根（唯一的仲裁根，杜绝多头拉复位）；分域（每个时钟域一条分支，域内共享释放沿）；逐叶命名（每个叶节点在设计文档里有名字、有归属域、有释放顺序）。树画不出来，说明架构还没想清楚——这是第 10 章「复位树清单化」的起点。

2.2 复位源仲裁与优先级

多源并存就要仲裁。仲裁要回答三个问题：拉复位的条件（任一源有效即拉，通常是或逻辑）、释放的条件（所有源无效且释放条件满足——注意是「且」，不是「或」）、优先级（当多个源同时有效时，系统记录谁、响应对谁）。

优先级的设定没有万能答案，但有两条经验：电源类事件（上电、欠压）通常优先于命令类事件（看门狗、软件），因为电源类意味着硬件条件不成立，命令类的响应没有意义；用于诊断的事件（看门狗、软件复位）要能被单独记录，否则第 7 章的复位原因记录就成了无米之炊。优先级排定之后，必须写进设计文档——排而不写，等于没排。

图 2 的上半是仲裁：五个源汇入一个面板，输出唯一的复位根；下半是分配：复位根经同步释放链，分到四个域。注意释放条件的表述——「所有源无效且释放条件满足」是与关系：任何一个源还挂着，或释放条件（时钟就绪、脉宽达标）没满足，复位就不放。这个「且」是上电即反复重启与上电一次成功之间的分界线。

2.3 复位延迟与顺序

复位从根到叶有延迟，不同分支的延迟不同，这就是复位 skew。skew 本身不是问题，问题是跨域的依赖关系：如果 A 域的逻辑要在复位释放后立即读 B 域的输出，而 B 域的复位放得比 A 晚，A 读到的就是旧值或未定义值。处理依赖关系的办法是定义释放顺序：被依赖的域先放，依赖方后放，顺序由「谁等谁」推导，不由布线的自然延迟决定。

典型顺序约束有四类：时钟域之间（快时钟域通常后放，让它看到稳定的慢域输出）；存储相关域（存储控制器先于使用存储的执行单元释放，保证首条命令落在就绪的控制器上）；总线主从之间（从设备先就绪，主设备后释放，避免上电即遇到无响应的总线）；模拟与数字之间（模拟偏置、参考电压先稳，数字后放）。顺序定义完成后，用复位序列器或延时链实现，并在设计文档里画出「谁先谁后、依据是什么」。

2.4 决策树：按系统规模选复位架构

复位架构的选择可以按「系统规模 × 安全要求」两个维度决策。小系统（单 MCU、单时钟域、无高速存储接口）：主芯片内部 POR / BOD + 复位引脚，全部搞定，重点是参数核算与引脚默认电平。中系统（单 SoC 多时钟域 + 一类存储接口）：内部源 + 外部监控芯片（补盲区）+ 看门狗，重点是仲裁与释放顺序。大系统（多主、多供电域、高速存储）：外部监控 + 复位序列器 + 分域同步链 + 多主协商（第 5 章），重点是顺序的可文档化与可测试性。安全相关系统（功能安全等级要求高的场景）还要加「监控独立性」——看门狗的时钟与复位路径要与被监控系统物理独立，避免共因失效。

2.5 与上电时序设计的衔接

复位是上电时序的最后一环，也是两条链路的缝合点：电源链路回答「电什么时候来、按什么顺序来」，复位链路回答「什么时候算就绪、什么时候放行」。两者的接口只有三个：上电完成判据（最后一条轨建立 + 稳定，是复位释放的前提）、解复位时机（时钟稳定后，总线解复位）、掉电方向（掉电时复位要先于轨掉电拉低，避免半供电状态）。

本篇聚焦复位链路，电源链路（轨序、斜坡、去耦）由上电时序专题承接；但两个专题共享同一份时序图——轨建立事件、时钟稳定事件、复位释放事件、首条命令事件画在同一条时间轴上，各自标注出处。分画两张图的团队，迟早会在「我以为你等了我」的扯皮上浪费时间。

本章小结：复位架构的要点是一根（唯一仲裁总闸）、分域（按时钟域分配）、逐叶命名（每个消费者有档案）、顺序有据（谁等谁可推导）。下一章进入电路层：上电复位与电压监控的具体实现，以及窗口检测、迟滞与掉电预警怎么落地。

3. 上电复位与电压监控

这一章把第 1 章的判决条件落到电路层：上电复位电路有哪几种形态、电压监控怎么从「只看低压」扩展到「窗口检测」、迟滞与抗噪怎么做、掉电预警怎么给软件争取时间、存储系统的多个供电轨各监控什么。核心观点：监控电路的职责不是「检测电压」，而是「把模拟量判决成可靠的事件」。

3.1 上电复位电路

上电复位电路有三种常见形态，按「精度与成本的权衡」展开。形态一：芯片内部的模拟 POR——比较器监测 VCC，越过阈值后启动内部计数器，计数结束释放复位。现代主芯片普遍内置，优势是阈值窗口与最小脉宽都有手册保证，系统侧只要核算斜坡与负载。形态二：外置 RC 延时电路——阻容网络保持复位引脚低电平一段时间，结构最简单、零成本，但宽度由 RC 时间常数决定，受温度、漏电、批次影响，且没有阈值精度可言，只适用于对复位时序没有苛刻要求的场合。形态三：外部监控芯片——专用 supervisor，提供精确阈值、多轨监控、手动复位输入，部分型号还带看门狗，是「内部 POR 不够用」时的标准答案。

3.2 电压监控与窗口检测

电压监控按「看几个方向」分三档。单向下限检测：只看欠压（BOD 一类），覆盖绝大多数场景——系统怕的是「电不够」。窗口检测：同时看下限与上限，VCC 跌过低阈值或超过高阈值都判异常。窗口检测的价值在上限：存储系统的编程电压轨（如 VPP 一类）超过上限有过流与介质损伤风险，只测欠压等于放任过压。多阈值检测：在同一方向上设多级——高位阈值出预警（给软件留时间）、低位阈值拉复位（硬件保护），预警与复位之间的间距就是软件的「保存窗口」（3.4 节展开）。

3.3 迟滞与抗噪

第 1 章讲了迟滞的原理，这里讲落地。迟滞的大小按「电源在该电压附近的正常波动」定：把负载切换、开关纹波、耦合噪声的最大峰峰值量出来，迟滞间距取它的若干倍，保证任何单一噪声事件都不足以跨越整个迟滞区。抗噪的第二个手段是消抖时间（判决延时）：电压越限后不立即动作，持续一段时间才判有效——欠压判决尤其需要，因为真跌落不会自己恢复，而毛刺会。第三个手段是监控器本体的电源抑制：监控电路自己的供电要与被监控轨同源且干净，否则「用带噪声的基准测噪声」。

3.4 掉电检测与预警

掉电是上电的逆过程，但软件的处境难得多：上电时可以等，掉电时每一毫秒都在流失。掉电保护的第一道设计是「预警早于复位」——欠压预警阈值设在欠压拉复位阈值之上，VCC 跌落时软件先收到预警中断，此时距离真正掉电还有一段由储能电容决定的时间。这段时间叫保存窗口：窗口内要完成冲刷缓存、落盘关键数据、记录现场。窗口时长按「电容量 × 跌落前后的电压差 / 负载电流」量级估算，核算时取最小电容量（批次下限）与最大负载（最坏电流）。

预警中断里的动作要有优先级：先停非必要活动（降低电流、延长窗口），再冲刷关键数据，最后记录现场。反过来做——先记录再冲刷——是现场最常见的顺序错误：日志还没写完，电已经没了。

3.5 存储供电轨的监控点

存储系统的供电往往不止一条轨：主供电（VCC 一类）、接口供电（VCCQ 一类，部分器件可与 VCC 共轨）、编程电压（VPP 一类，高层数介质与特定操作才升起）。每条轨的监控职责不同，用一个「总电源好」信号概括所有轨，是存储系统监控设计的高频疏漏——总信号好不代表每条轨都在窗口内，更不代表它们之间的相对关系正确。

• 主供电轨：欠压预警 + 欠压复位，窗口检测视系统成本可选。掉电方向是保护重点（缓存冲刷）。
• 接口供电轨：与主轨可以共轨或分轨；分轨时独立监控，因为总线电平的半途掉电会让挂在总线上的器件看到未定义电平。
• 编程电压轨：过压（介质损伤风险）与欠压（写不完整）都要看；关键是时序联动——写操作进行中撤除编程电压，等于制造一条半写完的记录，复位序列必须避开这种组合。

本章小结：上电复位与电压监控的要点是三句话——电路形态按精度与成本三选一（内部 POR / RC / 监控芯片）、监控从单向下限走向窗口与多阈值、掉电保护的核心是「预警早于复位」且窗口按最坏值核算。下一章进入看门狗：两种形态的区别、喂狗的时机与纪律、超时的动作分级。

4. 看门狗机制

这一章把看门狗从「一个会复位的计数器」讲成一套纪律：窗口看门狗与独立看门狗各抓什么故障、喂狗点怎么设计、超时之后动作怎么分级、饥饿与误喂两种失效怎么防、死锁怎么检出。核心观点：看门狗的价值不在「会复位」，而在「喂狗时机是系统健康的证据」。

4.1 窗口看门狗与独立看门狗

两种看门狗的本质区别在「喂狗的合法条件」。独立看门狗（IWDG 一类）是一个自由递减的计数器：从重装载值开始往下减，减到零之前喂狗（重装载）即可，超时则复位。它只抓一类故障——「程序跑飞后不再喂狗」。它的时钟通常独立于系统主时钟（内置低速源一类），主时钟挂了它照样计时，这是它最大的价值。窗口看门狗（WWDG 一类）在计数器之外加了一个「窗口」：只有当计数器减到窗口值以下时，喂狗才被接受；窗口开启前喂狗，与超时不喂一样，都按 Fault 处理。它抓的是另一类更隐蔽的故障——「程序跑飞了但还在喂狗」（跑进一个自带喂狗的循环、或卡在不停进中断的路径上）。

4.2 喂狗时机与任务划分

喂狗点的设计原则只有一条：喂狗必须发生在「健康检查通过」之后，而不是健康检查之前。健康检查的内容至少包括：所有关键任务自上次喂狗以来都运行过（心跳推进）、没有任务阻塞超过预算、关键资源（存储写入队列）没有卡死。检查不过，就不喂——让看门狗超时，这正是它存在的意义。

按「谁来喂」分三种组织方式。单一健康任务：一个专职任务做检查并喂狗，审计点唯一，是最推荐的结构。多点喂狗：每个任务喂一口，问题是任何一个点的喂狗都会掩盖其他任务的死亡——除非每个点只对自己负责的任务背书。中断里喂狗：最坏的结构，中断的触发与主循环的健康无关，主循环死透了我行我素，看门狗却被喂得饱饱的。

4.3 超时动作分级

看门狗超时之后做什么？答案是「分级」——从最软的动作到最硬的动作排成阶梯（图 5），按系统安全需求选一级作为主动作。分级的第一原则是「软的优先、早的优先」：能在软件还活着时做的事（记录、保存、收敛），不要留给复位之后；能在超时点之前做的事（早期预警中断），不要等到超时之后。

五级动作的大致形态：L0 仅记录——超时计数累加进诊断区，不干预运行，用于调试期摸清系统的真实裕量；L1 早期预警中断——在超时点之前出中断，软件保存现场并尝试恢复，是生产配置的常见主动作；L2 强制保存后交还——进非屏蔽中断，停掉非关键任务，冲刷关键数据，再让后续动作发生，带缓存写入的系统必配；L3 硬件拉复位——软件已不可信，交还硬件判决，这是看门狗存在的根本理由；L4 收敛到安全态——复位后若连续超限（复位计数器越限），不再无脑重启，而是进入安全模式：限制输出、点亮指示、等待人工或远程处置。升级可以跳级，降级不允许——从 L1 退回 L0 需要正式的偏差流程。

4.4 喂狗饥饿与误喂

喂狗相关的失效是成对出现的，方向相反、都会毁掉看门狗的可信度。饥饿：系统是健康的，但喂狗点被阻塞——健康任务优先级不够被高负载饿死、喂狗语句排在一个被死锁任务持有的互斥量后面、写日志的通道满了把健康任务挂住。饥饿的后果是「假超时」：看门狗杀死了健康的系统，团队对看门狗的信任开始崩塌，接下来的动作往往是调大超时或关掉——恶性循环的起点。误喂：系统已经死了，但喂狗还在继续——中断服务程序里喂狗、或者跑飞的程序恰好走进一个带喂狗的循环。误喂的后果是「假健康」：看门狗默许了一个死系统，故障以「功能不动但看门狗不报警」的形式暴露，排查时所有人的第一反应都是「看门狗没开吧」。

4.5 死锁检测设计

比「任务挂死」更难发现的是「死锁」：两个或多个任务互相等待对方持有的资源，系统看起来每个任务都在运行（都在等待里挂着），看门狗如果只查「任务有没有跑过」，可能全部通过——死锁的任务们确实都「跑过」。死锁检测要在心跳之外加两层。第一层：任务时限监控——每个关键任务声明自己的执行预算（最坏完成时间），健康任务检查「上次完成到这次完成的间隔」是否超过预算的数倍；死锁的任务间隔会持续增长。第二层：资源持有监控——关键互斥量记录持有者与持有时长，超过预算即标记；这条能直接指向「谁拿着不放」。

存储系统还有专属的一层：在写操作监控——写操作从开始到完成有正常时长分布，一次写得异常久（远超最坏值）本身就是卡死信号，此时不仅要报看门狗，还要给「写完成判据」一个出口——决定这次写是等、是重试、还是放弃并标记介质。三层合起来，覆盖「挂死」「死锁」「卡在在写操作」三类软件故障形态。

本章小结：看门狗的要点是四句话——窗口狗抓「假活」、独立狗抓「真死」，喂狗必须发生在健康检查之后，超时动作分级且软的优先，饥饿与误喂都靠「喂狗路径无等待 + 喂狗时机有窗口」来防。下一章离开片内监控，讲外部复位：按键、监控芯片、引脚默认电平与多主协商。