在实时系统里进行超时监控的时候，经常会碰到这样的问题，就是VxWorks的看门狗定时器应该怎样去使用，还有如果看门狗的回调函数没有被执行，那又该怎样去处理。VxWorks自身携带的那套软件看门狗，它是依赖系统的时钟节拍来工作的，等到设置好的时间到达以后，就会去运行那个事先指定的回调。用它来触发超时通知、对状态的变化进行标记，或者把一个任务唤醒，这些是比较合适的，但是这个回调在运行的时候，它所处的那个环境是受到很多限制的，一些比较复杂的业务处理，是不能直接交给它去完成的。在使用的过程中，应该把对象的创建、时间怎样去换算、回调怎样去设计，还有出现了问题怎样去查找，这几件事情给分开来，逐个去应对。

　　一、VxWorks看门狗定时器怎么使用

　　VxWorks看门狗在使用的时候，一般是按照先创建一个对象，再把它启动起来，让它去计时，时间到了就去执行回调，最后再把对象释放，这样一个顺序来进行的。真正容易出现问题的地方，倒不是那几个函数本身怎样去调用，而是在tick这个单位进行换算的时候没有弄准确，又或者是在回调里面，让它执行了不合适的操作。

　　1、创建看门狗对象

　　通过【wdCreate】来创建一个看门狗，创建完成以后，要去查看它返回的那个WDOG_ID，是不是一个有效的标识。

　　如果创建就已经失败了，那么后面的启动接口就不应该再接着去调用。看门狗的那个对象，是可以保留下来重复使用的，并不是说每一次超时，就一定要重新去创建一个。一直等到这个模块要被卸载，或者这个功能不再继续使用了的时候，才去使用wdDelete把它清理掉，以免资源一直被占用着。

　　2、按系统节拍设置时间

　　去调用【wdStart】的时候，里面那个负责延时的参数，使用的是系统自己的tick单位，并不是说可以直接就把毫秒或者秒填写进去。

　　程序可以先去获取系统时钟的频率，然后再把业务那边需要的超时时间，用这个频率换算成tick的数目。比如，系统时钟的频率如果是100Hz，那么两秒钟的延时，大致就是要给出两百个tick。在换算的时候，还要注意不要让算出来的结果变成零，也不要让整数溢出，另外，如果系统的时钟频率在后来被修改过了，也不要还在那里沿用以前的旧数值。

　　3、让回调只负责发出通知

　　在回调的那个函数里面，要让它尽量只去修改状态的标记，把一个计数器往上递增，或者是给那个负责监视这件事的任务，发送一个不会把它阻塞的通知。那些复杂的日志记录、对文件的读写、会耗去较长时间的计算，还有那种可能会停在原地等待的操作，都应该交给普通的任务去完成，否则的话，是有可能对系统时钟那一侧的处理造成干扰的，严重的时候，还会引出新的实时性方面的问题。

　　二、VxWorks看门狗回调不执行怎么办

　　当回调没有运行起来的时候，不能仅仅是知道在回调函数的里面去添加一些打印信息。问题有可能发生在创建的时候、启动的时候、计时的阶段，或者被取消掉了，再不然就是在进入回调的那个入口附近，好几个环节都有可能，所以需要先弄清楚，这个看门狗它是不是真的已经被顺利地启动了起来。

　　1、检查启动返回结果

　　每一次调用完wdStart之后，都一定要去查看它返回的那个状态，同时把看门狗的ID、延时具体是多少个tick，还有是在什么时间启动的，都记录下来。假如这个接口直接就返回了一个ERROR，那就说明问题是出在启动的那一个步骤上了，也就不必再继续等待回调的到来了。在这种时候，就应该去检查那个对象是否还有效，给出的参数是不是正确的，以及这个对象是不是在之前就已经被删除掉了。

　　2、检查回调声明和参数

