企业官网建设流程全解析

1. 项目概述与看门狗的核心价值

在嵌入式系统开发里，最让人头疼的往往不是功能实现，而是系统在无人值守、长期运行后，因为某个难以复现的软件跑飞、死锁或者内存泄漏，导致整个设备“卡死”。我经历过不止一次，设备在现场运行几个月后莫名宕机，重启后一切正常，查日志也一无所获，这种问题排查起来就像大海捞针。这时候，硬件看门狗定时器就成了嵌入式工程师手中最可靠的那道“保险丝”。

看门狗的本质，是一个独立于CPU运行的硬件计时器。你需要定期去“喂狗”，也就是重置这个计时器。只要软件运行正常，这个操作就会周期性地发生。一旦软件陷入死循环、任务调度卡住，导致“喂狗”动作停止，计时器就会溢出，进而触发整个系统的硬件复位，让设备从异常状态中恢复过来。这听起来简单，但要把这个机制用好、用对，尤其是在像TI OMAP这样复杂的多核、多电源域的高性能平台上，里面的门道可就多了。

这次我们深入TI OMAP3530/AM37x等经典平台的看门狗模块，特别是MPU侧的WDT2和IVA2子系统侧的WDT3。官方手册几百页，寄存器描述密密麻麻，但真正驱动开发时，你关心的无非是几件事：怎么根据我的系统心跳设置超时时间？怎么在低功耗模式下不让看门狗误触发？怎么安全地启停和喂狗？以及最关键的，如何通过寄存器编程，把手册里的方块图变成你代码里稳定可靠的几行配置。这篇文章，我就结合自己踩过的坑和项目经验，把这些关键点掰开揉碎了讲清楚，让你不仅能看懂手册，更能写出健壮的驱动代码。

2. 看门狗定时器的核心原理与硬件架构

2.1 基本工作原理：从计数器到系统复位

看门狗的核心是一个自由运行的32位向上计数器。你可以把它想象成一个沙漏，沙子（时钟脉冲）不断从上方流下，计数器（沙漏下方的沙子堆积量）随之增加。你的软件任务需要定期把这个沙漏翻转过来（喂狗），让计数重新开始。如果软件卡住，没人来翻转沙漏，沙子终究会流完，计数器溢出，这时就会产生一个复位信号。

在OMAP平台，这个“沙漏”由两部分组成：一个可编程的预分频器和一个32位的主计数器。时钟源（比如32kHz）首先经过预分频器进行分频，分频后的时钟再去驱动主计数器累加。公式很直观：溢出时间 = (0xFFFFFFFF - 装载值 + 1) × 时钟周期 × 分频系数。这里的“装载值”就是你初始化时写入WLDR寄存器的那个数，它决定了沙漏的“起始沙量”。预分频系数由WCLR寄存器的PRE和PTV位控制，范围是1到128（2^7）。

注意：这里有个极易出错的细节。手册里给的公式是(0xFFFF FFFF - WLDR + 1)。很多人会疑惑，为什么不是直接用WLDR值？因为这是一个向上计数器，它从0开始累加，直到溢出。WLDR定义的是溢出发生后，计数器被重新装载的值。所以，从当前值到0xFFFFFFFF溢出的这段计数长度，才是真正的超时窗口。假设你设置WLDR = 0xFFFF0000，那么计数器会从0开始计数到0xFFFFFFFF，总共需要计数0xFFFFFFFF - 0 + 1 = 0x100000000次吗？不对。实际上，硬件在计数器达到0xFFFFFFFF的瞬间就会触发溢出，并立即将WLDR值（0xFFFF0000）重新载入。因此，从载入值（0xFFFF0000）计数到溢出（0xFFFFFFFF）所需的周期数是：0xFFFFFFFF - 0xFFFF0000 + 1 = 0x10000 (65536)个周期。这与你理解的计算窗口是一致的。公式中的(0xFFFF FFFF - WLDR + 1)正是计算这个窗口大小的正确方法。

