AURIX TC27x看门狗：ENDINIT、密码访问与SMU报警

简介：面向汽车电子与嵌入式底层开发者的英飞凌 AURIX™ 系列 32 位 CPU 与安全看门狗应用笔记（AP32221），适合需要理解 TriCore™ 微控制器看门狗机制、ENDINIT 保护与安全监控逻辑的工程师对照手册查阅。文档系统讲解看门狗定时器（WDTs）的概况、特性与寄存器组成，并深入展开 ENDINIT 功能：对 WDTxCON0 寄存器的密码访问，包括静态密码、自动密码序列、与时间无关的密码以及时间检查的密码等几种方式，还涉及对受 ENDINIT 保护寄存器的检查访问与修改访问流程，读者可据此掌握安全看门狗在系统上电、初始化与异常复位中的实际行为，并规避误写保护寄存器导致的调试排错困难。压缩包共 1 个 PDF 文件，大小约 419KB，单文件即完整版应用笔记，便于随查随用、离线留存。目前已有 1066 人学习下载，是快速熟悉 AURIX 安全看门狗编程要点的实用参考资料。

1. AURIX 看门狗不只是"按时喂狗"：一份 2014 年的应用笔记为什么现在还能用

第一次在 AURIX TC27x 上调试的人，多半被 SMU 报警打断过：程序明明在跑，突然就复位或者进 NMI。查时钟、查电源、查堆栈，最后发现问题出在喂狗序列里——密码字段的位没有按规则取反。这份 AP32221 应用笔记讲的就是这颗 32 位芯片里 CPU 看门狗与安全看门狗的实现细节，包括 ENDINIT 保护、密码访问机制、14 位 LFSR 序列密码、超时模式窗口和 SMU 报警路径。它不是入门教程，是写给底层驱动和功能安全相关开发者的实现参考。只要你的代码碰过 WDTxCON0、清过 ENDINIT、改过受保护的寄存器，这份材料就值得放在手边——里面那些位域规则，错一位就是一个现场故障。

2. 两套看门狗与 ENDINIT：先分清谁在监控谁

很多人在项目里只记住"有个看门狗要喂"，等到系统出现偶发复位，才发现自己喂的根本不是出问题的那个。TC27x 里的看门狗不是一个，而是一组：一个安全看门狗加上三个 CPU 看门狗，各自有独立的控制寄存器、独立的密码、独立的报警路径。理不清这层关系，后面的所有配置都是盲猜。

2.1 安全看门狗与三个 CPU 看门狗的分工

按应用笔记的描述，安全看门狗（WDTSCON0）是中心资源，监测与安全相关的系统功能，它独立于任何 CPU 看门狗存在。三个 CPU 看门狗（WDTCPU0/1/2CON0）分别位于各 CPU 内部，负责监控本核的软件执行流程。这个划分直接决定了配置权限：CPU 看门狗只能被与它关联的那个 CPU 配置、使能、停用；安全看门狗则受 SCU 的写保护机制（ACCEN）约束，典型做法是只让承担安全职责的那个核去配置和喂狗。

复位后的默认状态是有差异的，这点经常被忽略。CPU0 复位后处于 RUN 模式，它的 CPU0 看门狗自动启动；其它 CPU 初始处于 HALT 状态，对应的看门狗是停用的。这意味着如果你在多核项目里只初始化了 CPU0 的看门狗，另外两个核的软件跑飞了也不会有任何硬件反应——它们压根没被监控。

选型上的经验是：单核任务流、只关心本核代码有没有卡死，用 CPU 看门狗就够了，成本低、隔离好；涉及跨核协同、系统级安全状态机、外部器件心跳，用安全看门狗；两者都开的时候，喂狗顺序要有明确约定，别让两个核在同一个时间窗口里互相踩。

2.2 ENDINIT 保护的是什么

ENDINIT 是这套机制里最容易被低估的部分。每个 WDTxCON0 寄存器里都有一个 ENDINIT 位，它保护的是系统关键寄存器免受意外写和未授权写。想写这些受保护的寄存器，必须同时满足两个条件：对应 WDTx 的 ENDINIT 位被清 0，以及 CPU 处于超级管理员模式。少一个条件，写操作会被直接忽略，寄存器内容不变，而且不会有任何显式报错——这是最坑的地方，代码看起来执行成功了，实际什么都没写进去。