　　回调函数的那个类型，一定要跟当前使用的这个VxWorks版本，以及目标是运行在什么架构上的要求对应上。那种原本是32位的工程，如果要迁移到64位的平台上面去，却仍然在那里把地址或者对象的指针，强制转换成普通的int类型去传递，那么参数就很有可能会被截断掉一段，在进入回调的那个入口处，也可能直接就发生异常。可以先把它替换成一个极其简单的回调，不使用任何参数，先去看看定时触发这一步是不是正常的，等到它没有问题了，再一点一点地把先前的那一套处理逻辑恢复回来。

　　3、检查是否被取消或覆盖

　　同一个WDOG_ID，如果还没有到达超时的时间，就被人用wdCancel给取消掉了，那么这个回调它是不会去执行的；如果又被人用wdStart给重新调用了一次，那么原来设置好的时间，还有那个回调，也就会被新给进去的那一套设置给覆盖掉。当有多个任务都去争着使用同一个看门狗对象的时候，这一类的麻烦，就会更加容易地暴露出来。需要去把所有的启动、取消，还有删除的那些调用位置，都检查上一遍，并且做到每一个看门狗，都只交给一个任务去清晰地管理。

　　三、VxWorks看门狗问题怎么进一步定位

　　如果wdStart返回的结果是正常的，时间也已经明显超过了，但是在业务的那一层，还是完全没有观察到处理的迹象，到了这一步，就需要去区分清楚，到底是回调它根本没有进去过，还是说确实进去了，只不过在执行的时候没能顺利通过。那个软件的看门狗，它是需要依靠系统的时钟才能存活的，它自身也是存在一个能力范围的边界的。

　　1、使用最小回调验证

　　可以让回调只去做一件事情，就是把一个用volatile修饰的计数器往上增加，然后再让一个普通的任务，每隔一段时间就去读取一下这个数值，并且把它输出出来。不要把printf打印出来的那些东西，当作是判断的唯一依据，因为在那种受到严格限制的环境里面，平常用来输出的那些函数，它不一定能够正常地工作。计数器的那个数值如果发生了变化，就说明这个看门狗它已经触发过了，那么问题就应该回过去，在原先那套回调的逻辑里面，逐渐地去查找。

　　2、检查回调中的受限操作

　　如果在回调里面，调用了taskDelay，获取了那种会把自己挂起的信号量，使用了跟文件有关的那些接口，又或者是别的什么可能会停在原地等待的函数，那么系统就说不定会发生异常，或者干脆就卡住不动了。在这种时候，就应该去查看异常留下来的那些记录，观察任务当前处于什么状态，还有调用的那个栈，然后把那些复杂的处理，都转移到一个专门的监控任务里面去，让回调它只负责完成通知的动作。

　　3、区分软件与硬件看门狗

　　VxWorks的那套软件的看门狗，它是依赖系统时钟的中断才能够运转的。要是CPU已经完全失去了控制，系统的时钟停止了，再或者中断被关闭了很长一段时间，那软件的回调，也是没有办法再继续运行的。如果要求在整个系统都陷入失效的时候，能够自动地去把设备复位一下，那就需要把芯片上面，或者板卡上面自带的那个硬件的看门狗给利用起来。软件的看门狗，用来监视局部那些任务的超时，是比较合适的，硬件的看门狗，就专门去负责整个系统级别的失控恢复，这两样东西，是可以相互配合在一起来使用的。

　　总结

　　VxWorks看门狗定时器怎么使用VxWorks看门狗回调不执行怎么办，这里面非常关键的一点，是要把WDOG_ID正确地建立起来，按照系统的tick去把延时设置准确，再让那个回调始终保持短小、可靠，并且不会发生阻塞的状态。回调如果没有动静，就应该顺着去检查启动时返回的结果、函数是怎样声明的、参数的宽度、有没有被反复地启动和取消，然后再利用那个最小的回调，去判断问题是出现在了哪一个环节上。如果是遇到了整个系统都发生了失控的情况，那还需要把硬件的看门狗给补充上去，不能仅仅依赖软件的那一套定时机制。