TC4x看门狗从WDT到WTU：窗口模式、ACU与多核安全监控设计

1. 为什么TC4x要把看门狗从WDT改成WTU

从TC3xx平台往TC4x平台迁移的工程师，最先感受到的差异之一，就是这个WTU模块。很多人手里还拿着TC3xx的WDT喂狗代码，原封不动搬到TC4x上，结果一上电就不断复位，查了半天才明白：不是代码跑飞了，是喂狗的方式彻底变了。

先看一个本质问题：看门狗到底在防什么。常规理解是防程序跑飞、防死循环，但做功能安全（ISO 26262）时间长了就会发现，这只是最低要求。真正的隐患在于：程序跑没跑飞，有时候很难用“超时”这一个信号刻画。举个典型场景：系统里发生了中断风暴，CPU一直在处理中断，主循环完全卡死，但中断服务函数里正好安排了喂狗操作——这种情况下，传统看门狗不但防不住问题，反而会把故障现场“伪装”成正常状态。另一个场景是硬件层面的信号故障，比如地址线被干扰拉低、钳位，导致某个外设寄存器被反复访问，传统看门狗的简单清零操作很容易在这种场景下失效。

TC4x的WTU（Watchdog Timer Unit）就是冲着这些问题来的。它的角色不再只是一个“倒计时到零就复位”的定时器，而是一个集合了多通道定时、窗口比较、访问确认、事务式刷新于一体的安全监控单元。用一句话概括：传统WDT是“计数器”，WTU是“监控器”。

TC4x的WTU和TC3xx的WDT之间的差异，我用一张表来列：

这张表背后反映的是一个很清晰的产品设计思路：随着整车电子电气架构复杂度上升，MCU上跑的软件越来越多，多核、多域、功能安全等级各不相同，看门狗必须是独立、可配置、可监控访问行为的安全基础设施，而不是简单挂在核心旁边的一个“闹钟”。

有三个核心概念决定了WTU和WDT是两代产物：

第一，多通道设计。TC4x的一个WTU模块里有两个独立的32位定时器通道，可以分配给不同上下文使用。比如CPU0用通道0，安全监控域用通道1；也可以把两个通道配置成“双通道冗余”模式，两个通道都独立运行，任何一个超时都触发报警——这种方式在ASIL-D场景中很常见，因为单一通道如果被软件错误屏蔽，还有个备份刹车。

第二，窗口刷新机制。WTU每个通道都带3个比较寄存器（CPR0、CPR1、CPR2），可以配置不同的窗口类型。刷新动作必须发生在合法的窗口区间内，太早太晚都算失败。这彻底改变了“只要在规定时间内喂狗就行”的老观念，也堵住了“喂狗操作被恶意代码抢占”的漏洞。

第三，访问确认（Access Acknowledge）。这个我后面单独展开，它解决的是“CPU是不是真的在按预期跑”的问题，而不是“CPU是否在某段时间内执行了喂狗指令”的问题，这是本质区别。

所以，如果你正在做TC4x平台的底层集成、BSP开发或者功能安全相关的工作，这篇文章值得从头看完。如果你只是想在工程上快速把WTU用起来，重点看第2章、第3章和第4章，参数计算和代码示例都在那里。

2. WTU模块的内部结构拆解

2.1 两个独立定时器通道：TIM0与TIM1

WTU模块内部有两个32位自由运行定时器，分别叫TIM0和TIM1，使用SPB（系统外设总线）时钟作为计数时钟源。它们的行为类似：上电后自由运行，计到0xFFFFFFFF后回绕，不回绕中断、不产生溢出事件，只是纯计数。

这里有一个工程上容易踩的坑：很多工程师用定时器回绕周期来推算窗口值，但TC4x的WTU并不要求你在一个回绕周期内完成刷新。两个定时器都是自由运行的，比较值寄存器存的是绝对时间戳或相对时间窗口，软件只需要关心“目标时间点”，不需要处理回绕问题，因为比较逻辑会自然处理32位回绕场景。初次实现时不要人为去加回绕判断，反而容易画蛇添足。

TIM0和TIM1可以分别配置给不同的刷新上下文。举个例子，一个系统里同时有CPU0应用和HSM安全岛（硬件安全模块）在运行，CPU0的应用代码刷新通道0，HSM或者SHE（安全硬件扩展）刷新通道1，两个通道互不干扰。这是TC3xx平台上做不到的——TC3xx每个核看门狗是物理独立的，但一旦某个核跑飞，它自己的WDT仍由它自己刷新，逃逸识别能力较弱；TC4x通过多通道让“监控者”和“被监控者”实现了角色分离。

