JP2005292978A - Simple debugging method for devices that operate under program control - Google Patents

Abstract

[PROBLEMS] It is possible to easily perform real-time trace of a program without using an in-circuit emulator by avoiding the drawbacks of the debugging method using an in-circuit emulator and limiting the function to program trace under a preset condition. Provide a simple debugging method.
An output terminal (55) for outputting debug data from a target device (54) is provided, and a debug data output program such as a simple program of several lines is included in a desired program for the target device (54). By operating, the debugging data is output from the output terminal (54).
[Selection] Figure 1

Description

  The present invention is a debugging that can know the program operation state from the outside in a state where the program is operated in the operating environment for debugging of the device controlled by the MPU program and analysis of malfunction symptoms during the operation. It relates to the method.

In general, debugging at the development stage of a device controlled by an MPU is performed by connecting measuring instruments such as an in-circuit emulator or a logic analyzer, or in a state where the OS can be operated on a device equipped with a keyboard and a display. If there is, it is common to use an online debugger program.
Much of the hardware is also integrated for miniaturization and flexibility, and many are controlled by some kind of processor.
Thus, the device controlled by the MPU cannot avoid the software debugging phase not only in software but also in hardware development.

As shown in FIG. 8, the debugging by the in-circuit emulator 50 is a very effective debugging tool because the program can be executed / stopped under various conditions and the degree of freedom of debugging is high. There are some disadvantages.
(1) Depending on the type of MPU, separate devices (emulation pod 51 and emulation probe 52) are required. In addition, since only one unit can be connected to each other, capital investment is increased if many types of devices are developed.
(2) It is necessary to prepare on the PC 53 a debugging environment (display / manipulate information from the emulator 50, information at compile / link time, and source code as composite information) that is consistent with the program development environment. Costs depending on the number of emulators.
(3) Depending on the package form of the CPU (in the case of direct soldering, etc.), it is necessary to prepare a dedicated board for connecting the emulator, which increases development investment.
(4) In a state where the CPU board 54 is mounted on the apparatus such as failure analysis in the operation state, it is often impossible to connect the emulator due to the structure or it is very difficult.
(5) By connecting the emulation probe 52 to a debug target device such as the target CPU board 54, the power supply load, the noise generation state, the load driving condition, and the like change, so the peripheral circuit is affected and the execution condition changes. May end up.
(6) Due to the specifications of the emulator 50, the memory space that can be used is limited, and thus the emulation itself may be restricted.
(7) In general, conditional compilation is performed during debugging, and optimization options for generated code are not set. This is because when optimization of binary code is performed by optimization processing, the information for displaying the source code, which is an intermediate output of the compiler, may not be consistent with the binary code, which is the final output of the compiler. However, the final execution code is often optimized to improve the processing speed, and in-circuit emulation may be difficult with the optimized code.

In order to overcome such drawbacks of the prior art, internal information is output from a test terminal connected to the LSI or the like in order to efficiently debug the system LSI, microcomputer MUP, digital signal processing device DSP or the like. A technique (see Patent Document 1) and a technique of connecting a test input / output terminal with a reduced number of terminals to a CPU (see Patent Document 2) have been proposed.
JP 2001-142733 A JP 2000-207380 A

  However, in these conventional techniques, in order to take out internal information, it is necessary to provide a test terminal for inputting a test signal.

  The object of the present invention is to avoid the above-mentioned drawbacks of the debugging method using an in-circuit emulator, and to limit the function to the program trace under a preset condition, thereby simplifying without using the in-circuit emulator. The object is to provide a simple debugging method that enables real-time tracing of a program.

In order to achieve this object, a simple debugging method according to the present invention includes an output terminal for outputting debugging data from a target device,
By operating a debug data output program such as a simple program of several lines in a desired program for the target device,
Data for debugging is output from the output terminal.

According to the present invention, the following effects can be obtained.
Simple program tracing is possible using only a logic analyzer or equivalent equipment.
(1) Simple software debugging and fault identification are possible even in an environment without an in-circuit emulator.
(2) Operation restrictions depending on the in-circuit emulator and influence on the circuit can be eliminated.
(3) There is very little software processing to output information for tracing, and if this processing is embedded at the time of source code creation, there is almost no burden on the software, and it is not necessary to delete it finally in the system. There is little if any impact. Therefore, almost no debugging resources are consumed.
(4) No investment depending on the type of CPU is required.
(5) It is possible to reduce the investment depending on the size of the debugging environment at the time of development.

Embodiments of the present invention are shown in FIGS. 1, 2, 3, 4, 5, 6 and 7.
1 is an overall configuration, FIGS. 2 and 4 are hardware (parallel and serial) according to an embodiment of the present invention, FIG. 3 is a hardware / parallel / timing chart according to an embodiment of the present invention, and FIG. 5 is an embodiment of the present invention. FIG. 6 is an example of software (in the case of C language) according to an embodiment of the present invention, and FIG. 7 is an example of trace status output according to the present invention.
As shown in FIG. 1, the configuration of the debugging environment according to the present invention is very simple. On the target CPU board 54 side, data allocated in advance for each processing portion of the program is output to the outside, and this output is output to the connector and probe 55. The data is simply recorded by an external logic analyzer 56 or a PC equipped with a digital input port.
The logic analyzer 56 and the PC are not limited as long as there is a means for inputting and recording parallel data and reading it separately.