2.2 OMAP平台看门狗硬件集成解析

OMAP的看门狗不是孤立的模块，它深度集成在芯片的电源、复位和时钟管理框架中。理解这张集成图，是避免低级错误的关键。

1. 双时钟域设计：这是第一个关键点。每个看门狗模块（WDT2/WDT3）都有两个时钟：

• 功能时钟：WDTi_FCLK。这是看门狗核心计数器实际工作的时钟，比如来自WKUP_32K_FCLK（32kHz）。计数器是在这个时钟域下累加的。
• 接口时钟：WDTi_ICLK。这是连接芯片内部L4总线用于CPU访问寄存器的时钟，比如WKUP_L4_ICLK。当你读写WCRR、WTGR等寄存器时，操作是同步到这个时钟域的。

这两个时钟是异步的！这意味着，你通过CPU（在ICLK域）写入一个喂狗值到WTGR寄存器，这个值需要经过同步电路才能传递到计数器所在的FCLK域。手册里提到的“Posted Write”模式和WWPS（写等待状态）寄存器，就是用来管理这个异步操作的。如果你在写入后立即读取，可能会读到旧值，必须检查WWPS中对应的W_PEND_*位是否清零，确认写入操作已经完成同步。

2. 电源与复位域：WDT2属于WKUP（唤醒）电源域，WDT3属于PER（外设）电源域。这带来两个重要影响：

• 复位源：WDT2受WKUP_RST信号控制，WDT3受PER_RST控制。这意味着对这两个域的软件复位或硬件复位，会分别复位对应的看门狗。
• 功耗管理：在系统进入低功耗状态时，PRCM模块可以分别控制这两个域的时钟开关。看门狗的行为需要通过WD_SYSCONFIG寄存器中的IDLEMODE和CLOCKACTIVITY位进行精细配置，防止在省电时被误触发或失效。

3. 输出信号：看门狗溢出后，可以产生两种信号：复位信号和中断信号。在OMAP上，WDT2的中断输出是未连接的，这意味着WDT2只能用作纯粹的复位看门狗。而WDT3的中断连接到了MPU的M_IRQ_36，因此它既可以配置为触发复位，也可以配置为仅产生中断，供软件进行更复杂的错误处理（例如尝试保存关键数据后再复位）。

2.3 关键寄存器组概览

驱动看门狗，本质上是操作一组内存映射的寄存器。OMAP的看门狗寄存器组设计得相对规整，主要分为控制和状态两类：

• 控制类：
  • WCLR：控制寄存器。核心是PRE（预分频器使能）和PTV（预分频值）位，决定了时钟分频比。
  • WLDR：装载值寄存器。设置看门狗溢出周期。
  • WTGR：触发寄存器。向此寄存器写入一个与上次不同的值，即可完成“喂狗”操作。
  • WSPR：启动/停止寄存器。通过写入特定的序列（0xAAAA然后0x5555停止；0xBBBB然后0x4444启动）来控制计数器运行。
  • WIER：中断使能寄存器。OVF_IT_ENA位用于使能溢出中断（WDT3可用）。
• 状态类：
  • WCRR：计数器值寄存器。可实时读取当前计数值，但要注意异步读取的同步问题。
  • WISR：中断状态寄存器。溢出时OVF_IT_FLAG位被置1，写1可清除该标志。
  • WWPS：写等待状态寄存器。这是最易忽略的寄存器。当你写入WCLR、WLDR、WSPR、WTGR、WCRR这些功能时钟域的寄存器后，必须轮询此寄存器中对应的W_PEND_*位，直到其变为0，才能确保写入操作已生效。
  • WD_SYSCONFIG：系统配置寄存器。配置IDLEMODE（空闲模式）和CLOCKACTIVITY（时钟活动），用于管理低功耗状态下的看门狗行为。

3. 看门狗驱动开发：从配置到喂狗的完整流程

