This application is based upon and claims priority from Japanese Patent Application No. 2003-297456 filed on Aug. 21, 2003, which is herein incorporated in its entirety by reference.
The present invention relates to a program processing device, and more particularly, to a control LSI optimal for use when testing the operation of built-in software (firmware).
In recent years, an evaluation chip is normally used when developing software. The evaluation chip includes a CPU of a target system and an interface circuit, which supports software debugging. The evaluation chip, which is mounted on a user board, is connected to an in-circuit emulator (ICE (a registered trademark)). The ICE provides a debug command to the CPU to perform software debugging. Japanese Laid-Open Patent Publication No. 11-282712 describes an example of a debug system that uses an evaluation chip.
In a semiconductor package device, such as a system on a chip (SOC) that lays out a plurality of peripheral circuits including a CPU to realize system level functioning, the bus for the CPU and control signals are concentrated in the chip. This structure decreases the debugging efficiency. More specifically, when developing software for the SOC, CPUs must separately be connected to an evaluation board to undergo debugging. Thereafter, the CPUs and a plurality of peripheral circuits are ultimately integrated in a single chip. This increases the developing cost, prolongs the designing time, and lengthens the turn around time (TAT).
Generally, the number of terminal pins that are used for debugging in an SOC is small to minimize the cost for conducting testing, such as software debugging. Thus, debugging cannot be performed efficiently.
When developing software in the prior art, a breakpoint is set in the source code for a program. The execution of the program is interrupted when reaching the breakpoint to perform debugging. However, the program memory must be rewritten to set the breakpoint. This makes debugging complicated.
One aspect of the present invention is a program processing device for processing a program including at least one variable. The program processing device includes a semiconductor substrate. A processor, arranged on the semiconductor substrate, executes the program and accesses the memory area. An internal bus is arranged on the semiconductor substrate and connected to the processor. The processor accesses the memory area via the internal bus. A monitor circuit, which is connected to the internal bus, monitors the at least one variable.
A further aspect of the present invention is a program processing device for accessing a memory area and processing a program including at least one variable. The program processing device includes a semiconductor substrate. A processor, arranged on the semiconductor substrate, accesses a memory area to execute the program. An internal bus is arranged on the semiconductor substrate and connected to the processor. The processor accesses a memory area via the internal bus to execute the program. A monitor circuit, which is connected to the internal bus, monitors the at least one variable. When the processor rewrites the value of the at least one variable, the monitor circuit stores the updated data.
Another aspect of the present invention is a debugging system for debugging a program including a variable designated by a programmer, including a debugging device. A program processing device, connected to the debugging device in a communicable manner, processes the program. The program processing device includes a semiconductor substrate. A processor, arranged on the semiconductor substrate, executes the program. An internal bus is arranged on the semiconductor substrate and connected to the processor. A monitor circuit monitors the internal bus during execution of the program and checks whether the variable has been rewritten. When the variable is rewritten, the monitor circuit stores the updated data and periodically transmits variable information to the debugging device in a predetermined transmission cycle.
Other aspects and advantages of the present invention will become apparent from the following description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
The invention, together with objects and advantages thereof, may best be understood by reference to the following description of the presently preferred embodiments together with the accompanying drawings in which:
A program processing device according to a preferred embodiment of the present invention will now be discussed. The program processing device is applied to a control LSI for debugging firmware.
Referring to
The control LSI 12 includes a debug terminal (not shown). A bus cable 15 of a tool bus is connected to the debug terminal. The control LSI 12 performs serial communication with the debugging tool 14 via the bus cable 15. It is preferred that the number of pins for the debug terminal be small to keep the control LSI 12 compact. In the preferred embodiment, there are two debug terminal pins, which are connected to a clock bus and a data bus. Data transfer (bidirectional) is performed between the control LSI 12 and the debugging tool 14 in synchronism with a clock signal.
The control LSI 12 includes a semiconductor substrate 10. A CPU core 21, a monitor circuit 22, a debug interface (I/F) 23, an external bus interface (I/F) 24, an internal RAM 25, and an internal register 26 are mounted on the semiconductor substrate 10. The internal RAM 25 and the internal register 26 function as peripheral circuits. The control LSI 12 includes a signal processing circuit 16 controlled by the CPU core 21.
The CPU core 21, the monitor circuit 22, the external bus I/F 24, the internal RAM 25, and the internal register 26 are connected to one another by an internal bus 27. The CPU core 21 and the monitor circuit 22 are connected to each other by an internal bus 28. The CPU core 21 and the debug I/F are connected to each other by an internal bus 29. The monitor circuit 22 and the debug I/F 23 are connected to each other by an internal bus 30. The signal processing circuit 16 and the CPU core 21 are connected to each other via an internal bus 18.
The external bus I/F 24 is connected to a program memory 32 by an external bus 31. The program memory 32 is, for example, a flash memory. Firmware, which is the subject of debugging, is stored in the CPU core 21 so that it can be executed by the CPU core 21. The program memory 32 may store command lines in machine language that can be executed by the CPU core 21. A compile process or a link process is performed on the firmware (program), which is written in high-level language such as C-language, to convert the firmware to the machine language command lines.
The CPU core 21 reads the command lines from the program memory 32 and decodes the command lines. The CPU core 21 accesses a section (memory area) designated by an address mapped on a memory map of the CPU core 21 to execute various processes in accordance with the decoding result. The memory area includes the internal RAM 25 and the internal register 26, which are connected to the CPU core 21 by the internal bus 27, and the memory area peripheral circuits (not shown) connected to the control LSI 12 by the external bus 31. The internal bus 27 is used when the CPU core 21 accesses the memory area.
When the CPU core 21 executes a program, the monitor circuit 22 monitors an internal bus 27 to monitor the state of one or more variables set in the source code for the program. The monitor circuit 22 will now be described with reference to
The internal register 41 will now be discussed with reference to
The monitor circuit 22 monitors the state of the twelve variables. Each piece of variable information is held in the address register 42 and the data register 43 in relation with monitor data MON0 to MON11.
The address register 42 includes a first register ADRH, a second register ADRM, and a third register ADRL, each of which stores eight bits of data, to store the address value of a variable monitored in a program (total twenty-four bits).
Based on the address values (each twenty-four bits) registered in the address register 42, the data register 43 stores the eight bits of a monitored variable value (designated value) as DATA.
For monitor data MON0 to MON11, the monitor circuit 22 monitors the variable designated by the address register 42. When a designated variable is rewritten by the CPU core 21, the address register 42 stores the updated variable in the data register 43.
For example, the monitor circuit 22 monitors the variable of the monitor data MON0 designated by “03:0000h”, “03:0001h”, “03:0002h” of the first, second, and third registers ADRH, ADRM, and ADRL shown in
Following a predetermined transmission command, the variable information stored in the internal register 41 (address register 42 and data register 43) is periodically transmitted from the monitor circuit 22 to the debugging tool 14 (PC 13) via the debug I/F 23. In the preferred embodiment, serial data is transmitted by the bus cable 15, which is applicable for two pins.
For example, as variable information following the transmission command “C0h” and “04h” (not shown), the monitor circuit 22 transmits the address value of the variable stored in the first, second, and third registers ADRH, ADRM, and ADRL corresponding to the monitor data MON0, that is, “03:000h”, “03:0001h”, and “03:0002h”. Based on the address value, the monitor circuit 22 transmits the data stored in “03:0003h” as the monitored variable based on the address value. The monitor circuit 22 transmits variable information to the debugging tool 14 in the order of monitor data MON0, MON1, . . . , MON11, and MON0 at a predetermined transmission cycle that is in accordance with the clock frequency of the CPU core 21.
The debugging tool 14 sets the address values in the internal register 41. The debugging tool 14 transmits the address of the variable monitored by the monitor circuit 22 to the control LSI 12 in accordance with an instruction input to an input device (not shown) of the PC 13 by a developer (user). More specifically, the debugging tool 14 obtains an address value of a variable, which is mapped, in the program from a memory map of the CPU core 21. Then, the debugging tool 14 transfers that address to the control LSI 12 from the PC 13 via the bus cable 15. The CPU core 21 receives the transferred address (address value of the variable) from the debug I/F 23 via the internal bus 29. Then, the CPU core 21 sets the received address in the monitor circuit 22 (internal register 41) through the internal bus 28.
Subsequently, the debugging tool 14 has the CPU core 21 execute the program (firmware). During the execution of the program, the monitor circuit 22 constantly monitors whether data (variable value) corresponding to a predetermined address value has been rewritten. When the data is rewritten, the monitor circuit 22 stores the updated variable value in the internal register 41. Then, the monitor circuit 22 transmits the variable information stored in the internal register 41 from the debug I/F 23 to the debugging tool 14 (PC 13) via the internal bus 30 together with the predetermined transmission command. The debugging tool 14 sequentially retrieves the variable information transmitted from the control LSI 12 and then outputs the contents of the information to a display (not shown) of the PC 13. Accordingly, the user may check the operation state of the program from the variable information and debug the firmware.
The preferred embodiment has the advantages described below.
(1) The control LSI 12 includes the monitor circuit 22, which monitors the internal bus 27 when the CPU core 21 accesses the memory area and monitors the state of designated variables. When a monitored variable is rewritten to an arbitrary value, the monitor circuit 22 stores the updated data (variable value) and periodically transmits the variable information held in the internal register 41 to the debugging tool 14. Thus, the variable designated in the program (e.g., variable located at a location where branching occurs) by a user may be checked to perform debugging. Further, the state of variables (program operation state) may be monitored in real time without stopping the operation of the CPU core 21. This improves the debugging efficiency.
(2) Debugging is performed on a plurality of variables that are designated beforehand based on the variable information sequentially transmitted in a serial manner from the monitor circuit 22. Further, debugging is performed using the cable 15 that includes two buses, the clock bus and the data bus. Since the number of debug terminals is reduced, the control LSI 12 does not have to be enlarged.
(3) A breakpoint used for debugging does not have to be provided in the program source code as in the prior art. Thus, the program memory does not have to be rewritten to set the breakpoint. However, it may be possible to set a breakpoint in the source code of a program in order to acquire variable information.
(4) When developing software for a microcomputer or the like, software debugging may be performed in a state in which the CPU (CPU core 21) is connected to the microcomputer. This improves the software development efficiency and reduces the development cost. As a result, designing time is reduced and the TAT is shortened.
It should be apparent to those skilled in the art that the present invention may be embodied in many other specific forms without departing from the spirit or scope of the invention. Particularly, it should be understood that the present invention may be embodied in the following forms.
The control LSI 12 (system LSI) includes the internal RAM 25 and the internal register 26 (
The configurations of the monitor circuit 22 and the internal register 41 does not have to be as shown in
The variable information held in the internal register 41 does not have to be periodically transmitted in the same manner as in the preferred embodiment. The variable information may be transmitted in accordance with a predetermined rule, such as whenever the variable information is updated.
The present invention may be applied when debugging anything other than firmware.
The present examples and embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalence of the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
2003-297456 | Aug 2003 | JP | national |
Number | Name | Date | Kind |
---|---|---|---|
5530804 | Edgington et al. | Jun 1996 | A |
5668815 | Gittinger et al. | Sep 1997 | A |
5860161 | Hansen | Jan 1999 | A |
5862148 | Typaldos et al. | Jan 1999 | A |
5903912 | Hansen | May 1999 | A |
5943498 | Yano et al. | Aug 1999 | A |
6041406 | Mann | Mar 2000 | A |
6094729 | Mann | Jul 2000 | A |
6158023 | Ubukata et al. | Dec 2000 | A |
6185731 | Maeda et al. | Feb 2001 | B1 |
6256777 | Ackerman | Jul 2001 | B1 |
6331957 | Kurts et al. | Dec 2001 | B1 |
6643803 | Swoboda et al. | Nov 2003 | B1 |
6668339 | Maeda | Dec 2003 | B1 |
6687857 | Iwata et al. | Feb 2004 | B1 |
6751751 | Murray et al. | Jun 2004 | B1 |
6820192 | Cho et al. | Nov 2004 | B2 |
6918058 | Miura et al. | Jul 2005 | B2 |
6934886 | Ok | Aug 2005 | B2 |
6985980 | Allegrucci | Jan 2006 | B1 |
7114101 | Kudo et al. | Sep 2006 | B2 |
20010010083 | Satoh | Jul 2001 | A1 |
20020065646 | Waldie et al. | May 2002 | A1 |
20020087918 | Miura et al. | Jul 2002 | A1 |
20020091494 | Kudo | Jul 2002 | A1 |
20020144235 | Simmers et al. | Oct 2002 | A1 |
20020157085 | Yabuno et al. | Oct 2002 | A1 |
Number | Date | Country |
---|---|---|
08-185339 | Jul 1996 | JP |
11-282712 | Oct 1999 | JP |
2003-162426 | Jun 2003 | JP |
Number | Date | Country | |
---|---|---|---|
20050044452 A1 | Feb 2005 | US |