企业官网建设流程全解析

1. 先搞清楚一个反直觉的事实：RP2040 的看门狗一旦开启就关不掉

树莓派 Pico 的 RP2040 内置看门狗（WDT）有一个让很多人措手不及的特性：一旦被使能，就不能被软件禁用，唯一能停掉它的办法是让芯片彻底复位。

很多人从 STM32、ESP32 转过来，习惯性地以为看门狗只是"定时器 + 复位"的组合，想开就开、想关就关。但在 RP2040 上，官方数据手册第 4.8 节写得很明确：写 WDT_CTRL 的 ENABLE 位只有第一次是有效的，之后无论你怎么写这个位，硬件都会忽略。这意味着你没法在运行中用"先关狗、再执行长时间操作、最后再开狗"的思路，这跟你在别的单片机上养成的习惯完全不同。

我当时第一次把 WDT 加进 Pico 项目时，没细看数据手册，想当然地在某个临界区前"暂停"看门狗，结果程序直接反复复位，串口打印出来的日志像是卡在死循环里。排查了大半天才发现，问题不是逻辑跑飞，而是看门狗根本关不掉，某个分支耗时超过了超时阈值，把自己喂了。

这个特性也决定了 RP2040 的 WDT 更适合什么场景：它适合做"最后一道防线"的系统级保护，不适合做"可随意启停的任务级超时管理"。如果你需要的是任务级看门狗，比如某个传感器在 500ms 内必须返回数据，否则就重试，那应该用普通定时器或者软件计数器自己实现，而不是依赖硬件 WDT。

在深入寄存器之前，先把时钟链路摸清楚，因为这直接决定了你配置出来的超时时间到底准不准。

2. 时钟永远没那么准：ROSC 环形振荡器与 WDT 的时间基准

2.1 RP2040 的看门狗不是用系统主频计数的

RP2040 的 WDT 模块有自己独立的时间基准，它不直接用 133MHz 的系统时钟，也不需要 PLL 参与。数据手册里的时钟框图写得很清楚：WDT 的时间基准来自芯片内部的一个低频时钟源，这个时钟源最终由ROSC（Ring Oscillator，环形振荡器）提供。

ROSC 是一个完全集成在芯片内部的 RC 振荡器，不需要外部晶振。它有一个标称工作频率，但实际频率受电压、温度、芯片个体差异的影响比较大。数据手册给的参考值是：经过分频后提供给 WDT 的时钟大致在 200kHz 左右，也就是一个 tick 约 5 微秒。注意"大致"这个词，实际量测你会发现不同板子之间能差出几个百分点。

这个特性带来的直接后果是：你用 WDT_LOAD 寄存器写入的超时计数值，换算成毫秒时只能当作近似值，不能当作精密定时器用。

很多人在论坛上问"为什么我的 Pico 看门狗复位时间比设置的晚了 3%"，这太正常了。ROSC 本来就不是高频晶振那种高精度时基，你不能用 32768Hz 晶振的精度标准去要求它。

2.2 超时时间的估算公式与实测修正方法

RP2040 数据手册给出的 WDT 时钟频率约 200kHz，所以理论上：

• 超时时间（秒） ≈ WDT_LOAD 值 ÷ 200000
• 如果你想让看门狗在约 1 秒后触发复位，WDT_LOAD 就写 200000 左右
• 如果你用 MicroPython 的machine.WDT(timeout=1000)，底层其实也是换算成 tick 计数

但在实际项目中，我建议你不要直接信这个换算。正确做法是：先写一个极短的测试程序，用 GPIO 翻转 + 逻辑分析仪（或者示波器）实测真实复位周期，然后反推你板子上的真实 tick 频率。

具体操作步骤：

1. 初始化一个 GPIO 为输出，在while(1)里翻转。
2. 设置看门狗超时值为一个你估算约 500ms 的值。
3. 板子复位后，GPIO 波形会周期性翻转，相邻复位之间的时间间隔就是实际超时时间。
4. 用实测时间除以写入的 LOAD 值，得到这块板子的真实时钟频率。

我在三块不同渠道买的 Pico 板上测过，真实 WDT 时钟频率在 189kHz 到 211kHz 之间。如果你的超时阈值设置得比较临界，比如正好卡在某个操作耗时的边缘，这个误差可能就是你程序时不时复位一次的元凶。

2.3 为什么官方不把 WDT 时钟引到外部引脚上