理解了原理和硬件，我们来看如何动手编程。下面以一个典型的MPU侧看门狗（WDT2）初始化、配置和喂狗流程为例，我会穿插讲解每个步骤的意图和避坑点。

3.1 初始化与基础配置

在系统启动早期，通常在时钟初始化之后、任务调度启动之前，就需要配置好看门狗。

第一步：模块使能与软复位首先，需要通过PRCM模块使能看门狗的时钟。对于WDT2，需要设置PRCM.CM_FCLKEN_WKUP[5](EN_WDT2) 和PRCM.CM_ICLKEN_WKUP[5](EN_WDT2) 位。很多BSP代码会封装这个操作。然后，对看门狗模块本身进行一次软复位以确保其处于确定状态。

// 假设已定义好寄存器基址 WDT2_BASE #define WDT2_WD_SYSCONFIG (*(volatile uint32_t *)(WDT2_BASE + 0x010)) void wdt2_init(void) { // 1. 通过PRCM使能WDT2时钟 (此处需调用PRCM相关函数，略) // prcm_enable_wdt2_clk(); // 2. 软件复位看门狗模块 WDT2_WD_SYSCONFIG = (1 << 1); // 设置SOFTRESET位为1 // 等待复位完成 while((WDT2_WD_SYSCONFIG & (1 << 1)) != 0); // SOFTRESET位会自清零 // 也可通过WD_SYSSTATUS[0] RESETDONE位确认 }

第二步：配置空闲模式与时钟活动这是连接功耗管理的关键。IDLEMODE决定了当PRCM请求模块进入空闲状态时，看门狗如何响应。

• 00- 强制空闲：无条件同意关闭时钟。风险极高，如果喂狗任务依赖该时钟，会导致看门狗失效。一般不用。
• 01- 无空闲：永远不同意关闭时钟。最安全，但无法省电。
• 10- 智能空闲：只有模块内部无活动事务时才同意关闭时钟。这是平衡可靠性与功耗的推荐设置。

CLOCKACTIVITY则进一步指定在智能空闲模式下，哪个时钟可以被关闭。通常，为了确保看门狗始终能计数，我们需要保持功能时钟FCLK活动。可以配置为0x2（仅FCLK保持活动）。

// 3. 配置IDLEMODE和CLOCKACTIVITY uint32_t sysconfig_val = 0; sysconfig_val |= (0x2 << 3); // IDLEMODE = 0x2 (Smart-idle) sysconfig_val |= (0x2 << 8); // CLOCKACTIVITY = 0x2 (Only WDTi_FCLK ON) // 保持EMUFREE=0 (仿真时冻结计数器)，AUTOIDLE=0 (接口时钟自由运行) WDT2_WD_SYSCONFIG = sysconfig_val;

第三步：设置超时时间与预分频这是计算的核心。假设我们使用32.768kHz的时钟源，希望看门狗超时时间为10秒。

1. 选择预分频比。为了获得较长的定时范围，我们可以先尝试不分频（PRE=0）或分频较小。假设设置PRE=1（使能），PTV=0（分频比=1）。
2. 计算需要的装载值WLDR。
   • 时钟周期 T_ck = 1 / 32768 Hz ≈ 30.518 us
   • 分频后时钟周期 T_ck_ps = T_ck * PS = 30.518 us * 1 = 30.518 us
   • 期望超时时间 T_out = 10 s
   • 需要的计数周期数 N = T_out / T_ck_ps = 10 s / 30.518 us ≈ 327,680
   • 由于是向上计数到0xFFFFFFFF溢出，所以WLDR = 0xFFFFFFFF - N + 1
   • N = 327680 = 0x50000
   • WLDR = 0xFFFFFFFF - 0x50000 + 1 = 0xFFFAFFFF

重要提示：在修改WCLR或WLDR之前，必须先停止看门狗计数器！直接修改运行中的看门狗参数可能导致不可预知的行为。