2 and 3 show an embodiment of the hardware part of the present invention. In this embodiment, data is output in parallel with n bits (n is an integer), but may be output in series as shown in FIGS.
However, in the case of serial output, it takes longer time to output than in the case of parallel, so it cannot be used when the time interval at which the output data changes is shorter than the time required for serial output.

<For parallel output>
In FIG. 2, an output port PPOUT of an n-bit register whose output state can be read is controlled by a device selection signal / CS generated from a write signal / WR and a read signal / RD generated by the CPU, an address bus signal, and the like. Is done. Data exchange between PPOUT and the CPU is assumed to be performed via a data bus. Since these control signals depend on the CPU architecture, this configuration is not necessarily required.
The latch clock LCK is assumed to be a constant frequency clock signal synchronized with the CPU clock. In general, it is possible to easily obtain such a clock by dividing the CPU clock.
PPOUT is assumed to be writable or readable when CS goes low.
When writing data to PPOUT, CS is set low and the input from the data bus is determined at the rising edge of WR.
When reading data from PPOUT, CS is set low and data is output to the data bus by setting RD low.

FIG. 3 is a conceptual diagram of these timing charts. Since the physical relationship such as the polarity and timing of the control signal depends on the architecture of the CPU, FIGS. 2 and 3 show the concept.
The output of PPOUT can be easily read by an external device. If a logic analyzer is used, the output of PPOUT can be recorded at a preset sampling interval without using LCK.
The LCK is prepared for the convenience of storing the output data by means other than the logic analyzer. For example, output data can be latched at the rising edge of LCK. The LCK can also play a role of communicating the passage of time to the outside. For example, by connecting the LCK to the clock input of the counter with an external device and recording the counter value at the change point of the output data, it is possible to easily estimate how much time is required for a predetermined range of the program. be able to.

<For serial output>
As shown in FIG. 4, in the case of serial output, parallel data is converted into serial data by a parallel-serial converter SPCNV that receives PPOUT output and an n-bit serial output control unit SCNT, and is output to the outside.
FIG. 5 is a timing chart thereof. The relationship between the CPU and PPOUT is the same as in FIGS.
The parallel data written to PPOUT is loaded into SPCNV by a latch signal / LD generated by delaying WR using SCK in SCNT.
The data latched in the SPCNV is outputted as So while being sequentially shifted in the SPCNV by the serial output clock Sc.
For the convenience of receiving the serially converted signal So externally, a serial output enable signal / Se is prepared, and serial output data So can be received externally when / Se is at a low level.
The hardware shown in FIGS. 2 and 4 can be easily configured by using a general-purpose device, and therefore will not be described in detail here.

<Software>
In the present invention, in addition to the simple hardware shown in FIGS.
FIG. 6 shows an example of a C language source program for explaining the present invention using seven function programs. However, since the present invention does not depend on language specifications, the same concept applies even if it is described in another language. can do.
In FIG. 6, the line starting with “#define” is a constant used to indicate the execution part of the program used in the present invention and the definition of the I / O address of the port indicated as PPOUT in FIGS. 2 and 4.

In the example of FIG. 4, MAIN is set as a numerical value unique to each function program. LOOP, FUNC 1, FUNC 2, SUBFUNC 1, SUBFUNC 2, DEVDR 1, DEVDR 2 is defined. Also, TRACE as the address of PPOUT IO is defined. Note that 0 × 0001 means a hexadecimal number 0001.
The line starting with “extern” is an external reference function declaration. Here, the functions import () and outport () of I / O port input / output arranged in the I / O address space are declared.

The program configuration of FIG. 6 is as follows.
(1) Function main loop (): Constructs an infinite loop and the function func 1 () and function func Call 2 ().
(2) Function func 1 (): Function subfunc Call 1 ().
(3) Function func 2 (): Function subfunc Call 2 ().
(4) Function subfunc 1 (): Function devdr Call 1 ().
(5) Function subfunc 2 (): Function devdr Call 2 ().
(6) Function devdr 1 (): Do nothing in particular.
(7) Function devdr 2 (): Do nothing in particular.
The part enclosed by “/ *” and “* /” in the program is a comment.

<Function main loop ()>
Process Sm1 and process Sm2 are declarations of local variables used in this function.
In process Sm1, the variable trace as an unsigned integer In Sm2, variables f1 and f2 are declared as signed integers.
The process Sm3 shows an infinite loop structure, and the processes Sm4, Sm5, Sm6, Sm7, and Sm8 are repeatedly executed in the loop.
Process Sm4 reads the current output value from the PPOUT port, trace Save to out.
Process Sm5 is a function main at the PPOUT port. Constant MAIN indicating execution of loop () Output LOOP.
Process Sm6 is function func 1 (), Sm7 is the function func Call 2 ().
Process Sm8 is trace The previous PPOUT output state saved in out is output.