2.2 三个比较寄存器与窗口模式

每个通道都带有一组比较控制逻辑和多个比较值寄存器。实际使用时，你可以为同一个通道配置多个比较值，形成不同的监控策略。

TC4x WTU支持的三种模式，背后是三种不同的监控思路：

• 固定窗口模式（Fixed Window）：设定一个时间窗口，只有在这个窗口内执行刷新才算合法。窗口下边界和上边界都配置在比较寄存器里，常见用法是“最短喂狗周期+最长喂狗周期”，比如要求在上次刷新后5ms到10ms之间完成本次刷新。太早刷新说明代码执行过快、逻辑可能被跳过，太晚刷新说明系统卡顿或中断异常。
• 延迟窗口模式（Delayed Window）：窗口前段是“警告区”，后段是“合法区”。如果你在警告区刷新，WTU不会判失败，但会产生一个Pre-warning事件给SMU；在合法区刷新则完全正常。这种模式适合做两级预警，比如警告事件可以触发一个日志记录或状态翻转，合法区刷新则清掉之前的警告状态。
• 绝对时间戳模式（Absolute Timestamp）：刷新时不要求“窗口内”，而是要求你写入一个预期的绝对时间戳，WTU会比较当前时间和预期时间戳的偏差。这种模式适合事件驱动型刷新。比如外部通信模块每隔不确定的时间间隔请求MCU刷新看门狗，你只需要把“下一跳”的预期时刻算出来写进去，偏差超过阈值就报警。

三种模式各有适用场景，但从实际项目分布来看，固定窗口和延迟窗口占了绝大多数，绝对时间戳模式更多用在网关、域控制器这类时间驱动强、任务跨度大的场景里。

2.3 刷新机制：直接刷新与框架刷新

TC4x的WTU对“刷新动作”本身做了强化设计。TC3xx时代，刷新WDT基本就是“按顺序往几个地址写值”，这种设计最大的软肋是：如果一个硬件故障导致地址总线被钳位、或者某段代码被反复执行，攻击者或异常代码可以通过重放地址序列来“骗过”看门狗。

TC4x提供了两种刷新方式：

直接刷新：往通道对应的刷新寄存器写入一个刷新值，WTU会比较当前时间是否落在合法窗口内。这个刷新值由配置阶段预先计算好，写入后硬件自动完成比较。这个机制比TC3xx强的点在于：刷新值是配置期生成的、带上下文关联的值，篡改刷新寄存器或者重放旧值，硬件比较逻辑会因为“时间不在窗口内”而拒绝。

框架刷新（Framework/Transactional Refresh）：这是一种更严谨的刷新协议。软件需要通过一组连续的总线事务完成刷新，事务序列中带有一个框架值（Framework Value），这个框架值会参与硬件比较。只有总线事务序列完全正确、框架值匹配、刷新时刻落在窗口内，三个条件同时满足，刷新才成功。框架刷新的设计意图很明确：即使异常代码能执行喂狗指令，也很难在不知道框架值的前提下构造出完整、合法的刷新事务序列。这个机制对应到ISO 26262里，就是针对“软件误操作导致安全机制失效”这一类失效模式做的防御。

从安全等级角度给一个建议：ASIL-B以下、跑传统RTOS的应用，直接刷新够用；ASIL-C/D、涉及动力域或底盘域的项目，把框架刷新机制用起来，虽然调试时麻烦一点，但后期的安全论证会好做一些。

2.4 ACU访问确认单元：另一个维度的监控

ACU（Access Acknowledge Unit）是TC4x相对TC3xx真正意义上的新增能力。它监控的是CPU对外设总线的“访问行为模式”——CPU在什么时候、以什么频率、去哪个外设区域做了访问，ACU把这些访问事件和预期行为做对比，一旦发现异常（比如某个受保护外设被非预期访问、总线访问频次异常、带有错误属性的访问），就产生事件上报SMU。

说一个具体应用场景：在一套多核系统里，CPU2在启动后应该只在特定安全任务中访问HSM相关的消息缓冲区，ACU配置为监控CPU2对这个区域的访问行为。如果CPU2跑飞、或者在异常中断里反复去读这个缓冲区，ACU会在很短时间内检测到访问模式异常，并发起报警。这种“访问行为”级别的监控，传统的看门狗完全做不到，因为传统机制根本感知不到总线访问。