#define WDT2_WSPR (*(volatile uint32_t *)(WDT2_BASE + 0x048)) #define WDT2_WCLR (*(volatile uint32_t *)(WDT2_BASE + 0x024)) #define WDT2_WLDR (*(volatile uint32_t *)(WDT2_BASE + 0x02C)) #define WDT2_WWPS (*(volatile uint32_t *)(WDT2_BASE + 0x034)) void wdt2_configure_period(uint32_t seconds) { // 1. 停止看门狗 WDT2_WSPR = 0xAAAA; WDT2_WSPR = 0x5555; // 等待停止操作完成 while (WDT2_WWPS & (1 << 4)); // 检查W_PEND_WSPR位 // 2. 配置预分频器 (1分频，即不分频) uint32_t wclr_val = 0; wclr_val |= (1 << 5); // PRE = 1, 使能预分频器 wclr_val |= (0 << 2); // PTV = 0, 分频系数 = 2^0 = 1 WDT2_WCLR = wclr_val; while (WDT2_WWPS & (1 << 0)); // 检查W_PEND_WCLR位 // 3. 计算并设置装载值 (基于32.768kHz时钟) const uint32_t clk_freq_hz = 32768; const uint32_t prescaler = 1; // 2^PTV uint32_t total_cycles = seconds * clk_freq_hz / prescaler; // 确保不超过32位计数范围 if (total_cycles > 0xFFFFFFFF) { total_cycles = 0xFFFFFFFF; // 或调整预分频比 } uint32_t wldr_value = 0xFFFFFFFF - total_cycles + 1; WDT2_WLDR = wldr_value; while (WDT2_WWPS & (1 << 2)); // 检查W_PEND_WLDR位 // 4. (可选)设置初始计数器值，如果需要从特定值开始 // WDT2_WCRR = some_value; // while (WDT2_WWPS & (1 << 1)); // 5. 启动看门狗 WDT2_WSPR = 0xBBBB; WDT2_WSPR = 0x4444; while (WDT2_WWPS & (1 << 4)); // 检查W_PEND_WSPR位 }

3.2 喂狗操作与最佳实践

喂狗，即触发计数器重载，是通过向WTGR寄存器写入一个与上次不同的值来实现的。这是看门狗机制中最频繁的操作，也是最容易写出问题的地方。

简单的喂狗函数：

#define WDT2_WTGR (*(volatile uint32_t *)(WDT2_BASE + 0x030)) static uint32_t last_kick_value = 0; void wdt2_kick(void) { last_kick_value++; WDT2_WTGR = last_kick_value; // 强烈建议等待写入完成，尤其在喂狗间隔很短的场景 while (WDT2_WWPS & (1 << 3)); // 检查W_PEND_WTGR位 }

喂狗策略与避坑指南：

1. 喂狗位置：喂狗必须在系统的主循环或最高优先级监控任务中进行。绝对不要只在某个中断服务程序里喂狗。因为中断可能正常响应，但主程序已经死锁，这样看门狗无法检测到故障。
2. 喂狗间隔：超时时间应设置为喂狗间隔的2-3倍以上。例如，如果你计划每1秒喂一次狗，超时时间至少设为3秒。这为系统处理临时高负载、任务调度延迟留出了余量，避免不必要的复位。
3. 多任务环境：在RTOS中，可以将喂狗设计为一个独立的低优先级任务，由其他所有关键任务定期发送信号（如信号量、事件标志）给这个“看门狗监护任务”。监护任务检查所有信号是否按时到达，只有全部按时到达，它才执行喂狗。这样，任何一个关键任务阻塞，都会导致喂狗停止。
4. 禁止在中断中长时间阻塞：虽然喂狗本身很快，但确保中断服务程序执行时间极短。长时间关中断或在高优先级中断中处理复杂逻辑，会阻塞低优先级的喂狗任务，导致看门狗超时。
5. 调试阶段的处理：在单步调试时，看门狗会持续计数。需要在调试器初始化脚本中暂时禁用看门狗，或者设置一个极长的超时时间。OMAP的看门狗在仿真模式下可以通过WD_SYSCONFIG[5] EMUFREE位控制计数器是否冻结。

