Watchdog method and apparatus

[0002] 1. Field of the Invention

[0003] The present invention relates generally to the field of processing systems and, more particularly, to a watchdog method and apparatus in such processing systems.

[0004] 2. Background Information

[0005] In a complex electronic system that includes multiple subsystems, one or more of the subsystems may fail or operate in a reduced capacity, thereby affecting the performance of the overall system. In such a situation, the failed subsystem(s) may cause the entire system to “lock up” or “freeze”. User intervention is then typically required to reset the entire system. Furthermore, the one or more failed subsystems may enhance the risk of damage or even fire to the system.

[0006] Accordingly, there is a need in the technology for a method and apparatus to reduce such effects.

[0007] The present invention comprises a watchdog method and apparatus for a processing system running one or more tasks for controlling one or more subsystems. In one embodiment, the method includes configuring a device to cause a hardware reset to the one or more subsystems in a predetermined time, and calling a first task in a table and changing a status of the first task to called. For one or more tasks in the table, the method determines the status of the task, and, if the status is called, sets a flag to a true state if a second predetermined time has passed since the task was called and has not replied. If the flag is not set to the true state, the method configures the device to push back the occurrence of a hardware reset to the predetermined time. A next task in the table is then called, and its status is changed to called.

[0008] Other embodiments are described and claimed herein.

[0009] FIG. 1 illustrates one embodiment of a system utilizing the present invention.

[0010] FIG. 2 illustrates one embodiment of the decoder of FIG. 1.

[0011] FIG. 3 shows a task table for registering tasks in the system main logic block 130, according to one embodiment of the present invention.

[0012] FIGS. 4A-4C illustrate a flow diagram of a watchdog module, according to one embodiment of the present invention.

[0013] The present invention comprises a watchdog method and apparatus for a processing system running one or more tasks for controlling one or more subsystems. In one embodiment, the method includes (a) configuring a device to cause a hardware reset to the one or more subsystems in a predetermined time, and (b) calling a first task in a table and changing a status of the first task to called. The method also includes (c) for one or more tasks in the table, determining the status of the task, and, if the status is called, sets a flag to a true state if a second predetermined time has passed since the task was called and has not replied. The method further includes (d) configuring the device to push back the occurrence of a hardware reset to the predetermined time if the flag is not set to the true state, and (e) calling a next task in the table, and changing its status to called. The method then jumps back to (c).

[0014] Herein, various terms are used to describe certain elements or characteristics of the present invention. For example, a “communication line” is broadly defined as any communication path between a source and a destination. The communication line may include one or more information-carrying lines (electrical wire, fiber optics, cable, etc.) or wireless communications through established techniques such as infrared (IR) and radio frequency (RF) signaling. A “signal” is construed as information transmitted in a parallel or serial manner. A “task module” is broadly defined as a piece of software for controlling and/or monitoring a device or subsystem (e.g., a piece of hardware), or for controlling and/or monitoring other software modules.

[0015] Referring to FIG. 1, one embodiment of a system utilizing the present invention is shown. The system 100 comprises an antenna 105, a broadcast receiver 110, a decoder 115 and a monitor 120. In one embodiment, the receiver 110 and the decoder 115 may be a single unit, and may be implemented as an integrated receiver decoder (IRD). The broadcast receiver 110, in general, receives a broadcast and performs operations on the broadcast signal to produce digital information. The digital information is decoded and dispatched to the monitor 120 for display. Alternatively, the broadcast receiver 110 may receive a digital broadcast signal (for example, a digital bit stream) from a digital source via a cable 125. Although the IRD may be implemented as the broadcast receiver in one embodiment, other types of broadcast receivers may be used such as a cable box for a Cable Broadcasting System, an Internet terminal, a digital television (DTV), and the like.

[0016] Antenna 105 may receive the digital bit stream from an orbiting satellite (not shown) and routes the bit stream to receiver 110. The bit stream is formatted in accordance with any video compression function and is usually encrypted under either a symmetric key cryptographic function or a public-key cryptographic function. Typically, the bit stream includes sensory data (e.g., video and/or audio, or communication data) and control information for a number of shows. The control information for each show includes programming data having the following content: date of broadcast, broadcast channel number, show start-time, show end-time, and also show title.