更关键的是，清 ENDINIT 这个动作本身也受保护。要清它，得先用有效密码访问解锁 WDTxCON0，再用有效的修改访问把 ENDINIT 写 0。而一旦 WDTxCON0 被解锁，看门狗会自动切入超时模式，也就是说访问窗口是有时限的：你必须在超时之前把 ENDINIT 重新置 1，否则就按软件流程故障处理，报警请求发往 SMU。

还有一个反直觉的点：即使你把看门狗本身停用了（WDTxSR.DS = 1），ENDINIT 特性依然有效。停用看门狗不等于打开保护寄存器的门，该走的密码访问和修改访问一个都不能省。不少人在这里翻车，以为关了看门狗就能随便写寄存器，结果配置全是无效的。

提示：清 ENDINIT 之后不要立刻去写目标寄存器，先回读一次 ENDINIT 位确认它真的变成 0 了。硬件上清这一位需要时间，跳过回读直接写，第一次写很可能落在保护窗口之外被丢弃。

2.3 三个寄存器的分工：CON0、CON1、SR

应用笔记里对 WDT 寄存器的描述比较精简，实际写代码时按这三个寄存器建立心智模型就够了。

WDTxCON0 是最核心的一个：它同时装着当前密码和重载值，还管着 ENDINIT 位和 LCK 锁定位。LCK 的值由硬件控制，只有在一次有效的密码访问和随后的修改访问之间才会变低，其余时间保持锁定。这个设计保证了任何一次对看门狗的合法操作都必须是一个完整的两步序列，中间被打断就作废。

WDTxCON1 管的是"看门狗怎么跑"：输入时钟选 fSPB/64、fSPB/256 还是 fSPB/16384，使能还是停用，检测到未喂狗报警之后是否阻止重载（UR 位），密码是否自动序列（PAS 位），以及是否启用时间戳检查（TCS 位）。注意 WDTxCON1 自身也受对应 WDTxCON0.ENDINIT 保护，改它之前一样要走清 ENDINIT 的流程。

WDTxSR 是排查问题的黑匣子。访问故障标志 AE、溢出故障标志、当前使能状态、超时模式标志、SMU 解锁限制状态、密码自动序列状态、时间戳检查状态，以及计数器的当前值 TIM 都在这里。现场调试时第一件事就应该是把 WDTxSR 整个读出来存档，很多问题看一眼标志位就有方向了。

3. 密码访问：喂狗为什么要算一个 LFSR

看门狗要防的是"程序跑飞之后仍然能误打误撞喂上狗"这种情况。所以 AURIX 把喂狗做成了一个带密码校验的两步事务，而不是简单写一个寄存器。这套机制的复杂度，是它区别于普通 MCU 看门狗的核心，也是绝大部分踩坑的来源。

3.1 三种访问类型与位模式

对 WDTxCON0 的写操作分三类，靠低两位区分，配合当前 LCK 状态决定行为。

密码访问要求 bit1 写 0、bit0 写 1；检查访问两位都是 1；修改访问 bit1 固定写 1，bit0 由你决定 ENDINIT 的目标值——想置 1 就写 11B，想清 0 就写 10B。这个细节记住了，能省掉大量"为什么我写进去的值不对"的排查时间。

检查访问的用途容易被低估。它等价于一次密码访问，唯一区别是成功后 LCK 不会被清 0，所以不能接着做修改。它适合放在任务序列的中间点做校验：结合序列密码或时间戳检查，可以在不改变看门狗状态的前提下，验证代码确实走到了预期位置、耗时也在预期范围内。

3.2 静态密码模式下的取反规则

没启用自动序列时（WDTxSR.PAS = 0），密码字段的拼接规则是：PW[7:2] 必须写入当前值的反码，PW[15:8] 写入当前值的原码。应用复位后的默认密码是 00000000111100B，也就是 PW[15:8] = 0x00、PW[7:2] = 0x3C 这个量级的初值。

这里有个必须知道的硬件行为：从 WDTxCON0.PW 读回的值，低 6 位（PW[7:2]）是取反后的。设计意图很明确——让"读出来再原样写回去"这种简单序列无法完成喂狗或解锁，防止跑飞的代码误打误撞通过校验。

工程上我一般不依赖读回值，而是在 RAM 里维护一份密码影子变量。理由有两个：一是读回值本身带取反处理，来回转换容易写错；二是影子变量让你能明确控制"什么时候换密码"，而不用关心硬件当前的返回状态。

