TWI306191B - A method for debugging a firmware program and a debugging microprocessor - Google Patents

Description

1306191 IX. Description of the Invention: [Technical Field] The present invention relates to an embedded firmware program, and more particularly to an error-fixing microprocessor and method for an embedded firmware program. [Previous technique #f] φ When using a microprocessor to perform debugging of a firmware program, it is usually necessary to review the value of the scratchpad inside the microprocessor. One way to achieve this is to add additional hardware support to make it easy for programmers to query the registers. Generally, a computer containing such a debugging application can be called a debugging host. Sometimes the debugger can communicate directly with the microprocessor', but usually a protocol converter is used to convert the debug host's output signal to the microprocessor's interface format. The protocol converter is responsible for setting up the microprocessor's debug register based on the debugger's requirements. In order to facilitate the debugging of the Lex program, the programmer usually sets the program breakpoint, the variable watchpoint, and the hardware event capture point during the debugging process. Program breakpoints are events that are set based on the instruction flow, such as when the microprocessor executes an instruction at a particular program address or when the microprocessor executes an opcode of a particular instruction. Variable observation points are events that are set based on the data flow, such as when the microprocessor accesses a variable from a particular variable address, or when the microprocessor accesses a particular data value. hard

Client's Docket No.: CRU04-00l6 TT's Docket No:0008-A4068'TW/Final/Yuan/2006-03-28 1306191 The body event capture point is for the programmer to know that it has a hardware-related event, such as an interrupt. , restart, etc.: In general, the debug module in the microprocessor will be scooped up - the 'storage register can be set to monitor the Boss = group temporary breakpoints or variables Observe the specific address or data value of the point. The number of programs is limited, and only a large increase in the module design complexity of the registers of the scratchpad is added, so the group = becomes a debug breakpoint or a variable watchpoint share. The first part of the register is used to monitor the memory address, and the γ P knife is used to monitor the data. The set of registers also includes the value of the internal memory of the device, and the address or data of the current desired line. If the address (whether the instruction 2 = address) is the temporary storage of the first part The material comparison, if it is the instruction data or the variable data, is compared with the second part of the register. This type of scratchpad can present the following problems when used in the entire debug system. A variable observation point can be seen in two ways. The first one is called a hardware variable observation point, and the second type is called a soft number observation point. In the case of the hardware variable, the programmer can quickly debug, because the system uses the registers in an embedded in-circuit emulator module. The data on the bus is compared to monitor the events corresponding to the variable observation points, and the microprocessor can execute the firmware at the original speed. In the case of a software variable observation point, whenever the microprocessor executes an instruction, the debugger needs to query the microprocessor once to check that the data value corresponding to the variable observation point is

Client's Docket N〇.:CRU04-0016 TT^ Docket No:0608-A40684-TW/Finaimlan/2006-03-28 7 1306191 No change, so in the case of software variable observation point, the speed of debugging is reported It's slow and hard to implement in real-world applications. The problem occurs when the programmer is unfamiliar with the difference between the hardware variable observation point and the software variable observation point' and believes that the order of setting the program breakpoint and the variable observation point does not cause a difference in debugging. For example, in a debug system with only one set of scratchpads for debugging, the programmer first sets the program breakpoint and then sets the variable watchpoint. When the program breakpoint is first set, the protocol converter sets the relationship between the scratchpad and the program breakpoint, and returns the debug host program breakpoint has been set successfully. When the variable observation point is set, the protocol converter finds that the scratchpad has been occupied by the program breakpoint and is not enough to set the variable observation point. Therefore, the communication protocol converter returns the debug host variable observation point is not set successfully. At this point, most of the debuggers have to choose to implement the variable observation point in the way of the software variable observation point. Therefore, each time the microprocessor executes a one-step dynamic program, the debugger needs to query the microprocessor for a variable change. The problem is that this method is too slow, and # is an effective way to perform firmware-based debugging. If the variable observation point is set first, then when the program breakpoint is set, the protocol converter finds that the scratchpad has been occupied by the variable observation point first, which is not enough to set the program breakpoint. Therefore, the protocol converter returns that the debug host program breakpoint is not set successfully. At this point, the debugger only has to display to the programmer the message that the program breakpoint is not set successfully, so the programmer can decide whether he wants to continue the debug work. At this point, if the debugging continues, the variable observation point will operate as expected by the programmer, but the program

Client's Docket N〇.:CRU04-0016 TT^ Docket No:0608-A40684-TW/Finaman/2006-03,28 8 1306191 - Designers cannot use program breakpoints for debugging during debugging. • In the debugging system of the program breakpoint and the variable observation point, the program breakpoint and the variable watchpoint are set differently, which will cause different execution states. Make the programmer feel very confused. Furthermore, the programmer cannot distinguish between the hardware and software variable observation points, and is therefore surprised by the slower execution speed of the software variable observation points. In addition, the software variable observation point can only detect the change of the variable value, _ and can not detect whether a certain variable address is read or written. When the same value is written to a variable address, the software variable observation point cannot Find. However, if the number of scratchpads is increased, the complexity of the debugging module design will be greatly improved. Therefore, the design of the debugging system of the prior art can cause considerable inconvenience to the programmer. SUMMARY OF THE INVENTION In view of the above, in order to avoid the problems caused by the prior art, the present invention provides a microprocessor for firmware debugging. The microprocessor can be controlled by a debug host to debug the firmware. The microprocessor includes a core module for executing the firmware, and a confluence coupled to the core module. The bus interface module is configured to retrieve a plurality of variables and access variables required for the core module from the firmware program through a bus, and the microprocessor includes An embedded in-circuit emulator coupled to the core module and the bus interface module stores the at least one first debugging parameter and at least one in a separate and independent manner The second debugging parameter, and notifying the core module when the following conditions are generated, the conditions include when the core Client's Docket N〇.: CRU04-0016 TT's Docket No: 0608-A40684-TW/Final/Yuan/2006- 03-28 „ 1306191 • If the information about the instructions transmitted between the loose group and the bus interface module matches any of the first debug parameters, or when the core module is The transmission between the bus interface modules The related information of the variable is consistent with any of the second debugging parameters. The invention further provides a method for debugging the firmware program, which is used by a microprocessor for debugging. Executing, the microprocessor retrieves a plurality of instructions of the firmware program through a bus and accesses a plurality of variables of the firmware, wherein the method for debugging the firmware includes: ??? storing, in a separate and independent manner, at least one first debugging parameter and at least one second debugging parameter. At this time, if the information related to the instructions captured by the microprocessor is related to the first debugging When any of the parameters matches, the microprocessor is suspended from executing the firmware and notifying the debug host. In addition, if the information related to the variables accessed by the microprocessor is related to the second debug When there is any match in the parameter, it is notified that the debug host has at least one brother and one debug parameter has been updated. _ In summary, the present invention still sets each temporary in the same group of registers without increasing the number of registers 1 Memory value, but each temporary Each of the devices stores different debugging parameters, so there is no such thing as the first time that the scratchpad is interrupted by the program or the error of the variable observation point (4), so the programmer does not need to The above and other objects, features, and advantages of the present invention will become more apparent from the aspects of the invention. The details are as follows:

Client’s Docket No. : CRU04-0016 TT’s Docket No: 0608-A40684-TW/Final/Yuan/2006-03-28 1306191 [Embodiment]

1 is a block diagram of a debug system 100 in accordance with the present invention. The debug system 100 includes a debugging host 102, a protocol converter 104, and a microprocessor 106. The debug host 102 is used as a user interface for the programmer of the firmware program to control the entire body program debugging process. The debug host 102 can be a computer system for storing debug programs, and the programmer can use the application to control the debug progress and change the detailed settings of the debug process. The microprocessor 106 is located on a circuit board 140 and executes a firmware program to control other components on the circuit board 140. The entire debugging process is intended to debug the firmware in execution. The protocol converter 1〇4 serves as a communication interface between the debug host 102 and the microprocessor 1〇6, and converts the signals communicated by the two into a format that can be understood by each other to enable the communication between the two to proceed smoothly. In addition to the microprocessor 106, other components included on the circuit board 140 include system memory 12 for storing data and firmware 150 executed by the microprocessor 1, a specific use wafer, and Other circuit components. Microprocessor 106 interfaces with these components via busbars 130 to control the components on these boards via busbars 130 and receive responses from those components. The bus bar 130 includes at least one address bus bar 132 and at least one data bus bar 134 connected between the system memory 12 〇 and the bus bar interface module. When the microprocessor 1 撷 6 wants to retrieve the firmware program stored in the system memory 120, first through the address bus ι 32

Client's Docket N〇.:CRU04-0016 TT,s Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 11 1306191 Specify the instruction address of the firmware program to the system memory 120; and the system memory After receiving the designated instruction address, the instruction file of the firmware 150 is transmitted back to the microprocessor 1〇6 via the data bus 134. In addition, a number of variables 160 are generated after the firmware 150 is executed and are also stored in the system memory 120. When the microprocessor 106 wants to retrieve the variable 160 stored in the system memory 12, the variable address of the variable 160 is first specified to the system memory 12 by the address bus 132; and the system memory 120 is received. After the variable address, the variable 160 of the variable 160 is passed back to the microprocessor 106 via the data bus 134. The system memory 120 may also be composed of a first memory storing the body program 150 and a second memory storing data, wherein the first memory may be a read only memory (ROM), and the second memory may be It is a random access memory (RAM). The microprocessor 106 includes a core module 11A, a bus interface module 112, an embedded in-circuit emulator module 114, and a joint test action group.

(joint test action group, hereinafter referred to as JTAG) interface 116. The JTAG interface 116 is a special 4 or 5 pin interface that is attached to the microprocessor 1 and the debug host 102 can communicate with the microprocessor 106 via a test probe connected to the JTAG interface 116. The core module 110 is the core of the microprocessor 100 and executes instructions of the program to control other components on the board. The bus interface module 112 can access the bus bar 130 on the circuit board 14A. Therefore, the core module 11 can access the firmware program 150 through the bus interface module 112, read variables from the system memory 120, and

Client’s Docket No·: CRU04-0016 λλ m TT's Docket No: 0608-A40684-TW/Final/Yuan/2006-03-28 1306191 Variables are written to the system memory. When the programmer uses the debug application pair in the debug host 1〇2

When the ϊ ϊ 均 150 150 150 150 150 150 150 150 150 150 150 150 150 ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ ’ At this point, the programmer can observe (4) some important values of the program on the screen of the debug host, and check whether the variables are correctly changed after the execution of the instruction before the ___. In addition, the value of the money set by the programmer is pre-set to her point (her hpQint). If the programmer thinks that the Wei value is partially wrong (4), the programmer can correct the Boomer program to test whether the variable values will change correctly. If the variable values are correct, they are expressed in the program breakpoint precursor. The program's Lai JE does 'and * needs any correction. The programmer then decides through the debug field whether to let the microprocessor perform the subtraction. The embedded in-circuit simulator module 114 is the core of the debug process. The re-monitoring instruction bus occurs with the occurrence of the _ program breakpoint and monitors the ^ 贞 贞 魏 Wei observation (4). When the core module no performs storage;: When the system memory is __, the core remainder is the instruction that continues to execute the program from the system memory. Whenever the -(4) program is used, the core module must specify the instruction address of the instruction to be retrieved from the system through the bus interface module 112, and then "the memory will return the instruction data of the address." Passed to the core module iig. Because the in-circuit simulator module and group 114 can monitor the command address_order data transmitted between the core module m and the busbar 2 module U2, the program breakpoint is detected. When _ to program breakpoint, embedded ^

Client’s Docket N〇_:CRU04-0016 TT’s Docket No:0608-A40684-TW/Final/Yuan/200匕 〇3 force 1306191

The internal simulator module 114 will notify the debug host 102' through the TAG interface 116 and suspend the action of the core module 110. At this time, the programmer can check whether the execution result is correct for subsequent program modification. , or continue to connect 7 variables view __ debug. Another embodiment of the present invention is an embedded in-circuit simulator module 114 that also monitors the billet bus to detect the occurrence of variable observation points. When the core module 10 executes the fej body & formula, the variable value peach calculated by the core d and the group 11G is stored in the system memory. Therefore, when executing the body program, the core module 110 must continue to read the variable data from the system memory, and the number of data is written to the system memory. Whenever the access-variable, the core 110 must specify the (four) variable address of the system memory through the bus interface module 112, and then the variable data of the system memory is transmitted back to the core module. Therefore, the embedded power;: | § right group 114 can monitor the variable information related to the variable address or variable data transmitted between the core module 11 〇 and the bus interface module ′, the variable observation point. When the point is observed, the embedded circuit internal light module 114 will notify the debug host 1〇2 through the JTAG interface φ 116 and transmit the variable observation value to the debug line 1G2. In this case, the programmer can check whether the execution result of this stage is correct for subsequent modification, or choose to continue the program breakpoint to debug. Figure 2 is a block diagram of the in-circuit emulator module 2 (10) in accordance with the present invention. The embedded in-circuit emulator module 200 corresponds to the in-circuit emulator module 114 of Fig. 1. The embedded in-circuit simulator module 200 is monitored between the core module 11〇 and the busbar interface module 1丨2.

Client's Docket N〇.:CRU04-0016 TT's Docket No:0608-A40684-TW/FinalAruan/2006-03-28 1306191 Command and variable related information, and the instruction related information and program breakpoints match 'combination or variable related information and When the variable observation points coincide, the debug host 102 is notified through the JTAG interface 116. Whenever the core module 110 reads an instruction from the system memory storing the executed firmware program, the core module 110 must output the address of the instruction through the bus interface module 112, and then the instruction of the address. The data is then passed back to the core module 110 by the system memory. Similarly, whenever the core module 110 reads a variable from the system memory in which the firmware variable data is stored, or when the core module 110 writes a variable value into the system memory, the core The module 110 must output the address of the variable through the bus interface module 112, and then the variable data of the address is transmitted back to the core module 110 by the system memory, or the system memory specified by the variable address is written. in. The embedded in-circuit emulator module 200 includes an instruction address register 202 for storing the program address of the program breakpoint, and an instruction data register 204 for storing the instruction data of the program break point. The variable address register 206 for storing the variable address of the variable view point, and a variable data register 208 for storing the variable data of the variable observation point. Although the storage space of the four registers is the same as that of the conventional register group, it is specifically used to separately and independently store the information about the address and data of the program breakpoint and the variable observation point. Since the data register and the address register of the simulator module 200 in the embedded circuit are not shared by the program breakpoint and the variable observation point, the prior order of the variable observation point and the program break point does not occur. The problem that causes the different effects of the debugging process is bothering the programmer.

Client's Docket N〇.:CRU04-0016 TT's Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 15 1306191 Whenever the core module 110 assigns an instruction to the system memory through the bus interface module 112 The address 'comparator 212 compares the instruction address with the instruction address stored in the program bit address in the instruction address register 202 to generate a first comparison result signal. If the instruction address matches any of the instruction addresses of the program breakpoint, then the first comparison result signal generated by the comparator 212 is in an enabled state. Whenever the system memory transmits back a command data to the core module 11 through the bus interface module 112, the comparator 214 outputs the command and the instruction stored in the instruction data register 2〇4. The data is compared to produce a second comparison result signal. If the command data matches any of the command data of the program breakpoint, the second comparison result signal generated by the comparator 214 is in an enabled state. Whenever the core module 110 assigns a variable address to the system memory through the bus interface module 112, the comparator 216 compares the variable address with the variable address of the variable observation point stored in the variable address register 206. In comparison, a second comparison result signal is generated. If the variable address matches any of the variable addresses of the variable observation point, the third comparison result signal generated by the comparator 216 is in an enabled state. Whenever the system memory returns the variable data to the core module 110 through the bus interface module 112, the comparator 218 compares the variable data with the variable data stored in the variable observation point of the variable data register 2〇8. Compare to generate a fourth comparison result signal. If the variable data matches any of the variable data of the variable observation point, the fourth comparison result signal generated by the comparator 218 is in an enabled state. The four comparison result signals output from the comparators 212 to 218 described above are executed by the OR gate 220 to perform an 0R function to generate an output value. If the loss

Client's Docket No.:CRU04-0016 TT^ Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 16 1306191 The value system is enabled, which may indicate that the core module is set by the programmer. The program breakpoint part = ^ Dingle - wrong host will receive the embedded circuit simulator module 2 提 and the core module 110 is also embedded in the circuit simulator modulo = two suffix Actions. The round-out value appears as an enablement from ^ =::U° is being changed by the programmer; number view:: == will receive 'notification' in the embedded circuit '=, and 200 The new change of the variable observation point is sent to the debug host, and the W-cut designer is divided into the flowchart of the (4) program according to the present invention, except for the micro-location/day, the method. Storing at least one first debugging parameter and reaching. The second dividing and independently 302). The first debugging error parameter may be a wrong parameter (step program breakpoint, and the second debugging parameter is a variable variable observation point of the number variable). The first de-calcification program of the calcium-removing program can be repeated by the complex instruction address register 2〇2, and the instruction data corresponding to the instruction bit parameter corresponding to the library can be #复复, and the first debugging _, For example, the variable variable address can be stored by the complex variable address, and the corresponding variable data can be stored by the complex variable: the second debugging parameter is stored as shown in Fig. 2 The Bayer register 208 is stored to store the complex variables that are accessed by the microprocessors retrieved by the microprocessor. Address match ^ order 'command position and the corresponding parameter of the first debug instruction of the person 13, generates a first comparison

