第1章：看门狗定时器原理
大家好，我是你们的嵌入式系统讲师。今天咱们聊聊看门狗——这个在ECU里看似简单、实则暗藏玄机的模块。
说实话，我入行头三年，一直觉得看门狗就是个「定时喂狗」的活儿。直到有一次，我在一个量产项目上栽了跟头——客户反馈车辆偶发性重启，查了两个月才发现是看门狗超时处理不当。从那以后，我对这玩意儿就再也不敢马虎了。
1.1 内部计数器机制
看门狗的核心，说白了就是一个递减计数器。你给它一个初始值，它就开始往下数。数到0，系统复位。
嗯，就这么简单。但简单背后有门道。
我见过不少工程师把看门狗当成「定时器」来理解，其实两者有本质区别：
- 定时器：到时间了触发中断，程序可以继续跑
- 看门狗：到时间了直接复位，程序必须从头来
为什么会这样？因为看门狗的设计初衷就是「最后一道防线」。当你的程序跑飞了、死循环了、中断卡死了，定时器还能正常工作吗？不能。但看门狗可以——它独立于CPU核心，有自己的时钟源。
关键点：看门狗计数器通常使用独立的RC振荡器或低速晶振，不依赖主时钟。这样即使主时钟失效，看门狗依然能工作。
我个人习惯把看门狗计数器想象成一个「沙漏」。沙子漏完了，系统就重启。而喂狗操作，就是把沙漏翻过来——让沙子重新开始漏。
1.2 喂狗操作流程
喂狗，也叫「清狗」或「刷新看门狗」。操作流程通常是这样的：
- 向看门狗控制寄存器写入特定的「喂狗序列」
- 计数器被重置为初始值
- 系统继续正常运行
这里有个坑——喂狗序列。很多看门狗芯片要求你按特定顺序写入两个不同的值，比如先写0x55、再写0xAA。如果顺序错了，或者中间插入了其他操作，喂狗就会失败。
避坑指南：我曾经在一个项目里，因为中断服务程序里顺手写了个喂狗操作，结果主循环和中断同时喂狗，把喂狗序列打乱了。系统每隔几分钟就复位一次，查得我头秃。后来我规定：喂狗代码只能放在主循环的固定位置，中断里绝对不碰。
来看一个典型的喂狗代码示例：
/* 喂狗函数 - 仅在主循环中调用 */
void Watchdog_Feed(void)
{
/* 喂狗序列：先写0x55，再写0xAA */
WDT_CTRL_REG = 0x55;
WDT_CTRL_REG = 0xAA;
/* 检查喂狗是否成功（部分芯片支持） */
if (WDT_STATUS_REG & WDT_FEED_FAIL)
{
/* 喂狗失败，记录错误 */
Error_Log("Watchdog feed failed!");
}
}
你想想看，为什么芯片厂商要设计这么复杂的喂狗序列？就是为了防止程序跑飞时「碰巧」把看门狗给喂了。如果喂狗只需要写一个0xAA，那程序跑飞时寄存器里正好是0xAA的概率就太大了。
1.3 超时时间计算
超时时间，就是计数器从初始值减到0所需要的时间。计算公式很简单：
超时时间 = 计数器初始值 × 计数时钟周期
举个例子：
| 参数 | 值 |
|---|---|
| 计数器初始值 | 1024 |
| 计数时钟频率 | 32.768 kHz |
| 时钟周期 | 1 / 32768 ≈ 30.5 μs |
| 超时时间 | 1024 × 30.5 μs ≈ 31.25 ms |
但实际项目中，你不能卡着这个时间点去喂狗。为什么？因为你的程序执行时间不是固定的——有时候任务多，跑得慢；有时候任务少，跑得快。
我的经验：超时时间至少留出50%的余量。比如你的主循环最长执行时间是20ms，那就把看门狗超时设为30ms以上。我曾经见过一个同事把超时设成20.5ms，结果主循环偶尔跑到21ms，系统就频繁复位。这种问题最难查，因为不是每次都发生。
另外，不同芯片的看门狗超时范围差异很大：
- 低端MCU：通常只有几个固定档位，比如16ms、32ms、64ms
- 中高端MCU：支持可编程计数器，从1ms到几秒都可以设
- 外部看门狗芯片：通过外部电阻电容设定，范围更宽
我记得有一次做ADAS控制器，要求看门狗超时时间必须小于100ms，但主循环里有个传感器校准任务偶尔会跑到150ms。怎么办？我把校准任务拆成多个小步骤，每完成一步就喂一次狗。这样既保证了功能完整，又没让看门狗超时。
嗯，这里要注意：拆任务喂狗有个前提——你必须确保每个子步骤都不会死锁。否则，程序卡在某个子步骤里，看门狗照样被喂着，系统永远不会复位，那看门狗就形同虚设了。
小结
这一章我们聊了看门狗的三大核心：
- 计数器机制：独立时钟、递减计数、到0复位
- 喂狗操作：特定序列、固定位置、避免中断干扰
- 超时计算：留余量、考虑最坏情况、必要时拆任务
下一章，咱们聊聊看门狗在功能安全中的角色——ISO 26262里对看门狗有什么要求？怎么设计才能通过功能安全认证？到时候我会分享一个我亲身经历的「差点没通过审核」的故事。
公众号:蓝海资料掘金营，微信deep3321