/* 密码影子：低 6 位对应 PW[7:2]，高 8 位对应 PW[15:8] */ static uint16_t s_wdt_pw = 0x003Cu; /* 复位默认值，实际项目按需改写 */ /* 拼装一次密码访问的 32 位写值；rel 为当前重载值 */ static uint32_t wdt_build_password_access(uint16_t pw, uint16_t rel) { uint32_t v = 0; v |= ((uint32_t)((~pw) & 0x3Fu)) << 2; /* PW[7:2]：写反码 */ v |= ((uint32_t)(pw & 0xFF00u)); /* PW[15:8]：写原码 */ v |= 0x1u; /* bit[1:0] = 01B，密码访问 */ v |= ((uint32_t)rel) << 16; /* bit[31:16]：当前 REL */ return v; }

这段代码把位域关系显式摊开了，方便对照手册逐位核对。pw参数用的是"原值"语义，函数内部对低 6 位取反，这样调用方不用记住哪几位要翻。rel参数在未启用时间检查时必须填当前重载值，写错一样会触发访问错误。返回值直接写进 WDTxCON0 即可，写完立刻读 WDTxSR 看 AE 位有没有被置起——这是判断这次访问是否被接受的最快方式。

3.3 自动密码序列与 14 位 LFSR

启用自动序列之后（PAS = 1），每次密码检查或密码访问完成，密码都会自动更新，下一个期望值遵循 14 位 Fibonacci LFSR 的伪随机序列，特征多项式是 x¹⁴ + x¹³ + x¹² + x² + 1。这意味着软件必须和硬件同步推进这个状态机，任何一次跳步都会导致后续全部对不上。

好处是显而易见的：静态密码一旦被跑飞的代码"学到"，看门狗就形同虚设；序列密码让每次喂狗用的值都不同，误喂的概率大幅下降。代价是软件复杂度上升，尤其是在多任务或者有中断抢占的场景里，密码状态的推进必须严格串行。

/* 14 位 Fibonacci LFSR 单步推进，抽头对应 x^14+x^13+x^12+x^2+1 */ static uint16_t wdt_pw_next(uint16_t pw) { uint16_t fb; pw &= 0x3FFFu; /* 只保留 14 位 */ fb = (uint16_t)(((pw >> 13) ^ (pw >> 12) ^ (pw >> 11) ^ (pw >> 1)) & 1u); return (uint16_t)(((pw << 1) | fb) & 0x3FFFu); }

这个函数只是把多项式翻译成了一次移位加异或，移位方向和初始状态必须和硬件一致。稳妥的落地路径是：先把看门狗切到静态密码模式跑通全流程，再切序列模式，切换后用一个调试变量把软件算出的下一个密码和硬件期望值做对比，连续比对上几十次再放手。这一步多花半小时，能省掉后面几天的偶发复位排查。

注意：序列密码模式和中断优先级要一起考虑。如果喂狗发生在可被打断的上下文里，而更高优先级中断里又有别的代码碰了 WDTxCON0，密码状态机就会错位。常见做法是把喂狗序列放进不可被打断的临界区，或者干脆收拢到单一任务里。

3.4 时间检查：把执行时间也纳入喂狗

时间检查是这套机制里比较高级的一档。启用之后（TCS = 1），密码访问的 bit[31:16] 不再是重载值，而是当前计数器值 WDTxSR.TIM 的反码，允许的误差范围由 WDTxSR.TCT 规定。写进去的估值落在 TIM ± TCT 之外，就直接判定为 SMU 报警状况。

这个设计的价值在于，它把"代码有没有按预期时间执行完"变成了硬件可校验的条件。一个任务如果被意外阻塞、跑了两倍时间才来喂狗，即便最终喂上了，时间戳校验也会失败。对于有实时性要求的控制回路，这比单纯判超时更有意义。

代价是喂狗点必须离读取 TIM 足够近。中间隔了太多指令，或者被中断打断，估值就可能漂出容差窗口。TCT 的取值要在"能抓到真实超时"和"不误报"之间找平衡，我一般从宽松值开始，用实测的抖动分布往下收，而不是一上来就卡到最小值。

4. 从复位到稳定运行：初始化与喂狗时序的落地写法

