Patent Publication Number: US-7222263-B2

Title: Program-controlled unit with on-chip debug resources able to control watchdog timers

Description:
BACKGROUND OF THE INVENTION  
     Field of the Invention 
     The present invention relates to a program-controlled unit, having a core for executing the program to be executed by the program-controlled unit, and having debug resources for tracking and influencing the operations proceeding within the core. 
     Program-controlled units, such as microprocessors, microcontrollers, signal processors, etc., exist in innumerable embodiments and do not require more detailed explanation. 
     A problem of such program-controlled units is that it is often not possible or not readily possible to localize and eliminate errors that occur. 
     For such a reason, there has been a changeover to equipping program-controlled units with debug resources that make it possible to track and influence the operations proceeding within the program-controlled unit. These debug resources include, for example, the prior art on-chip debug support modules or OCDS modules. 
     Such and other debug resources make it possible to monitor the occurrence of states or events within the program-controlled unit, which states or events can be prescribed from outside the program-controlled unit, and, when such a state or such an event has occurred, to carry out actions that can be prescribed from outside the program-controlled unit. 
     The states or events whose occurrence can be monitored by the debug resources may include, by way of example, but not exclusively:
         the access by the program-controlled unit or specific components thereof to specific memory addresses or registers; and/or   the transfer of specific data within the program-controlled unit; and/or   the position of the instruction pointer.
 
The actions that the debug resources execute when such a state or other state or event occurs may include, by way of example, but likewise not exclusively:
   reporting of the fact that the condition to be monitored has occurred, to a device provided outside the program-controlled unit;   the read-out or the alteration of the content of specific memory elements or registers;   the outputting of trace information, i.e., the outputting of addresses, data, and/or control signals that are used or transferred within the program-controlled unit, to a device provided outside the program-controlled unit;   the stopping of the program execution;   the continuation of the program execution in the so-called single-step mode; or   the execution of routines serving for the debugging or emulation of the program-controlled unit.       

     The provision of such debug resources in program-controlled units, thus, affords a whole host of possibilities for localizing and eliminating errors occurring in the program-controlled unit. 
     An existing disadvantage of such debug resources is that it is thereby often not possible to examine the program-controlled unit in real time. By way of example, if the debug resources cause the core of the program-controlled unit:
         to stop the program execution; or   to continue the program execution in the single-step mode; or   to execute instructions that do not belong to the (application) program that is actually to be executed, but, rather, are instructions serving for the debugging or emulation of the program-controlled unit,
 