把ACU和窗口刷新组合起来使用，就构成了TC4x看门狗体系的两道防线：第一道防线，ACU发现访问行为异常，立即通知SMU；“第二道防线”，即使ACU没有抓住异常，只要CPU没有按时按规范完成刷新，窗口比较逻辑照样会兜底触发报警。两道防线独立工作，任何一道触发，系统都能及时响应。

3. 三种窗口模式的配置逻辑与参数计算

3.1 如何选择模式

芯片手册里把寄存器配置列得很清楚，但真正到工程里，第一步永远不是打开寄存器手册，而是想清楚“你希望看门狗监控到什么程度”。

如果项目只需要防“死循环/跑飞”这种基本故障，固定窗口就够了：它既保证代码在最坏情况下能被及时喂狗，又能识别出“喂狗太早”的异常执行路径。我碰到过不少项目，上线后发现偶发复位，查到最后是某段中断服务函数执行时间抖动大，导致喂狗时间落在窗口下边界之外，用固定窗口一眼就揪出来了。

如果系统有NVM写入、Flash擦除这类长耗时操作，或者希望先给软件一个“自救”的机会再复位，延迟窗口是更好的选择。它在正式报警之前保留一段“黄牌警告区”窗口，软件可以在警告区里执行恢复逻辑。

如果系统是时间驱动型架构，任务执行时间本身就不均匀、但每个任务的预期完成时刻是确定的，那就用绝对时间戳模式。这种模式适合在通信网关、域控这类偏事件驱动、刷新节奏天然离散的平台上使用。

3.2 窗口参数计算实例

假设平台的SPB时钟频率为100MHz，也就是计数周期10ns。我们要把通道0配置成固定窗口模式，期望“上次刷新之后的5ms到10ms之间完成下次刷新”。

计算公式是：

• 窗口下边界比较值 = 下边界时间 / 计数周期 = 5ms / 10ns = 500000（十进制） = 0x7A120
• 窗口上边界比较值 = 上边界时间 / 计数周期 = 10ms / 10ns = 1000000（十进制） = 0xF4240

配置到CPR寄存器之后，软件每次刷新时，硬件会锁存当前TIM0的计数值，并判断这个值相对于“上次成功刷新时刻”的窗口偏移是否落在两个比较值之间。因为计数器是32位自由运行的，窗口值的单位直接就是计数周期，不需要额外做分频换算。

从我实际做项目的经验来看，这里有一个容易被忽视的问题：刷新执行不是瞬时的。从软件发起刷新指令到硬件完成窗口比较，存在总线访问延迟和寄存器同步延迟，在100MHz总线下通常多消耗几个周期到几百个周期不等。低优先级任务里喂狗，延迟可能被调度器拉长到几微秒甚至几十微秒。所以窗口上边界不要掐得太死，至少留出20%到30%的余量，否则系统在正常负载波动时也会偶发复位。比如上面例子中10ms的上边界，实际取8到9ms，或者把窗口设置为5ms到12ms，让出2到3ms的余量，更稳妥。

3.3 最小窗口与最大窗口的安全权衡

窗口设置还有一个功能安全层面的权衡逻辑。窗口下边界太短，等于允许代码在下一次喂狗之前的极小时间窗内执行大量未受控操作，监控粒度变粗；窗口上边界太长，等于可以容忍系统长时间卡死，安全反应时间变长。ISO 26262里面有一个概念叫“安全时间间隔”，它定义了从故障发生到安全措施生效的最大允许时间。看门狗窗口的上边界，必须小于等于这个安全时间间隔。

所以我的建议是：加窗口参数之前，先和系统架构师确认三个数字——当前任务最长阻塞时间、安全状态建立所需时间、安全时间间隔。这三个数字直接决定窗口的上下边界，而不是随手填一个看起来合理的值。

3.4 绝对时间戳模式下的计算差异

绝对时间戳模式的配置逻辑和窗口模式不太一样，它不需要比较“两次刷新之间的时间间隔”，而是要软件计算“下一个预期刷新时刻”的绝对计数值，并在刷新时写入。比较逻辑检查当前TIM值和预期绝对值的偏差是否在允许容差内。

这种模式下，重点在于任务调度器对“绝对时间”的把握。比如当前TIM值为0x0010F000，预计下一个安全任务将在2ms后执行，那么预期的刷新时间戳就是当前值加上200000（100MHz下2ms对应的计数值），但这个值要在刷新时刻写入，写早了写晚了都会产生偏差。因为存在调度延迟，通常可以在预期值上再加一个小的提前余量，让比较值落在容差范围内。