Client’s Docket N〇.: CRU04-0016 TT's Docket No: 0608-A40684-TW/Fmal/Yuan/2006-03-28 1306191 Result signal ((iv) 304). When the command data corresponding to the Wei parameter matches, the f: debug is generated (step chat if the address of the complex variable matches the variable position of the second two =, a corresponding number is generated) The data of the complex variables &^ ratio == (when the step variable data is matched, the result signal of the fourth is generated to generate a round-off value. (Step 312) ^ At this point, if the step 312 The round-out value is positive (the event corresponding to the program breakpoint or the variable observation point before the step occurs. If this = 2 or the mb is the result of the positive ((4), the corresponding event occurs, it is micro-processed) Table 4 (4) The observation point parameters match, so the variable of the debug host is notified that the variable of the ^ is updated with the second debug (step 318). Otherwise, the second debug attribute has been positively represented as the event corresponding to the program breakpoint. ^Two comparison results the signal processor continues to execute the Bosch program and informs the debugging that the micro-group is only 3 = 3 addresses ^ embedded in-circuit simulator mode ==::r, respectively, and self-micro processing Bit == The number of embedded circuit in-circuit emulator modules in the prior art is limited. If the program design, the program breakpoint, there is no space to set the variable observation point. So - the debug field can only be in the (four) money line -