这一点也是新手容易产生疑问的地方：既然 ROSC 精度不够，为什么不能像晶振那样给 WDT 一个精准的外部时钟？

答案要从芯片设计角度理解。看门狗的定位是"最恶劣情况下依然能工作的保底机制"。外部晶振可能虚焊、可能受震动失效、可能被软件配置错误关闭。如果看门狗依赖外部时钟，那外部时钟失效时，看门狗也一起失效了，这违背了看门狗的存在意义。

ROSC 的优势在于：它不需要任何外部元件，只要芯片有电，它就能震荡起来。这也意味着即使你的程序把外部 Flash 的时钟搞崩了、把 PLL 配置写错了，WDT 依然能用自己的 ROSC 时间基准独立计数并触发复位。这在量产设备的故障恢复场景里是保命设计。

3. 寄存器级别的拆解：WDT_CTRL、WDT_LOAD、WDT_REASON 到底怎么工作

3.1 寄存器总览与基地址

RP2040 的看门狗外设位于 APB 总线地址空间的0x40058000起始处。模块里一共有 14 个寄存器，但对于日常使用，真正需要关心的只有这几个：

3.2 WDT_CTRL 的位域语义（重点解读）

WDT_CTRL 的 32 位里，真正影响工作行为的只有几个位，但每个位背后都有设计意图：

• bit 31（ENABLE）：写 1 使能看门狗。这个位一旦置 1，硬件层面就不再允许清零。数据手册里特别提示：软件可以在任何时候读这个位来确认看门狗是否在运行，但写 0 不会生效。

• bit 30（RESET）：写 1 会在 2 个时钟周期内强制触发芯片复位。这个位属于"软件主动触发复位"的快捷方式，等于手动扮演"程序跑飞后硬件自动触发复位"的角色。测试代码时如果想模拟看门狗超时场景，不需要干等着计数器走完，直接写这个位即可。

• bit 29（PAUSE_ON_DEBUG）：当调试器通过 SWD 连接，CPU 处于 halt 状态时，如果这个位为 1，则看门狗计数器暂停计数。功能很好理解——你单步调试代码时，不希望看门狗因为 CPU 停着而触发复位把调试会话打断。默认状态下这个位是 1，也就是调试暂停时看门狗默认暂停。但如果你做的是需要严格模拟真实运行环境的调试，记得把这位清 0，否则你调出来的程序时间行为跟实际运行不一致。

• bit 0（TIME_MASK）：用于屏蔽 WDT_TIME 寄存器的更新时间。一般情况下不需要配置，但如果你需要精确定时喂狗，可以让 WDT_TIME 在特定时机更新，避免读到半更新状态的数据。

这里要特别提醒一个结合 PAUSE_ON_DEBUG 的坑：如果你把程序下载到板子上之后没有拔掉 USB 线，但又没有开启调试器连接，PAUSE_ON_DEBUG 位是不生效的，看门狗正常走时。可一旦你打开调试器、进入单步模式，看门狗就暂停了。很多人在调试阶段觉得"我的程序没问题啊，喂狗正常"，一断开调试器跑就疯狂复位，原因就在这——调试态和非调试态的时间行为完全不一样。

3.3 WDT_LOAD 与 WDT_CTRL 配合时的底层动作

WDT_LOAD 寄存器的写入行为有一个细节：写入 WDT_LOAD 的同时，硬件会把计数器的当前值重置为新值，并同时清除超时标志。也就是说，喂狗的操作本质上是重新写了一遍 WDT_LOAD。

从数据手册的寄存器描述里能看到，WDT_LOAD 是 width 24 的寄存器，最大值 0xFFFFFF（约 1677 万）。按 200kHz 折算，最大超时时间约 83 秒。但这个数值是你直接操作寄存器时的上限，MicroPython 和 C SDK 会在上层帮你做防御性检查。

当你把 LOAD 值写入后，内部的计数器开始从 LOAD 值向下递减。当计数减到 0 时，WDT_CTRL 内部的超时标志置位，同时产生一个内部复位信号。注意这里有个很多人没注意到的细节：RP2040 的 WDT 在计数器归零后复位芯片时，不是立即断电式复位，而是经过短暂延迟的内部复位过程。这个延迟在数据手册里没有给出精确数值，实测大约在几十微秒到上百微秒之间，具体取决于 ROSC 当前频率。这个延迟对绝大多数应用没有影响，但在极端时序敏感场景里，比如你同时用 WDT 复位来触发外部硬件重新初始化，需要考虑这个不确定性。