这个模式配套使用的场景是：多个安全任务都可以触发刷新，但每次刷新的预期时刻由最新的调度结果确定，从而实现“动态刷新周期”。设计得当的话，可以既保证监控密度，又不被固定窗口周期绑死。

4. 初始化配置与刷新实操流程

4.1 复位后的默认状态与时钟依赖

TC4x复位后，WTU默认处于运行状态，但此时外部时钟配置可能还没完成，如果过早访问WTU寄存器或者过早使能窗口比较，容易产生误报警。所以初始化WTU的正确时机，是在系统时钟树稳定、SPB频率确定之后进行，这一点和TC3xx平台的习惯一致。

另一个和TC3xx有明显差异的点是：TC3xx的WDT配置模块受ENDINIT保护，要改配置先得解锁ENDINIT；TC4x的WTU改用内部事务保护机制，配置流程更简洁，但前提是严格按照“先配置比较值、再配置刷新方式、最后使能/启动”的顺序执行。如果配置顺序倒过来，比如先使能了刷新窗口比较、再写比较值，硬件可能因为“窗口值尚未有效”而直接判定下一次刷新非法。

4.2 初始化代码示例

下面给一个基于寄存器操作的示意代码（具体寄存器名称和偏移以TC4x用户手册为准，不同子型号会略有差异，代码体现的是配置逻辑）：

/* 假设已经获取到SPB时钟频率，单位Hz */ uint32_t spb_freq = get_spb_frequency(); /* 例如 100MHz */ uint32_t tick_ns = 1000000000U / spb_freq; /* 每个计数的纳秒数 */ /* 窗口边界：5ms ~ 10ms */ uint32_t lower_bound_cnt = 5U * 1000U * 1000U / tick_ns; /* 500000 */ uint32_t upper_bound_cnt = 10U * 1000U * 1000U / tick_ns; /* 1000000 */ /* 1. 选择通道0，配置为固定窗口模式 */ WTU->CH[0].CFG |= WTU_CFG_MODE_FIXED_WINDOW; /* 2. 写窗口下边界和上边界比较值 */ WTU->CH[0].CPR0 = lower_bound_cnt; WTU->CH[0].CPR1 = upper_bound_cnt; /* 3. 配置刷新方式：直接刷新 */ WTU->CH[0].FCR |= WTU_FCR_DIRECT_REFRESH; /* 4. 选择通道0的刷新归属，比如CPU0 */ WTU->CH[0].CFG |= WTU_CFG_REFRESH_OWNER_CPU0; /* 5. 使能通道0，启动窗口比较 */ WTU->CH[0].CFG |= WTU_CFG_ENABLE;

这段代码体现的配置顺序很重要：先写比较值，再选刷新方式，再定刷新归属，最后使能。实测中这个顺序最稳妥，避免寄存器处于中间状态时产生误报警。

4.3 刷新函数与调用位置

初始化完成后，周期刷新逻辑本身并不复杂。直接刷新模式下，刷新动作就是在窗口内把通道的刷新值写到刷新寄存器：

void wtu_ch0_refresh(void) { /* 写入刷新值，硬件会自动比较窗口 */ WTU->CH[0].RELOAD = WTU_RELOAD_VALUE; }

真正的难点在于刷新函数的调用位置。我把几个常见做法和各自的风险列一下：

我个人的工程结论是：不要把WTU刷新放在普通中断里。前面说过，中断风暴会让看门狗完全失去监测意义。比较合理的架构是：看门狗刷新放置在一个独立的高优先级安全任务里，这个任务只做采集各核心跳、刷新WTU、清报警标志这三件事。其他所有的应用任务与看门狗没有直接关系。

4.4 框架刷新的实现差异

框架刷新模式下，刷新动作不是单一寄存器写入，而是需要按顺序执行几次事务访问，事务序列中携带着配置阶段生成的框架值。代码上看起来类似：

void wtu_ch1_framework_refresh(void) { /* 第一次写：更新框架偏移 */ WTU->CH[1].FRAME = WTU_FRAME_BASE + offset_1; /* 第二次写：触发框架校验 */ WTU->CH[1].TOGGLE = 0x01U; }

注意，框架值的生成必须在系统初始化阶段固定下来，并且需要在内存里单独存放。框架刷新的事务序列表述在手册里的细节比较多，各个子型号的地址映射差异也大，这里只给出思路。工程上如果SHE/HSM有独立的看门狗刷新需求，框架刷新几乎是必选项，因为HSM侧对“外部伪刷新”的防御要求更高。

