在VxWorks里做看门狗，最容易混掉的是两件事，一件是定时器本身怎么建，另一件是超时以后到底让谁来处理后续动作。官方文档把这条线分得很清楚，看门狗先用`wdCreate`创建，再用`wdStart`以tick为单位启动，超时后回调函数默认在系统时钟ISR上下文里执行，所以配置阶段就要把“定时触发”和“后续处理”拆开设计。

　　一、VxWorks看门狗怎么配置

　　先把看门狗对象和时间单位理顺，再去写业务逻辑，会比后面一边报错一边改回调更稳。看门狗不是一次性函数，而是一套创建、启动、取消、删除的完整流程。

　　1、先用`wdCreate`创建看门狗

　　看门狗必须先创建，拿到`WDOG_ID`以后，后面才能启动、取消和删除。没有这一步，后面的`wdStart`就没有合法对象可用。

　　2、再用`wdStart`启动超时

　　`wdStart`需要给出三个核心信息，也就是延时tick数、超时后要执行的函数以及传给该函数的参数。这里的时间单位不是毫秒，而是系统tick，所以如果你的需求是按秒或毫秒算，前面就要先按系统时钟频率换算。

　　3、需要续期时直接重新`wdStart`

　　同一个看门狗如果要刷新超时时间，不必先删再建，直接再次启动即可。真正日常使用里，这就是最常见的喂狗动作。

　　4、任务结束或逻辑取消时用`wdCancel`和`wdDelete`

　　如果只是本次超时不再需要，可以先`wdCancel`；如果对象本身也不再使用，再继续`wdDelete`。这样做能避免旧定时器还挂在系统tick队列里，后面引出误触发。

　　二、VxWorks看门狗超时后怎么处理

　　超时处理最怕写得太重。因为官方文档已经明确说明，看门狗回调运行在系统时钟ISR上下文里，所以它要遵守ISR限制，不能在里面做会阻塞的事。更稳的做法，是让回调只负责发信号或投递消息，把真正的恢复、清理和重启动作放到任务上下文里做。

　　1、回调里优先做轻量通知

　　最常见的处理方式，就是在超时回调里`semGive`一个同步信号量，唤醒专门的监控任务。官方示例本身就展示了ISR通过`semGive`通知任务继续处理事件的用法，这种思路同样适合看门狗超时。

　　2、也可以用消息队列转给后台任务

　　如果你不仅想通知“超时了”，还想把对象编号、通道号或错误码一起带过去，更适合在回调里用`msgQSend`，并把超时参数设成`NO_WAIT`。官方文档明确写到，这个调用可以在ISR中使用，但在中断上下文里不能等待。

　　3、不要在回调里做阻塞或复杂处理

　　看门狗回调受ISR约束，像`semTake`这类会阻塞的操作本来就不能在ISR里调用。也正因为这个限制，超时后的资源回收、日志整理、状态迁移和重试决策，更适合交给被唤醒的任务去做。

　　4、需要周期性超时时在回调里重新启动

　　如果你做的是周期性巡检，而不是一次性超时，那么回调或后续任务可以在本轮处理完以后重新`wdStart`。这样比新建多个看门狗对象更稳，也更容易控状态。

　　三、VxWorks看门狗配置后先查什么

　　很多问题不是看门狗不会用，而是时间单位、上下文限制和处理顺序没有先想清楚。把这几项先查一遍，通常比反复改回调函数更省时间。

　　1、先查tick换算是不是对的

　　`wdStart`用的是tick，不是毫秒。系统时钟频率不同，同样一个数字对应的真实超时时间也不同，所以超时不准时先看`sysClkRateGet`这一层。

　　2、再查回调里有没有放了阻塞调用

　　如果回调里混进了等待型操作，问题通常不在看门狗本身，而在上下文用错。凡是要等待资源、等待队列或等待时钟的逻辑，都不适合直接放进看门狗回调。

　　3、最后查通知链路是不是闭环

　　如果回调已经正常触发，但业务层还是“像没处理”，那就继续看`semGive`或`msgQSend`后面有没有对应任务在接，任务优先级是不是合理，消息队列是不是会满。这一层顺了，看门狗超时处理才算真正闭环。

　　总结

　　VxWorks看门狗怎么配置，核心就是先`wdCreate`，再按tick用`wdStart`启动，需要时用`wdCancel`和`wdDelete`收口。VxWorks看门狗超时后怎么处理，更稳的做法则是让回调只做ISR安全范围内的轻量通知，例如`semGive`或`msgQSend`，再把真正的恢复动作放到任务上下文里。把“计时”和“处理”这两层拆开以后，看门狗会比一味把逻辑塞进回调里稳定很多。