3.4 WDT_REASON 与 SCRATCH 寄存器的黄金组合：复位原因追溯

WDT_REASON 寄存器可以告诉你上一次复位是什么原因触发的。它的 bit 0 表示上电复位（POR），bit 1 表示看门狗复位。但真正实用的是配合 SCRATCH 寄存器使用。

SCRATCH0~7 这一组寄存器是"掉电不清零"的通用存储区。什么概念呢？芯片正常复位（包括看门狗复位）不会清空它们的内容，只有彻底断电（POWER_ON_RESET）才会恢复默认值。利用这个特性，你可以在代码里维护一套"复位原因日志"：

• 每次启动时，先读 WDT_REASON 和一组 SCRATCH 寄存器。
• 如果 WDT_REASON 表明是看门狗复位，就把某个 SCRATCH 值递增 1，记录"看门狗复位次数"。
• 在关键代码路径上，把当前执行到的模块编号写入 SCRATCH0。
• 下次复位后，读 SCRATCH0 就能知道最后一次跑到哪。

这个组合拳在排查"程序到底挂在哪儿"的时候极其好用。我曾经有一个 Pico 做的现场设备，客户报告偶发重启，但复现概率极低。就是在关键函数入口写 SCRATCH 标记，跑了一周后取回设备，读出 SCRATCH0 的值直接锁定了是 Modbus 解析函数的某个分支耗时过长，超出了看门狗阈值。

C SDK 里已经封装了对应的函数，watchdog_get_reason()返回枚举值，底层读的就是 WDT_REASON；watchdog_caused_reboot()是一个更直接的布尔判断。

4. 从代码层面把 WDT 用起来的两种姿势：MicroPython 与 C SDK

4.1 MicroPython：三行代码的事，但别忽略底层换算

MicroPython 的machine.WDT类把寄存器细节封装得很彻底，你只需要：

from machine import WDT wdt = WDT(timeout=3000) # 3秒超时 wdt.feed() # 喂狗

但这里有两个底层机制你需要知道：

第一，timeout是毫秒单位，MicroPython 固件内部会把毫秒数除以"每毫秒 tick 数"得到一个 tick 计数值，写入 WDT_LOAD。如果 timeout 太小（比如小于某个固件设定的最小值），固件会抛ValueError或直接设置成最小值。不同版本的 MicroPython 固件对这个最小值的设定不完全一样，建议不要依赖这个边界行为，应用层就老老实实用 1000ms 以上。

第二，MicroPython 的WDT一旦创建就不可停止，实例销毁也不行，这正是 RP2040 硬件特性的直接体现。我在 Raspberry Pi Pico 官方 MicroPython 环境里实测，wdt = WDT(timeout=3000)之后，如果主程序进入死循环且没有wdt.feed()，大约 3.0~3.1 秒后芯片复位。

MicroPython 里喂狗有个天然的局限：Python 解释器本身的执行效率不稳定。如果你在循环里调用了阻塞式网络请求、文件读写或者较重的计算，解释器被卡住时，即使代码逻辑上"马上就该执行 wdt.feed()"，实际间隔也可能超过预期。所以用 MicroPython 跑 WDT，超时阈值一定要留足余量，我个人的经验是至少是任务最大耗时的 3 倍以上。

4.2 C SDK：watchdog_enable 和 watchdog_update 的使用姿势

C SDK 提供的接口非常直观：

#include "hardware/watchdog.h" // 使能看门狗，超时时间 ms 单位，debug 时是否暂停 watchdog_enable(2000, true); // 喂狗 watchdog_update();

watchdog_enable的第一个参数是毫秒，第二个参数pause_on_debug对应的是 WDT_CTRL 的 PAUSE_ON_DEBUG 位。典型的主循环模式是：