原理理清之后，真正落到板子上还有一堆顺序问题。这一章按"上电默认状态 → 初始化骨架 → 参数算例 → 运行时调整 → 喂狗点选择"的顺序走一遍，每一步都对应应用笔记里执行与用途那一章的具体动作。

4.1 上电默认状态与三种定时器模式

复位之后，安全看门狗和 CPU0 看门狗默认有效，其它 CPU 处于 HALT 状态、对应看门狗停用。每个看门狗有三个模式需要区分清楚：

• 正常模式：计数器按用户配置的重载值循环，喂狗就是重新装载。
• 超时模式：一旦 WDTxCON0 被解锁就自动进入，使用固定重载值 0xFFFC，窗口很短，必须在 ENDINIT 重新置位之前完成操作。
• 停用模式：看门狗停止计数，但访问保护和 ENDINIT 功能仍然有效。

超时模式是理解整套机制的关键。它不是"出错了才进"的状态，而是每次合法访问的必经阶段。你解锁 CON0 的那一刻，看门狗就从正常模式切到超时模式，计数器用 0xFFFC 快速回卷。这个窗口的存在，是为了保证"清 ENDINIT 打开保护 → 改寄存器 → 重新置 ENDINIT"这整套动作必须在一个有限时间内完成，不能开着保护窗口去干别的事。

停用模式也要留个心眼。停用看门狗之后 ENDINIT 依然有效，也就是说你仍然要走完整的两步序列才能碰受保护的寄存器。这一点在实际项目中经常被误解为"关了看门狗就自由了"。

4.2 初始化骨架：先解锁再配置

初始化顺序上，我的习惯是：先读状态存档，再配 CON1（分频、使能策略），最后配 CON0（重载值、ENDINIT 归位）。每次写之前都要走完整的密码访问加修改访问序列，中间不要插入无关代码。

/* 寄存器基址与字段偏移以具体型号用户手册为准，此处用占位宏表示 */ #define WDTCPU0_CON0 (*(volatile uint32_t *)WDT_CPU0_CON0_ADDR) #define WDTCPU0_CON1 (*(volatile uint32_t *)WDT_CPU0_CON1_ADDR) #define WDTCPU0_SR (*(volatile uint32_t *)WDT_CPU0_SR_ADDR) /* 一次完整的"解锁 + 改写 CON0"事务；endinit_target 为 ENDINIT 目标值 */ static int wdt_cpu0_modify(uint16_t new_pw, uint16_t new_rel, uint32_t endinit_target) { uint32_t key; uint32_t sr; /* 步骤 1：密码访问，要求 LCK 当前为 1（已锁定） */ key = wdt_build_password_access(s_wdt_pw, new_rel); WDTCPU0_CON0 = key; sr = WDTCPU0_SR; if (sr & WDT_SR_AE_MASK) { /* 访问错误：密码或 REL 不匹配 */ return -1; } if (WDTCPU0_CON0 & WDT_CON0_LCK_MASK) { return -2; /* 仍处锁定态，解锁未成功 */ } /* 步骤 2：修改访问，bit1 固定 1，bit0 为 ENDINIT 目标值 */ key = ((uint32_t)new_pw & 0xFF00u); /* PW[15:8] 原码 */ key |= ((uint32_t)((~new_pw) & 0x3Fu)) << 2; /* PW[7:2] 反码 */ key |= 0x2u; /* bit1 = 1 */ key |= (endinit_target & 0x1u); /* bit0 = ENDINIT */ key |= ((uint32_t)new_rel) << 16; /* 新重载值 */ WDTCPU0_CON0 = key; s_wdt_pw = new_pw; /* 同步软件影子 */ return 0; }

这段代码里，第一次写是密码访问，第二次写才是修改访问，中间用 WDTxSR 的 AE 位和 CON0 的 LCK 位做双重校验。少了这两个检查，出错的时候你只会看到"配置没生效"这种模糊现象。new_pw用原值语义传入，函数内部负责取反，和前面拼装函数的约定保持一致。endinit_target只取最低位，避免调用方传进来一个带其它标志的值把 bit1 覆盖掉。

配置 CON1 的顺序要放在 CON0 之前，因为 CON1 受 CON0 的 ENDINIT 保护——你得先通过一次事务把 ENDINIT 清掉，改完 CON1 再通过另一次事务把它置回来。两次事务之间就是那个有硬时限的访问窗口，窗口里只做必要的事，别顺手去改别的外设。

4.3 重载值与分频的算例

