📄 devs-watchdog-synth.html
字号:
<!-- Copyright (C) 2003 Red Hat, Inc. --><!-- This material may be distributed only subject to the terms --><!-- and conditions set forth in the Open Publication License, v1.0 --><!-- or later (the latest version is presently available at --><!-- http://www.opencontent.org/openpub/). --><!-- Distribution of the work or derivative of the work in any --><!-- standard (paper) book form is prohibited unless prior --><!-- permission is obtained from the copyright holder. --><HTML><HEAD><TITLE>Synthetic Target Watchdog Device</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE="Synthetic Target Watchdog Device"HREF="devs-watchdog-synth-ref.html"><LINKREL="PREVIOUS"TITLE="Synthetic Target Watchdog Device"HREF="devs-watchdog-synth-ref.html"></HEAD><BODYCLASS="REFENTRY"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="devs-watchdog-synth-ref.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"> </TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="DEVS-WATCHDOG-SYNTH">Synthetic Target Watchdog Device</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN19056"></A><H2>Name</H2>Synthetic Target Watchdog Device -- Emulate watchdog hardware in the synthetic target</DIV><DIVCLASS="REFSECT1"><ANAME="AEN19059"></A><H2>Overview</H2><P>Some target hardware comes equipped with a watchdog timer. Applicationcode can start this timer and after a certain period of time,typically a second, the watchdog will trigger. Usually this causes thehardware to reboot. The application can prevent this by regularlyresetting the watchdog. An automatic reboot can be very useful whendeploying hardware in the field: a hardware glitch could cause theunit to hang; or the software could receive an unexpected sequence ofinputs, never seen in the laboratory, causing the system to lock up.Often the hardware is still functional, and a reboot sorts out theproblem with only a brief interruption in service. </P><P>The synthetic target watchdog package emulates watchdog hardware.During system initialization watchdog device will be instantiated,and the <TTCLASS="FILENAME">watchdog.tcl</TT> script will be loaded by theI/O auxiliary. When the eCos application starts the watchdog device,the <TTCLASS="FILENAME">watchdog.tcl</TT> script will start checking thestate of the eCos application at one second intervals. A watchdogreset call simply involves a message to the I/O auxiliary. If the<TTCLASS="FILENAME">watchdog.tcl</TT> script detects that a second has<AHREF="devs-watchdog-synth.html#SYNTH-WATCHDOG-WALLCLOCK-ELAPSED">elapsed</A>without a reset then it will send a <TTCLASS="LITERAL">SIGPWR</TT> signalto the eCos application, causing the latter to terminate. If gdb isbeing used to run the application, the user will get a chance toinvestigate what is happening. This behaviour is different from realhardware in that there is no automatic reboot, but the synthetictarget is used only for development purposes, not deployment in thefield: if a reboot is desired then this can be achieved very easilyby using gdb commands to run another instance of the application. </P></DIV><DIVCLASS="REFSECT1"><ANAME="DEVS-WATCHDOG-SYNTH-INSTALL"></A><H2>Installation</H2><P>Before a synthetic target eCos application can use a watchdog deviceit is necessary to build and install host-side support. The relevantcode resides in the <TTCLASS="FILENAME">host</TT>subdirectory of the synthetic target watchdog package, and building itinvolves the standard <BCLASS="COMMAND">configure</B>,<BCLASS="COMMAND">make</B> and <BCLASS="COMMAND">make install</B> steps. Theimplementation of the watchdog support does not require anyexecutables, just a Tcl script <TTCLASS="FILENAME">watchdog.tcl</TT> andsome support files, so the <BCLASS="COMMAND">make</B> step is a no-op. </P><P>There are two main ways of building the host-side software. It ispossible to build both the generic host-side software and allpackage-specific host-side software, including the watchdog support,in a single build tree. This involves using the<BCLASS="COMMAND">configure</B> script at the toplevel of the eCosrepository. For more information on this, see the<TTCLASS="FILENAME">README.host</TT> file at the top of the repository.Note that if you have an existing build tree which does not includethe synthetic target watchdog support then it will be necessary torerun the toplevel configure script: the search for appropriatepackages happens at configure time. </P><P>The alternative is to build just the host-side for this package.This requires a separate build directory, building directly in thesource tree is disallowed. The <BCLASS="COMMAND">configure</B> optionsare much the same as for a build from the toplevel, and the<TTCLASS="FILENAME">README.host</TT> file can be consulted for moredetails. It is essential that the watchdog support be configured withthe same <TTCLASS="OPTION">--prefix</TT> option as other eCos host-sidesoftware, especially the I/O auxiliary provided by the architecturalsynthetic target HAL package, otherwise the I/O auxiliary will beunable to locate the watchdog support. </P></DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-WATCHDOG-TARGET-CONFIG"></A><H2>Target-sideConfiguration</H2><P>The watchdog device depends on the generic watchdog support,<TTCLASS="VARNAME">CYGPKG_IO_WATCHDOG</TT>: if the generic support isabsent then the watchdog device will be inactive. Some templatesinclude this generic package by default, but not all. If theconfiguration does not include the generic package then it can beadded using the eCos configuration tools, for example: </P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="SCREEN">$ ecosconfig add CYGPKG_IO_WATCHDOG</PRE></TD></TR></TABLE><P>By default the configuration will use the hardware-specific support,i.e. this package. However the generic watchdog package contains analternative implementation using the kernel alarm facility, and thatimplementation can be selected if desired. However usually it will bebetter to rely on an external watchdog facility as provided by the I/Oauxiliary and the <TTCLASS="FILENAME">watchdog.tcl</TT> script: if thereare serious problems within the application, for example memorycorruption, then an internal software-only implementation will not bereliable. </P><P>The watchdog resolution is currently fixed to one second: if thedevice does not receive a reset signal at least once a second thenthe watchdog will trigger and the eCos application will be terminatedwith a <TTCLASS="LITERAL">SIGPWR</TT> signal. The current implementationdoes not allow this resolution to be changed. </P><P>On some targets the watchdog device does not perform a hard reset.Instead the device works more or less via the interrupt subsystem,allowing application code to install action routines that will becalled when the watchdog triggers. The synthetic target watchdogsupport effectively does perform a hard reset, by sending a<TTCLASS="LITERAL">SIGPWR</TT> signal to the eCos application, and there isno support for action routines. </P><P>The synthetic target watchdog package provides some configurationoptions for manipulating the compiler flags used for building thetarget-side code. That code is fairly simple, so for nearly allapplications the default flags will suffice. </P><P>It should be noted that the watchdog device is subject to selectivelinking. Unless some code explicitly references the device, forexample by calling the start and reset functions, the watchdog supportwill not appear in the final executable. This is desirable because awatchdog device has no effect until started. </P></DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-WATCHDOG-WALLCLOCK-ELAPSED"></A><H2>Wallclock versus Elapsed Time</H2><P>On real hardware the watchdog device uses wallclock time: if thedevice does not receive a reset signal within a set period of timethen the watchdog will trigger. When developing for the synthetictarget this is not always appropriate. There may be other processesrunning, using up some or most of the cpu time. For example, theapplication may be written such that it will issue a reset after somecalculations which are known to complete within half a second, wellwithin the one-second resolution of the watchdog device. However ifother Linux processes are running then the synthetic targetapplication may get timesliced, and half a second of computation maytake several seconds of wallclock time. </P><P⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -