Recent years have witnessed marked growth in the scale of programs being developed, and the time required for the task of debugging is having an increasing impact on product development schedules. As a result, there is a need for the construction of an environment that would allow debugging to be carried out with greater efficiency. A method in which a diagnostic processor is used to support debugging such as the debugging system described in Patent Document 1 “Processor Information Collector and Program Recording Medium Therefor” is one method of efficiently carrying out debugging.
As shown in FIG. 1, this debugging system of the related art is provided with arithmetic processor group 801, memory device 802, and diagnostic processor 803 for monitoring the operating state of arithmetic processor group 801. Diagnostic processor 803 is further provided with: stall detector 831 for detecting the stalled state of each of the arithmetic processors that make up arithmetic processor group 801, collector 832 for collecting the internal states of the arithmetic processors, write unit 834 for saving the internal states of arithmetic processors in memory device 802, and initialization unit 836 for initializing the information processing system while holding unchanged the internal states of the arithmetic processors in memory device 802.
A debugging system of this configuration of the related art operates as described below.
Stall detector 831 first detects whether arithmetic processors that make up arithmetic processor group 801 have entered a stalled state. When a stall occurs, collector 832 collects the internal states of the arithmetic processors and writes the collected internal states of the arithmetic processors as arithmetic processor internal states 821 in memory device 802. The information processing system is then initialized with the internal states of the arithmetic processors saved unchanged in memory device 802. Because the information of the internal states of arithmetic processors has been saved in memory device 802 even after initialization, this information can be used to carry out a debugging operation regarding the state in which the stall occurred.
Although a method in which diagnostic processor 803, which is high-function dedicated hardware for debugging, is mounted in a system as in the related art described in Patent Document 1 can achieve the effect of raising the efficiency of debugging, this method also has the drawbacks of requiring the addition of hardware that does not contribute to normal operations and further, of raising the cost of the system. In addition, requirements that mean increased cost for equipments whose components are built-in are particularly severe, and this frequently prohibits the mounting of dedicated hardware.
On the other hand, the miniaturization of semiconductor integrated circuits and the greater functionality demanded of system LSI has led to an increase in the mounting of a plurality of execution units such as CPUs in system LSI. The debugging system disclosed in Patent Document 2 “Resetting Circuit and Resetting Method for Multiple CPU” is an example of the related art for increasing the efficiency of debugging while avoiding an increase in costs due to dedicated hardware for debugging.
As shown in FIG. 2, this debugging system of the related art is provided with CPU control circuit 903 for controlling the resetting and interruption of system LSI that incorporates a plurality of CPUs (CPU-A901 and CPU-B902). CPU control circuit 903 has the capability for setting one of a plurality of CPUs (CPU-A901 and CPU-B902) to a debugging means in which a program for normal operations is replaced by program for debugging. In addition, CPU control circuit 903 is further provided with: interrupt control circuit 904, bus trace function 905, strap take-in circuit 906, and debugging control circuit 907.
Explanation next regards the operation of the debugging system of the related art having this configuration with reference to FIG. 3.
First, when CPU control circuit 903 detects hardware resetting, debugging control circuit 907 issues a command for the resetting of each internal function block (not shown) (Step S91).
Strap take-in circuit 906 next reads external setting information such as strap information from strap setting unit 908 (Step S92).
When the strap information that has been read indicates normal operation (“NO” in Step S93), debugging control circuit 907 cancels the resetting for CPU-A901 and CPU-B902 and for each function block based on the strap information that has been read (Step S94).
When resetting has been canceled, each function block begins operation (Step S95).
On the other hand, when the strap information that has been read designates debugging (“YES” in Step S93), the debugging process begins (Step S96).
When the strap information selects CPU-B902 as the debugger (“B” in Step S961), debugging control circuit 907 cancels the resetting of CPU-B902 that has been selected by the strap information (Step S962).
Debugger CPU-B902 is then activated (Step S963), and upon completing the start-up operation (“YES” in Step S964), the resetting of target CPU-A901 and each functional block is canceled (Step S965).
On the other hand, when the strap information selects CPU-A901 as the debugger (“A” in Step S961), debugging control circuit 907 cancels the resetting of CPU-A901 that was selected by the strap information (Step S966).
Debugger CPU-A901 then starts up (Step S967) and upon completing the start-up operation (“YES” in Step S968), cancels the resetting of target CPU-B902 and each functional block (Step S969).
When debugging a program that is executed in a system in which a plurality of execution units perform linked operation, information that relates to communication between the plurality of execution units and that can be checked from the outside by components other than the execution units or information this is generated during the occurrence of a fault is saved and then subsequently checked. In this method, however, the cause of the occurrence of a fault cannot be adequately investigated in many cases. On the other hand, when using a program for debugging that artificially generates transmission content that is generated by a program for normal operation or by a program for debugging that reports to the debugging technician the transmission/reception content, the cause of the occurrence of a fault can usually be effectively investigated. These programs for debugging are therefore put into operation on execution units to carry out the task of debugging.
However, putting these debugging programs into operation beforehand increases the load on the CPU, and further, because the debugging programs use storage area, influences the operation timing of the normal operation program. As a result, the existence of the debugging program has the drawbacks of preventing the occurrence of faults that may occur in normal operation, and conversely, of causing the occurrence of faults that should not occur when executing only the normal operation program.
Further, in a program that is executed in a system in which a plurality of execution units perform linked operation, the execution unit in which a fault, particularly a fault produced by timing, occurs cannot be uniquely determined, and the occurrence of such a fault is therefore difficult to anticipate. When an execution unit enters a stalled state or when a fault occurs that has an effect on the operation of execution units, the debugging program may be unusable on the execution unit that is in a stalled state, or the debugging program may be unusable in execution units in which the operation is affected. As a result, the debugging program may have to be operated in a different execution unit. However, when the site of the fault occurrence cannot be uniquely determined, an execution unit that is unaffected by the fault also cannot be determined.
The method of the related art described in Patent Document 2 features the assignment of an execution unit (debugging CPU) that activates a debugging program at the time of resetting, and resetting must be carried out again when changing the debugging CPU. As a result, when a fault occurs that has an effect upon the operation of a debugging CPU that has been assigned at the time of resetting, the state cannot be debugged.
As explained hereinabove, in the above-described debugging system of the related art, the following problems arise when carrying out debugging in a system in which a plurality of execution units (CPUs) perform linked operation:
(1) When the debugging program is activated beforehand, the operation timing differs from a case in which only the normal operation program is in operation, and the presence of the debugging program therefore prevents the occurrence of faults that would occur in normal operation, or conversely, causes faults to occur that should not occur when only the normal operation program is executed.
(2) The execution unit that is to execute the debugging program must be set in advance, but the occurrence of a fault that has an influence upon the operation of the execution unit that has been set prevents debugging of the state.
Patent Document 1: JP-A-H11-184736
Patent Document 2: JP-A-2004-164113
USPTO Backgrounds
USPTO Backgrounds