I. OBJECTIVES: Embedded systems use a watch dog timer to recover from program malfunctions. During faulty software operations $($e$.$g$.$ a program gets stuck in an infinite loop$),$ expiration of a watchdog timer causes the system to reboot. In embedded applications, these timers can be implemented in either software or hardware. This assignment teaches students on how to implement a watchdog timer in software. Copy files for this exercise from $/$courses$/$cs $341/$ s $23/$ hefeiqiu$/$mp$5/$ to your cs $341/$ mp $5$ directory. You will use timing functions provided in timepack$\_$sapc.c$.$ II$.$ Operations of a Watchdog Timer: One can imagine if an embedded system installed in a remote area goes haywire, it may be impossible or very costly to send a service personnel to reset the system. See an example application on the NASA Deep Space Probe and a more recent one on the Mars helicopter flight. A watchdog timer can automatically reset the system without human intervention in the event of a system failure. In theory, a watch dog timer is a timer that is set to expire at a pre$-$determined time interval. During a faulty condition $($e$.$g$.$ software is stuck in an infinite loop$),$ timer expiry reboots the entire system. If the watchdog timer is implemented in external hardware, its logic will send a signal to the reset circuit $($e$.$g$.$ power up restart$)$ of the embedded system when the timer expires. If implemented in software, the internupt service routine of the timer will run a reboot function that restarts the application from scratch. Since rebooting an application causes a major interruption to the operation of the system $($similar to the powering up your computer$),$ you don't want to reboot it if this is not needed. In most cases, we don't know exactly when the problem will occur, but we may have some estimate on the time when the problem will likely to occur. Then you set the watchdog timer to expire at or a little after that estimated time. For those times that the software is nunning without fault, you reset the watchdog timer before it expires to prevent internupt from happening. This action is known as "kicking the dog" III. Software implementation of a Watchdog timer: a$)$ Part $1$: Simulating the coding problem: We use a similar test set up as in mp$4.$ The test program for this m p is charGenl.c and is provided in the cs $341/$ mp$5/$ directory. scp the file to your vserver VM and build the charGen$1$ executable at the vserver V $$ using: gec $-0$ charGenl charGenlic $1$Build the software application watchdog.lnx on users.cs$.$umb.edu $($pe$15)$ using the provided makefile, watchdog.c$,$ reboot.s and timepack$\_$sapc.c files. scp the watchdog. ln x to your vserver VM and load it into the tutor VM using mtip and $$d$.$ Run the programs in this sequence: i$)$ Start the watchdog.lnx using tutor command: go $100100$ ii$)$ Open up a remote ssh window at vserver V M and nun charGenl to generate test characters to COM$2$ at $1$ second intervals using: sudo JcharGenl $($use cs $444$ as your sudo password$)$ The provided code in watchdog.c will print out characters received from the charGen$1$ driver. After $10$ characters, the system will get stuck in a simulated infinite loop and no characters will be printed out. However, the serial port interrupts are ongoing. The program continues to execute the serial port ISR and process the received characters, but the main $0$ is not printing them out. Capture a run of your program in the tutor VM with a typescript file named script$\_$part$\_1.$b$)$ Part $2$a: Reset the system using a watchdog timer Code the watchdog timer using functions provided in timepac$\_$sapc.c$.$ Set the count value to generate an interrupt every $55$ mse $($this is longest duration between interrupts you can with a $16-$bit counter hardware$).$ When the watch dog timer expires, the ISR calls a reboot function $($the provided reboot.s$)$ that restarts the watchdog.lnx program. If you want to wait longer time to do reboot$0,$ you have to modify the ISR software as follows: void irq$0$inthandc $0\{$ tickcount $+1$ ; if $($tickcount $\%300==0)$ reboot $0$ ; $//$ this will do reboot every $300*55$ms $...$ void irq$0$inthandco $\{....$ tickcount$+1$; if $($tickcount $\%300==0)$ reboot $0$ ; $//$ this will do reboot every $300^*55$ms $3$ Cat your programs $($watchdog$.$c$,$ timepack$\_$sapc.c and reboot.s$)$ and capture the run of your program in the tutor VM with a typescript file named script$\_$part $2$a$.$ c$)$ Part $2$b: Implement the "Kick the dog" function In watchdog.c$,$ at the end of the do$\_$work$0$ function, implement a kick$\_$dogO$)$ to call the set$\_$timer$\_$count function to reset the count back to $0.$ This will prevent the timer from expiring under normal circumstances. If the program gets stuck in the middle of do$\_$work$0$ and kick$\_$dogO is not run, then the timer will expire and the program will get rebooted at the timer ISR. Cat your programs $($watchdog$.$c$,$ timepack$\_$sapc.c and reboot.s$)$ and capture the run of your program in the tutor VM in a typescript file named script$\_$part$\_2$b$.$ Any private functions or variables you need should be declared static in "timepack$\_$sapc.c$",$ so that the calling program can never accidentally use a variable or function with the same name, or interfere with yours.