看门狗的超时时间由输入时钟和重载值共同决定。输入时钟三档可选：fSPB/64、fSPB/256、fSPB/16384。假设系统外设总线时钟是 100 MHz，不同组合下的超时时间大致如下（正常模式，16 位重载值）。

最后两列的 0xFFFC 就是超时模式使用的固定重载值。它同时给了你一个参考：当你在访问窗口里操作时，可用时间就是这一档分频对应的值。比如选了 /64 分频，超时模式窗口只有 42 ms 左右，清 ENDINIT、改几个寄存器、再置回来，时间是够的，但绝不能在里面等外设握手或者打印日志。

正常模式的重载值选取，经验做法是让喂狗周期落在超时时间的 1/3 到 1/2 之间。太接近超时点，调度抖动就会造成误复位；太保守，故障检测的实时性又不够。真要做得细一点，把最坏情况下的任务响应时间测出来，再乘一个安全系数往上取。

提示：分频档位的选择要和喂狗周期一起定。想在低功耗场景下用很长的超时，直接选 /16384，别靠反复改重载值凑——重载值改动需要走完整的两步事务，频繁改既费事又增加出错面。

4.4 运行时改重载值、停用与重新使能

运行中改重载值和初始化时改 CON0 是同一套流程：密码访问 + 修改访问。区别只在于参数是运行期算出来的，而且改完之后要立刻更新软件侧的影子变量，否则下一次密码访问就会因为密码不一致触发 AE。

停用看门狗走的是 CON1 里的禁用请求位，同样受 ENDINIT 保护。停用之后 WDTxSR 里的使能状态位会反映出来，读一下确认再往下走。要重新使能，把禁用位清掉，然后按正常流程喂一次狗。

有个细节值得单独提：应用笔记里提到解锁限制位（UR）的作用——检测到未喂狗安全报警之后，用它阻止看门狗重载，确保未处理的报警一定会引起 SMU 的硬件响应。这个位在安全相关的项目里建议打开，它能防止"报警发生了但被后续喂狗掩盖过去"的情况。代价是一旦触发就没法软恢复，只能走复位，所以调试阶段可以先关掉，量产配置里再打开。

4.5 喂狗点放在哪里：主循环、定时器中断还是任务钩子

这是设计层面最容易被轻视、出问题又最难查的一环。放在主循环里，好处是能真实反映主循环有没有卡死，坏处是任何一次耗时操作都可能造成误复位。放在定时器中断里，周期稳定，但监控意义就退化了——中断还在跑，说明不了主任务是否正常。

比较务实的做法是分层：CPU 看门狗用任务钩子喂，每个关键任务执行到自己的检查点时打一次卡，多个任务全部打卡才真正触发喂狗；安全看门狗用固定周期的定时器喂，同时用检查访问在中间点做序列校验。这样任何一个任务卡住，组合条件就不成立，看门狗自然超时。

多核场景下还要加一条：喂狗序列必须保证原子性。两个核同时操作各自的 CON0 没问题，但如果安全看门狗被多个核碰，就必须约定唯一 owner，其它核通过 IPC 请求服务，而不是自己去写寄存器。

5. 避坑与排查：五条从现场带回来的记录

这一章全部是现象级的记录，每一条都能对应到具体的寄存器位。遇到问题按这个顺序过一遍，通常十分钟内能定位。

5.1 现象：喂狗函数返回成功，但 WDTxSR.AE 被置起

原因几乎总是密码字段拼错。要么是 PW[7:2] 忘了取反，要么是 bit[1:0] 写成了 00B 或者 10B。还有一种情况是 REL 字段填了"新值"而不是"当前值"——在未启用时间检查时，密码访问阶段的 bit[31:16] 必须写当前重载值，写了目标值一样判定为访问错误。

解决方式是把拼装过程拆成独立的纯函数，输入当前密码和当前重载值，输出 32 位写值，然后拿这个函数做单元测试，把默认密码 00000000111100B 代进去逐位核对。别在生产代码里现场拼位域。

5.2 现象：清了 ENDINIT，写受保护寄存器却没反应

原因有两个常见分支。一是没等 ENDINIT 真正生效就去写，硬件清这一位需要时间，中间那段窗口里写操作会被静默丢弃。二是 CPU 不在超级管理员模式，条件不满足，写操作同样被忽略且不报错。

