干嵌入式最怕的一种状态，就是板子在现场跑着跑着突然死了，不是一两次，而是偶发性的，代码看了好几遍却找不到规律。我刚开始做项目那会儿，第一反应是怀疑电源、怀疑晶振、怀疑通讯被干扰，后来才发现这些问题都可以用一个硬件手段兜住——STM32 看门狗。看门狗说白了就是一块硬件定时器，程序必须在约定时间内定时“喂”它一次，否则它就认为系统已经失控，直接把芯片拉回复位状态。用得好，它能让无人值守的设备在死机后自动恢复正常，是产品可靠性的最后一道防线。这篇就把独立看门狗 IWDG 和窗口看门狗 WWDG 从原理到项目落地一次讲清楚，让你能在自己的工程里直接抄作业。1. 项目背景：程序“卡死”为什么不能只靠人工重启在嵌入式产品里，“死机”是绕不开的坎。任何软件和硬件都有出错的概率，而且越复杂的系统越容易在极端情况下出问题——电压跌落、高频干扰、看门狗寄存器被误写、内存碎片导致堆栈异常。这些情况平时不发生，一旦发生，程序就可能在某个地方“挂住”，不响应按键、不上报数据、不刷新外围设备，表现得像一块砖头。开发板死机了可以随时按复位键，可产品交付到现场之后，谁天天去按复位？所以工程师在设计阶段就得想清楚：系统一旦失控，靠什么在无人干预的情况下自救。这个“靠自己自救”的工具，就是 STM32 看门狗。它是一路独立的硬件定时器，不受程序正常流程的控制，程序必须在设定周期内主动去“喂”它，也就是把计数器重新装满。如果程序因为某种原因停止喂狗，计时器一路递减到零，芯片就被强制复位，从复位向量重新执行一遍启动流程。用大白话说，它就像一个专门盯着程序是否喘气的监工，你隔一阵子没动静，它就一脚把系统踢回起点，让程序重新来过。看门狗不解决“为什么会死机”，它解决的是“死后能不能自己活过来”。写这篇文章的起因，是我最近在帮同事排查一台现场设备的偶发死机问题。现象很典型：设备工作到某个阶段就暂停响应，通讯超时后上位机报错，人工重启后又恢复正常。问题表象千奇百怪，但排查思路就一条——先确认看门狗有没有正确配置和工作，再往更深层查逻辑 Bug。结果发现那台机器压根没开看门狗，裸奔跑在生产现场。补上配置并留出合适余量之后，设备才真正稳定下来。想提醒刚入门的朋友：不管你做的项目是控制板、采集器还是某个有意思的 DIY，STM32 看门狗都应该和时钟配置一样，列入上电初始化的一部分。2. 方案选型：IWDG 与 WWDG 到底怎么选2.1 独立看门狗 IWDG：简单粗暴的兜底方案IWDG 的全称是 Independent Watchdog，独立看门狗。它最大的特点就是“独立”——有自己独立的时钟源 LSI，也就是芯片内部的低速时钟，哪怕主时钟 HSE 出问题了，它的计数还在走。这个特征在实际工程中非常关键，因为很多死机场景恰恰就是主时钟被干扰或者配置出错造成的，如果看门狗本身依赖同一个时钟源，那就等于灾难时监工自己也失联了，失去意义。IWDG 的工作方式也简单：从启动时刻开始，内部计数器不断递减，减到 0 触发系统复位。我们可以给它配置预分频系数和重装载值，决定“最长多久必须被喂一次”。它没有窗口的概念，只要还没减到零，喂狗就能重新装载，所以代码里不用太精确地安排喂狗时机，主循环里定时喂一次就可以。缺点是它只能判断“超时没喂”，判断不了“程序是否按正常节奏跑”，因为哪怕程序已经进入某个错误分支，只要还在循环里喂狗，它照样不出手。因此 IWDG 适合做保底，不适合做严格的任务时序监督。2.2 窗口看门狗 WWDG：喂早了也不行WWDG 全称是 Window Watchdog，窗口看门狗。它和 IWDG 最大的区别是增加了一个“窗口”区间，喂狗必须落在设定窗口内。窗口由两个边界组成：最晚边界是计数器减到 0x3F，一旦减到就复位；最早边界是窗口寄存器 W 的值，如果在计数器还没减到窗口值之前就去喂狗，同样会触发复位。说白了，IWDG 是“你不喊我我就重启”，WWDG 是“你必须在我规定的时间段里喊我，早了晚了都不行”。正是这个“喂早了也不行”的特性，让 WWDG 能监督程序的执行节奏，而不只是死循环。比如说一个主循环任务，正常执行周期是 20ms，如果因为某个功能被跳过或者执行异常，循环跑得太快，它在错误的窗口时间内喂狗，系统就会复位。这对那些对处理周期有严格要求的控制类项目很有价值。但 WWDG 的时钟来自 APB 总线，不是独立时钟源，如果主时钟本身乱了，它的判断也会受牵连，所以它更适合做“节奏监督”，不适合单独承担“故障兜底”。2.3 组合使用：一个项目可不可以“放两条狗”我实际项目里的做法，很多时候是两条狗一起用：IWDG 作为绝对的生存保障，超时时间设得比较宽，专门对付程序整体失控；WWDG 用来监控任务循环是否在正常周期内运行，超时或者过早都会复位。这种“双看门狗”方案在一些控制器上还比较常见，因为两条狗监督的维度不同，互相之间不会有冲突。需要注意，双狗一起上对代码结构要求更高。喂狗的位置要分配清楚，不能把两个喂狗动作放在同一个地方，否则 WWDG 就失去了监督节奏的意义。另外，WWDG 的窗口值要根据任务最坏情况来留余量，不能算得刚好，因为任务里一旦出现某个分支耗时变长，就会从“喂得太早”变成“喂得太晚”。如果拿不准 WWDG 用来监督什么，宁可只上 IWDG，也别为了功能堆功能把人搞懵。3. IWDG 独立看门狗的原理与超时计算3.1 从寄存器角度看 IWDG 的工作机制IWDG 在 STM32 内部由四个核心寄存器控制：关键字寄存器 IWDG_KR、预分频寄存器 IWDG_PR、重装载寄存器 IWDG_RLR、状态寄存器 IWDG_SR。理解这四个寄存器，就算不依赖任何固件库，也能把逻辑摸透。先看 IWDG_KR。它是一个 16 位的“魔法数字”入口，往里面写不同的值代表不同操作：写 0x5555 打开对 PR 和 RLR 的写保护，也就是允许修改配置；写 0xAAAA 把 RLR 中的值重新装载进计数器，这个过程叫“喂狗”或者“刷新”；写 0xCCCC 启动看门狗。一旦写入 0xCCCC 启动之后，IWDG 就无法被软件停止，只有系统复位才能让它重新进入所谓的“初始化”过程。PR 和 RLR 决定了看门狗的超时时间。PR 的取值对应一个分频系数，比如 PR=0 对应分频系数 4，PR=4 对应 64，PR=6 对应 256。RLR 是一个 12 位寄存器，取值范围 0 到 4095。递减计数器每减少一次需要消耗的 LSI 时钟周期，就等于“分频系数”，计数器从 RLR 值减到 0 的总时间，就是看门狗超时。整个计算过程我用一个具体例子展开。3.2 超时时间怎么算：一个带数值的实操案例先明确 LSI 的典型频率。STM32 大部分系列的内部 RC 时钟 LSI 典型值在 40kHz 附近，但注意这个数值精度很低，全温区范围内可能偏差到百分之二三十。我用 40kHz 这个典型值做计算：超时时间 = (分频系数 × RLR 重装载值) / LSI 频率如果 PR 配置成分频系数 64，RLR 配置成 625，那么超时时间就是：64 × 625 / 40000 = 1 秒也就是说，如果程序超过 1 秒没有喂狗，芯片就会被复位。这个时间长度很适合多数主循环在几十毫秒级别的应用，主流程跑一圈的时间远小于超时时间，喂狗非常从容。再举个例子，如果把 PR 配置成 256 分频，RLR 配到最大 4095，那超时时间是：256 × 4095 / 40000 = 26.2 秒这种长超时偶尔会在低功耗产品里用到，因为系统大部分时间在睡眠，唤醒周期很长，喂狗节奏也很慢。下面这张表列出常见 PR 值下 RLR 最大能支撑的近似超时，方便配置时快速参考：PR 寄存器值分频系数LSI=40kHz 时最大超时（RLR=4095）04约 0.41 秒18约 0.82 秒216约 1.64 秒332约 3.28 秒464约 6.55 秒5128约 13.1 秒6256约 26.2 秒这里需要特别提醒一点：LSI 不是精密晶振，它只是一个片上 RC 振荡器。同一片芯片在不同温度下，LSI 频率可能从 30kHz 漂到 50kHz。如果按照 40kHz 算出 1 秒超时，实际最差情况可能只有 0.65 秒；反过来说，如果你在超时还剩 100ms 时才喂狗，某次温度或者电压波动会让狗提前发威。所以我在配置时从来不会把喂狗周期压到接近超时上限，一般至少留出两倍以上的安全余量。比如超时设 1 秒，喂狗周期尽量控制在 200ms 到 500ms 之间，给干扰和程序偶然抖动都留出空间。3.3 喂狗代码的位置和写法配置好超时之后，代码里的关键就是找到合适的喂狗时机。我见过不少新人在所有地方都喂狗，中断里喂、定时器里喂、主循环里喂，这样看起来“保险”，实际上反而掩盖了问题。因为如果每个中断都在喂狗，主程序就算死在某处，中断照样有可能运行，该起作用时它起不到作用。比较稳妥的做法是：只在主循环的任务调度末尾喂一次 IWDG，并且确保主循环内任何一个分支的执行时间都不要超过喂狗周期。如果一个任务里出现耗时的阻塞等待，比如串口等待应答的死循环，可能整个主循环被卡住，喂狗自然就停了，看门狗就能把这个程序里的卡死点暴露出来。再配合后面的复位源检测，你就能知道板子是被看门狗复位，而不是纯粹掉电复位。这个检测点后面单开一节写。4. WWDG 窗口看门狗的原理与窗口设计4.1 窗口看门狗为什么会有“两个边界”WWDG 的计数器和 IWDG 不同，它不是从大往小减到 0，而是在 0x40 到 0x7F 这个范围内工作。0x7F 是最大值，代表刚启动或者刚被喂过，计数器从 0x7F 开始一点点往下降，降到 0x3F 就产生系统复位。注意这里有个非常容易踩的坑：它复位不是因为计数到 0，而是计数到 0x40 再往下走一步，跌进 0x3F，就会复位。窗口寄存器 W 的作用是设置“你可以喂狗的最早时刻”。在计数器从 0x7F 降到 W 之前，你如果尝试喂狗，硬件会直接复位。所以喂狗实际被限制在一个区间内：计数器值必须小于等于 W，同时还没到 0x40。这个区间就是窗口。简单理解：窗口上边界 W 控制“喂太早报错”，下边界 0x40 控制“喂太晚报错”，中间这段才是安全喂狗区。窗口值越大，允许你最早喂狗的时刻越早；窗口值越小，安全区间越窄，越难掌握。为什么要搞这么麻烦？因为 WWDG 想防的一种故障是“程序跑飞但还在喂”。举例来说，某个定时器中断被意外反复触发，主程序在错误的时间点喂狗，如果用的 IWDG，它根本分辨不出来，照样放行；用 WWDG 就能把这种异常节奏逮住。4.2 窗口参数的公式和计算实例WWDG 的时钟来自 APB1 总线，具体计数周期取决于 APB1 频率和 WWDG 内部的可选预分频 WDGTB。STM32 参考手册里通常给出的计算公式是：超时时间 = 4096 × 2^WDGTB × (T[5:0] + 1) / Fpclk1其中 T[5:0] 是从 WWDG_CR 读到的低 6 位计数值，就是递减计数器当前值。如果 PCLK1 为 36MHz，WDGTB=00，T[5:0]=0x3F（即 63），那么超时：4096 × 1 × (63+1) / 36000000 = 262144 / 36000000 ≈ 7.28ms若 WDGTB=01，也就是内部预分频 2，同样的 T 值下周期翻倍，约 14.56ms。这个时间窗口非常短，所以 WWDG 通常用来监督毫秒级的快速循环，不太适合当成普通的秒级看门狗用。窗口值 W 的设定需要结合任务主循环的真实耗时。比如你的主循环最快路径耗时 5ms，最慢路径耗时 8ms，PCLK1 算出的满周期是 10ms，那窗口值可以选一个让喂狗只能在计数器降到 6~9ms 这个区间内进行。具体数值根据寄存器位宽来算，先把窗口值换算成对应的计数值偏移，再通过实际程序跑起来后观察喂狗时刻对应的计数值来确定。工程上我建议先给 W 设一个大值（比如 0x60），跑起来用示波器或调试器观察实际喂狗时刻的计数值，再逐步收紧。4.3 搭配 EWI 中断，但别在中断里喂狗WWDG 还有一个可利用的功能是早期唤醒中断 EWI。当计数器降到 0x40 时，硬件可以触发一次中断，让你在系统即将被复位之前有一小段“善后”时间。这个中断不是用来确保你不复位的，而是给你机会把关键数据保存到备份寄存器或者把故障标志记录下来，方便复位后定位问题。很多新手容易犯的错是：在 EWI 中断里直接喂狗，以为这样最及时。实际这么做会让 WWDG 完全失去监督主循环的作用——中断的优先级通常设置得很高，主循环卡死也照样能被中断打断，中断里一喂狗，看门狗就永远不咬人了。我在项目里一般只在中断里置一个标志位，主循环读到这个标志后再执行真正的喂狗动作和故障处理。这样既能保证喂狗行为发生在主流程的节奏上，也保留了故障预处理能力。5. 工程落地：从 CubeMX 到代码实现5.1 配置工具里的设置要点假设你用的是 STM32CubeMX，IWDG 配置项通常在 Peripherals 下的 IWDG 一栏。开启 IWDG 后，需要填预分频系数和重装载值，并确认 LSI 时钟已经使能。CubeMX 会根据你填的值自动计算一个超时时间范围，但注意它计算时用的频率值是以项目时钟树为基础的默认值，如果你用的芯片 LSI 不是 40kHz，要根据芯片手册手动修正预期结果。WWDG 的配置项在 WWDG 一栏，需要填预分频、窗口值和计数器初始值。CubeMX 同样会给出一个估算范围。它生成的初始化代码用的是 HAL 库，如果你更习惯标准外设库或者寄存器操作，按原理自己写也不难。工具生成代码只是起点，真正的工程细节还是在喂狗位置和时机控制上。5.2 IWDG 初始化与喂狗的代码参考下面这段用一个寄存器操作风格来演示 IWDG 核心流程，逻辑在任何 STM32 系列上都通用：void IWDG_Init(uint16_t reload) { /* 第一步：解除写保护，让 PR 和 RLR 可以被修改 */ IWDG->KR = 0x5555; /* 第二步：配置预分频系数为 64，重装载值为传入参数 */ IWDG->PR = 4; /* PR=4 对应分频系数 64 */ IWDG->RLR = reload; /* 第三步：把 RLR 的值预装载到计数器 */ IWDG->KR = 0xAAAA; /* 第四步：启动看门狗，启动后无法再关闭 */ IWDG->KR = 0xCCCC; } void IWDG_Feed(void) { IWDG->KR = 0xAAAA; }如果用的是 HAL 库，初始化部分长这样：IWDG_HandleTypeDef hiwdg; hiwdg.Instance = IWDG; hiwdg.Init.Prescaler = IWDG_PRESCALER_64; hiwdg.Init.Reload = 625; HAL_IWDG_Init(&hiwdg);喂狗时调用HAL_IWDG_Refresh(&hiwdg)就行。HAL 库本质上就是把上面那几步寄存器操作包装成了函数，理解底层后去哪儿都能写，不会被某个库限制住。有一点需要注意：在修改 PR 和 RLR 之后，最好等待 IWDG_SR 中对应的更新状态位清零再进行下一步，尤其是紧接着又要启动或者写入时。虽然多数情况下很快，但严谨的初始化流程要把状态判断写进去，否则在极端情况下可能出现配置值未生效的情况。5.3 WWDG 初始化代码与中断示例WWDG 的初始化同样可以只用寄存器，下面以窗口值 0x50、预分频 1 为例：void WWDG_Init(void) { /* 启动窗口看门狗，计数器从 0x7F 开始 */ WWDG->CR = 0x7F; /* 设置预分频和窗口值 */ WWDG->CFR = (0 << 7) | 0x50; /* 使能 EWI 中断 */ WWDG->CFR |= (1 << 9); /* 具体位位置以芯片手册为准 */ /* 置 WDGA 位启动看门狗 */ WWDG->CR |= (1 << 7); }注意上面代码里的位偏移必须对照你所用芯片的参考手册，STM32 不同系列在 CFR 寄存器位定义上不完全一样。我在这里特意不写死某一种宏定义，是为了提醒你：看门狗相关的寄存器虽然原理统一，但位布局在不同系列间会有差异，特别是从 F1 换到 F0 或 G0 时一定要重新核对。HAL 库的方法更省心：WWDG_HandleTypeDef hwwdg; hwwdg.Instance = WWDG; hwwdg.Init.Prescaler = WWDG_PRESCALER_1; hwwdg.Init.Window = 0x50; hwwdg.Init.Counter = 0x7F; hwwdg.Init.EWIMode = WWDG_EWI_ENABLE; HAL_WWDG_Init(&hwwdg);EWI 中断的服务函数里，我的习惯是只清标志、置全局标志，不在中断里喂狗：void WWDG_IRQHandler(void) { if (WWDG->SR & WWDG_SR_EWIF) { WWDG->SR = 0; g_wwdg_ewi_flag = 1; } }主循环的任务最后一段再检查这个标志，决定是否执行喂狗以及是否记录故障信息。5.4 通过复位源判断“到底是谁咬的”收到客户反馈“板子老自动重启”时，第一步不是改代码，而是读出复位源。STM32 的复位控制寄存器里存了本次复位的原因：外部复位、上电复位、IWDG 复位、WWDG 复位还是独立窗口引脚复位。以最常见的串口打印为例，在系统初始化最前面读取并打印：if (RCC->CSR & RCC_CSR_IWDGRSTF) { /* IWDG 引起的复位 */ printf("Reset by IWDG\n"); RCC->CSR |= RCC_CSR_RMVF; /* 清除复位标志 */ } else if (RCC->CSR & RCC_CSR_WWDGRSTF) { /* WWDG 引起的复位 */ printf("Reset by WWDG\n"); RCC->CSR |= RCC_CSR_RMVF; }这个功能在联调时几乎必用。之前我在某块板子上调试，程序不定时复位，一直怀疑是电源干扰，后来把复位源打印加进去后，发现复位标志居然每次都落在 IWDG 上，说明问题出在某个任务阻塞了主循环，导致喂狗超时。顺着这个线索很快就定位到了任务里的一个 while 等待循环，问题才真正解决。6. 排查实录：看门狗相关的常见坑与思路6.1 观察复位波形是最高效的第一步遇到看门狗引起的问题，我习惯先把示波器接在芯片的 NRST 复位引脚上观察。如果复位是周期性的，波形间隔基本等于你设置的看门狗超时时间，那基本可以断定是看门狗在反复咬。这种周期要么是程序从未启动喂狗，要么是超时配置与实际喂狗周期不匹配。如果波形间隔不确定，忽长忽短，那就更可能是程序在不同任务分支里卡死，导致喂狗时间不固定。此时我会上位机打开串口，把进入任务的日志打出来，看最后一条卡在哪个模块。结合复位源判断，基本能把范围缩小到某个任务函数。6.2 喂狗周期紧贴着超时时间这是非常常见的配置错误。有人算好超时 1 秒，然后每 900ms 喂一次，觉得没问题。要知道 LSI 是个精度并不高的 RC 振荡器，它的实际频率可能偏离典型值百分之二三十，也就是说 1 秒的超时在高温下可能缩水到 0.7 秒。如果喂狗周期刚好 0.9 秒，那就可能出现“明明程序正常，却反复被复位”的怪现象。我给这类问题的排查建议是：先把喂狗周期改成超时时间的一半以下，排除频率漂移的影响；如果复位消失，说明之前就是余量不够。然后再根据实际现场温度逐步调整到合适的值。6.3 调试时一停下就复位用调试器在线调试时，只要在代码里打了断点或者暂停运行，喂狗就停了，看门狗可能马上咬人。不同 IDE 和调试器对这种情况的处理方式不同，有的会在连接调试器时自动停止看门狗，有的不会。更可靠的方案是调试版固件里通过宏控制看门狗的启用。比如在产品化版本里初始化看门狗，在 DEBUG 宏开启时跳过初始化：#ifndef DEBUG_ENABLE IWDG_Init(625); #endif这样调试版完全不受看门狗干扰，生产版保留看门狗功能。还有一类 ST 系列芯片提供 DBGMCU 寄存器，可以在调试模式下停止 IWDG/WWDG 计数，适合那些必须带着看门狗一起联调的场景。但我不建议长期依赖这个功能，因为它容易掩盖超时问题。6.4 低功耗模式下的“隐形咬人”有的项目会进入 STOP 或者 STANDBY 低功耗模式。STANDBY 模式下，大部分时钟会停，IWDG 能不能继续跑取决于芯片具体实现。不少 STM32 在 STANDBY 下 LSI 仍可运行，看门狗就会继续计数，如果唤醒周期很长，程序还没来得及喂狗就被复位，表现为“睡眠后自动重启”。处理方式通常有两种：一是在进低功耗前根据产品需求决定是否关闭 IWDG，前提是开发阶段确认产品允许；二是确保唤醒事件的周期小于看门狗超时，并且在唤醒后的第一时间及时喂狗。这里要特别小心，有些芯片关闭 IWDG 的唯一方式是复位，所以功耗策略需要提前规划，不能只靠软件一行命令随口关。6.5 窗口值设置不当导致“喂啥都复位”WWDG 配置里，窗口值 W 如果设得过大或者过小，都会让系统陷入怪圈。W 设得过大意味着很早就允许喂狗，喂狗容易落到窗口外；W 设得过小意味着喂狗窗口被压缩，主循环稍有抖动就喂晚了。实践中遇到“一喂狗就复位”的情况，十有八九是 W 的值和代码实际喂狗时机不匹配。调试 WWDG 时，我常用的办法是先把 W 设成 0x7F，也就是把最早喂狗时间放宽到启动时刻，先让系统不咬人；然后程序正常运行，在喂狗点把此时 WWDG_CR 的计数值打印出来，根据这个实测值反推合适的 W。这是最直接的标定思路，比拍脑袋算寄存器值靠谱得多，也适合拿到现场去针对不同工况调整。7. 一点个人建议如果让我给刚接触看门狗的人一个最精简的结论：先把 IWDG 用好、用稳定，再去考虑 WWDG；喂狗的动作永远放在主循环里，别贪图方便丢进中断；超时时间宁可设宽一点也别贴着 LSI 精度赌运气；每个板子的第一版固件都加上复位源打印。做到这几点，大部分“偶发死机”的疑难杂症都能快速收敛。我自己每个项目都养成了习惯：复位源检测放在系统上电的第一个函数里，喂狗时间间隔做成可配置项，并且把喂狗心跳映射到一个空闲引脚上方便示波器观察。这些小动作初看费事，真正到了现场排查问题时，能省下大半天功夫。看门狗这东西，看起来只是一个不起眼的硬件定时器，但它决定了你的设备在无人值守时是“一次宕机等人工”还是“自动恢复继续跑”。多花一点时间把它配置扎实，后面整个生命周期都会轻松很多。
干嵌入式最怕的一种状态，就是板子在现场跑着跑着突然死了，不是一两次，而是偶发性的，代码看了好几遍却找不到规律。我刚开始做项目那会儿，第一反应是怀疑电源、怀疑晶振、怀疑通讯被干扰，后来才发现这些问题都可以用一个硬件手段兜住——STM32 看门狗。看门狗说白了就是一块硬件定时器，程序必须在约定时间内定时“喂”它一次，否则它就认为系统已经失控，直接把芯片拉回复位状态。用得好，它能让无人值守的设备在死机后自动恢复正常，是产品可靠性的最后一道防线。这篇就把独立看门狗 IWDG 和窗口看门狗 WWDG 从原理到项目落地一次讲清楚，让你能在自己的工程里直接抄作业。1. 项目背景：程序“卡死”为什么不能只靠人工重启在嵌入式产品里，“死机”是绕不开的坎。任何软件和硬件都有出错的概率，而且越复杂的系统越容易在极端情况下出问题——电压跌落、高频干扰、看门狗寄存器被误写、内存碎片导致堆栈异常。这些情况平时不发生，一旦发生，程序就可能在某个地方“挂住”，不响应按键、不上报数据、不刷新外围设备，表现得像一块砖头。开发板死机了可以随时按复位键，可产品交付到现场之后，谁天天去按复位？所以工程师在设计阶段就得想清楚：系统一旦失控，靠什么在无人干预的情况下自救。这个“靠自己自救”的工具，就是 STM32 看门狗。它是一路独立的硬件定时器，不受程序正常流程的控制，程序必须在设定周期内主动去“喂”它，也就是把计数器重新装满。如果程序因为某种原因停止喂狗，计时器一路递减到零，芯片就被强制复位，从复位向量重新执行一遍启动流程。用大白话说，它就像一个专门盯着程序是否喘气的监工，你隔一阵子没动静，它就一脚把系统踢回起点，让程序重新来过。看门狗不解决“为什么会死机”，它解决的是“死后能不能自己活过来”。写这篇文章的起因，是我最近在帮同事排查一台现场设备的偶发死机问题。现象很典型：设备工作到某个阶段就暂停响应，通讯超时后上位机报错，人工重启后又恢复正常。问题表象千奇百怪，但排查思路就一条——先确认看门狗有没有正确配置和工作，再往更深层查逻辑 Bug。结果发现那台机器压根没开看门狗，裸奔跑在生产现场。补上配置并留出合适余量之后，设备才真正稳定下来。想提醒刚入门的朋友：不管你做的项目是控制板、采集器还是某个有意思的 DIY，STM32 看门狗都应该和时钟配置一样，列入上电初始化的一部分。2. 方案选型：IWDG 与 WWDG 到底怎么选2.1 独立看门狗 IWDG：简单粗暴的兜底方案IWDG 的全称是 Independent Watchdog，独立看门狗。它最大的特点就是“独立”——有自己独立的时钟源 LSI，也就是芯片内部的低速时钟，哪怕主时钟 HSE 出问题了，它的计数还在走。这个特征在实际工程中非常关键，因为很多死机场景恰恰就是主时钟被干扰或者配置出错造成的，如果看门狗本身依赖同一个时钟源，那就等于灾难时监工自己也失联了，失去意义。IWDG 的工作方式也简单：从启动时刻开始，内部计数器不断递减，减到 0 触发系统复位。我们可以给它配置预分频系数和重装载值，决定“最长多久必须被喂一次”。它没有窗口的概念，只要还没减到零，喂狗就能重新装载，所以代码里不用太精确地安排喂狗时机，主循环里定时喂一次就可以。缺点是它只能判断“超时没喂”，判断不了“程序是否按正常节奏跑”，因为哪怕程序已经进入某个错误分支，只要还在循环里喂狗，它照样不出手。因此 IWDG 适合做保底，不适合做严格的任务时序监督。2.2 窗口看门狗 WWDG：喂早了也不行WWDG 全称是 Window Watchdog，窗口看门狗。它和 IWDG 最大的区别是增加了一个“窗口”区间，喂狗必须落在设定窗口内。窗口由两个边界组成：最晚边界是计数器减到 0x3F，一旦减到就复位；最早边界是窗口寄存器 W 的值，如果在计数器还没减到窗口值之前就去喂狗，同样会触发复位。说白了，IWDG 是“你不喊我我就重启”，WWDG 是“你必须在我规定的时间段里喊我，早了晚了都不行”。正是这个“喂早了也不行”的特性，让 WWDG 能监督程序的执行节奏，而不只是死循环。比如说一个主循环任务，正常执行周期是 20ms，如果因为某个功能被跳过或者执行异常，循环跑得太快，它在错误的窗口时间内喂狗，系统就会复位。这对那些对处理周期有严格要求的控制类项目很有价值。但 WWDG 的时钟来自 APB 总线，不是独立时钟源，如果主时钟本身乱了，它的判断也会受牵连，所以它更适合做“节奏监督”，不适合单独承担“故障兜底”。2.3 组合使用：一个项目可不可以“放两条狗”我实际项目里的做法，很多时候是两条狗一起用：IWDG 作为绝对的生存保障，超时时间设得比较宽，专门对付程序整体失控；WWDG 用来监控任务循环是否在正常周期内运行，超时或者过早都会复位。这种“双看门狗”方案在一些控制器上还比较常见，因为两条狗监督的维度不同，互相之间不会有冲突。需要注意，双狗一起上对代码结构要求更高。喂狗的位置要分配清楚，不能把两个喂狗动作放在同一个地方，否则 WWDG 就失去了监督节奏的意义。另外，WWDG 的窗口值要根据任务最坏情况来留余量，不能算得刚好，因为任务里一旦出现某个分支耗时变长，就会从“喂得太早”变成“喂得太晚”。如果拿不准 WWDG 用来监督什么，宁可只上 IWDG，也别为了功能堆功能把人搞懵。3. IWDG 独立看门狗的原理与超时计算3.1 从寄存器角度看 IWDG 的工作机制IWDG 在 STM32 内部由四个核心寄存器控制：关键字寄存器 IWDG_KR、预分频寄存器 IWDG_PR、重装载寄存器 IWDG_RLR、状态寄存器 IWDG_SR。理解这四个寄存器，就算不依赖任何固件库，也能把逻辑摸透。先看 IWDG_KR。它是一个 16 位的“魔法数字”入口，往里面写不同的值代表不同操作：写 0x5555 打开对 PR 和 RLR 的写保护，也就是允许修改配置；写 0xAAAA 把 RLR 中的值重新装载进计数器，这个过程叫“喂狗”或者“刷新”；写 0xCCCC 启动看门狗。一旦写入 0xCCCC 启动之后，IWDG 就无法被软件停止，只有系统复位才能让它重新进入所谓的“初始化”过程。PR 和 RLR 决定了看门狗的超时时间。PR 的取值对应一个分频系数，比如 PR=0 对应分频系数 4，PR=4 对应 64，PR=6 对应 256。RLR 是一个 12 位寄存器，取值范围 0 到 4095。递减计数器每减少一次需要消耗的 LSI 时钟周期，就等于“分频系数”，计数器从 RLR 值减到 0 的总时间，就是看门狗超时。整个计算过程我用一个具体例子展开。3.2 超时时间怎么算：一个带数值的实操案例先明确 LSI 的典型频率。STM32 大部分系列的内部 RC 时钟 LSI 典型值在 40kHz 附近，但注意这个数值精度很低，全温区范围内可能偏差到百分之二三十。我用 40kHz 这个典型值做计算：超时时间 = (分频系数 × RLR 重装载值) / LSI 频率如果 PR 配置成分频系数 64，RLR 配置成 625，那么超时时间就是：64 × 625 / 40000 = 1 秒也就是说，如果程序超过 1 秒没有喂狗，芯片就会被复位。这个时间长度很适合多数主循环在几十毫秒级别的应用，主流程跑一圈的时间远小于超时时间，喂狗非常从容。再举个例子，如果把 PR 配置成 256 分频，RLR 配到最大 4095，那超时时间是：256 × 4095 / 40000 = 26.2 秒这种长超时偶尔会在低功耗产品里用到，因为系统大部分时间在睡眠，唤醒周期很长，喂狗节奏也很慢。下面这张表列出常见 PR 值下 RLR 最大能支撑的近似超时，方便配置时快速参考：PR 寄存器值分频系数LSI=40kHz 时最大超时（RLR=4095）04约 0.41 秒18约 0.82 秒216约 1.64 秒332约 3.28 秒464约 6.55 秒5128约 13.1 秒6256约 26.2 秒这里需要特别提醒一点：LSI 不是精密晶振，它只是一个片上 RC 振荡器。同一片芯片在不同温度下，LSI 频率可能从 30kHz 漂到 50kHz。如果按照 40kHz 算出 1 秒超时，实际最差情况可能只有 0.65 秒；反过来说，如果你在超时还剩 100ms 时才喂狗，某次温度或者电压波动会让狗提前发威。所以我在配置时从来不会把喂狗周期压到接近超时上限，一般至少留出两倍以上的安全余量。比如超时设 1 秒，喂狗周期尽量控制在 200ms 到 500ms 之间，给干扰和程序偶然抖动都留出空间。3.3 喂狗代码的位置和写法配置好超时之后，代码里的关键就是找到合适的喂狗时机。我见过不少新人在所有地方都喂狗，中断里喂、定时器里喂、主循环里喂，这样看起来“保险”，实际上反而掩盖了问题。因为如果每个中断都在喂狗，主程序就算死在某处，中断照样有可能运行，该起作用时它起不到作用。比较稳妥的做法是：只在主循环的任务调度末尾喂一次 IWDG，并且确保主循环内任何一个分支的执行时间都不要超过喂狗周期。如果一个任务里出现耗时的阻塞等待，比如串口等待应答的死循环，可能整个主循环被卡住，喂狗自然就停了，看门狗就能把这个程序里的卡死点暴露出来。再配合后面的复位源检测，你就能知道板子是被看门狗复位，而不是纯粹掉电复位。这个检测点后面单开一节写。4. WWDG 窗口看门狗的原理与窗口设计4.1 窗口看门狗为什么会有“两个边界”WWDG 的计数器和 IWDG 不同，它不是从大往小减到 0，而是在 0x40 到 0x7F 这个范围内工作。0x7F 是最大值，代表刚启动或者刚被喂过，计数器从 0x7F 开始一点点往下降，降到 0x3F 就产生系统复位。注意这里有个非常容易踩的坑：它复位不是因为计数到 0，而是计数到 0x40 再往下走一步，跌进 0x3F，就会复位。窗口寄存器 W 的作用是设置“你可以喂狗的最早时刻”。在计数器从 0x7F 降到 W 之前，你如果尝试喂狗，硬件会直接复位。所以喂狗实际被限制在一个区间内：计数器值必须小于等于 W，同时还没到 0x40。这个区间就是窗口。简单理解：窗口上边界 W 控制“喂太早报错”，下边界 0x40 控制“喂太晚报错”，中间这段才是安全喂狗区。窗口值越大，允许你最早喂狗的时刻越早；窗口值越小，安全区间越窄，越难掌握。为什么要搞这么麻烦？因为 WWDG 想防的一种故障是“程序跑飞但还在喂”。举例来说，某个定时器中断被意外反复触发，主程序在错误的时间点喂狗，如果用的 IWDG，它根本分辨不出来，照样放行；用 WWDG 就能把这种异常节奏逮住。4.2 窗口参数的公式和计算实例WWDG 的时钟来自 APB1 总线，具体计数周期取决于 APB1 频率和 WWDG 内部的可选预分频 WDGTB。STM32 参考手册里通常给出的计算公式是：超时时间 = 4096 × 2^WDGTB × (T[5:0] + 1) / Fpclk1其中 T[5:0] 是从 WWDG_CR 读到的低 6 位计数值，就是递减计数器当前值。如果 PCLK1 为 36MHz，WDGTB=00，T[5:0]=0x3F（即 63），那么超时：4096 × 1 × (63+1) / 36000000 = 262144 / 36000000 ≈ 7.28ms若 WDGTB=01，也就是内部预分频 2，同样的 T 值下周期翻倍，约 14.56ms。这个时间窗口非常短，所以 WWDG 通常用来监督毫秒级的快速循环，不太适合当成普通的秒级看门狗用。窗口值 W 的设定需要结合任务主循环的真实耗时。比如你的主循环最快路径耗时 5ms，最慢路径耗时 8ms，PCLK1 算出的满周期是 10ms，那窗口值可以选一个让喂狗只能在计数器降到 6~9ms 这个区间内进行。具体数值根据寄存器位宽来算，先把窗口值换算成对应的计数值偏移，再通过实际程序跑起来后观察喂狗时刻对应的计数值来确定。工程上我建议先给 W 设一个大值（比如 0x60），跑起来用示波器或调试器观察实际喂狗时刻的计数值，再逐步收紧。4.3 搭配 EWI 中断，但别在中断里喂狗WWDG 还有一个可利用的功能是早期唤醒中断 EWI。当计数器降到 0x40 时，硬件可以触发一次中断，让你在系统即将被复位之前有一小段“善后”时间。这个中断不是用来确保你不复位的，而是给你机会把关键数据保存到备份寄存器或者把故障标志记录下来，方便复位后定位问题。很多新手容易犯的错是：在 EWI 中断里直接喂狗，以为这样最及时。实际这么做会让 WWDG 完全失去监督主循环的作用——中断的优先级通常设置得很高，主循环卡死也照样能被中断打断，中断里一喂狗，看门狗就永远不咬人了。我在项目里一般只在中断里置一个标志位，主循环读到这个标志后再执行真正的喂狗动作和故障处理。这样既能保证喂狗行为发生在主流程的节奏上，也保留了故障预处理能力。5. 工程落地：从 CubeMX 到代码实现5.1 配置工具里的设置要点假设你用的是 STM32CubeMX，IWDG 配置项通常在 Peripherals 下的 IWDG 一栏。开启 IWDG 后，需要填预分频系数和重装载值，并确认 LSI 时钟已经使能。CubeMX 会根据你填的值自动计算一个超时时间范围，但注意它计算时用的频率值是以项目时钟树为基础的默认值，如果你用的芯片 LSI 不是 40kHz，要根据芯片手册手动修正预期结果。WWDG 的配置项在 WWDG 一栏，需要填预分频、窗口值和计数器初始值。CubeMX 同样会给出一个估算范围。它生成的初始化代码用的是 HAL 库，如果你更习惯标准外设库或者寄存器操作，按原理自己写也不难。工具生成代码只是起点，真正的工程细节还是在喂狗位置和时机控制上。5.2 IWDG 初始化与喂狗的代码参考下面这段用一个寄存器操作风格来演示 IWDG 核心流程，逻辑在任何 STM32 系列上都通用：void IWDG_Init(uint16_t reload) { /* 第一步：解除写保护，让 PR 和 RLR 可以被修改 */ IWDG->KR = 0x5555; /* 第二步：配置预分频系数为 64，重装载值为传入参数 */ IWDG->PR = 4; /* PR=4 对应分频系数 64 */ IWDG->RLR = reload; /* 第三步：把 RLR 的值预装载到计数器 */ IWDG->KR = 0xAAAA; /* 第四步：启动看门狗，启动后无法再关闭 */ IWDG->KR = 0xCCCC; } void IWDG_Feed(void) { IWDG->KR = 0xAAAA; }如果用的是 HAL 库，初始化部分长这样：IWDG_HandleTypeDef hiwdg; hiwdg.Instance = IWDG; hiwdg.Init.Prescaler = IWDG_PRESCALER_64; hiwdg.Init.Reload = 625; HAL_IWDG_Init(&hiwdg);喂狗时调用HAL_IWDG_Refresh(&hiwdg)就行。HAL 库本质上就是把上面那几步寄存器操作包装成了函数，理解底层后去哪儿都能写，不会被某个库限制住。有一点需要注意：在修改 PR 和 RLR 之后，最好等待 IWDG_SR 中对应的更新状态位清零再进行下一步，尤其是紧接着又要启动或者写入时。虽然多数情况下很快，但严谨的初始化流程要把状态判断写进去，否则在极端情况下可能出现配置值未生效的情况。5.3 WWDG 初始化代码与中断示例WWDG 的初始化同样可以只用寄存器，下面以窗口值 0x50、预分频 1 为例：void WWDG_Init(void) { /* 启动窗口看门狗，计数器从 0x7F 开始 */ WWDG->CR = 0x7F; /* 设置预分频和窗口值 */ WWDG->CFR = (0 << 7) | 0x50; /* 使能 EWI 中断 */ WWDG->CFR |= (1 << 9); /* 具体位位置以芯片手册为准 */ /* 置 WDGA 位启动看门狗 */ WWDG->CR |= (1 << 7); }注意上面代码里的位偏移必须对照你所用芯片的参考手册，STM32 不同系列在 CFR 寄存器位定义上不完全一样。我在这里特意不写死某一种宏定义，是为了提醒你：看门狗相关的寄存器虽然原理统一，但位布局在不同系列间会有差异，特别是从 F1 换到 F0 或 G0 时一定要重新核对。HAL 库的方法更省心：WWDG_HandleTypeDef hwwdg; hwwdg.Instance = WWDG; hwwdg.Init.Prescaler = WWDG_PRESCALER_1; hwwdg.Init.Window = 0x50; hwwdg.Init.Counter = 0x7F; hwwdg.Init.EWIMode = WWDG_EWI_ENABLE; HAL_WWDG_Init(&hwwdg);EWI 中断的服务函数里，我的习惯是只清标志、置全局标志，不在中断里喂狗：void WWDG_IRQHandler(void) { if (WWDG->SR & WWDG_SR_EWIF) { WWDG->SR = 0; g_wwdg_ewi_flag = 1; } }主循环的任务最后一段再检查这个标志，决定是否执行喂狗以及是否记录故障信息。5.4 通过复位源判断“到底是谁咬的”收到客户反馈“板子老自动重启”时，第一步不是改代码，而是读出复位源。STM32 的复位控制寄存器里存了本次复位的原因：外部复位、上电复位、IWDG 复位、WWDG 复位还是独立窗口引脚复位。以最常见的串口打印为例，在系统初始化最前面读取并打印：if (RCC->CSR & RCC_CSR_IWDGRSTF) { /* IWDG 引起的复位 */ printf("Reset by IWDG\n"); RCC->CSR |= RCC_CSR_RMVF; /* 清除复位标志 */ } else if (RCC->CSR & RCC_CSR_WWDGRSTF) { /* WWDG 引起的复位 */ printf("Reset by WWDG\n"); RCC->CSR |= RCC_CSR_RMVF; }这个功能在联调时几乎必用。之前我在某块板子上调试，程序不定时复位，一直怀疑是电源干扰，后来把复位源打印加进去后，发现复位标志居然每次都落在 IWDG 上，说明问题出在某个任务阻塞了主循环，导致喂狗超时。顺着这个线索很快就定位到了任务里的一个 while 等待循环，问题才真正解决。6. 排查实录：看门狗相关的常见坑与思路6.1 观察复位波形是最高效的第一步遇到看门狗引起的问题，我习惯先把示波器接在芯片的 NRST 复位引脚上观察。如果复位是周期性的，波形间隔基本等于你设置的看门狗超时时间，那基本可以断定是看门狗在反复咬。这种周期要么是程序从未启动喂狗，要么是超时配置与实际喂狗周期不匹配。如果波形间隔不确定，忽长忽短，那就更可能是程序在不同任务分支里卡死，导致喂狗时间不固定。此时我会上位机打开串口，把进入任务的日志打出来，看最后一条卡在哪个模块。结合复位源判断，基本能把范围缩小到某个任务函数。6.2 喂狗周期紧贴着超时时间这是非常常见的配置错误。有人算好超时 1 秒，然后每 900ms 喂一次，觉得没问题。要知道 LSI 是个精度并不高的 RC 振荡器，它的实际频率可能偏离典型值百分之二三十，也就是说 1 秒的超时在高温下可能缩水到 0.7 秒。如果喂狗周期刚好 0.9 秒，那就可能出现“明明程序正常，却反复被复位”的怪现象。我给这类问题的排查建议是：先把喂狗周期改成超时时间的一半以下，排除频率漂移的影响；如果复位消失，说明之前就是余量不够。然后再根据实际现场温度逐步调整到合适的值。6.3 调试时一停下就复位用调试器在线调试时，只要在代码里打了断点或者暂停运行，喂狗就停了，看门狗可能马上咬人。不同 IDE 和调试器对这种情况的处理方式不同，有的会在连接调试器时自动停止看门狗，有的不会。更可靠的方案是调试版固件里通过宏控制看门狗的启用。比如在产品化版本里初始化看门狗，在 DEBUG 宏开启时跳过初始化：#ifndef DEBUG_ENABLE IWDG_Init(625); #endif这样调试版完全不受看门狗干扰，生产版保留看门狗功能。还有一类 ST 系列芯片提供 DBGMCU 寄存器，可以在调试模式下停止 IWDG/WWDG 计数，适合那些必须带着看门狗一起联调的场景。但我不建议长期依赖这个功能，因为它容易掩盖超时问题。6.4 低功耗模式下的“隐形咬人”有的项目会进入 STOP 或者 STANDBY 低功耗模式。STANDBY 模式下，大部分时钟会停，IWDG 能不能继续跑取决于芯片具体实现。不少 STM32 在 STANDBY 下 LSI 仍可运行，看门狗就会继续计数，如果唤醒周期很长，程序还没来得及喂狗就被复位，表现为“睡眠后自动重启”。处理方式通常有两种：一是在进低功耗前根据产品需求决定是否关闭 IWDG，前提是开发阶段确认产品允许；二是确保唤醒事件的周期小于看门狗超时，并且在唤醒后的第一时间及时喂狗。这里要特别小心，有些芯片关闭 IWDG 的唯一方式是复位，所以功耗策略需要提前规划，不能只靠软件一行命令随口关。6.5 窗口值设置不当导致“喂啥都复位”WWDG 配置里，窗口值 W 如果设得过大或者过小，都会让系统陷入怪圈。W 设得过大意味着很早就允许喂狗，喂狗容易落到窗口外；W 设得过小意味着喂狗窗口被压缩，主循环稍有抖动就喂晚了。实践中遇到“一喂狗就复位”的情况，十有八九是 W 的值和代码实际喂狗时机不匹配。调试 WWDG 时，我常用的办法是先把 W 设成 0x7F，也就是把最早喂狗时间放宽到启动时刻，先让系统不咬人；然后程序正常运行，在喂狗点把此时 WWDG_CR 的计数值打印出来，根据这个实测值反推合适的 W。这是最直接的标定思路，比拍脑袋算寄存器值靠谱得多，也适合拿到现场去针对不同工况调整。7. 一点个人建议如果让我给刚接触看门狗的人一个最精简的结论：先把 IWDG 用好、用稳定，再去考虑 WWDG；喂狗的动作永远放在主循环里，别贪图方便丢进中断；超时时间宁可设宽一点也别贴着 LSI 精度赌运气；每个板子的第一版固件都加上复位源打印。做到这几点，大部分“偶发死机”的疑难杂症都能快速收敛。我自己每个项目都养成了习惯：复位源检测放在系统上电的第一个函数里，喂狗时间间隔做成可配置项，并且把喂狗心跳映射到一个空闲引脚上方便示波器观察。这些小动作初看费事，真正到了现场排查问题时，能省下大半天功夫。看门狗这东西，看起来只是一个不起眼的硬件定时器，但它决定了你的设备在无人值守时是“一次宕机等人工”还是“自动恢复继续跑”。多花一点时间把它配置扎实，后面整个生命周期都会轻松很多。