Client's Docket N〇.:CRU04-0016 TT5sDocketNo:0608-A40684-TW/FmayYuan/2006-03-28 18 1306191 After checking the value of the variable observation point, this is called the software variable observation point and will be greatly reduced. The execution speed of the firmware program. Similarly, if the programmer sets too many variable observation points, there is no space for setting the program breakpoint. Since the programmer does not necessarily understand the internal design details of the emulator module in the embedded circuit, the programmer may have a reason. The difference between the variable observation point and the program breakpoint setting sequence is different because of the different effects of the debugging process. Therefore, the present invention provides a debug system for each of the program breakpoints and variable watchpoints having their own dedicated data register and address register. This design greatly simplifies the process of setting program breakpoints and variable watchpoints, and avoids the problems caused by the shared data register and address register. This design also allows the programmer to achieve consistent results regardless of the program breakpoint or variable viewpoint when debugging, and avoids the programmer's confusion. In addition, because the variable observation points have exclusive hardware support, the programmer is not surprised by the sudden change from the hardware variable observation point to the software variable observation point. Although the present invention has been disclosed in the above preferred embodiments, it is not intended to limit the invention, and it is intended that the invention may be modified and modified without departing from the spirit and scope of the invention. The scope of the invention is defined by the scope of the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a debug system according to the present invention; FIG. 2 is a block diagram of an emulator module in an embedded circuit according to the present invention.