4.5 初始化阶段的死锁陷阱

初始化WTU过程中最常见的一个死锁：你把窗口比较使能打开了，但软件里负责喂狗的任务还没创建。在RTOS启动阶段，从WTU使能到第一个安全任务开始运行，中间如果超过了窗口上边界，就会触发复位。

解决办法有两种：一种是在RTOS启动前，先用一个“初始化预告”刷新值把窗口“顶”到足够宽的区域（比如10秒），等所有任务就绪后再把窗口收紧到正常运行值；另一种是把使能WTU的时机推迟到第一个安全任务创建完成之后。两种方法我都用过，后者更简单，但需要保证“从复位到使能WTU”之间的无保护窗口在整个项目里是可控且被评审过的。

5. 多核系统里的看门狗策略设计

5.1 双通道的多核分配方案

TC4x平台最多可以跑到六核，多核场景下看门狗策略的复杂度和单核完全不在一个量级。合理的做法是：把WTU的两个通道当成独立的“监控摄像头”，分别对准不同的监控对象。

典型分配方案：

• 通道0：分配给主核（CPU0），负责监控“整车控制主循环”的运行节奏，由CPU0的安全任务刷新；
• 通道1：分配给安全域或HSM/SHE，监控安全软件的运行节奏，由HSM固件或SHE上下文刷新。

这种分配方式的好处在于，HSM/SHE侧拥有独立的刷新通道，不受CPU0上的调度抖动影响。很多新平台项目的安全要求是“即使主核跑飞，安全域仍然能独立执行降级策略”，双通道正好支撑这种架构。

另一种分配方案是“单被监控者、双通道冗余”：两个通道配置为同样的窗口，由同一个安全任务同时刷新，任何一个通道超时都会触发报警。这样即使其中一个通道因硬件原因失效，另一个通道也能兜底。代价是需要同时维护两套刷新上下文，软件复杂度会上升。

5.2 多核心跳与硬看门狗的组合

在核数较多（4核及以上）的平台上，单纯依赖WTU窗口刷新无法监控到每一个核的执行状态——WTU只有两个通道，但可能四个核都需要被监控。这时候通用的做法是“软心跳+硬看门狗”的组合：

• 每个核维护一个心跳计数变量，周期性地把自己的心跳值递增；
• CPU0的安全任务周期性地检查其他核的心跳值是否在正常推进；
• 只要有一个核的心跳推进停滞，安全任务就不刷新WTU（或者做一次非法刷新），让看门狗自然超时复位；
• 如果安全任务自身跑飞，WTU窗口也会兜底复位。

这个方案的精髓在于：看门狗不只监控代码的喂狗行为，而是通过“喂狗行为是否发生”来反向推导整个多核系统是否健康。我在实际项目里更倾向把“心跳检查”和“WTU刷新”放在同一段代码里，确保两者之间存在严格的因果链：心跳异常——不刷新——看门狗超时——复位。

5.3 SMU联动与两级报警架构

TC4x的WTU报警路由是走SMU（安全管理单元）的，这给了系统设计很大的灵活性。你可以把WTU通道0超时配置成“触发SMU报警→SMU产生中断→软件记录故障并尝试恢复”，通道1超时配置成“触发SMU报警→SMU直接发起系统复位”。两条路径可以共存。

这就是典型的两级看门狗架构：

• 第一级：可恢复故障。看门狗超时但还在“黄牌”阶段，触发执行恢复逻辑，比如重置故障任务、切换到降级运行模式；
• 第二级：不可恢复故障。软件没有在规定时间内完成恢复，或者恢复尝试失败，直接复位系统，回到初始化状态重新开始。

实现两级架构的关键在于延迟窗口模式——只有延迟窗口才能提供“警告区域”和“合法区域”两个阶段。工程上可以先配置一个较宽的延迟窗口，然后根据实际运行情况逐步收紧警告区范围。这个“从宽到紧”的调参过程，建议在整车上做完整的失效注入测试，不要只跑台架测试，因为车载环境下的EMC干扰、电源波动会让窗口参数的行为和实验室里完全不同。

5.4 安全域复位的独立性问题

最后提一个安全架构层面的注意点：如果主核和HSM共用同一个复位源，那么“主核跑飞→看门狗复位→整个系统复位”这个链路中，HSM也会被一起复位，降级策略可能来不及执行。因此在高安全等级设计里，要确认HSM/SHE是否有独立的复位源，或者让HSM通过专用通道监控主核故障而不受系统复位影响。