解决办法固定成两步：清 ENDINIT 之后立刻回读该位，确认为 0 再往下走；同时在初始化阶段确认特权级别，别在用户模式下调试底层寄存器。这个回读操作开销极小，但能挡掉一大类"配置不生效"的玄学问题。

5.3 现象：接上调试器单步，程序必定复位

原因是调试覆盖机制。芯片里有一个调试模块可以在调试状态下覆盖所有看门狗的 ENDINIT 控制，相关状态位置起时，全部 ENDINIT 保护被停用；清 0 时控制权回到看门狗。调试器 halt 住 CPU 的时候看门狗仍在计数，单步几步就超时了。

解决办法是调试阶段用调试器的看门狗暂停支持，或者临时把超时时间拉到最长档。但要注意，暂停支持只是调试便利，不能作为量产配置的一部分——真机上没有调试器，行为完全不一样。

5.4 现象：启用时间检查后随机报警，复现困难

原因通常是容差 TCT 设得太紧，或者喂狗点离读取 TIM 的位置太远。中断抢占、缓存未命中、总线等待都会让实际耗时抖动，估值漂出窗口就报警。另一种可能是喂狗序列被高优先级中断打断，密码状态机和硬件错位。

解决办法是先关掉时间检查，用调试变量把每次喂狗时的 TIM 和软件估值都记下来，跑一段时间看抖动分布，再据此定 TCT。喂狗序列本身收进临界区，确保中间不被打断。这套流程走一遍要花小半天，但比后面靠猜要快得多。

5.5 现象：心跳引脚上量不到波形

心跳功能的原理是把 WDTxCON0.LCK 的状态送到外部引脚，因为 LCK 只在服务期间（密码访问和修改访问之间）变低，所以会形成一个周期性脉冲，可以给外部监控器做"看门狗还活着"的指示。量不到波形，先查引脚复用配置有没有切到看门狗功能，再查解锁限制位 UR 是否被置起——UR 打开时，任何其它 SMU 安全报警状态都会阻止看门狗运行，心跳自然就停了。

还有一个文档层面的坑：应用笔记里列出的心跳引脚映射中，WDT0LCK 和 WDT1LCK 标了同一个引脚号。实际硬件上两个看门狗不可能共用一个物理引脚同时输出，具体映射必须以对应型号的引脚表和用户手册为准，别直接照抄笔记里的表。

6. 进阶：把看门狗变成可观测的安全机制

到这一步，看门狗已经能正常工作了，但"能工作"和"能定位问题"是两回事。真正让我改变做法的，是一次现场故障：设备偶发复位，日志什么都没有，最后靠 WDTxSR 里一个 AE 标志才定位到是某段代码在中断上下文里误碰了 CON0。从那以后，我在每个项目里都会加一层故障快照。

具体做法是在 SMU 报警路径上挂一个 NMI 处理入口，进去第一件事不是复位，而是把关键状态刷到非易失存储里：WDTxSR 全字、WDTxCON0 的当前值、出问题的核 ID、以及一个软件维护的阶段计数器。有了这几样，八成以上的看门狗类故障能在一次复现内定位。代价是复位会晚几百微秒，对绝大多数系统可以接受。

验证环节建议做三个主动注入用例，每次改完看门狗配置都跑一遍。

第三个用例特别值得做。它能同时验证时间检查是否真的在起作用，以及 TCT 的容差设得是否合理。我一般会从 1.5 倍正常抖动量开始往下收，收到刚好不误报为止，再往上留 20% 余量。

另一个值得提前规划的点是心跳引脚的用途。它不只是给外部监控器看的，也可以反过来作为调试手段：示波器抓这个引脚，周期是否稳定、有没有突然消失，比读寄存器直观得多。外部监控器的超时时间要设得比内部看门狗长一点，形成两级兜底——内部先报，外部后动，中间留出记录现场的时间。

最后说个习惯。我现在每次动看门狗相关配置，不管是改分频、改重载值还是切密码模式，都会强制走一遍"清 ENDINIT → 回读确认 → 改寄存器 → 置回 ENDINIT → 读 SR 存档"这五步，哪怕只改一个位。这套动作看起来啰嗦，但它把两类最容易翻车的问题——保护窗口没打开就写、访问错误被忽略——都挡在了前面。看门狗这东西平时不声不响，真出问题时又很难给你第二次机会，多花这几分钟很值。希望帮到你。

本文还有配套的精品资源，点击获取