Client's Docket No· :CRU04-0016 TT's Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 19 1306191 Block Diagram; and 'Figure 3 is the debugging of the firmware program according to the present invention. Method " Flowchart. [Main component symbol description] 102~Debug host; 104~communication protocol converter; 106~microprocessor; φ110~core module; 112~bus interface module; 132~address bus; 134~ Busbar; 130~ busbar; 140~ circuit board; 120~ system memory; 150~ firmware program; 160~ variable; 114, 200~ embedded circuit simulator module; 116~JTAG interface; Instruction address register; 204~ instruction data register; 206~variable address register; 208~variable data register; 220~OR gate; 212-218~ comparator.

Client's Docket N〇.:CRU04-0016 TT's Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 20

Claims (1)

1306191 X. Patent application scope: - 1. A microprocessor for firmware debugging, which can be debugged by a master-machine to debug a firmware program, including a core module. The bus interface module is coupled to the core module for capturing a plurality of instructions of the firmware program for the core module through a bus bar. Accessing the complex variable of the firmware program; and an embedded in-circuit I emulator, which is connected to the core module and the bus interface module for separation and independence Storing at least one first debugging parameter and at least one second debugging parameter, and the plurality of instructions and the at least one first debugging parameter transmitted by the core module and the bus interface module The core module is notified when one of the coincidences, or when the complex variable transmitted by the core module and the bus interface module matches any of the at least one second debugging parameter. 2. The microprocessor for firmware debugging according to claim 1, wherein the at least one first debugging parameter and the at least one second debugging parameter are performed via the debug host. Settings and modifications. 3. The microprocessor for firmware debugging according to claim 1, wherein the at least one first debugging parameter is at least one program breakpoint for interrupting execution of the firmware program ( Breakpoint). 4. The microprocessor for firmware decoding according to claim 1, wherein the at least one second debugging parameter is at least one variable for monitoring the complex variables of the firmware program. Watchpoint. Client's Docket No.: CRU04-0016 TT5s Docket No: 0608-A40684-TW/Final/Yuan/2006-03-28 21 1306191 5. For the firmware of the firmware as described in item 1 of the patent application scope The processor, wherein the plurality of instructions of the firmware program are stored in a first memory, wherein the plurality of variables are stored in a second memory, and the first and second memories are The bus bar is coupled to the microprocessor. 6. The microprocessor for firmware firmware debugging according to claim 1, wherein the embedded circuit simulator module comprises: a plurality of instruction address registers for storing the division At least one instruction address of the at least one first debugging parameter set by the wrong host; a plurality of instruction data registers for storing at least one instruction data of the at least one first debugging parameter set by the debugging host; a plurality of variable address registers for storing at least one variable address of the at least one second debugging parameter set by the debug host; and a complex variable data register for storing settings by the debug host At least one variable data of the at least one second debugging parameter. 7. The microprocessor for firmware debugging according to claim 6, wherein the embedded in-circuit emulator module further comprises: a first comparator coupled to the core module And the plurality of instruction address registeres for generating a first comparison result when the addresses of the plurality of instructions coincide with any of the at least one instruction position of the at least one first debugging parameter a signal, wherein the core module outputs the addresses of the plurality of instructions to cause the bus interface module to capture the plurality of instructions; a second comparator coupled to the bus interface module and the plurality of instructions a data register for the data of the plurality of instructions and the at least one Clienfs Docket No.: CRU04-0016 TT^ Docket No: 0608-A40684-TW/Final/Yuan/2006-03-28 Ϊ306191 first division When any one of the at least one command data of the wrong parameter is met, a second comparison result signal is generated, wherein the bus interface module retrieves the data of the plurality of instructions and returns the data of the plurality of instructions Passed to the core module; a third comparator And coupled to the core module and the plurality of variable address registers for matching the address of the complex variable with any of the at least one variable position of the at least one second debugging parameter a third comparison result signal is generated, wherein the core module specifies a bit address of the complex variable to allow the bus interface interface module to capture the complex variable; and a fourth comparator coupled to the confluence The interface module and the plurality of variable data registers are configured to generate a fourth when the data of the complex variables matches any of the at least one variable data of the at least one second debugging parameter Comparing the result signals, wherein the bus interface module retrieves the data of the complex variables and transmits the data of the complex variables back to the core module; and an OR gate coupled to the first and second The third and fourth comparators, ???arem for performing an OR function on the first, second, third, and fourth comparison result signals to generate an output value; wherein the output value is an enable state, the embedding In-circuit simulator module The debug host is notified. 8. A method for debugging a firmware program, the firmware program being executed by a microprocessor for debugging, the microprocessor capturing a plurality of instructions of the firmware program and accessing the firmware The complex variable of the program, the method for debugging the firmware program includes the following steps: Client's Docket N〇.: CRU04-0016 TT's Docket No: 0608-A40684-TW/Final/Yuan/2006-03-28 23 Ϊ306191 The microprocessor separately and independently stores at least one first debugging parameter and at least one second debugging parameter; if the plurality of instructions captured by the microprocessor and the at least one first debugging parameter In either case, the microprocessor is suspended from executing the firmware and notifying a debug host; and if the complex variable accessed by the microprocessor matches any of the at least one second debug parameter When the debug host is notified, the at least one second debug parameter has been updated. 9. The method of debugging a firmware program as described in claim 8 wherein the at least one first debug parameter is at least one program breakpoint for interrupting execution of the firmware. 10. The method for debugging a firmware program according to claim 8, wherein the at least one second debugging parameter is at least one variable observation point for monitoring the complex variables of the firmware program. . 11. The method for debugging a firmware program according to claim 8, wherein the storing step comprises the steps of: separately and independently storing the at least one first debugging parameter set by the debug host. At least one instruction address and at least one instruction data; and separately and independently storing at least one variable address and at least one variable data of the at least one second debugging parameter set by the debug host. 12. The method for debugging a firmware program according to claim 11 of the patent application, further comprising the steps of: if the address of the plurality of instructions and the at least one instruction position of the at least one first debugging parameter When any of the matches is met, a first comparison result Client's Docket No. is generated: CRU04-0016 TT's Docket No: 0608-A40684_TW/Final/Yuan/2006-03-28 24 1306191 m signal, wherein the microprocessor specifies The addresses of the plurality of instructions for capturing - the plurality of instructions; * generating a first if the data of the plurality of instructions matches any of the at least one of the at least one first debugging parameter Comparing the result signals, wherein the data of the plurality of instructions is retrieved and transmitted back to the microprocessor; if the address of the complex variable is in the at least one variable position of the at least one second debugging parameter When any of the phases meets, a third comparison result k signal is generated, wherein the microprocessor specifies the addresses of the complex variables to retrieve the complex variables; if the data of the complex variables and the at least one second except When any one of the at least one variable data of the wrong parameter matches, a fourth comparison result signal is generated, wherein the data of the complex variables is captured and transmitted back to the microprocessor; performing an OR function on the The first, second, third, and fourth comparison result signals generate an output value; and > if the output value is in an enabled state, the debug host is notified. 13. The method of debugging a firmware program as described in claim 8 wherein the debugger can command the micro-processor after the microprocessor is suspended in the abort step. The processor continues to execute the firmware. Client’s Docket No. :CRU04-0016 TT’s Docket No:0608-A40684-TW/Final/Yuan/2006-03-28 25