<Function func 1 () and func 2 ()>
Processes Sf11, Sf12, Sf21, and Sf22 are declarations of local variables used in this function.
In processing Sf11 and Sf21, the variable trace is set as an unsigned integer. In Sf12 and Sf22, the variable sbf is declared as a sign integer.
Processes Sf13 and Sf23 read the current output value from the PPOUT port, trace Save to out.
Processes Sf14 and Sf24 are set to function func at the PPOUT port. 1 () or func Constant FUNC indicating execution of 2 () 1 or FUNC 2 is output.
Process Sf15 is a function subfunc. 1 (), Sf25 is a function subfunc Call 2 ().
Processes Sf16 and Sf26 are trace Outputs the previous PPOUT output state stored in out.
Processes Sf17 and Sf27 represent exiting this function with the value of sbf as a return value.

<Function subfunc 1 () and subfunc 2 ()>
Processing Ssf11, processing Ssf12, Ssf21, and Ssf22 are declarations of local variables used in this function.
In processing Ssf11 and Ssf21, the variable trace is set as an unsigned integer. out is changed to a variable devdr as a signed integer in the processes Ssf12 and Ssf22. st is declared.
Processes Ssf13 and Ssf23 read the current output value from the PPOUT port, trace Save to out.
Processes Ssf14 and Ssf24 are set to function subfunc at the PPOUT port. 1 () or subfunc Constant indicating execution of 2 () SUBFUNC 1 or SUBFUNC 2 is output.
The process Ssf15 is a function devdr 1 (), Ssf25 is the function devdr Call 2 ().
Processes Ssf16 and Ssf26 are trace Outputs the previous PPOUT output state stored in out.
Processes Ssf17 and Ssf27 return devdr Represents exiting this function with a value of st.

<Function devdr 1 () and devdr 2 ()>
Process Sd11 and process Sd21 are declarations of local variables used in this function.
In process Sd11 and process Sd21, the variable trace is set as an unsigned integer. Declares out.
Process Sd12 and Process Sd22 read the current output value from the PPOUT port, trace Save to out.
Process Sd13 and process Sd23 are functions devdr at the PPOUT port. 1 () or devdr Constant DEVDR indicating execution of 2 () 1 or DEVDR 2 is output.
Process Sd14 and process Sd24 are trace Outputs the previous PPOUT output state stored in out.
Process Sd15 and process Sd25 have a value of “1” or “2” as a return value, and indicate that this function is exited.

When the program of FIG. 6 is executed, a PPOUT output as shown in FIG. 7 is obtained with the passage of time.
The program in FIG. 6 is described for explaining the operation, and does not include any particularly effective processing. In practice, for example, some process is usually described between the processes Sm5 and Sm8.

In the present invention, what is necessary on the software is to output individual data to PPOUT at the beginning of the process to be traced. Since software processing normally has a nested structure as shown in FIG. 6, it is easier to debug when returning to the previous output state after finishing the processing to be traced.
In general, an I / O device input / output process such as PPOUT (external reference function in FIG. 6) is a very short process, and can be described in one or two lines even in assembly language. In FIG. 6, the function call is declared, but in many cases, it is processed as a micro of an inline assembly language by compiler processing.
In the assembly language, processing from one to two lines is usually not affected at all unless it is a special instruction. In many cases, there is no problem even if it is described during interrupt processing. .
Generally, conditional compilation is performed during debugging, and the optimization option of generated code is not set for the convenience of debugging. However, the present invention is a simple bag means in the first place and does not directly affect the original processing. Since it is clear that code is generated in the part, there is no influence even if optimization is performed.
In the present invention, execution / stop of a program cannot be controlled and only a function of tracing is provided, but real-time tracing is possible even in an operating state with a minimum of resources.

  It is possible to efficiently debug a target device that operates under program control such as a system LSI, microcomputer MPU, or DPS.

It is a block diagram which shows the whole structure of the Example of this invention. It is a block diagram which shows the Example of this invention using a parallel structure circuit. It is a timing chart which shows the operation | movement in the Example of this invention shown in FIG. It is a block diagram which shows the Example of this invention using a series structure circuit. 5 is a timing chart showing an operation in the embodiment of the present invention shown in FIG. It is a figure which shows the specific example in the case of using the C language software in this invention system. It is a figure which shows the relationship between the output data in this invention system, and a program execution state. It is a block diagram for demonstrating the conventional debugging system by an in-circuit emulator.

Explanation of symbols

50 Emulator body 51 Emulation pod 52 Emulation probe 53 Personal computer (PC)
54 Target (CPU board)
55 Connector and probe 56 Logic analyzer (PC etc.)

Claims (1)

Equipped with an output terminal that outputs debug data from the target device,
By operating a debug data output program such as a simple program of several lines in a desired program for the target device,
A simple debugging method for a device that operates under program control in which debugging data is output from the output terminal.

Images