这个问题在硬件设计阶段就要确认清楚，软件只能做一些补充，比如把关键降级参数存放在HSM的保留RAM中，让系统复位后HSM固件能快速恢复降级决策状态。WTU的两个通道在这里也能派上用场：一个通道负责复位系统，另一个通道只发事件给HSM而不复位HSM域，实现“部分复位”效果。

6. 常见问题与排查技巧实录

6.1 喂狗立刻复位：配置顺序错了

现象：初始化代码执行完WTU使能后，紧接着第一次喂狗，系统直接复位。

排查思路：先确认使能WTU前比较值是否已经写入；再确认比较值是否被正确换算成计数周期；最后确认刷新方式是否和寄存器配置一致。最常见的原因是：窗口值寄存器默认是0，而0会被判定为非法窗口，第一次刷新直接失败。

6.2 系统偶发复位，频率无规律

现象：车辆运行过程中，一段时间一切正常，某次颠簸或干扰之后复位，频率不定，间隔从几秒到几十分钟都有。

排查思路：这种问题优先怀疑窗口上边界太窄。用调试器抓复位原因寄存器，确认复位源是WTU超时后，先放大窗口上边界（比如把余量从10%扩到30%），观察故障频率是否显著下降。如果下降明显，说明原始窗口确实太紧，需要重新分析任务最大执行时间。

我遇到过一次棘手的案例：窗口上边界放到50%余量后仍然偶发复位，最后用逻辑分析仪抓总线访问，发现是某个DMA传输的优先级配置过高，在安全任务刷新WTU的瞬间抢占了总线，导致刷新事务被延迟了几个毫秒。这类问题在纯软件层面看根本不可能出错，但总线仲裁和刷新时序叠加在一起，就形成了“看不见的延迟”。

6.3 调试暂停时系统复位：调试模式没配

现象：连接调试器，在断点处暂停程序，系统直接复位，完全没办法单步调试。

原因：WTU使能后，调试器暂停核心会让喂狗任务无法执行，窗口超时后触发复位。TC4x支持调试模式相关配置，在调试会话中可以暂停看门狗计时，但这个配置默认不开启，需要在调试器初始化脚本中提前设置。

解决办法：在调试器连接脚本（比如UDE/ADS的初始化脚本）里配置WTU的调试暂停位，使仿真暂停时看门狗计时同步暂停。只要配置了这个位，断点调试就不再触发看门狗复位。

6.4 多核环境中刷了别人的狗

现象：两个通道都使能后，A核的任务去刷新通道1，导致通道1的窗口比较错乱，误触发报警。

原因：TC4x的WTU允许所有核访问同一组寄存器，但谁负责刷新哪个通道，需要在初始化时明确并写进配置。如果通道分配给了HSM，应用核就不应该再访问该通道的刷新寄存器。

排查方法：给每个通道的刷新函数加上调用者标识参数，在刷新函数入口断言当前核ID和配置的归属一致。这个断言在发布版本里可以关掉，但在开发阶段能省很多时间。

6.5 窗口值换算错误导致报警时间提前

现象：配置窗口下边界为5ms，但实际在3ms左右就触发了报警。

排查方向：确认SPB频率配置。很多工程师用内核频率去算窗口值，但WTU的计数源是SPB时钟，两者可能不同。如果内核200MHz、SPB是100MHz，用内核频率算出来的比较值恰好是正常值的两倍，窗口比较时机自然提前。

建议把SPB频率获取函数抽象出来，在初始化阶段统一获取，不要在多个模块里各写一份“时钟频率”常量。

6.6 排查技巧速查表

TC4x的WTU是一个值得花时间读懂的安全基础设施。我在实际项目里踩过的坑，几乎都集中在“把新模块当成旧习惯来用”这件事上：用TC3xx的思维写TC4x的喂狗代码，把框架刷新当成普通寄存器操作，在多核平台上不做刷新归属设计。抛开寄存器层面的差异，WTU这套新机制真正启发我的地方在于，它把看门狗从“最后的保底手段”提升到了“主动监控系统健康度”的位置——窗口、框架刷新、访问确认这三个能力组合起来，能做很多以往不敢想的诊断逻辑。建议拿到新板子之后，先把WTU的三种窗口模式各跑一遍，再设计安全监控策略，这个过程本身就会加深对TC4x平台整体安全架构的理解。