3.3 中断模式的使用（以WDT3为例）

WDT3的中断是连接的，这为我们提供了“软复位”或“分级恢复”的可能。例如，可以在第一次溢出时先进入中断，尝试记录错误、保存数据，然后如果问题持续，第二次溢出再触发硬件复位。

配置中断模式：

#define WDT3_WIER (*(volatile uint32_t *)(WDT3_BASE + 0x01C)) #define WDT3_WISR (*(volatile uint32_t *)(WDT3_BASE + 0x018)) void wdt3_enable_interrupt(void) { // 1. 停止看门狗 (略) // 2. 配置超时时间 (略) // 3. 使能溢出中断 WDT3_WIER |= 0x1; // 设置OVF_IT_ENA位 // 4. 清除可能已有的中断标志 WDT3_WISR |= 0x1; // 写1清除OVF_IT_FLAG // 5. 启动看门狗 (略) // 6. 在MPU中断控制器中使能M_IRQ_36 (略) } // 中断服务程序 void WDT3_IRQ_Handler(void) { // 1. 清除看门狗模块内的中断标志 WDT3_WISR |= 0x1; // 2. 进行紧急处理：保存关键数据到非易失存储器、记录错误码等 // save_critical_data(); // log_error_code(ERROR_WDT_PRE_RESET); // 3. (可选) 执行一次喂狗，延长复位时间，给保存操作留出时间 // wdt3_kick(); // 注意：如果问题未解决，看门狗最终��会溢出并触发复位。 }

警告：使用中断模式需要非常小心。中断处理程序必须极其精简和可靠。如果导致看门狗溢出的错误同样影响了中断系统或该中断处理程序本身，那么这种“软恢复”机制就会失效。因此，硬件复位仍然是最终兜底的最可靠手段。中断通常用于在复位前完成最后的“善后”工作。

4. 低功耗场景下的看门狗配置策略

在电池供电的设备中，功耗至关重要。OMAP的PRCM模块可以动态关闭闲置模块的时钟以省电。看门狗作为系统安全的守护者，其配置需要仔细权衡。

场景分析：系统进入空闲状态当CPU进入空闲状态，PRCM可能会尝试关闭WKUP或PER域的时钟。此时，WD_SYSCONFIG寄存器的配置决定了看门狗的行为：

1. IDLEMODE = 0x2(Smart-idle)：这是推荐配置。当PRCM发出空闲请求时，看门狗硬件会检查内部是否有未完成的事务（如正在进行的寄存器访问）。如果没有，它才应答空闲请求。这保证了在喂狗操作间隙，看门狗可以随域一起进入低功耗状态。
2. CLOCKACTIVITY = 0x2：在智能空闲模式下，此设置指明“仅功能时钟FCLK保持活动”。这意味着即使看门狗同意了空闲请求，其核心计数器时钟FCLK也不会被关闭，看门狗继续计数。这是确保安全监控不中断的关键。接口时钟ICLK可以被关闭以省电，因为此时CPU可能已休眠，无需访问寄存器。

配置示例与检查清单：

// 进入低功耗前的看门狗检查 void enter_low_power_mode(void) { // 1. 确保最后一次喂狗操作已完成 while (WDT2_WWPS & (1 << 3)); // 等待可能的喂狗写入完成 // 2. 确认看门狗配置为智能空闲且功能时钟保持活动 uint32_t syscfg = WDT2_WD_SYSCONFIG; if (((syscfg >> 3) & 0x3) != 0x2) { // IDLEMODE不是Smart-idle，需要重新配置 } if (((syscfg >> 8) & 0x3) != 0x2) { // CLOCKACTIVITY不是仅FCLK保持活动，需要重新配置 } // 3. 计算并确保超时时间足够长，覆盖低功耗模式的持续时间 // 假设睡眠10秒，看门狗超时必须大于10秒+喂狗间隔余量。 // 4. 执行进入低功耗的指令 (如WFI) // __asm__ volatile("wfi"); }