[0017] The decoder 115 is responsible for decoding the bit stream, for storing programming data, for executing software stored in the processing unit 130 located within the decoder 115, and for processing the decoded bit stream to produce one or more output signals having appropriate formats. As shown, an output signal is placed in an analog format and sent to monitor 120 for viewing. The output signal may also be sent to a recording device (not shown) for recording. The analog format may be in accordance with a video format established by National Television Systems Committee (NTSC), or perhaps other video formats, including but is not limited or restricted to Phase Alternating Line (PAL), Sequential Couleur Avec Memoire (SECAM) and other recognized formats. In one embodiment, the decoder 110 may be coupled to a computer 135 for diagnostic/debugging purposes. The computer 135 may be decoupled when the diagnostic procedures are complete.

[0018] In one embodiment, the receiver 110 includes a front-end unit 110a. The antenna 105 transfers the bit stream to the front-end unit 110a. Although not shown, the front-end unit 110aincludes (i) amplification circuitry used to amplify any relatively weak signals received at antenna 105, and (ii) a tuner which allows a user to receive a desired broadcast channel. The resulting signal is then forwarded to the decoder 115.

[0019] Additionally, the receiver 110 is responsible for responding to a plurality of commands from a remote control (not shown). The remote control may include any type of remote control, including one described in U.S. Pat. No. 5,453,758 assigned to Sony Corporation of Tokyo, Japan. Examples of commands from the remote control include commands causing receiver 110 to tune to a particular channel, or for performing a mute operation.

[0020] FIG. 2 illustrates one embodiment of the decoder 115 of FIG. 1. For the case where the user wishes to view a show provided by a broadcaster, the bit stream associated with the desired broadcast channel is routed from front-end unit 110ato a demodulator 140 located within decoder 115. In demodulator 140, the bit stream is initially processed before transferring to a main logic block 130 for further processing. Such initial processing may include exposing the bit stream to Vestigial Side Band (VSB) demodulation, viterbi-decoding, de-interleaving and Reed-Solomon decoding.

[0021] In certain situations, decoder 115 is connected to other peripheral devices such as digital VCRs, digital video disk players, digital laser disk players and the like. These digital-input peripheral devices communicate with a processor within main logic block 130.

[0022] FIG. 2 also illustrates one embodiment of the main logic block 130. As shown, the main logic block 130 comprises a processor 150 that is coupled to a memory module 155 via a system bus 160. The processor 150 includes any one of the ×86, Pentium™, Pentium II™, and Pentium Pro™ microprocessors as marketed by Intel™ Corporation, the K-6 microprocessor as marketed by AMD™, or the 6×86MX microprocessor as marketed by Cyrix™ Corp. Further examples include the Alpha™ processor as marketed by Digital Equipment Corporation™, the 680×0 processor as marketed by Motorola™; or the Power PC™ processor as marketed by IBM™. In addition, any of a variety of other processors, including those from Sun Microsystems, MIPS, IBM, Motorola, NEC, Cyrix, AMD, Nexgen and others may be used for implementing processor 150. The processor 150 is not limited to microprocessor but may take on other forms such as microcontrollers, digital signal processors, reduced instruction set computers (RISC), application specific integrated circuits, and the like.

[0023] The memory module 155 includes a DRAM 155aand a FLASH Read Only Memory (ROM) 155b. In one embodiment, the DRAM 155acontains a task table 185 together with other data. In one embodiment, the FLASH ROM 155bcontains a watchdog module (WD module) 190, one or more task modules 192₁-192_T(where “T” is a positive whole number), and other software code. Alternatively, the watchdog module 190 and/or the task modules 192₁-192_Tare copied into DRAM 155aduring boot-up. The watchdog module 190 and the task modules 192₁-192_Tare executed by the processor 150.

