Study on Watchdog Timer in MSP430 MCU

　　introduction

　　Software reliability has always been a key issue. Anyone who uses software may experience computer crashes or program errors, and this also happens in embedded systems. Due to the limited anti-interference ability of microcontrollers, instrumentation in industrial sites often crashes due to voltage instability, arc interference, etc. When water meters, electricity meters, etc. are unattended, the system may not be able to restart due to interference. In order to ensure that the system can automatically return to normal after interference, the use of a watchdog timer is very valuable.

　　1 The role of the watchdog

　　The watchdog timer is a counter whose basic function is to restart the system after a software problem or program runaway. The watchdog counter counts automatically when it is working normally, and the program flow resets it to zero regularly. If the system is stuck or runaway somewhere, the timer will overflow and will enter an interrupt. Some reset operations are performed in the timer interrupt to restore the system to normal working state, that is, when the program is not running normally, the watchdog is reset as scheduled to ensure that the selected timer overflows to zero and the processor is restarted.

　　2 Watchdog Problem and Related Experiments

　　Some popular single-chip microcomputers on the market today are mostly embedded with internal WDT, such as TI's MSP430 series, Philips' P87XXX and P89XXX series, Microchip's PIC series, Atmel's AT89SXX series and Holtek's Htxxx series. However, these internal watchdogs often have certain errors when working. Some engineers ignore this point during the design process, resulting in system abnormalities. The MSP430 series of single-chip microcomputers is a new generation of single-chip microcomputers developed by Texas Instruments (TI) in recent years. This series is a 16-bit, ultra-low power hybrid single-chip microcomputer with a new concept. Among many single-chip microcomputer series, it has become a dazzling new star because of its extremely low power consumption, rich on-chip peripherals and convenient and flexible development methods. It has its own watchdog and reset circuit. In theory, if the program runs away, the watchdog can be used to reset it. But in actual use, it is found that the role of the watchdog is not foolproof. The following experiment proves this.

　　The experimental circuit is shown in Figure 1.

　　Experimental procedure list:

　　#include

　　void main(void) {

　　P1DIR l=0x0f; //Set P1.2~P1.0 as output

　　for(;;){

　　volatile unsigned int i;

　　WDTCTL=WDTPW+ WDTCNTCL;

　　//Reset WDT counter

　　PIOUT==0x0t; //P1.0~P1.2 are mutually exclusive OR

　　i=5000; //Delay

　　d0(i--);

　　while(i != 0);

　　}

　　}

　　After the above experiment is started, if the program runs normally, the LED will flash. By default, the watchdog of MSP430 is in the enabled state, and the running program will continuously access the watchdog. In theory, this system will not fail to start, because even if the startup fails, the watchdog should start within hundreds of milliseconds and reset the entire system. Based on this idea, the reset of the microcontroller is tested. K2 is disconnected, and K1 is used to continuously generate. Reset signal to test the success rate of the watchdog to restart the system. When K2 is closed, the reset end is high. In theory, K1 cannot effectively generate a reset pulse. Observe whether the watchdog works.

　　3 Experimental results and analysis

　　The experimental results are as follows: when K2 is disconnected and K1 is continuously switched on and off, the system is powered on and restarted, and it fails once every 155 times on average (the LED does not flash), that is, the probability of watchdog failure is 0.6%; when K2 is closed and K1 is continuously switched on and off, it fails once every 18 times on average (the LED does not flash), and once it fails, it will continue to fail, and the watchdog inefficiency accounts for about 5.5%.

　　In addition, when other series of microcontrollers with built-in watchdog are used to replace the MSP430 in the experiment and the startup program segment is modified accordingly, the experimental results are still roughly the same, which shows that the problems faced by microcontrollers with built-in watchdog are the same. After analysis, the possible reasons are as follows:

　　① Since the watchdog clock is not independent and the counting clock and the system share the same frequency division link, the watchdog cannot operate effectively when a problem occurs in the system.

　　② Since the clock can be set by software, when the startup fails, the startup clock may be in neutral, and the watchdog cannot take effect without a clock.

　　③ Some watchdogs need to be set or started by software. Therefore, after the startup fails, the initialization program is not activated, and the CPU may jump to random code, making the watchdog disabled. Such a watchdog needs to be guaranteed by a reliable power-on reset. Therefore, theoretically, the original design is unreasonable. Based on the above analysis, the off-chip watchdog dedicated chip TPS3823 is used to provide counting pulses by an independent frequency division oscillation circuit. The experimental circuit is shown in Figure 2.

　　In the above circuit, TPS3823 outputs a timing overflow signal to the Reset terminal. In the program segment, the CPU must continuously output a dog-feeding signal through the I/O port to clear the watchdog counter. In this circuit, the same actions of K1 and K2 in the above test are repeated, and the system restart success rate reaches 100%.

　　Conclusion

　　In the future, the built-in watchdog must have an independent and reliable clock. After the system is powered on, the watchdog is in the enabled state, without software settings. It can only be disabled by an external hardware jumper or an internal fuse. At present, if you need to design an embedded system with high reliability, an external watchdog must be considered. Another problem with the built-in watchdog is that after the system is reset, the program should determine whether it is caused by the normal power-on reset of the Reset terminal or the program running away from the watchdog, thereby determining whether the field data should be retained. This is also something that should be considered in the watchdog application.