关键陷阱：CLOCKACTIVITY与PRCM时钟使能位的不一致。手册中用一个CAUTION专门强调了这一点。假设软件将CLOCKACTIVITY设为0x3（两个时钟都保持活动），但同时又在PRCM寄存器中禁用了看门狗的时钟使能位（CM_FCLKEN_x和CM_ICLKEN_x）。PRCM认为时钟可以关闭，并向看门狗发出空闲请求。由于CLOCKACTIVITY=0x3，看门狗会认为两个时钟都应保持活动，其内部判断“无活动”的条件可能不成立，从而可能拒绝空闲请求。这种软件配置的矛盾会导致系统功耗状态管理混乱。因此，软件必须保证PRCM的时钟控制策略与看门狗的CLOCKACTIVITY设置逻辑一致。

5. 常见问题排查与调试技巧实录

即使按照手册编程，在实际项目中你还是会遇到各种古怪的问题。下面是我总结的几个典型场景和排查思路。

5.1 问题一：看门狗无法启动或立即复位

现象：调用启动序列后，系统几乎立即复位。排查步骤：

1. 检查启动序列：确保严格按照0xBBBB->0x4444的顺序写入WSPR寄存器，并且检查了WWPS位。一个常见的错误是写反了顺序或忘记了等待写入完成。
2. 检查超时时间：计算WLDR装载值是否正确。一个典型的错误是WLDR值设置得过大，非常接近0xFFFFFFFF，导致超时时间极短（几微秒）。使用前面提到的公式仔细验算。
3. 检查预分频器：确认WCLR寄存器的PRE位是否已使能（如果打算使用分频）。PTV值是否在0-7范围内。
4. 确认时钟源：通过PRCM寄存器确认WKUP_32K_FCLK或PER_32K_ALWON_FCLK时钟确实已启用并稳定。有时系统初始化时低速时钟可能未就绪。
5. 使用仿真器调试：在启动看门狗前设置断点，单步执行启动代码，并实时读取WCRR寄存器，观察计数器是否真的开始递增。如果计数器不增，问题可能在时钟或配置；如果计数器疯涨，问题在装载值。

5.2 问题二：喂狗后系统仍不定期复位

现象：喂狗程序看似正常执行，但系统仍会随机复位，时间不固定。排查步骤：

1. 检查喂狗间隔与超时时间：这是最常见的原因。使用逻辑分析仪或高精度定时器，实际测量喂狗函数两次被调用的最大时间间隔。确保这个最大间隔远小于你设置的看门狗超时时间（建议3倍以上）。考虑任务阻塞、中断关闭、高优先级任务长时间执行等因素。
2. 检查WWPS等待：在喂狗函数中，是否在写入WTGR后等待了W_PEND_WTGR位清零？如果没有，在总线繁忙或时钟频率较低时，写入操作可能延迟生效，导致本次喂狗“无效”。务必在每次写入功能时钟域寄存器后检查对应的WWPS位。
3. 检查多任务竞争：如果多个任务都能喂狗，可能存在竞争条件。确保喂狗操作是原子的，或者使用互斥锁保护。
4. 检查低功耗模式：系统进入低功耗模式时，喂狗任务是否被挂起？看门狗时钟FCLK是否被关闭？确认IDLEMODE和CLOCKACTIVITY配置符合预期，确保在低功耗模式下看门狗仍在正确计时。

5.3 问题三：读取的计数器值WCRR不准确或跳变

