JP5906789B2 - Message output control device and message output control method - Google Patents

Description

  The present invention relates to controlling message output during debugging with driver software of a communication IP (Intellectual Property) macro.

  Conventionally, when developing driver software for communication IP macros, debugger software, which is a standard software debugging tool, cannot be used for debugging. This is because in the debugger, the operation speed is significantly slower than the standard speed of the actual communication system IP, and if used, the communication partner will generate a time-out error and the original operation check state cannot be made. . Therefore, in communication IP macro debugging, messages (log messages) output during operation of the communication IP macro from the driver software for verifying the communication IP macro are mainly stored in the storage area. After the operation is finished, the developer checks the output message and verifies it.

  Therefore, for example, it has been proposed to periodically write a device message to the acknowledge device during execution of software instructions.

JP 2010-044747 A

  However, in the above prior art, it is possible to output the register value of the communication system IP macro to an output device such as a file or a console, but the operation of the IP macro becomes complicated by mounting different communication standards. Therefore, in a situation where the number of registers is increasing, a mechanism for always outputting the values of all the registers is not practical for effective debugging.

  On the other hand, it is possible to incorporate a mechanism for outputting only the necessary register values into the driver software for debugging purposes. Actually, the developer repeatedly performs the work of incorporating the mechanism into the driver software, but such work by the developer has the following problems.

  (1) A necessary register is appropriately determined, and a mechanism for acquiring the value is compiled into the driver software, compiled, run on the target device, and a message is acquired and analyzed. In this case, since the register to be verified differs depending on the debug stage, it is complicated to change the driver software for each debug stage. In addition, when the number of registers increases, a code that should not be changed when it is changed may be erroneously corrected. There was a problem that new bugs were created by incorrect corrections, which increased the burden in addition to the original debugging work.

  (2) On the other hand, it is not realistic to delete the once output message as it is because it impedes analysis.

  (3) In addition, since it is a message dedicated to debugging, it is ultimately necessary to delete the message, but if the number of message output descriptions increases, there is a high possibility that the message will be forgotten to be deleted. If you forget to delete the debug message, the actual product may inadvertently output the message.

Message output control apparatus disclosed includes a source code, a storage unit that stores an embedded instruction to the specified file register to be message output target, the source code, depending on the embedding instruction file stored in the storage unit The description for accessing the specified register is replaced with the replacement content including the description for outputting the message including the value of the register to the output device during the output period, and the execution format is executed from the source code replaced with the content. A creating unit for creating the binary file in the storage unit.

  Further, as means for solving the above-described problems, a message output control method executed by a computer and a program for causing a computer to function as the message output control device can be used.

  With the disclosed technology, it is possible to control message output during debugging with the driver software of the communication IP macro.

It is a figure which shows the structural example of the debug system which concerns on 1st Example. It is a figure which shows the hardware constitutions of a host apparatus. It is a figure which shows the correspondence of the hierarchy of a communication protocol, and a function. It is a figure which shows the example of a format of an embedding instruction | indication file. It is a figure for demonstrating the flow of a process by a developer. It is a figure for demonstrating an example of the creation process of the binary file by the host CPU which performs the conversion program. It is a figure for demonstrating the source code analysis process in step S114. It is a figure for demonstrating the other example of the creation process of the binary file by the host CPU which performs the conversion program. It is a figure for demonstrating the assembler code analysis process in step S134. It is a figure which shows the example of an embedding instruction | indication structure. It is a figure for demonstrating the structure creation process by the host CPU which performs the conversion program. It is a figure which shows the example of a function output state preservation | save area | region. It is a figure which shows the structural example of each function output state preservation | save area | region. It is a figure for demonstrating the process which the register access instruction to an IP macro performs. It is a figure for demonstrating the process by the subprogram of a timer interruption handler. It is a figure which shows the example of an output of a message. It is a figure which shows the example of communication at the time of verification. It is a figure for demonstrating the difference in the output amount of a message. It is a figure which shows the other structural example of the debugging system which concerns on 1st Example. It is a figure for demonstrating the flow of a process by the developer in the debugging system of FIG. It is a figure which shows the structural example of the debug system which concerns on 2nd Example. It is a figure for demonstrating the executable format creation process. It is a figure for demonstrating the example of the problem which can be eliminated by applying.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In this embodiment, the following features of the communication IP macro are used.

  (1) The function supported by the communication system IP macro undergoes a state change as a result of the exchange with the opposite side (communication partner).

  (2) When a state change occurs, the effect converges within a certain time according to the function, and after a certain time, until the next state change occurs again as a result of the exchange with the opposite side, There is no change.

  (3) In the communication IP macro, the registers are classified for each function supported, and there are very few functions in common.

  Here, description will be made using an IP macro of a USB (Universal Serial Bus) function (“USB Function”). However, this embodiment is not limited to the USB standard IP macro, but other communication system IPs. The present invention can also be applied to macros (SATA (Serial Advanced Technology Attachment), PCI-Express, Ethernet (registered trademark), etc.).

