|
软件WATCHDOG的问题
分类：非技术问题 平凡 (1899-12-30)
前一段时间有朋友在讨论这个问题，虽有很好的发言，但仍觉有问题，转贴周教授的文章，虽是1995年的，但仍很有价值
MCS51系列单片机软件抗干扰技术中的误区
周航慈
摘要：文章指出了一种广泛流传的误解：在MCS-51系列单片机中，只要用指令使程序从起始地址开始执行，就可以复位单片机，摆脱干扰。通过一个简单的实验，揭示了软件复位的可靠方法。
有的单片机（如8098）有专门的复位指令，某些增强型MCS-51系统单片机虽然没有复位指令，但片内集成了WATCHDOG电路，故抗干扰也不成问题。而普及型MCS-51系列单片机（如8031和8032）既然无复位指令，又不带硬件WATCHDOS，如果没有外接硬件WATCHDOG电路，就必须采用软件抗干扰技术。常用的软件抗干扰技术有：软件陷阱、指令冗余、软件WATCHDOG等，它们的作用是在系统受干扰时能及时发现，再用软件的方法使系统复位。所谓软件复位就是用一系列指令来模仿复位操作，这就是MCS-51系列单片机所特有的软件复位技术。
现用一简单的实验说明，实验电路如附图所示。接于仿真插座P1.0的发光二极管LED0用来表示主程序的工作情况，接于P1。1的发光二极管LED1用于表示低级中断子程序的工作情况，接于P1。2的发光二极管LED2用来表示高级中断子程序的工作情况，接于P3。2口的按钮用来设立干扰标志，程序检测到干扰标志后故意进入死循环或掉进陷井，模仿受干扰的情况，从而检验各种复位方法的实际效果。寮验初始化程序如下：
ORG 0000H
STAT: LJMP MAIN ;复位入口地址
LJMP PX0 ;按钮中断向量（低级中断）
ORG 000BH
LJMP PT0 ;t0中断向量（低级中断）
ORG 001BH
LJMP PT1 ;T1中断向量（高级中断）
ORG 0030H
MAIN：
CLR EA
MOV SP，#7
MOV P1，#0FFH
MOV P3，#0FFH
MOV TMOD，#11H
CLR 00H ;干扰标志初始化
SETB ET0
SETB ET1
SETB EX0
SETB PT1
SETB TR0
SETB TR1
SETB EA
LOOP: CPL P1.0 ;主程序发光二极管LED闪烁
MOV R6,#80H
MOV R7,#0
TT1:
DJNZ R7,TT1
DJNZ R6,TT1
SJMP LOOP
PX0:
SETB 00H ;设立干扰标志，模拟发生干扰
PT0: CPL P1.1 ;低级中断程序发光二极管LED1闪烁
RETI
PT1: CPL P1.2 ;高级中断程序发光二极管LED2闪烁
RETI
END
实验步骤如下：
1． 按上述程序启动执行，三个发光二极管都应闪烁（否则应先排除故障），表示主程序和各中断子程序正常。因模拟干扰标志未加检测，故不受按钮影响。
2． 修改主程序如下，按下按钮后主程序即掉入死循环中。
LOOP: CPL P1.0
MOV R6,#80H
MOV R7,#0H
TT1: DJNZ R7,TT1
DJNZ R6,TT1
JNB 00H,LOOP ;受干扰否？
STOP： LJMP STOP ;掉入死循环。
这时可以看到，主程序停止工作（LED0停止闪烁），而两个中断子程序继续运行（LED1和LED2继续闪烁）。
3． 将定时器T1妆作软件WATCHDOG，将30H单元用作软件WATCHDOG计数器。主程序中加入一条复位软件WATCHDOG的指令。
LOOP: CPL P1.0
MOV 30H,#0 ;复位软件WATCHDOG计数器
LOOP: CPL P1.0
MOV R6,#80H
MOV R7,#0H
TT1: DJNZ R7,TT1
DJNZ R6,TT1
JNB 00H,LOOP ;受干扰否？
STOP： LJMP STOP ;掉入死循环。
T1中断子程序修改如下：
PT1: CPL P1.2 ;高级中断程序发光二极管闪烁
INC 30H
MOV A,30H
ADD A,#0FDH
JC ERR ;达到3次否？
RETI
ERR: LJMP STAT ;软件WATCHDOG动作
当按下按钮前，程序正常运行（三个LED全闪）。按下按钮后，主程序能迅速恢复工作，但两个中断子程序被封锁，不再工作。过程如下：主程序检测到干扰后进入死循环，不能执行复位30H单元的操作，T1中断使30H不断增值，计数到3时，软件WATCHDOG执行动作，执行一条LJMP指令，使程序从头执行。MAIN过程中清除了干扰标志（表示干扰已经过去），使主程序迅速恢复工作。按理说MAIN过程中也重新设定了各个中断，并开放了它们，为什么中断不能恢复工作呢？这是因为中断激活标志的复位工作被遗忘了，因为它没有明确的位地址可供编程，直接转向0000H地址并不能完成真正的复位。软件复位是使用软件陷井和软件WATCHDOG后必须进行的工作，这时程序出错完全有可能发生中断子程序中，中断激活标志已置位，它将阻止同级中断响应。由于软件WATCHDOG是高级中断，它将阻止所有中断响应。由此可见，清除中断激活标志的得要性，很多文献的作者回为没有认识到这一点进入误区。
4． 在所有指令中，只有RETI指令能清除中断激活标志。出错处理程序ERR主要是完成这一功能，其它的善后工作交由复位后的系统去完成。为此，我们重新设计T1中断子程序如下所示：
PT1: CPL P1.2 ;高级中断程序发光二极管闪烁
INC 30H ;软件WATCHDOG计数器增值
MOV A,30H
ADD A,#0FD
JC ERR ;达到3次否？
RETI
ERR: CLR EA ;关中断
CLR A ;准备复位地址（0000H）
PUSH ACC
PUSH ACC
RETI ;清除中断激活标志并复位
这段程序先关中断，以便后续处理能顺利进行，然后用RETI指令替代LJMP指令，从而既清除了中断激活标志又完成了转向0000H的任务。按这样改好后程序再运行，结果仍不理想：按下按钮后，有时只有主程序和高级中断子程序能迅速恢复正常，而低级中断仍有被关闭的可能。如果按如下方法把干扰转移到低级中断中，则按下按钮后低级中断必然被关闭：
LOOP: CPL P1.0
MOV R6,#80H
MOV R7,#0H
TT1: DJNZ R7,TT1
DJNZ R6,TT1
SJMP LOOP
PT0: CPL P1.1
JB 00H,STOP
RETI
STOP： LJMP STOP ;掉入死循环。
仔细分析后可能得出结论：当软件WATCHDOG是嵌套在低级中断中起作用时，复位后只清除了高级中断激活标志，低级中断标志仍然被置位，从而使低级中断一直被关闭。
5． 修改出错处理如下：
ERR: CLR EA ;正确的软件复位入口
MOV 66H,#0AAH ;重建上电标志
MOV 67H,#55H
MOV DPTR,#ERR1 ;准备第一次返回地址
PUSH DPL
PUSH DPH
RETI ;清除高级中断激活标志
ERR1: CLR A
PUSH ACC
PUSH ACC
RETI ;清除低级中断激活标志
这时，必须执行两次RETI，才能到达0000H，以保证清除全部中断激活标志，达到和硬件复位相同的效果。同样，软件陷井也必须由下列三条指令
NOP
NOP
LJMP STAT
改成：
NOP
NOP
LJMP ERR
才能达到目的。
当主程序受到干扰被软件陷阱捕获时，中断标志并未置位，执行ERR过程中，RETI指令等效于RET指令，同样可以达到软件复位的目的。有兴趣的读者可以将软件陷阱代替死循环，分别用LJMP STAT和LJMP ERR1来替代LJMP ERR，再将干扰检测分别设在低级中断和主程序中，实验结果必然证明同：只有LJMP ERR才能万无一失地实现软件复位，使系统摆脱干扰同，恢复正常。在MCS-51单片机的软件复位过程中，必须连续执行两次中断返回指令RETI才能确保系统恢复正常。
张明峰 (1899-12-30)
由于51单片机指令结构是多字节的，在受到干扰后PC有可能被篡改，既然PC的值被篡改了，你就无法预先知道篡改后程序飞到哪里。如果是它落在一条合法的指令上，问题还不大；如果它落在一条指令的操作数上(多字节指令，一个字节操作码，后跟一个或多个字节的操作数)，单片机就会把该操作数作为操作码来译码执行，这时情况就严重了 - 后面有多少指令是不可预测的？天知道！它们做了哪些具体的操作？也是天知道！那么，有一种可能性必然存在：程序飞了后把相关的中断给关了，这时，你上面的方法还有效吗？
我常对客户的工程师这样说：你的系统如果需要用到看门狗，千万不要用软件看门狗；用了硬件看门狗，千万不要在中断里面清看门狗。有时软件死循环了，但中断还能进入，如果靠中断清看门狗，就永远不能退出死循环。
style (1899-12-30)
对原文的补充:DIV/MUL指令可能会异常,但极罕见.
fibro (1899-12-30)
软件看门狗好像只是在理论,教学中使用,真正应用就连用硬件看门狗都不放心,还敢用软件的???!!!
zxcasd (1899-12-30)
请问各位:难道软狗真的连一点作用都没有吗?
liuq (1899-12-30)
单纯地谈可靠性的问题，不应该简单地从有无Watchdog方面考虑。更重要的是从影响性能稳定、运行可靠的因素方面，排除干扰源对所设计系统的作用是至关重要的！
有位业界的朋友说：“完成软硬件的设计，只是一个产品设计的十分之一，更多的是去做系统的可靠性、工艺性、合理性方面的工作”。
我认为能够满足一个设计，所有品牌的MCU都是一样的。当然在选型时，有些小公司的MCU产品是要予以考虑的。
我见过的很多电子产品（工业应用产品，进口产品）并没有使用Watchdog!当然有Watchdog要比没有Watchdog的要好，这是事实，但不应该把救命稻草寄托在Watchdog之上！首先是要系统能够抵御外部的影响和干扰！
欢迎讨论！
style (1899-12-30)
不同意楼上的看法.
是否安装软件狗完全取决于系统需求,在很多应用里,狗叫了意味着系统的彻底失败,就像火箭发射了以后不可能再回到地面.这些应用才是追求系统的高可靠性.
平凡 (1899-12-30)
To：张工
您的意见不敢苟同。没有什么场合是需要看门狗的，用看门狗是没有办法的办法，它是只增加系统的可靠性而已，一个系统是否用看门狗，和设计者有很大的关系，而不仅仅是和系统本相关。软件看门狗可以提高系统的可靠性，硬件看门狗也可以增加系统的可靠性，就同一个设计者来说，可能硬件看门狗设计、使用更方便，而软件看门狗则需要更高的技巧，设计得不好反而容易出麻烦，所以可能使用软件看门狗的可靠性不及使用硬件看门狗。但即便如此，软件看门狗还是可以在一定程度上提高系统的可靠性的（和不用相比）。而对一个高手而言，可能他根本不需要用看门狗就可以把系统的可靠性设计得比用硬件看门狗还可靠。所以我认为研究软件看门狗的技术也是有价值的，在一些场合是可以应用的。
张明峰 (1899-12-30)
100%同意平凡老师的意见。用肯定比不用强。其实我以前也一直这么用的。如故意写连续的5/6条NOP指令，目的不是为了延时，而只是想让跳飞了的程序走回正轨。我提上面的问题只是想说明软件看门狗的局限性而已，只要做过具体产品设计的人，都少会有体会。
抗干扰的问题是一个系统设计的问题而不仅仅是一个芯片如何如何的问题。但现在很多设计人员关注的仅仅在于某颗芯片怎么好或怎么不好。如果觉得芯片好而置其它考虑因素于不顾(最常见如PCB Layout)，不知是不是误区？
平凡 (1899-12-30)
不过要是芯片抗干扰性高的话，其他地方能省点事又何乐而不办呢？不过这样就是培养不出水平了。要是一个项目一定指定用那个芯片，或者由于成本、供货等原因，没法用高抗干扰的芯片，就没办法了，所以还是多掌握一点技术的好。
5130840 (1899-12-30)
单片机失控的表现，看来看去，好象有以下表现：
其一，在指令执行中失控，尤其对变指令系统尤为有理，读了不该读的数据，译了不该译的指令，对这些情况，经典教科书中都有论述。
其二，表现为RETI，和RET的跳转关系，21IC中有多篇可以参考。
问题：
是否存在这样一种情况：
单片机处于HALT状态，好象正常，又不能正常工作。
如果存在，对这种情况，WATCHDOG是否一定能使单片机回到正常工作的状况？
平凡 (1899-12-30)
一定，实在是谈不上，硬件WATCHDOG的复位时间是以百毫秒计以至以秒计，这段时间可以执行多少指令啊，如果是逻辑处理的问题可能还好办，要是运算，累积，那得造成多大的失误呢？所以即便是硬件WATCHDOG也是不得已而为之的办法了。
阿里克 (1899-12-30)
看门狗是不得已而为之，我认为这只是一个保障，所以硬的比软的好，为保险起见，最好不要用51，用单字节的片子。狗还是一定要加的。
|
《匠人手记》推荐网上购书渠道： 
匠人学习：