[0024] The main logic block 130 further comprises a video decoder 165 and an audio decoder 170, each of which is coupled to the processor 150 via the system bus 160. The video and audio decoders 165 and 170 perform video and audio functions, respectively. That is, the video decoder 165 decodes the video components of the incoming bit stream while the audio decoder 170 decodes the audio components of the incoming bit stream. In addition, a plurality of other subsystems 195₁-195_S(where “S” is a positive whole number) are coupled to the system bus 160 for performing other functions in the main logic block 130. The task modules 192₁-192_Tare software modules that control the hardware devices in the logic block 130 (e.g., the video and audio decoders 165 and 170, and subsystems 195₁-195_S), and other software modules for coordination of the system 100. For example, task module 192₁controls the video decoder 165, task module 192₂controls the audio decoder 170, task module 192₃controls subsystem 195₁, and so on. Task modules may also be used to interface with other software modules in the logic block 130.

[0025] The main logic block 130 further comprises a reset controller 175 that is coupled to the processor 150. The reset controller 175 includes a timer chip 178. Alternatively, the timer chip 178 may be integrated as part of the processor 150. When configured and operational, the timer chip 178 causes the reset controller 175 to reset the receiver 110, decoder 115, and/or monitor 120 in the system 100 when its configured time expires. An EEPROM 180 is also coupled to the processor 150. The EEPROM 180 is for storing tables used for tuning, as well as other data.

[0026] During operation, the watchdog module 190 communicates with the task modules 192₁-192_Tto determine the status of the video decoder 165, audio decoder 170, subsystems 195₁-195_S, and/or other software modules in the system 100. The communication involves transmitting a call message to a task module (or task) and waiting for a reply message from the called task. One main function of the watchdog module 190 is to continually determine the status of the tasks, such that when a task is delinquent in responding back, the watchdog module 190 will not reset or “push back” the time of the timer chip 178. Consequently, the timer chip 178 will inevitably expire, causing the reset controller 175 to reset the receiver 110, decoder 115, and/or monitor 120. By continually monitoring the status of the tasks, the watchdog module 190 prevents the receiver 110, decoder 115, and/or monitor 120, or subsystems of such devices from locking up.

[0027] FIG. 3 shows an exemplary embodiment of the task table 185 of FIG. 2. In one embodiment, the task table 185 is contained in DRAM 155aand administered by the watchdog module 190 (FIG. 2). Alternatively, the task table 185 may be contained in FLASH ROM 155b, and copied into DRAM 155a. The task table 185 is used by the watchdog module 190 to register and maintain the status of task modules (tasks).

[0028] Referring to FIG. 3, the task table 185 includes one or more entries 310₁-310_N(where “N” is a positive whole number) created and maintained for the one or more tasks that are registered with the watchdog module 190. In one embodiment, each entry includes (i) field 315 containing the index number of the task, (ii) field 320 containing the task name and identification (ID), (iii) field 325 containing the status of the task (e.g., REGISTERED, CALLED, REPLIED, etc.), (iv) field 330 containing the time that the task was called (referred to as T_N), (v) field 335 containing the predetermined timeout value for the task (PT_N), and (vi) field 340 containing other miscellaneous information relating to the task. The predetermined timeout value (PT_N) may be different for one task to another depending on the function of the task and/or other factors.

[0029] FIGS. 4A-4C illustrate a flow diagram of a watchdog module 400, according to one embodiment of the present invention. The watchdog module 400 is contained in FLASH ROM 155b, as shown by numeral 190 (FIG. 2). The watchdog module 400 may be executed by processor 150 directly from FLASH ROM 155b, or may be copied into and executed from DRAM 155a.

[0030] Referring to FIG. 4, the watchdog module 400 commences at block 410 where the timer chip 178 (FIG. 2) is configured to a predetermined hardware timeout value. If the timer chip 178 expires, before being set again by the watchdog module 400, the reset controller 175 causes a hardware reset of the receiver 110, decoder 115, and/or monitor 120. In addition, at block 410, a variable OVER_LIMIT is initialized to FALSE. At block 414, the watchdog module 400 calls the first task in the task table 185, records the current time for the first task (T1) in field 330, and changes the status in field 325 to CALLED. At block 418, the module 400 sets a software timer to a predetermined software timeout value. In one embodiment, the predetermined software timeout value is smaller than the predetermined hardware timeout value. The software timer is used by the module 400 to check the status of the tasks, when the timer times out.