“USB Function”
(Function A) USB Bus control (Function B) Endpoint management: Control data transfer to Default-Endpoint (Endpoint # 0) (Function C) Data transfer such as Bulk (bulk data transfer)
Including mainly. Although there are a plurality of registers for realizing the function A, the function B, and the function C, in this embodiment, confirmation of state changes of the following register values and control are executed. An actual IP macro requires more registers for interrupt notification to the CPU on the system, but is omitted here.

  In the verification of the function A, the state register “USB_S” for confirming the state change and the control register “USB_C” for controlling the state are targeted.

  In the verification of the function B, the state register “EP0_S” for confirming the state change and the control register “EP0_C” for controlling the state are targeted.

  In the verification of the function C, the state register “EP1_S” for confirming the state change and the control register “EP1_C” for controlling the state are targeted.

Hereinafter, description will be given focusing on control data transfer to Default-Endpoint of function B. In the control data transfer, the driver software executes the following procedure.
(B-1) The status register “EP0_S” confirms whether or not control data transfer has occurred.
(B-2) If control data transfer has occurred in (B-1) above, the packet size of the control data is checked, and the transfer type is read from the status register “EP0_S”.

And
(B-3) A read completion flag is set in the control register “EP0_C”.
(B-4) A required number of data (bytes) is set to the data value of the packet to be returned to the opposite side in the control register according to the transfer type read in (B-2) above.
(B-5) Check the status register “EP0_S” and write that all values (return packets) set in the control register “EP0_C” have been set.

next,
(B-6) The arrival of the receipt confirmation packet from the opposite side is confirmed by the status register “EP0_C”. Continue checking until it arrives.
(B-7) Upon confirming the arrival of the receipt confirmation packet, the contents are read from the status register “EP0_C”, and the read completion flag is set in the control register “EP0_C”.

  Each register of the function (B) after the setting of the procedure (B-3) at the time of debugging in the part realizing the flow of the procedure (B-1) to the procedure (B-7) in the driver software If the contents of the period until the completion of the procedure (B-7), it can be useful debugging. The values of the status register “EP0_C” and the control register “EP0_C” before the procedure (B-3) or after the procedure (B-7) cannot be particularly required for debugging.

  Therefore, if only the values of the status register “EP0_C” and the control register “EP0_C” related to the function (B) in the period from the procedure (B-3) to the procedure (B-7) are sequentially output, the necessary information is obtained. All obtained and unnecessary output can be suppressed.

  The determination of the start of the procedure (B-3) can be made by writing to the status register “EP0_C” and the control register “EP0_C” related to the function (B).

  As for the output stop condition, it is sufficient if the output is stopped after the procedure (B-7). However, although it is not necessarily impossible for the determination of the procedure (B-7) to distinguish between write operations to other registers, it becomes complicated. If complicated judgment logic is incorporated, a new problem may occur.

  In communication protocols, there is usually an upper limit on response time, and subsequent information can be made unnecessary. It suffices if there is an output of the register value within the response time from the procedure (B-3). For example, since there are a plurality of communication procedures, it is set to N times (predetermined times) the time determined by the standard. The predetermined multiple (N times) time is within a time length that can be determined based on the standard.

  A configuration for realizing output control of the message (log message) as described above will be described below.

  FIG. 1 is a diagram illustrating a configuration example of a debugging system according to the first embodiment. The debug system 101 illustrated in FIG. 1 includes a host device 10, an ICE (In-Circuit Emulator) device 224, and a target device 30. The debug system 101 corresponds to a message output control device.

  The host device 10 is a host computer that is connected to the ICE device 224 and controls the ICE device 224 to verify the target device 30. The host device 10 has a hardware configuration shown in FIG.

  The host device 10 is controlled by the host CPU 11 and has storage areas 221 and 222. The storage area 221 is a storage area used for the host CPU 11 to execute processing, and is used, for example, when the host CPU 11 executes an embedded (cross) compiler and a linker program. The storage area 222 is a storage area for storing a program source code, an embedding instruction file according to the first embodiment, a binary file, and the like.

  In the hardware configuration shown in FIG. 2 described later, the storage area 221 corresponds to a storage area of the main storage device 12 having a RAM (Random Access Memory) or the like, and the storage area 222 is an auxiliary storage device having a hard disk device or the like. It corresponds to 13. The host CPU 11, the storage area 221, and the storage area 222 are connected by a bus 223.

  The storage area 222 stores the source code 200, the embedding instruction file 202, the binary file 210, and the conversion program 220. The source code 200 is a source code of a program (driver software) that controls the IP macro 212. The embedding instruction file 202 is a data file that is created for each macro based on the IP macro specification / standard document 202 and includes a code for monitoring a predetermined register and outputting a message including the value.

  The binary file 210 is an executable format binary file, and is a binary file 210 that causes a message to be output only for a specified register among the registers related to the function to be verified in accordance with the embedding instruction file 202.

  The conversion program 220 is an embedded (cross) compiler and linker program that inputs the embedding instruction file 202 and the source code 200 of the program and outputs an executable program (binary file 210). A processing unit realized by executing the conversion program 220 by the host CPU 11 corresponds to a creation unit that creates the binary file 210.

  In the case of a data file, the IP macro specification / standard document 201 may be stored in the storage area 222.

  The ICE device 222 is a device for verifying software and hardware, and transfers the binary file 210 to the storage area 214 of the target device 30 in accordance with an instruction of a control program executed by the host CPU 11 to This is a device that causes the target CPU 211 to operate according to the contents of the binary file 210.

  The target device 30 includes a target CPU 211, an IP macro 212, a connection destination device 213, a storage area 214, a message output device 217, and a timer module 218.

  The target CPU 211 is a CPU that runs an executable program. The IP macro 212 corresponds to a functional part that performs communication control, and is connected to the target CPU 211. The connection destination device 213 is an apparatus that is connected to the IP macro 212 and performs communication. The storage area 214 is a storage area for storing a program executed by the target CPU 211, and is a memory device such as a RAM.

  The message output device 217 is a device that outputs a message in response to an instruction during program execution, and includes a display unit such as a CRT (Cathode Ray Tube) or an LCD (Liquid Crystal Display). The timer module 218 is a timer function used for message output determination.

  The target CPU 211, the IP macro 212, the storage area 214, the message output device 217, and the timer module 218 are connected by a bus 215. The connection destination device 213 is connected to the IP macro 212 via the bus 216.

  The host device 10 according to the first embodiment has a hardware configuration as shown in FIG. FIG. 2 is a diagram illustrating a hardware configuration of the host device. In FIG. 2, a host device 10 is a terminal controlled by a computer, and includes a host CPU (Central Processing Unit) 11, a main storage device 12, an auxiliary storage device 13, an input device 14, and a display device 15. , Drive 18 and connected to bus B.

  The host CPU 11 controls the host device 10 according to the control program stored in the main storage device 12 and instructs the ICE device 224 to verify the target device 30. For example, a RAM (Random Access Memory) or the like is used as the main storage device 12 and is obtained by a control program executed by the host CPU 11, data necessary for processing by the host CPU 11, and processing by the host CPU 11. Stores data etc. A part of the main storage device 12 is allocated as a work area used for processing in the host CPU 11.

  For example, a hard disk drive is used as the auxiliary storage device 13 and stores data such as programs for executing various processes. A part of the program stored in the auxiliary storage device 13 is loaded into the main storage device 12 and executed by the host CPU 11 to realize various processes. The storage unit 130 includes a main storage device 12 and an auxiliary storage device 13.

  The input device 14 includes a mouse, a keyboard, and the like, and is used for a user to input various information necessary for processing by the host device 10. The display device 15 displays various information required under the control of the host CPU 11.

  A control program for realizing the processing performed by the host device 10 is provided to the host device 10 by a storage medium 19 such as a CD-ROM (Compact Disc Read-Only Memory). That is, when the storage medium 19 storing the program is set in the drive 18, the drive 18 reads the program from the storage medium 19, and the read program is installed in the auxiliary storage device 13 via the bus B. . When the program is started, the host CPU 11 starts its processing according to the program installed in the auxiliary storage device 13. The medium for storing the program is not limited to a CD-ROM, and any medium that can be read by a computer may be used. As a computer-readable storage medium, in addition to a CD-ROM, a portable recording medium such as a DVD disk or a USB memory, or a semiconductor memory such as a flash memory may be used.

  In addition, a control program that implements processing performed by the host device 10 may be provided from an external device via the communication I / F 17. Alternatively, the program may be provided to an external device, and each process described below may be realized by the external device. Communication by the communication I / F 17 is not limited to wireless or wired.

  Taking USB communication as an example, the correspondence between the communication protocol hierarchy and the USB functions (A) to (C) described above will be described. FIG. 3 is a diagram illustrating a correspondence relationship between communication protocol layers and functions. In FIG. 3, the USB communication protocol layer 2 is defined by the IP macro specification / standard document 201, and includes a USB Bus state, USB EndPoint control, USB Class control, and an upper layer in order from the lower layer. Further, the processing in each layer is also indicated by the IP macro specification / standard document 201.

  In the USB communication protocol layer 2, the USB Bus state layer corresponds to function A (USB Bus control), and the USB EndPoint control layer corresponds to function B (USB EndPoint control (EndPoint management)). The USB class control layer and the upper layer correspond to function C (USB EndPoint control (data transfer)).

  Next, the format of the embedding instruction file 202 will be described. FIG. 4 is a diagram illustrating a format example of an embedding instruction file. In FIG. 4A, in the embedding instruction file 202 created for each macro, a control code 4 related to message output is created for each function type, that is, for each function, specifying a target register. Each control code 4 indicates a function name 4a, a message output conditional expression 4b, and register information 4c for each target register.

  The message output conditional expression 4b specifies a timer time indicating a time interval for outputting a message including the value of the target register. The register information 4c has a configuration as illustrated in FIG.

  In FIG. 4B, register name 4c-1, register address 4c-2, and message output format 4c-3 are designated by register information 4c.

  FIG. 5 is a diagram for explaining the flow of processing by the developer in the debug system 100 of FIG. In FIG. 5, the developer manually creates an embedding instruction file 202 based on the IP macro specification / standard document 201 and stores it in the storage area 222 (step S101). The developer instructs the host device 10 to execute the conversion program 220 (step S102). The conversion program 220 is loaded into the storage area 221 and executed by the host CPU 11. By executing the conversion program 220, a binary file 210 is created and stored in the storage area 222.

  The developer causes the host device 10 to start verification of the target device 30 (step S103). The host device 10 causes the ICE device 224 to transfer the binary file 210 to the storage area 214 of the target device 30 and cause the target CPU 211 of the target device 30 to execute it.

  When the target CPU 211 operates according to the binary file 210, the target CPU 211 controls the IP macro 212, and communication with the connection destination device 213 is executed via the bus 216 (step S104). At this time, a message including a register value designated by the embedding instruction file 202 is output to the message output device 217.

  The developer checks the message output to the message output device 217, the message output from the connection destination device 213, and the like (step S105), and determines whether there is a problem (step S106). If the developer determines that there is a problem, the developer analyzes a message regarding the problem (step S107).

  The developer determines whether a message is insufficient for analyzing the problem (step S108). If the developer determines that the message is sufficient, the developer corrects the source code 200 to solve the problem (step S109), and returns to step S102. On the other hand, when the developer determines that the message is insufficient, the developer corrects and adds the embedding instruction file 202, saves it in the storage area 222 (step S110), and returns to step S102.

  In step S106, when the developer determines that there is no problem, the process (work) is terminated.

  In accordance with the execution instruction from the developer in step S102 described above, the flowchart from the source code 200 using the register operation API to the IP macro 212 to the creation of the binary file 210 during execution of the conversion program 220 by the host CPU 11 is illustrated. 6 will be described.

  FIG. 6 is a diagram for explaining an example of a binary file creation process by the host CPU that executes the conversion program. 6, the host CPU 11 reads the embedding instruction file 202 and stores an “embedding instruction structure” (described later) in the storage area 221 in accordance with the contents of the embedding instruction file 202 (step S111). The host CPU 11 determines whether or not unprocessed source code 200 remains (step S112).

  When the host CPU 11 determines that the unprocessed source code 200 remains, the host CPU 11 creates a temporary file 3f for work in the storage area 221 (step S113). The host CPU 11 executes source code analysis processing for analyzing the source code, and stores the execution result in the created temporary file 3f (step S114).

  Thereafter, the host CPU 11 compiles the temporary file 3f and creates an object code (step S115). Further, the host CPU 11 changes the file name of the object code to an appropriate name based on the file name of the original source code 200 (step S116).

  If no unprocessed source code 200 remains in step S112, the host CPU 11 creates a subprogram that secures a necessary area in the storage area 214 of the target device 30 as an object file in accordance with the contents of the embedding instruction. (Step S117). In addition, the host CPU 11 creates a subprogram for executing processing in the interrupt handler as an object file (step S118).

  The host CPU 11 links all object files to create a binary file 210 (step S119), and ends this process.

  The source code analysis process in step S114 described above will be described with reference to FIG. FIG. 7 is a diagram for explaining the source code analysis processing in step S114. In FIG. 7, the host CPU 11 determines whether or not it is the last of the source code 200 (step S121). The host CPU 11 ends this process when the source code 200 is the last.

  The host CPU 11 extracts the next syntax element by Parser (syntax analysis) (step S122), and determines whether or not the extracted syntax element is a register operation API to the IP macro (step S123). If the host CPU 11 determines that the extracted syntax element is not a register operation API to the IP macro, the host CPU 11 outputs the description as it is to the temporary file 3f (step S124), returns to step S121, and repeats the same processing as described above.

  On the other hand, in step S123, when the extracted syntax element is the register operation API to the IP macro, the host CPU 11 determines the write distinction from the name of the register operation API, and determines the register address from the address specified by the API argument. Obtain (step S125).

  Then, the host CPU 11 refers to the “embedding instruction structure” (FIG. 10) and searches the obtained register address from each register table 5r (FIG. 10) (step S126). The structure of the register table 5r in which the acquired register address is set is specified. Further, the host CPU 11 acquires the function table 5f (FIG. 10) to which the register table 5r is connected (step S127).

  Next, the host CPU 11 obtains an output control rule from the function table 5f, obtains an output format from the register table 5r, creates a replacement content, and calls an operation API call with a replacement content indicating a register access instruction to the IP macro. Is replaced (step S128). The host CPU 11 outputs the replacement result to the temporary file 3f (step S129), returns to step S121, and repeats the same processing as described above.

  On the other hand, if the host CPU 11 determines in step S121 that it is the last of the source code 200, the process is terminated.

  From the source code 200 in which the register operation API to the IP macro 212 is not used (for example, written in assembler code) during the execution of the conversion program 220 by the host CPU 11 in accordance with the execution instruction by the developer in step S102 described above. The flow up to creation of the binary file 210 will be described with reference to FIG.

  FIG. 8 is a diagram for explaining another example of the binary file creation process by the host CPU that executes the conversion program. In FIG. 8, the host CPU 11 reads the embedding instruction file 202 and stores an “embedding instruction structure” (described later) in the storage area 221 in accordance with the contents of the embedding instruction file 202 (step S131). The host CPU 11 determines whether or not unprocessed source code 200 remains (step S132).

  When the host CPU 11 determines that the unprocessed source code 200 remains, the host CPU 11 compiles the source code 200 by the compiler and creates an assembler code 200a in the storage unit storage area 222 (step S132-2). A temporary file 3f is created in the storage area 221 (step S133). The host CPU 11 executes an assembler code analysis process for analyzing the assembler code 200a, and stores the execution result in the temporary file 3f created in the storage area 221 (step S134).

  Thereafter, the host CPU 11 converts the temporary file 3f into an object code by the assembler (step S135). Further, the host CPU 11 changes the file name of the object code to an appropriate name based on the file name of the original source code 200 (step S136).

  If no unprocessed source code 200 remains in step S132, the host CPU 11 creates a subprogram that secures a necessary area in the storage area 214 of the target device 30 as an object file in accordance with the contents of the embedding instruction. (Step S137). In addition, the host CPU 11 creates a subprogram for executing processing in the interrupt handler as an object file (step S138).

  The host CPU 11 links all object files to create a binary file 210 (step S119), and ends this process.

  The assembler code analysis process in step S134 described above will be described with reference to FIG. FIG. 9 is a diagram for explaining the assembler code analysis processing in step S134. In FIG. 9, the host CPU 11 determines whether or not the assembler code 200a is finished (step S141). If the assembler code 200a is terminated, the host CPU 11 terminates this process.

  The host CPU 11 extracts the next instruction (opcode and operand) (step S142), and determines whether the opcode is Load / Store (step S143). If the host CPU 11 determines that the operation code is not Load / Store, it outputs the instruction (operation code and operand) to the temporary file 3f as it is (step S124), returns to step S141, and repeats the same processing as described above.

  On the other hand, if the host CPU 11 determines in step S143 that the operation code is Load / Store, the host CPU 11 acquires the memory address to be loaded / stored from the instruction, and refers to the “embedding instruction structure” (FIG. 10), The obtained register address is searched from each register table 5r (FIG. 10) (step S145). The structure of the register table 5r in which the acquired register address is set is specified. Further, the host CPU 11 acquires the function table 5f (FIG. 10) to which the register table 5r is connected (step S146).

  Next, the host CPU 11 acquires an output control rule from the function table 5f, acquires an output format from the register table 5r, creates a replacement content from the distinction between read and write determined from the Load / Store instruction, The Load / Store instruction is replaced with the replacement content indicating the register access instruction to the macro (step S147). The host CPU 11 outputs the replacement result to the temporary file 3f (step S148), returns to step S141, and repeats the same processing as described above.

  On the other hand, if the host CPU 11 determines in step S141 that the assembler code 200a has ended, this process ends.

  FIG. 10 is a diagram illustrating an example of the embedding instruction structure. FIG. 10A shows the relationship between the tables. The embedding instruction structure associates a plurality of function tables 5f with one or more register tables 5r from each function table 5f.

  The function table 5f corresponds to each control code 4 in FIG. The register table 5r corresponds to the register information 4c in each control code 4 of FIG. The function table 5f and the register table 5r are managed by an embedding instruction structure.

  In the conversion program 220, a pointer to the top function table 5f (head function table pointer) may be indicated. The next function table 5f may be indicated by a pointer from each function table 5f. The function table 5f is set as the current function table by the pointer to the next function table 5f (current function table pointer).

  In addition, a pointer from each function table 5f to the first register table 5r is shown, and in each register table 5r, a pointer to the next register table 5r may be shown.

  The embedding instruction structure includes a structure of the function table 5f illustrated in FIG. 10B and a structure of the register table 5r illustrated in FIG. 10B and 10C, the pointer to the next table, the pointer from the function table 5f to the register table 5r, and the like are omitted.

  FIG. 10B shows an example of the structure of the function table 5f. Depending on the structure, the function table 5f includes function names and output control rules. The function name corresponds to the function name 4a of the embedding instruction file 202 shown in FIG. The output control rule has an output start condition and an output period. The output control rule corresponds to the message output information 4b. FIG. 10C shows an example of the structure of the register table 5r. The register table 5r has a register name, a register address, and an output format.

  Next, a structure creation process for creating an embedding instruction structure from the embedding instruction file 202 during execution of the conversion program 220 in step S111 of FIG. 6 and step S131 of FIG. 8 will be described with reference to FIG.

  FIG. 11 is a diagram for explaining the structure creation processing by the host CPU that executes the conversion program. In FIG. 11, the host CPU 11 initializes the embedding instruction structure (step S151), and opens the embedding instruction file 202 (step S152).

  The host CPU 11 determines whether or not all the contents of the embedding instruction file 202 have been completed (step S153). When all the contents of the embedding instruction file 202 have been completed, the embedding instruction file 202 is closed (step S153-2), and this process ends.

  On the other hand, if all the contents of the embedding instruction file 202 have not been completed, the host CPU 11 reads the next line from the embedding instruction file 202 (step S154), and determines whether it is a comment or a blank line (step S155). .

  If it is determined that the read line is a comment or a blank line, the host CPU 11 further determines whether or not the function definition is started (step S156). When the function definition is started, the host CPU 11 creates the function table 5f and sets the function name 4a of the embedding instruction file 202 to the function name of the function table 5f (step S157).

  Further, the host CPU 11 acquires the output control rule by referring to the message output conditional expression 4b from the embedding instruction file 202, and sets it in the created function table 5f (step S158). Further, the host CPU 11 sets the created function table as a current function table (step S159). Then, the host CPU 11 returns to step S153 and repeats the same processing as described above.

  On the other hand, if it is determined in step S156 that the function definition is not started, the host CPU 11 acquires the register name 4c-1, the register address 4c-2, and the message output format 4c-3 from the register information 4c of the embedding instruction file 202. (Step S160). A register table 5r is created using the acquired register name 4c-1, register address 4c-2, and message output format 4c-3 (step S161), and the created register table 5r is added to the current function table (step S161). S162), this process is terminated.

  In step S117 of FIG. 6 and step S137 of FIG. 8, a storage area (“function output state storage area” secured and initialized by a subprogram that secures a necessary area in the storage area 214 of the target device 30 to be incorporated in the binary file 210. ]) Will be described with reference to FIG.

  FIG. 12 is a diagram illustrating an example of the function output state storage area. In FIG. 12, a part of the storage area 214 used by executing the code in the binary file 210 is shown. In the storage area 214 of the target device 30, one function output state storage area 7 is secured for each function described in the embedding instruction file 202.

  FIG. 13 is a diagram illustrating a configuration example of each function output state storage area. In FIG. 13, the function output state storage area 7 includes values such as an output control flag, a timer value, a timer set value, and an output routine.

  Next, processing executed by the register access instruction to the replaced IP macro in step S128 of FIG. 7 and step S147 of FIG. 9 will be described with reference to FIG. FIG. 14 is a diagram for explaining processing executed by a register access instruction to the IP macro. A register access instruction to the IP macro is executed by the target CPU 211. In the process shown in FIG. 14, a case where only one timer can be used will be described.

  In FIG. 14, the target CPU 211 performs register access to the IP macro in accordance with the register access instruction to the IP macro (step S171), and determines whether or not a timer interrupt handler is set (step S172). If it is determined that the timer interrupt handler has not been set, the target CPU 211 sets a timer interrupt handler, sets a timer interval, starts a timer (step S172-2), and proceeds to step S173.

  On the other hand, when determining that the timer interrupt handler has been set, the target CPU 211 determines whether or not to write to the register (step S173). If it is determined that the data is read from the register, the target CPU 211 determines whether or not the output control flag (FIG. 13) of the function output state storage area 7 is set to “1” (step S173-2). When the output control flag (FIG. 13) is set to “1”, the target CPU 211 outputs a message to the message output device 217 using the output routine specified in the function output state storage area 7 ( In step S173-4), this process ends. On the other hand, when the output control flag (FIG. 13) is set to “0”, the target CPU 211 ends this process.

  On the other hand, if it is determined in step S173 that the data is written to the register, the target CPU 211 sets the timer setting value to a value obtained by adding the timer value indicating the specified output time to the timer value in the function output state storage area 7. (Step S174).

  Further, the target CPU 211 sets “1” to the output control flag in the function output state storage area 7 (step S175), and uses the output routine specified in the function output state storage area 7 to send a message to the message output device 217. Is output (step S176), and this process ends.

  Next, the processing by the subprogram of the timer interrupt handler that is called when the code in the binary file 210 is executed by the target CPU 211 in step S118 of FIG. 6 and step S138 of FIG. 8 will be described with reference to FIG.

  FIG. 15 is a diagram for explaining processing by the subprogram of the timer interrupt handler. In FIG. 15, the target CPU 211 increments the timer value set in the function output state storage area 7 for each function in the storage area 214 of the target device 30 and compares it with the timer set value in the function output state storage area 7. If they match, the output control flag of the function output state storage area 7 of the function is set to “0” in order to stop the output of the corresponding function (step S181).

  Thereafter, the target CPU 211 clears (initializes) the timer interrupt factor (step S182), and ends the timer interrupt handler.

  With the above processing, unnecessary message output can be suppressed. An example of message output depending on whether or not the first embodiment is applied in the verification of the function B will be described with reference to FIG. FIG. 16 is a diagram illustrating a message output example.

  FIG. 16A shows a message output 6a when the first embodiment is not applied. The message output 6a includes messages related to registers other than the status register “EP0_S” and the control register “EP0_C” related to the function B.

  FIG. 16B shows a message output 6b when the first embodiment is not applied. The message output 6b includes only messages of the status register “EP0_S” and the control register “EP0_C” regarding the function B.

  Next, the flow of operation when the first embodiment is applied will be described with reference to FIG. FIG. 17 is a diagram illustrating a communication example at the time of verification.

  FIG. 17A shows a legend of a diagram showing communication. Components of the target device 30 other than the connection destination device 213 are represented by an evaluation environment 300. The connection destination device 213 and the evaluation environment 300 are connected by the USB bus 8s. Communication between the connection destination device 213 and the evaluation environment 300 is performed by a packet 8p.

