cc2640看门狗

          cc2640的协议栈使用的是ti的rtos，稳定性还是很不错的，而且公司做得产品电池是可拆卸的，所以一直没有在项目中使用过看门狗，但是使用的人多了以后，有几个反应程序会跑飞的用户，当然这是极少数情况，所以很难复现和排除原因。于是想到了添加看门狗。

         ti关于看门狗这块的资料还是蛮少的，所以添加过程中有很多疑问，最终经过自己研究实验，总结了一些经验，由于没办法模拟之前跑飞的现象，所以没有经过验证，仅供参考。

         1、首先ti官方协议栈里面是有看门狗的api的，所以可以方便的添加相应的文件到自己的工程，直接调用官方api。

         2、至于清除中断标志放到哪里合适？为了方便放到了KeyFobDemo_taskFxn的for循环里，通过观察发现，如果打开了POWER_SAVING，那么在没有操作的情况下，这个for循环也是不工作的，所以觉得放到这里可能会错过清除中断，从而引起系统频繁重启，那么想到了添加一个定时器来清中断。可是这样做保证了设备不会错误重启，但是低功耗就得不到保证了，所以这是下下策，除非是迫不得已，不然不会选择。后来查阅文档发现，在进入休眠模式的时候，看门狗的timer也是不工作的，这样就不必担心进低功耗引起重启的问题了，经过实际测试发现的确如此。（需要继续验证，不能保证）

         3、添加了看门狗之后发现不能进行oad了，每次都失败，以至于把自己的设备弄成不能更新了。还好一个巧合的原因发现了这个问题，不然几万的设备升级这个版本后，都不能再升级，那会引起多么严重的后果。想想都后怕。经过排除发现是oad数据传输完成后，校验需要5s左右的时间，这段时间是不会跑进KeyFobDemo_taskFxn这里去的，所以看门狗的时间如果小于这个校验时间，则完不成校验，所以每次都会失败，解决方法是在oad之前加大看门狗定时时间。

         以上都是自己研究的结果，可能会存在一些问题，欢迎大家指正，另外关于2中的观点，不能保证完成正确，需要进一步验证、

经过学习验证之后，喂狗可以用以下两种方式实现：

一、把watchdog timer溢出的时间设置为最大1s，然后把它加在下面for循环内：

void osal_start_system( void )
{
#if !defined ( ZBIT ) && !defined ( UBIT )
for(;;) // Forever Loop
#endif
{
osal_run_system();
//feed watchdog
}
}

二、使用watchdog的callback函数进行喂狗操作：

1. void wdtCallback(UArg handle)   
2. {  
3.     Watchdog_clear((Watchdog_Handle)handle);  
4. }  
5.   
6. void wdtInitFxn()   
7. {  
8.     Watchdog_Params wp;  
9.     Watchdog_Handle watchdog;  
10.     Watchdog_Params_init(&wp);  
11.     wp.callbackFxn    = wdtCallback;  
12.     wp.debugStallMode = Watchdog_DEBUG_STALL_ON;  
13.     wp.resetMode      = Watchdog_RESET_ON;  
14.   
15.     watchdog = Watchdog_open(Board_WATCHDOG, &wp);  
16.     Watchdog_setReload(watchdog, 1500000); // 1sec (WDT runs always at 48MHz/32)  
17. }