现象：为了调试，读取当前计数器值，发现值不合理或两次读取差异巨大。原因与解决：这几乎肯定是异步时钟域访问问题。WCRR寄存器在FCLK域更新，而CPU通过ICLK域读取。手册明确要求，为了读取一个连贯的32位值，必须先读低16位（地址偏移0x28），再读高16位（地址偏移0x2A）。硬件内部有一个影子寄存器机制来保证这种分裂读取的一致性。直接进行32位读取或顺序读反，都会得到错误数据。

正确的读取函数：

uint32_t wdt2_get_current_count(void) { volatile uint16_t *wcrr_lsb = (volatile uint16_t *)(WDT2_BASE + 0x028); volatile uint16_t *wcrr_msb = (volatile uint16_t *)(WDT2_BASE + 0x02A); uint32_t count; uint16_t lsb, msb; // 先读LSB，这会触发影子寄存器更新 lsb = *wcrr_lsb; // 再读MSB，此时读取的是与LSB同一时刻锁存的高位 msb = *wcrr_msb; count = ((uint32_t)msb << 16) | lsb; return count; }

5.4 问题四：在调试器下看门狗行为异常

现象：代码在仿真器单步调试时，看门狗突然复位。处理：这是因为看门狗计数器在仿真时默认仍在运行（除非配置了EMUFREE=0）。有两个方法：

1. 初始化时配置EMUFREE=0：在WD_SYSCONFIG寄存器中设置EMUFREE位为0。这样当调试器暂停CPU时，看门狗计数器也会冻结。
2. 在调试会话开始时禁用看门狗：在调试器（如CCS）的初始化脚本中，添加一段GEL脚本或直接修改内存，执行看门狗的停止序列。但务必记住在调试结束后重新启用，否则产品将失去保护。

// GEL脚本示例（需根据实际地址调整） void DisableWatchdog() { *(int *)0x48314048 = 0xAAAA; // WSPR *(int *)0x48314048 = 0x5555; while (*(int *)0x48314034 & (1<<4)); // 等待WWPS }

5.5 看门狗问题排查速查表

6. 高级应用与设计思考

看门狗不仅仅是最后一道防线，通过巧妙的设计，它可以成为系统健康度监测的有机组成部分。

分级看门狗策略：在复杂的系统中，可以部署多个看门狗或使用其中断功能。例如，用一个超时较短（如100ms）的看门狗监控最高优先级的“心跳”任务，用另一个超时较长（如10s）的看门狗监控整体应用框架。短超时的负责检测急性死锁，长超时的负责检测渐进性故障。

喂狗逻辑的健壮性设计：不要简单地在一个地方喂狗。可以设计一个“看门狗服务”模块，其他关键模块向其注册“健康检查”回调函数。看门狗服务任务定期遍历这些回调，只有所有回调都返回“健康”状态，才执行喂狗。这样，任何一个子系统出问题，都会导致喂狗停止。

与软件看门狗结合：硬件看门狗检测的是系统完全死锁。对于更细粒度的任务监控，可以使用软件看门狗（任务超时检测）。每个关键任务维护一个“保活”计数器，由一个高优先级监控任务定期检查。任何软件看门狗超时，可以触发一个graceful的错误处理流程，甚至主动调用硬件看门狗触发复位，并在复位前记录更详细的错误上下文。

最后，关于OMAP看门狗，还有一个容易混淆的点：WDT2和WDT3在复位后的默认行为。根据手册Note，WDT2在上电或热复位后是启动并开始计数的。而WDT3在复位后是停止状态。这意味着如果你的系统依赖WDT3，必须在初始化代码中显式启动它；而如果使用WDT2，则要注意其默认的10秒超时（基于32kHz时钟和默认WLDR），你可能需要在系统初始化早期就重新配置或禁用它，以防止它在你准备好之前就触发复位。

看门狗的配置，是嵌入式系统可靠性设计的基石。它要求开发者对系统的时间特性、任务调度和功耗管理有全局的、量化的理解。希望这篇结合了TI OMAP平台具体细节的长文，能帮你把这块“基石”打得更牢。