the program-controlled unit often behaves differently than is the case in normal operation thereof. The consequence of such behavior is that errors that occur in normal operation of the program-controlled unit often do not occur during the debugging or emulation of the program-controlled unit using the debug resources, and/or that errors that do not occur in normal operation of the program-controlled unit occasionally occur during the debugging or emulation of the program-controlled unit using the debug resources.
       

     This greatly limits the possibilities for use of the debug resources. In particular, errors occurring in complex program-controlled units or applications are often not localized and eliminated by the debug resources, or are only partly localized and eliminated, or are localized and eliminated only with a very high outlay. 
     SUMMARY OF THE INVENTION  
     It is accordingly an object of the invention to provide a program-controlled unit that overcomes the hereinafore-mentioned disadvantages of the heretofore-known devices of this general type and that localizes and eliminates errors occurring in the program-controlled unit under all circumstances rapidly and simply. 
     With the foregoing and other objects in view, there is provided, in accordance with the invention, a program-controlled unit, including a core for executing a program, debug resources connected to the core for tracking and influencing operations proceeding within the core, other components connected to at least one of the debug resources and the core, and the debug resources influencing at least one of the other components and cooperation of the other components with at least one of one another and the core. 
     The program-controlled unit according to the invention is distinguished by the fact that the debug resources are able also to influence other components of the program-controlled unit than the core itself and/or the cooperation of these components with one another and/or with the core. 
     Such ability makes it possible to avoid problems that occur in conventional program-controlled units if the debug resources put the core into a state in which the latter behaves differently than in normal operation. In particular, it is, thus, possible to avoid the problems that result from the fact that the components of the program-controlled unit no longer operate and/or cooperate as intended in the case of an altered behavior of the core. 
     By virtue of the possibility of putting not only the core but also other components of the program-controlled unit into a state in which these behave differently than in normal operation, the behavior of the other components can be adapted to the altered behavior of the core. It is preferably provided that when the debug resources put the core of the program-controlled unit into a state in which the latter behaves differently than in normal operation, these debug resources automatically simultaneously adapt the other components of the program-controlled unit to the altered behavior of the core. 
     This makes it possible to avoid to the greatest possible extent, in a simple manner, the situation wherein disturbances or errors that do not occur in normal operation of the program-controlled unit occur during the debugging or emulation of the program-controlled unit, and/or wherein errors that occur in normal operation of the program-controlled unit do not occur during the debugging or emulation of the program-controlled unit. 
     In accordance with another feature of the invention, the other components are components having behavior influencing a behavior of the core. 
     In accordance with a further feature of the invention, the other components include at least one watchdog timer. 
     In accordance with an added feature of the invention, the debug resources deactivate the other components, turn off the other components, place the other components into a given state, reset the other components, reconfigure the other components, and/or alter signals fed to the other components. 
     In accordance with an additional feature of the invention, the influencing of the other components by the debug resources is a deactivation of the other components, a turning off of the other components, a placement of the other components into a given state, a reset of the other components, a reconfiguration of the other components, and/or an alteration of signals fed to the other components. 
     In accordance with yet another feature of the invention, the debug resources prevent the other components from cooperating. 
     In accordance with yet a further feature of the invention, the debug resources initiate cooperation of components not otherwise cooperating. 
     In accordance with yet an added feature of the invention, the debug resources at least one of carry out influencing of the other components and carry out the cooperation of the other components at least one of with one another and with the core automatically when predefined events occur. 
     In accordance with yet an additional feature of the invention, the predefined events include an altering of an overall behavior by actions executed by the debug resources. 
     In accordance with a concomitant feature of the invention, the debug resources executing actions altering a behavior of the core, the debug resources stopping execution of the program, the debug resources altering a speed at which the program is executed, the debug resources causing the core to execute the program in a single-step mode, the debug resources causing execution of instructions not part of the program, and/or the debug resources causing execution of instructions of one of a debugging program and an emulation program. 
     Other features that are considered as characteristic for the invention are set forth in the appended claims. 
     Although the invention is illustrated and described herein as embodied-in a program-controlled unit, it is, nevertheless, not intended to be limited to the details shown because various modifications and structural changes may be made therein without departing from the spirit of the invention and within the scope and range of equivalents of the claims. 
     The construction and method of operation of the invention, however, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         FIG. 1  is a diagrammatic illustration and block circuit diagram of a program-controlled unit in accordance with a first exemplary embodiment of the invention; and 
         FIG. 2  is a diagrammatic illustration and block circuit diagram of a program-controlled unit in accordance with a second exemplary embodiment of the invention. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The program-controlled unit described below is a microcontroller. However, it is noted that the special features of the microcontroller that are described below can also be provided in any other program-controlled units, such as microprocessors, signal processors, etc. 
     The program-controlled units described below are distinguished by the fact that their debug resources are able to influence not only the core but also other components of the program-controlled unit and/or the cooperation of these components with one another and/or with the core. 
     For the sake of completeness, it is noted that the components of the program-controlled units considered that are illustrated and described are only the components that are of particular interest in the present case. 
     Referring now to the figures of the drawings in detail and first, particularly to  FIG. 1  thereof, there is shown a program-controlled unit containing a core C, memory devices S 1  to Sn connected to the core C through a first bus BUS 1 , periphery units P 1  to Pn connected to the core C through a second bus BUS 2 , a watchdog timer WD, and an OCDS module OCDS. 
     The core C reads data representing instructions and operands from the memory devices S 1  to Sn or from an external memory device that is provided outside the microcontroller and is not shown in  FIG. 1 , and executes the data. 
     The memory devices S 1  to Sn may be formed by a ROM, a flash memory, a RAM, or by any other memory devices. 
     The peripheral units P 1  to Pn are, for example, an A/D converter, a timer, a coding device, a DMA controller, a CAN controller, a USB controller, or other devices that can be integrated in microcontrollers. 
     The watchdog timer WD is a counter that:
         automatically counts upward or downward in a specific timing;   is reset when predetermined events occur; and   executes or initiates a specific action when a specific count is reached, the action including, for example, in the watchdog timer WD resetting, or putting into a specific other state, either the program-controlled unit in its entirety or, alternatively, at least the core C and/or one or more other components of the program-controlled unit.       

     The construction, the function and the method of operation of watchdog timers exist in the prior art so that the description of further details can be dispensed with. 
     The OCDS module OCDS is an OCDS module of the type mentioned in the introduction, but has a number of special features by comparison therewith. For the sake of completeness, it is noted that the OCDS module can be connected to a device provided outside the program-controlled device through one or more input and/or output terminals of the program-controlled unit, for example, through a JTAG or a NEXUS interface. The external device controls the OCDS module, i.e., specifies to the OCDS module when it has to carry out a particular action(s), and evaluates information output by the OCDS module. 
     In the example considered, the above mentioned special features of the OCDS module lie in the OCDS module automatically deactivating the watchdog timer if the OCDS module executes an action that alters the behavior of the program-controlled unit. 
     The aforementioned action is an action:
         that stops or interrupts the execution of the program that is to be executed by the program-controlled unit; or   alters the speed with which the program to be executed by the program-controlled unit is executed, that is to say, for example, putting the program-controlled unit into the single-step mode; or   that causes the program-controlled unit, more precisely, the core C thereof, to execute instructions that are not part of the (application) program that is to be actually executed by the program-controlled unit, but, rather, are instructions serving for the debugging or for the emulation of the program-controlled unit.       

     The watchdog timer WD is deactivated by the OCDS module outputting a deactivation signal that is fed to the watchdog timer, more precisely, a terminal ONOFF provided for the activation and deactivation thereof, through a control line CTRL. 
     In the above mentioned situations, the watchdog timer WD is deactivated automatically, i.e., without the execution of a special instruction and without separate initiating by the external device controlling the OCDS module. 
     Normally, i.e., in program-controlled units without the OCDS module used-in the present case, the watchdog timer WD is activated and deactivated exclusively through a non-illustrated system control unit connected to the terminal ONOFF of the watchdog timer, the system control unit being caused to activate and deactivate the watchdog timer by instructions executed by the program-controlled unit or by a logic that initializes the program-controlled unit after the resetting thereof. In other words, in program-controlled units without the OCDS module used in the present case, a special instruction would have to be executed to be able to reset the watchdog timer during the debugging or emulation of the program-controlled unit. 
     The automatic deactivation of the watchdog timer that is carried out by the OCDS module used in the present case has a number of advantages over such processes. In particular, the invention makes the operation of the OCDS module simpler, and, furthermore, precludes a possible error source during debugging or emulation. The reason for the first-mentioned advantage is that it is no longer necessary to perform special actions for deactivating the watchdog timer. The reason for the second advantage is that the situation wherein the watchdog timer disturbs the debugging or emulation of the program-controlled unit is reliably precluded; a watchdog timer that is inadvertently not deactivated could lead to the program-controlled unit being reset during the debugging or emulation thereof, the resetting itself and/or the cause thereof not being readily discernable. 
     The watchdog timer WD is activated again, preferably, after the end of the operations in response to which the watchdog timer was deactivated, that is to say, when the program-controlled unit executes the application program normally again (is not stopped, is not operating in the single-step mode, is not executing instructions serving for debugging or for emulation). What is achieved thereby is that the program-controlled unit—insofar as is possible under the given circumstances—operates as in normal operation during the debugging or emulation thereof. 
     As a result of the above-described deactivation of the watchdog timer WD, the watchdog timer WD or at least specific parts thereof is or are turned off. In other words, a deactivated watchdog timer no longer counts or at least no longer initiates actions, if it reaches the count that, when reached, would cause it to initiate, in the activated state, a resetting of the program-controlled unit or of parts thereof, or other actions. 
     The deactivation of the watchdog timer WD can also be carried out differently than in the manner described above. 
     One of the possibilities suitable therefor lies in the OCDS module carrying out an automatic reconfiguration of the watchdog timer when the events in response to which the watchdog timer is to be deactivated occur. Such reconfiguration may include, for example, in the count that, when reached, causes the watchdog timer to reset the program-controlled unit or parts thereof being set to a value that cannot be reached in phases in which the program-controlled unit behaves differently than in normal operation. By such or a different reconfiguration, it is possible, as a result, to obtain the same effect as through the above-described deactivation of the watchdog timer: the watchdog timer does not reset the program-controlled unit in phases in which the latter behaves differently than in normal operation. 
     A further possibility for deactivating the watchdog timer lies in the OCDS module regularly resetting the watchdog timer in phases in which the program-controlled unit behaves differently than in normal operation. What can be achieved by such a process, too, is that the watchdog timer does not reset the program-controlled unit in phases in which the program-controlled unit behaves differently than in normal operation. 
     The watchdog timer can, furthermore, be deactivated by the OCDS module ensuring that the generation or the supply of the clock signal depending on which the watchdog timer counts is prevented. As an alternative, it might be provided that a clock signal with a lower frequency is fed to the watchdog timer. What can be achieved by these measures, too, is that the watchdog timer does not reset the program-controlled unit in phases in which the program-controlled unit behaves differently than in normal operation. 
     For the sake of completeness, it is noted that the OCDS module also automatically carries out the aforementioned alternatives to the first-described deactivation of the watchdog timer, if the program-controlled unit behaves differently than in normal operation. 
     Irrespective of all that, it may be provided that the OCDS module automatically deactivates further or other components in addition to the watchdog timer or instead of the watchdog timer, if the program-controlled unit behaves differently than in normal operation. One component for which this might prove to be advantageous is, by way of example, but quite evidently not exclusively, a DMA controller. 
     The automatic deactivation of the watchdog timer or other components of the program-controlled unit may also be carried out by different debug resources than an OCDS module. 
     It may, furthermore, be provided that the OCDS module influences the watchdog timer or other components of the program-controlled unit differently than by a deactivation. What influencing this may be depends on the respective individual case. It is an aim in each case to adapt the behavior of the influenced components, by the influencing, as optimally as possible to the altered behavior of the core. In such a case, optimum adaptation means that the influenced components, on account of the influencing, operate and cooperate such way precisely the errors and disturbances that occur in normal operation of the program-controlled unit occur during the debugging or emulation of the program-controlled unit, in other words, if possible, the errors and disturbances that occur are no more, no fewer, and no different than in normal operation of the program-controlled unit. 
     It may also be provided that the OCDS module or other debug resources automatically influence the cooperation of specific components with one another and/or with the core, if the program-controlled unit behaves differently than in normal operation. For the sake of completeness, it is noted that this can be effected independently of the deactivation described above. 
     A program-controlled unit in which such is the case is illustrated in  FIG. 2 . 
     The program-controlled unit shown in  FIG. 2  contains:
         a plurality of cores, more precisely, a first core C 1 , a second core C 2 , and a third core C 3 ;   a plurality of watchdog timers, more precisely, a first watchdog timer WD 1  assigned to the first core C 1 , a second watchdog timer WD 2  assigned to the second core C 2 , and a third watchdog timer WD 3  assigned to the third core C 3 ;   an OCDS module including three components, more precisely, a first OCDS module component OCDS 1  assigned to the first core C 1 , a second OCDS module component OCDS 2  assigned to the second core C 2 , and a third OCDS module component OCDS 3  assigned to the third core C 3 ; and   for the remainder, corresponds to the program-controlled unit shown in  FIG. 1 , i.e., contains diverse memory devices S 1  to Sn and peripheral units P 1  to Pn.       

     The memory devices S 1  to Sn may be common memory devices that can be accessed by all the cores C 1  to C 3 , or, alternatively, private memory devices may be involved that can be accessed in each case only by a specific core. The same applies correspondingly to the peripheral units. 
     For the remainder, the memory devices S 1  to Sn and also the peripheral units P 1  to Pn correspond to the memory devices and peripheral units of the program-controlled unit in accordance with  FIG. 1 . 
     The cores C 1  to C 3  operate in parallel. They read data representing instructions and operands from the memory devices S 1  to Sn or from an external memory device that is provided outside the microcontroller and is not shown in  FIG. 2 , and execute the data. 
     The watchdog timers WD 1  to WD 3  in each case correspond to the watchdog timer WD of the program-controlled unit in accordance with  FIG. 1 . In other words, in each case counters are involved that:
         automatically count upward or downward in a specific timing;   are reset when predetermined events occur; and   execute or initiate a specific action when a specific count is reached, the action including, for example, in the watchdog timer resetting, or putting into a specific other state, either the program-controlled unit in its entirety or, alternatively, at least one or more cores and/or one or more other components of the program-controlled unit.       

     Although the watchdog timers WD 1  to WD 3  are respectively assigned to a specific core, each of the watchdog timers can reset one or a plurality of arbitrary cores when the specific count is reached. What watchdog timer resets what core or what cores can be set in the watchdog timers or a non-illustrated control device. 
     The OCDS module components OCDS 1  to OCDS 3  in each case correspond to the OCDS module OCDS of the program-controlled unit in accordance with  FIG. 1 . However, they have a number of further special features by comparison therewith. 
     In the example considered, these special features lie in the OCDS module components, when they execute an action that alters the behavior of one of the cores, automatically altering the setting that defines what watchdog timer can reset what core. 
     The aforementioned actions are those actions in the case of which the OCDS module OCDS of the program-controlled unit in accordance with  FIG. 1  deactivates the watchdog timer WD. 
     As a result, to name just one of a virtually unlimited number of examples, a setting in the case of which each watchdog timer resets all the cores in each case can be altered to the effect that each watchdog timer resets only in each case those cores to which it is not assigned. 
     In such a case, the different OCDS module components OCDS 1  to OCDS 3  can carry out different alterations of the settings. By way of example, it may be provided:
         that the first OCDS module component OCDS 1 , in the case where it causes the core to which it is assigned, that is to say, the core C 1 , to behave differently than in normal operation (e.g., to be stopped, to be operated in the single-step mode, or to execute instructions serving for debugging or emulation), alters the existing setting to the effect that the watchdog timer WD 1  assigned to the core C 1  resets none of the cores present, and the other watchdog timers WD 2  and WD 3  can reset the core C 2  and/or the core C 3  but not the core C 1 ;   that the second OCDS module component OCDS 2 , in the case where it causes the core to which it is assigned, that is to say, the core C 2 , to behave differently than in normal operation (e.g., to be stopped, to be operated in the single-step mode, or to execute instructions serving for debugging or emulation), alters the existing setting to the effect that the watchdog timer WD 2  assigned to the core C 2  resets none of the cores present, and the other watchdog timers WD 1  and WD 3  can reset the core C 1  and/or the core C 3  but not the core C 2 ; and   that the third OCDS module component OCDS 3 , in the case where it causes the core to which it is assigned, that is to say, the core C 3 , to behave differently than in normal operation (e.g., to be stopped, to be operated in the single-step mode, or to execute instructions serving for debugging or emulation), alters the existing setting to the effect that the watchdog timer WD 3  assigned to the core C 3  resets none of the cores present, and the other watchdog timers WD 1  and WD 2  can reset the core C 1  and/or the core C 2  but not the core C 3 .       

     It goes without saying that any other combinations desired are also possible. 
     Furthermore, the OCDS module components can also influence whether and, if appropriate, what other components of the program-controlled unit are reset by the respective watchdog timers. 
     Preferably, the OCDS module components cause the setting alterations to be entirely or partly reversed again if the core to which they are respectively assigned is operating normally again (is no longer stopped, is no longer operating in the single-step mode, and is not executing a program serving for debugging or emulating, etc.). 
     As a result of the setting alterations that can be carried out by the OCDS module components, it is possible, during the debugging or emulation of the program-controlled unit, for the latter to be brought into a state in which the debugging or the emulation is disturbed as little as possible, and/or the program-controlled unit behaves as a normal operation—insofar as is possible under the given circumstances—during the debugging or emulation. 
     Furthermore, it may (but need not) be provided that the OCDS module components can deactivate the watchdog timers like the OCDS module of the program-controlled unit in accordance with  FIG. 1 . 
     The program-controlled units described make it possible, independently of the details of the practical realization, for errors occurring therein to be localized and eliminated under all circumstances rapidly and simply.