while (1) { // 执行业务逻辑... process_sensor_data(); update_display(); // 在主循环末尾喂狗 watchdog_update(); // 或者如果业务逻辑有多个耗时阶段，每个阶段后喂一次 }

不过这里我要给出一个反直觉的实践建议：不要把喂狗放在主循环末尾就完事。

我见过很多 Pico 项目是"主循环跑一圈、末尾喂一次狗"，结果某个子函数在循环中间跑飞了（比如陷入了一个意外死循环），而主循环末尾的喂狗代码永远执行不到，看门狗确实能触发，但问题在于：你只知道程序卡死了，不知道卡在哪个环节。配合前面说的 SCRATCH 寄存器标记法，喂狗前先把"当前已完成的最后一步"写入 SCRATCH，然后喂狗。这样复位后你能立刻知道程序是死循环在哪个阶段。在 C SDK 里，SCRATCH 寄存器也有现成的封装函数：

watchdog_enable(2000, true); while (1) { watchdog_scratch_write(0, 1); // 标记进入阶段1 process_sensor_data(); watchdog_scratch_write(0, 2); // 标记进入阶段2 update_display(); watchdog_update(); }

芯片复位后，通过watchdog_scratch_read(0)就能读到最后一次写入的数字，直接定位卡死阶段。

4.3 为什么要用 SCRATCH 而不是设一个全局数组

有人会问：我直接用 volatile 全局变量不行吗？不行。普通全局变量活在内存里，程序卡死时它的值会停留在最后一次写入的状态——这一点 SCRATCH 寄存器也能做到。但 SCRATCH 的关键差异是：

• 当程序跑飞导致栈溢出、堆栈覆盖了全局变量区域时，全局变量可能被破坏，SCRATCH 寄存器不占用内存地址空间，不受栈溢出影响。
• 当复位发生时，全局变量会被重新初始化，SCRATCH 寄存器不清零（仅 POR 清零）。

举个例子：程序卡在某个递归函数里导致栈溢出，栈指针一路增长覆盖了你的标记变量，然后看门狗超时复位，启动代码清零 BSS 段，全局变量回到初值。你啥也看不出来。SCRATCH 寄存器直接坐在硬件里，不存在被内存破坏的风险。这也是它被设计出来的本意——提供一个在软件状态崩坏之后仍然可靠的信息载体。

5. 真实踩坑记录：从"偶发复位"到"精确复位原因"的排查链路

5.1 现象描述与初步猜测

去年我做了一个基于 Pico 的数据采集节点，跑 Modbus RTU 从站，同时驱动一个舵机做云台动作。现场反馈设备会偶发重启，没有任何规律。接上串口日志跑本地复现，连续跑两天没出问题，一送到现场几天就复位一次。

最初我的猜测方向是电源问题，因为舵机启动瞬间电流尖峰可能拉低 3.3V，导致芯片掉电复位。查了电源波纹、加了电容，问题依旧。

然后是尝试从 WDT_REASON 判断。我在启动代码里加入：

static const char *reset_reason_str(uint32_t reason) { switch (reason) { case 0: return "normal"; case 1: return "wdt"; case 2: return "crash"; case 3: return "other"; } } printf("Reset reason: %s\n", reset_reason_str(watchdog_get_reason()));

复位后串口打印的是 "wdt"，说明确实走的是看门狗复位路径，不是电源掉电复位。但问题是：为什么看门狗会超时？主循环耗时明明测过，从不超时。

5.2 用 SCRATCH 寄存器抓到真凶的过程

为了抓到卡死点，我改用了分段标记法。在关键函数入口都打上 SCRATCH 标记：

#define MARK_ENTER_MODBUS_PARSE 10 #define MARK_ENTER_GPIO_HANDLE 20 #define MARK_ENTER_SERVO_MOVE 30 #define MARK_ENTER_UART_SEND 40 watchdog_scratch_write(0, MARK_ENTER_MODBUS_PARSE); // 执行 Modbus 解析... watchdog_scratch_write(0, MARK_ENTER_GPIO_HANDLE); // 执行 GPIO 处理... watchdog_scratch_write(0, MARK_ENTER_SERVO_MOVE); // 舵机控制...

每个阶段入口都打标记。然后现场运行，等复位发生后，把设备拿回来，通过串口读 SCRATCH0 的值。连续复现了三次，三次都停在MARK_ENTER_SERVO_MOVE（舵机控制）。

这就把问题缩小到了舵机控制代码。再继续深入分析，最终发现舵机库的某个旧版本在 PWM 占空比设置的底层函数里有一个条件分支，在特定输入角度下会进入一段较长的计算循环，加上 Modbus 刚好在那一刻触发中断，多个中断嵌套导致舵机控制函数执行时间超过看门狗阈值。

修复方案很简单：在舵机控制循环内加上watchdog_update()的"局部喂狗"策略，保证最长执行路径也远小于 WDT 超时阈值。同时把 WDT 超时时间从 2000ms 提高到 3000ms，多留余量。

5.3 另一个高频坑：Pico 进入休眠模式后看门狗的状态

RP2040 支持多种低功耗模式，其中 sleep 和 dormancy 模式下，看门狗时钟源 ROSC 可能被关闭，看门狗不工作。这不是 bug，是设计行为——低功耗模式本来就不希望外设继续耗电。

但随之而来的问题就是：如果你在进入休眠前没有关看门狗（而且你也关不掉），唤醒后看门狗是继续计时还是重置？

实测结果是：进入 sleep 模式后看门狗停止计时，唤醒后从停止时的计数值继续往下减。这个行为在不同版本的 SDK 里略有差异，官方 SDK 在进入休眠前会做内部处理，但如果你用寄存器级别操作进入休眠，需要自己确认状态。

我个人的建议是：如果项目里有低功耗需求，就明确设计"休眠前不依赖看门狗来守护休眠过程"，而是在唤醒后手动重置定时器。千万别以为看门狗在休眠期间还能帮你"守夜"——它做不到。

5.4 启动阶段的看门狗问题：初始化的时间窗口

还有一个容易被忽略的场景：芯片上电后，从复位向量到看门狗使能之间有一段时间窗口。这段时间内看门狗没有工作，程序理论上可以随便跑。但如果你的程序在初始化阶段就卡死了（比如等待某个外设就绪的轮询循环），看门狗还没使能，就无法提供保护。

更微妙的情况是：如果你在初始化代码早期就使能了看门狗，但后续初始化流程（文件系统挂载、网络连接等）特别耗时，超过了超时阈值，那么芯片会在初始化完成前就被看门狗复位，形成"永远初始化不完"的循环。

解决思路有两种：

1. 初始化早期就使能看门狗，但把超时时间设得足够长，超过最坏情况的初始化总时长。
2. 在初始化的每个耗时步骤之间喂狗，等全部就绪后再把超时调整到正常运行所需的值。

注意方案 2 有一个 RP2040 特有的限制：一旦使能，你不能通过调整 LOAD 之外的任何手段"重置"看门狗的运行状态，所以想"改超时时间"只能靠重新写 WDT_LOAD 间接实现，但软件上无法真正做到"从某一刻起重新计算超时周期"，因为 WDT_LOAD 每次写入就算一次喂狗。所以严格来说，"改超时"和"喂狗"在寄存器层面是同一个操作，不存在"只改超时但不喂狗"的独立通道，这个认知能帮你避免不少困惑。

6. 关于临界超时设计的几条硬经验

如果看门狗只是简单地在主循环末尾喂狗，那么以上知识点基本够用了。但很多项目对可靠性要求更高，会做一些"临界超时设计"——即喂狗间隔接近看门狗阈值甚至超过阈值。这时候有几条硬经验需要刻在脑子里。

第一，永远不要在中断服务函数里喂狗，除非你能保证中断没有嵌套。RP2040 的中断控制器支持嵌套中断，高优先级中断可以抢占低优先级中断。如果你在某个 ISR 里喂狗，主循环卡死时，只要这个中断还在触发，看门狗就会被持续喂饱，跑飞的主循环反而不会被发现。这种"假活"在故障诊断时极具迷惑性。

第二，喂狗的位置应该放在业务逻辑的关键路径上，而不是放在空闲等待路径上。正确做法是把喂狗放在你认为"程序完成了一片完整工作"的里程碑位置。这样一旦某个里程碑之间出现了异常耗时，看门狗立即触发，问题能被准确定位到两个里程碑之间。

第三，超时时间不是越小越好。很多人觉得"看门狗时间设短一点，响应更快"。但对 unpredicted 执行时间敏感的系统来说，过于激进的阈值反而会导致误复位。比如你用了某种 Flash 存储，在极端情况下写入一次需要几十毫秒，如果看门狗阈值只有 50ms，很可能偶发超时。我建议阈值设置至少大于正常路径最大耗时的 2 倍，并保留至少 30% 的余量。

第四，注意 Pico 的 USB 枚举耗时。用 C SDK 开发时，如果程序启用了 USB CDC 串口，上电后会等待 USB 枚举完成，这个耗时因主机不同而差异很大。你在开发板上插着 USB 调试时一切正常，一旦脱离 USB 独立供电，USB 枚举不等待了，程序节奏发生变化，原先没问题的喂狗时序可能突然出问题。量产固件建议做一次"无 USB 长时间运行"测试。

7. 结合舵机控制场景的一个典型 WDT 配置范例

热词里出现了"树莓派pico控制舵机"，这也是 Pico 最常见的应用场景之一。舵机控制本身不复杂，但因为舵机上电瞬间电流大、PWM 信号要求连续，一旦程序跑飞，舵机可能保持在某个错误角度持续出力，轻则抖动，重则烧舵机。用 WDT 来做舵机失控保护是个很自然的思路。

以 SG90 舵机为例，控制信号是 50Hz 的 PWM，脉宽 0.5ms~2.5ms 对应 0°~180°。Pico 可以用 PWM 硬件产生信号，主循环只需要周期性更新占空比。一个典型的 WDT + 舵机保护方案如下：

#include "hardware/watchdog.h" #include "hardware/pwm.h" #include "hardware/gpio.h" #define SERVO_PIN 15 #define WDT_TIMEOUT_MS 3000 int main() { // 初始化 PWM 舵机引脚 gpio_set_function(SERVO_PIN, GPIO_FUNC_PWM); uint slice = pwm_gpio_to_slice_num(SERVO_PIN); pwm_set_wrap(slice, 19999); // 50Hz, 20ms 周期 pwm_set_chan_level(slice, PWM_CHAN_A, 1000); // 1ms 脉宽 pwm_set_enabled(slice, true); // 每 100ms 写一次 SCRATCH0 标记 + 喂狗 uint32_t loop_counter = 0; watchdog_enable(WDT_TIMEOUT_MS, true); while (1) { // 舵机角度逻辑 uint16_t duty = calculate_duty_from_target(target_angle); pwm_set_chan_level(slice, PWM_CHAN_A, duty); // 每 100 次循环（约 10s）更新一次标记 if (++loop_counter % 100 == 0) { watchdog_scratch_write(0, loop_counter); watchdog_update(); } sleep_ms(100); } }

注意这里喂狗是放在循环内的，且喂狗频率远高于看门狗超时阈值。实际项目中，如果舵机控制循环出现异常卡死，3000ms 后看门狗复位，SCRATCH0 里记录的是最后一次成功运行到的循环次数，能帮你判断卡死前程序运行了多久。

不过提前说一句：舵机失控保护不能只靠 WDT。WDT 只能保证程序不卡死，但如果程序逻辑本身没问题、只是舵机收到错误的角度指令，WDT 不会管这件事。更稳妥的方案是同时加一个角度合法性校验，不在指令层面让舵机进入死角位置。

8. 排查 WDT 问题的通用"三板斧"

最后把我排查 RP2040 看门狗问题的经验收敛成三个通用步骤，任何 WDT 异常都能用这三步快速定位。

第一板斧：确认复位来源。上电后第一时间读 WDT_REASON，明确这次复位是 WDT 触发的还是电源异常。这一步在启动代码的最前面做，越早越好，最好在初始化时钟之前就把原因打印出来或存入非易失存储。C SDK 里可以直接用watchdog_caused_reboot()和watchdog_get_reason()。

第二板斧：用 SCRATCH 寄存器建立"运行轨迹地图"。在项目早期就定义好一组整型常量（如 1=初始化完成、2=进入主循环、3=进入传感器读取、4=进入通信处理），在代码关键节点写入 SCRATCH0。每次 WDT 复位后，第一件事就是读这个值，直接把问题区间缩小到两个标记点之间。我吃过不设置标记的亏——程序卡死只能从头到尾翻代码，费时费力。这个教训现在已经成了我做所有单片机项目的默认流程。

第三板斧：实测超时时间，不信理论标称值。用 GPIO 翻转 + 示波器的方案实测实际复位周期，用这个实测值去校准你的超时配置。不同板子有差异，换了一块 Pico 之后一定要重新测一次。我曾经因为换了同一批次但不同出厂日期的 Pico，WDT 实际超时时间差了近 8%，直接把一个精心配置的临界算法搞崩了。

这三板斧用下来，绝大多数 WDT 疑难杂症都能在一个小时内定位到原因。剩下的少数问题，往往是外设硬件层面的电气问题导致的，那已经不是看门狗配置的范畴了。