[0031] Once the software timer is set, the module 400 moves to block 422 and waits for a message, either from a task or from the software timer, in the case of a software timeout. The message may be a registration message from a task that has not yet registered with the watchdog module 400. In such a case, the module 400 moves to block 426 where a new entry 310 is created in the task table 185 for the task requesting registration. The timeout value in field 335 may be set by the registering task (e.g., in the registration message) or may be set by the module 400. Once the new task is registered, the module 400 moves back to block 422 and waits for another message.

[0032] At block 422, if the message is a response message from a task that has been previously called, the module 400 moves to block 430. At block 430, if the status of the task (field 325) that sent the response message is CALLED, the module moves to block 434, where the status in field 325 is changed to REPLIED. However, if at block 430, the status was REPLIED, the module moves to block 438 where an error is reported. This is because a task should not be sending a response message if it has not been called (e.g., its status is replied). The watchdog module 400 may optionally store the reported error in an error table in DRAM 155aor FLASH ROM 155bfor subsequent retrieval by the computer 135 for diagnostic/debugging purposes. In either case, the module moves back to block 422 and waits for a new message.

[0033] At block 422, if the message is a timeout message, from the software timer, the module 400 continues to block 442 where the status of the first entry is obtained. At block 446, if the status is CALLED, then the module moves to block 450, where the recorded call time (T₁) is subtracted from the current time, and the result is the time elapsed. At block 454, if the time elapsed is greater than (or equal to) the predetermined timeout value (PT₁), the module moves to block 458 and the task (task 1) is deemed to be delinquent (i.e., has not responded in time). Consequently, at block 458 the variable OVER_LIMIT is set to TRUE. The delinquency of the task may be optionally recorded in the error table in DRAM 155aor FLASH ROM 155bfor diagnostic/debugging purposes. If, at block 446, the status of the task is REPLIED, the task is deemed to be in good standing, and the module moves to block 462. If, at block 454, the predetermined time (PT) is greater than the time elapsed, the task is deemed not to be delinquent, and the module moves to block 462.

[0034] At block 462, a determination is made as to whether there are any more unchecked tasks in the task table 185. If so, the process moves to block 466 where the status of a next entry in the task table 185 is obtained. In one embodiment, blocks 446-466 are performed until all the tasks in the task table 185 have been checked. In another embodiment, a random number of tasks are checked when a software timeout occurs.

[0035] At block 470, a check of the variable OVER_LIMIT is made. If OVER_LIMIT is FALSE, the module moves to block 474 where the hardware watchdog timer (timer chip 178) is “reset” or “pushed back” (e.g., configured to the predetermined hardware timeout value) to temporarily prevent a hardware reset (until it is “reset” or “pushed back” again). However, if OVER_LIMIT is TRUE, the module 400 jumps over block 474 to block 478. Consequently, the timer chip 178 will inevitably cause a hardware reset. At block 478 a task of a next entry in the task table 185 is called, the current time stored in field 330 of the called task, and the status is changed to CALLED. At block 482, the software timer is again reset to the predetermined software timeout value for eventually causing another software timeout message in order to check the status of the tasks in the task table 185. The process then moves back to block 422.

[0036] It must be noted that the present invention is described with respect to a DTV system having multiple tasks, one or more of which may be controlling subsystems in the system. However, other types of systems may benefit from the present invention including, for example, computer systems, automated teller machines, avionics systems, medical instruments, or any system which has the need for lockup recovery to ensure the responsiveness and function of the system over time.

[0037] In accordance with the practices of persons skilled in the art of computer programming, the present invention is described below with reference to symbolic representations of operations that are performed by computer system 100, unless indicated otherwise. Such operations are sometimes referred to as being computer-executed. It will be appreciated that operations that are symbolically represented include the manipulation by processor 150 of electrical signals representing data bits and the maintenance of data bits at memory locations in memory module 155, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits.

[0038] Thus, the present invention may be embodied in one of several forms including a method, an apparatus, and a program product that includes a computer readable medium having embodiment therein computer readable program. When implemented in software, the elements of the present invention are essentially the code segments to perform the necessary tasks. The program or code segments can be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave over a transmission medium or communication link. The “processor readable medium” or “machine-readable medium” may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.

[0039] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.