FIG. 17B shows an output state in which a message corresponding to communication can be output. In FIG. 17B, the SETUP packet 8p-1 is transmitted from the connection destination device 213 to the evaluation apparatus 300.
(Output state I) The IP macro 212 detects the packet 8p-1 and generates an interrupt.
(Output state II) The packet reception is detected by the interrupt routine of the driver software.
(Output state III) Then, the driver software writes a value to the register of the corresponding function.

Next, the DATA packet 8p-2 is transmitted from the evaluation environment 300 to the connection destination device 213, and the ACK packet 8p-3 is transmitted from the connection destination device 213 to the evaluation environment 300, whereby data is transferred.
(Output state IV) The driver software reads the value from the corresponding function register, and the driver software writes the value to the corresponding function register. Then, after (output state III), a message is output during a register access for a predetermined time (for example, 1 second).
(Output state V) After a predetermined time (1 second) has elapsed from (Output state III), message output is stopped.

  The difference in message output amount between the case where the first embodiment is not applied and the case where the first embodiment is applied in each of the states (output state I) to (output state V) described above. 18 will be described. FIG. 18 is a diagram for explaining a difference in output amount of messages. FIG. 18 shows a message output example in each output state in FIG. “N / A” indicates a case where the first embodiment is not applied, and “Applicable” indicates a case where the first embodiment is applied.

  Due to (output state I), a packet is waited for. In “Not Applicable”, output of messages indicating the values of the status register “EP0_S” and the control register “EP0_C” is repeated, but in “Applicable”, it is not output.

  When the state after the activation of the interrupt routine is reached due to (Output State II), in “Not Applicable”, output of messages indicating the values of the status register “EP0_S” and the control register “EP0_C” is repeated, but “Applicable” Then, it is not output.

  According to (output state III), writing to the register from the determination result of the interrupt factor to the corresponding function (in this case, packet transmission / reception processing to Endpoint # 1) is performed. In “Not Applicable”, the output of messages relating to the status register “EP0_S” and the control register “EP0_C” is repeated. On the other hand, in “applicable”, messages relating to the status register “EP0_S” and the control register “EP0_C” are only output once.

  According to (output state IV), writing to the register and reading from the register are performed. In “N / A”, the output of messages indicating the values of the status register “EP0_S” and the control register “EP0_C” is repeated. On the other hand, in “Applicable”, a message is output only when the status register “EP0_S” and the control register “EP0_C” are accessed.

  In (Output State V), after a predetermined time (1 second) has elapsed from (Output State III), in “Not Applicable”, output of messages indicating the values of the status register “EP0_S” and the control register “EP0_C” is repeated. On the other hand, in “Applicable”, no message is output.

  Next, another example of a debugging system in which the operation of the target CPU 211 is also performed by one CPU without using the ICE device 224 in the first embodiment will be described below.

  FIG. 19 is a diagram illustrating another configuration example of the debugging system according to the first embodiment. The debug system 101a shown in FIG. 19 is realized by a single computer apparatus 10-2. The computer apparatus 10-2 includes a CPU 712, a storage area 713, an IP macro 714, a timer 715, a message output device 716, a storage area 717, and a connection destination device 213. The debug system 101a corresponds to a message output control device.

  The computer apparatus 10-2 is controlled by the CPU 712 and includes a debugger function. The storage area 713 is a storage area used for the CPU 712 to execute processing, and is, for example, a storage area provided by a memory device such as a RAM used by the CPU 712 during processing. The storage area 717 is a storage area for storing an executable format, an embedding instruction file, a program source code, a program such as a compiler and a linker, and is a storage area provided by an auxiliary storage device such as a hard disk device, for example. The storage area 713 and the storage area 717 correspond to the storage area of the storage unit 130 illustrated in FIG.

  The storage area 717 stores a source code 200, an embedding instruction file 202, a binary file 710, and a conversion program 720. The source code 200 is a source code of a program that controls the IP macro 714. The embedding instruction file 202 is a data file that is created for each macro based on the IP macro specification / standard document 202 and includes a code for monitoring a predetermined register and outputting a message including the value. The binary file 710 is an executable binary file. The conversion program 220 is an embedded (cross) compiler and linker program that inputs an embedding instruction file 202 and a program source code 200 and outputs an executable program. The IP macro specification / standard document 201 may be stored in the storage area 717 in the case of a data file.

  The IP macro 714 corresponds to a functional part that performs communication control, and communicates with the connection destination device 213 via the bus 719. The timer module 715 corresponds to the timer module 218 in FIG. 1 and is a timer function used for message output determination. The message output device 716 corresponds to the message output device 217 in FIG. 1 and is a device that outputs a message in response to an instruction during program execution, and has a display unit such as a CRT (Cathode Ray Tube) or LCD (Liquid Crystal Display). .

  The flow of processing by the developer in the debugging system having the configuration shown in FIG. 19 will be described with reference to FIG. FIG. 20 is a diagram for explaining the flow of processing by the developer in the debug system 101a of FIG. In FIG. 20, the developer manually creates an embedding instruction file 202 based on the IP macro specification / standard document 201 and stores it in the storage area 717 (step S201). The developer instructs the computer apparatus 10-2 to execute the conversion program 720 (step S202). The conversion program 720 is loaded into the storage area 221 and executed by the host CPU 11. By executing the conversion program 720, a binary file 710 is created and stored in the storage area 717.

  The developer causes the computer device 10-2 to start verification (step S203). The IP macro 714 is controlled by the CPU 712 operating according to the binary file 710, and the IP macro 710 communicates with the connection destination device 213 via the bus 719. (Step S204). At this time, a message including a register value designated by the embedding instruction file 202 is output to the message output device 716.

  The developer checks the message output to the message output device 716, the message output from the connection destination device 213, and the like (step S205), and determines whether there is a problem (step S206). When the developer determines that there is a problem, the developer analyzes a message regarding the problem (step S207).

  The developer determines whether a message is insufficient for analyzing the problem (step S208). If the developer determines that the message is sufficient, the developer corrects the source code 200 to solve the problem (step S209), and returns to step S202. On the other hand, if the developer determines that the message is insufficient, the developer corrects and adds the embedding instruction file 202, saves it in the storage area 717 (step S710), and returns to step S202.

  In step S206, when the developer determines that there is no problem, the process (work) is terminated.

  FIG. 10 is a flowchart for creating a binary file 710 from the source code 200 in which the register operation API for the IP macro 212 is used during execution of the conversion program 220 by the host CPU 11 in accordance with the execution instruction from the developer in step S202 described above. 6 will be described.

  Next, a configuration example of the debug system according to the second embodiment will be described. FIG. 21 is a diagram illustrating a configuration example of the debug system according to the second embodiment. The configuration of the debug system 102 illustrated in FIG. 21 is different from the debug system 101 illustrated in FIG. 1 in that it includes an output determination routine 230, a header file 231, and a conversion program 240 instead of the conversion program 220. In other respects, the other configuration is the same, and the description thereof is omitted. The debug system 102 corresponds to a message output control device.

  The output determination routine 230 is a routine in which a routine for determining message output is made into a library by a compiler. The header file 231 is a header file that defines the interface of the output determination routine 230 defined in the library.

  The conversion program 240 inputs the embedding instruction file 202 and the source code 200 of the program, and replaces an access part to the IP macro in the source code 200 with an API defined by the output determination routine 230 and the header file 231. It is a program that creates a binary file 210 that is an executable program by compiling and linking the function and the replacement result. A processing unit realized by executing the conversion program 240 by the host CPU 11 corresponds to a creation unit that creates the binary file 210.

  Processing for creating a binary file 210 that is a format executable by the host CPU 11 by the conversion program 240 will be described with reference to FIG. FIG. 22 is a diagram for explaining an executable format creation process. In FIG. 22, the developer creates a header file 231 in the same API format as the register operation API to the IP macro 212 (step S221). Further, the developer creates an output determination routine 230 according to the contents of the embedding instruction file 202 (step S222).

  The developer changes the directory of the header and library to the register operation API to the IP macro 212 specified at the time of compiling and linking to the directory storing the created output determination routine 230 and the header file 231 (step S223).

  Then, the developer causes the host CPU 11 to compile and link to create the binary file 210 (step S224). The created binary file 210 is stored in the storage area 222.

  When creating the output determination routine 230 from the embedding instruction file 202, it is possible to embed each function determination and output format manually by the developer, but the embedding instruction file 202 and the IP macro 212 can be changed by a tool or the like. It can also be automatically created from memory map information.

  In addition, the creation process for creating the binary file 210 according to the developer's instruction in step S224 is the same as the description of FIG. 6 and FIG. 7 or FIG. 8 and FIG. .

  In the first or second embodiment, the time measurement by the timer is started on the condition that writing to the register is performed, but other conditions such as a condition that a specific field of the register becomes a certain value may be used. good.

  In an environment where the timer cannot be used, it can be realized by adding a mechanism for incrementing the counter for each predetermined code in the execution format.

  When the first or second embodiment as described above is applied, the output of unnecessary messages can be reduced and the problems in the case of no application as illustrated in FIG. 23 can be solved. . FIG. 23 is a diagram for explaining an example of a problem that can be solved by applying. In FIG. 23, when the first or second embodiment is not applied, the message output part is manually deleted from the non-applied code 22a corresponding to the driver source code including the message output part.

  The post-operation non-applied code 22a ′ indicates a state in which the message output part has been deleted. When the deletion is performed manually, for example, there is a problem that a description of access to a register that is originally necessary is erroneously set in a comment sentence and is not executed, such as erroneous deletion 22b. In addition, problems such as forgetting to delete the description of the message output to be deleted 22c also occur.

  However, when the first or second embodiment is applied, a manual operation such as deletion of a message output part by a developer is not necessary, and thus it is possible to eliminate erroneous erasure 22b and forgetting to erase 22c.

  As described above, in order to debug the driver software of the communication system IP macro, the function of the communication system IP macro is classified for the software program that outputs a message for debugging the software, and according to the function classification The IP macro registers are classified. Then, the source code 200 of the driver software is analyzed, and a program for outputting a debug message including the register value of the function is embedded based on the embedding instruction file 202. In this embedded program, all the registers of the function are output at a constant interval between the access time and a fixed time, or are output when accessing the register of the same function. In this case, time management may be performed using timer hardware installed in an environment where the driver software runs.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

Regarding the embodiment including the first and second examples, the following additional notes are disclosed.
(Appendix 1)
A storage unit that stores a source code and an embedding instruction file that specifies a register that is a message output target;
A description of accessing the register specified by the embedding instruction file stored in the storage unit in the source code includes a description of outputting a message including the value of the register to an output device during an output period. A computer apparatus, comprising: a creation unit that creates a binary file in an executable format in the storage unit from the source code that is replaced with the replacement content.
(Appendix 2)
The embedding instruction file specifies a message output conditional expression for specifying the output period and register information for each function,
The replacement content includes the output period set in a timer specified by a message output conditional expression and a message output format specified by register information including specification information of a target register. A computer device as described.
(Appendix 3)
The creation unit includes a function structure in which the output period is set for each function based on the embedding instruction file, and an embedding instruction structure including the register information from the register information connected from the function structure. Is created in the storage unit. The computer apparatus according to appendix 2.
(Appendix 4)
Executes the binary file, starts to output a message including the value of the register when accessing the designated register, and sets the output period to the set value of the timer activated at the time of accessing Accordingly, after the output period, the output of the message to the output device is stopped, The computer device according to any one of appendix 2 or 3,
(Appendix 5)
A determination routine for determining whether or not the description read from the source code is a description for accessing the register specified by the embedding instruction file stored in the storage unit; and a determination routine defined by the library The computer apparatus according to any one of appendices 1 to 3, further comprising: a header file defining the interface.
(Appendix 6)
6. The computer apparatus according to any one of appendices 1 to 5, wherein the source code is a code describing a macro for performing communication control.
(Appendix 7)
A message output control method executed by a computer,
Input the source code stored in the storage unit and the embedding instruction file specifying the register that is the message output target,
In the source code, a description for accessing the register specified by the embedding instruction file is replaced with a replacement content including a description for outputting a message including the value of the register to an output device during an output period.
A message output control method, comprising: creating an executable binary file in the storage unit from the source code replaced with the content.
(Appendix 8)
Input the source code stored in the storage unit and the embedding instruction file specifying the register that is the message output target,
In the source code, a description for accessing the register specified by the embedding instruction file is replaced with a replacement content including a description for outputting a message including the value of the register to an output device during an output period.
A program that causes a computer to execute a process of creating an executable binary file in the storage unit from the source code replaced with the content.

10 Host device 11 Host CPU
DESCRIPTION OF SYMBOLS 12 Main memory device 13 Auxiliary memory device 14 Input device 15 Display device 18 Driver 19 Storage medium 101 Debug system 200 Source code 201 IP macro specification / standard document 202 Embedding instruction file 210 Binary file 211 Target CPU
212 IP Macro 213 Connected Device 214 Storage Area 217 Message Output Device 218 Timer Module 220 Conversion Program 221 Storage Area 224 ICE Device 230 Output Determination Routine 231 Header File 240 Conversion Program

Claims (5)

A storage unit that stores a source code and an embedding instruction file that specifies a register that is a message output target;
Of the source code, the description to access the register thus specified in the embedded instruction file stored in the storage unit, during the output period, contains a description of the output device a message containing the value of the register A message output control apparatus comprising: a creation unit that creates a binary file in an executable format in the storage unit from the source code replaced by the replacement content. The embedding instruction file specifies a message output conditional expression for specifying the output period and register information for each function,
The replacement content includes the output period set in a timer specified by a message output conditional expression and a message output format specified by register information including specification information of a target register. The message output control device according to 1.   The creation unit includes a function structure in which the output period is set for each function based on the embedding instruction file, and an embedding instruction structure including the register information from the register information connected from the function structure. The message output control device according to claim 2, wherein the message output control device is created in the storage unit.   Executes the binary file, starts to output a message including the value of the register when accessing the designated register, and sets the output period to the set value of the timer activated at the time of accessing 4. The message output control device according to claim 2, wherein output of the message to the output device is stopped after the output period. A message output control method executed by a computer,
Input the source code stored in the storage unit and the embedding instruction file specifying the register that is the message output target,
In the source code, a description for accessing the register specified by the embedding instruction file is replaced with a replacement content including a description for outputting a message including the value of the register to an output device during an output period.
A message output control method, comprising: creating an executable binary file in the storage unit from the source code replaced with the content.

Images