调用wdStart后没有看到预期日志，很容易怀疑定时器没有启动。但实际情况可能是超时单位算错、定时器被反复重启，或者回调已经进入，日志却没有正常输出。VxWorks的wdLib提供的是软件看门狗定时器，配置时既要核对计时条件，也要注意回调的执行限制。下面以内核侧使用方式为例，说明配置流程和排查方法。

　　一、VxWorks如何配置看门狗定时器

　　这里讨论的wdLib与板卡硬件看门狗需要分开理解。软件定时器到期后调用指定函数，并不会仅因创建成功就自动复位设备。

　　1、创建对象并明确使用位置

　　①确认目标镜像包含看门狗及所需的创建、删除支持，在代码中包含vxWorks.h和wdLib.h。

　　②调用wdCreate，保存返回的WDOG_ID，并检查是否创建成功。

　　③由初始化流程统一管理对象，避免不同模块覆盖同一个标识。

　　wdLib用于内核侧。RTP用户态需要按版本支持选择相应定时机制，不能直接套用内核看门狗流程。接口参数类型也应以当前SDK头文件为准。

　　2、换算延时并启动计时

　　①通过sysClkRateGet获取系统时钟频率，将目标时间换算为tick。

　　②调用wdStart，传入看门狗标识、延时tick数、回调函数和参数。

　　③检查返回值，失败时立即保存错误码，再进行日志记录。

　　④对短时间换算检查整数截断，确保不会意外得到0；同时检查长延时是否超出参数范围。

　　例如，系统时钟为100 Hz，约1秒对应100 tick。不能把100毫秒直接填成100。实际触发还受tick边界和系统执行条件影响，因此不宜把它当成高精度硬件定时输出。

　　3、让回调只做必要动作

　　①按当前版本要求声明回调函数，核对参数类型，尤其避免在64位环境中把地址强制压入int。

　　②回调中仅保留简短、可在中断限制下执行的操作，例如通过允许的通知接口唤醒工作任务。

　　③将文件操作、复杂日志、网络处理及其他可能阻塞的工作放回任务中执行。

　　一次wdStart通常只触发一次。需要周期执行时，应明确安排重新启动，并检查每次启动结果；否则第一次回调结束后没有下一次，是接口语义，并非定时器失效。

　　二、VxWorks定时器回调未触发如何检查

　　排查时可以先把回调缩减为最小动作，确认“有没有进入”，再验证通知和业务处理。这样能够避免把后续处理失败误判为定时器没有到期。

　　1、启动调用是否真正成功

　　①记录wdCreate、wdStart的结果及对象标识，确认启动路径确实执行。

　　②检查错误分支是否提前返回，以及初始化后是否替换过WDOG_ID。

　　③将回调地址与实际加载模块对应，确认模块尚未卸载、函数地址仍有效。

　　只在创建位置打印“初始化成功”，不能证明后面的wdStart也成功。创建和启动应分别检查。

　　2、是否一直有人重新开始计时

　　①查找同一对象上的全部wdStart、wdCancel和wdDelete调用，记录调用时间与来源。

　　②对照超时长度，检查是否在到期前反复调用wdStart。

　　③检查退出、异常恢复和模块重载分支，确认没有提前取消或删除对象。

　　对同一个标识再次调用wdStart，会替换之前的计时安排。假设超时为2秒，而某个循环每秒重启一次，只要循环继续运行，回调就可能始终等不到到期时刻。

　　3、系统时钟和回调执行是否被拖延

　　①在任务上下文中间隔读取系统tick，确认计时正常推进，并核对时钟频率。

　　②检查长时间关中断、耗时中断处理及异常内核执行路径。

　　③镜像包含显示支持时，使用wdShow查看对象状态、剩余tick及回调信息。

　　wdLib依赖系统时钟机制。某些版本还存在延后处理路径，分析时应结合对应版本说明。wdShow显示的只是查询时刻状态，不能单凭一次结果断定回调从未执行。

　　4、没有日志是否等于没有进入回调

　　①移除回调中的printf、等待锁、taskDelay等不适合该执行环境的操作。

　　②使用平台支持的原子计数或轻量事件记录确认入口执行，再由任务读取并输出。

　　③若回调通过信号量或消息队列通知任务，检查通知结果、接收对象及工作任务状态。

　　④核查回调参数指向的数据是否仍有效，排除局部变量失效或对象提前释放。

　　看门狗回调应遵守中断服务程序限制。即使某些版本会在特定情况下延后执行，也不应据此在回调中加入可能阻塞的操作。

　　三、VxWorks看门狗怎样验证监控逻辑有效

　　回调能够执行，只验证了定时机制。用于任务健康监控时，还要确认重新计时与被监控任务的实际进展有关。

　　1、让任务进展决定是否重新计时

　　①在任务完成指定工作阶段后更新健康状态，由监控逻辑检查后决定是否调用wdStart。

　　②在测试环境中暂停健康状态更新，确认经过约定时间后能够进入超时处理。

　　③再恢复正常执行，检查健康状态更新和超时处理之间是否存在竞态。

　　如果独立监控任务不检查业务状态，只按固定周期重启看门狗，那么业务任务即使停止工作，定时器也可能一直不到期。这种现象属于监控逻辑没有覆盖故障。

　　2、退出时处理仍可能执行的回调

　　①先阻止新的启动和重新计时，再按流程取消定时器。

　　②确认回调及其通知的工作不再访问相关资源后，删除对象并释放上下文。

　　③模块卸载和SMP环境中，额外核查回调与清理流程的同步，不能把取消操作当成所有回调均已结束的证明。

　　总结

　　看门狗回调未触发，值得先查启动结果、tick换算和重复启动，再看系统时钟及回调内部动作。日志没有出现，也要区分是入口未执行，还是输出、通知或后续任务出了问题。用于健康监控时，重新计时还必须反映业务进展，才能发现任务停滞。希望这些检查方法能帮助大家把定时机制与监控逻辑分别验证清楚，减少现场反复试改。后续使用VxWorks如有相关需求，欢迎联系我们交流。