JP4558376B2 - controller - Google Patents

Description

The present invention relates to a controller that executes tracing of a program described in a high-level language program .

  Program development of an embedded device such as a programmable controller (development of an embedded program) is performed in a cross development environment. The cross-development environment is developed in a state in which a development host system that develops a program to be incorporated and a development target that is an apparatus that incorporates and operates the program is communicated by RS-232C (Recommended Standard 232 version C) or the like.

  When debugging in a cross-development environment, data necessary for debugging is held in the development host system, and information such as symbol information on the development target side and values stored in variables is passed to the development target via communication. Yes. In this case, dedicated communication corresponding to the development target is required, and a dedicated debug tool is required in the development host system in the cross development environment.

  As a means for performing debugging when there is no OS (operating system) system program in the development target, there is a method of using an ICE that emulates the development target microprocessor and its dedicated tool. In this method, debug information is collected in the ICE and communication is established between the host target and the ICE, which are a cross development environment, and the ICE is collected.

  The method for debugging a microcomputer program described in Patent Document 1 embeds a debug module in a program generated by a high-level language compiler for ICE and stored in a program memory, and executes the debug module by an evaluation CPU. When the value of an argument passed to the function or the value of a specific argument exceeds an allowable range, it is recorded in the trace memory device. By this ICE, error processing related to a module or an argument that has passed an argument value passed to a function or an argument exceeding an allowable range is evaluated without breaking the execution of the program.

JP-A-10-124350

  However, the above-described conventional technique has a problem that the configuration of the apparatus for performing debugging is complicated because ICE is required for performing debugging. In addition, there is a problem that a clock or the like is restricted in the ICE operated for debugging. Further, when a failure occurs in a controller that performs control for a long time such as a PLC (Programmable Logic Controller), debugging cannot be performed unless debug information is collected at the time of occurrence. In such a case, after preparing the environment where the problem reoccurs, it is necessary to search for the defect part while checking the operation information using the debug tool, so it takes a lot of time to collect the debug information. was there. In addition, in a controller that is built in a production line such as a PLC and operates for a long time, host / target communication is always performed in order to obtain debug information. There is a problem that it is difficult to obtain debug information because of fear.

  The present invention has been made in view of the above, and an object of the present invention is to obtain a controller capable of investigating a failure in a short time with a simple device configuration when a failure occurs in a program.

In order to solve the above-described problems and achieve the object, the present invention provides a unit that controls its own operation by a system program that is an operating system and operates an external device by a user program described by a high-level language program. When executing the system program and the user program in a controller that performs control, a data storage unit that stores the system program and the user program, and the system program and the user program are expanded in the data storage unit and a CPU for executing the system program and the user program by the CPU by executing the system program, the system program in the data storage portion is A program area information is the address range of the area that use the access address, the operation information accessed data and program counter is associated as information used during execution of the system program and the user program, said system Based on the program area information, the operation information, and the error address by executing a program information acquisition process for acquiring an error address of an error that occurred during execution of the program and the user program, and the system program performs a program analysis processing for error analysis of the system program and the user program, the program area information is acquired by the CPU before the user program is started, and the operation Broadcast while the own controller is operating, acquired by the CPU, when the program analysis processing, the CPU is the program area information, the acquisition of the operation information and the error address is stopped, Thereafter, it is determined whether an address error has occurred based on the presence or absence of the error address. If an address error has occurred, an access address where the error has occurred is acquired from the error address, and the error is The operation information having the same access address as the generated access address is acquired, and the cause of error is the user program based on whether the access address of the acquired operation information is within the range of the program area information. Or whether it is the system program.

  According to this invention, the program area information relating to the area where the system program is stored in the data storage unit, the operation information during execution of the user program, and the error information relating to errors occurring during the execution of the user program are obtained, Since the error analysis of the user program is performed based on the program area information, the operation information, and the error information, it is possible to easily confirm the trace of the operation status of the user program and the factor determination at the time of the error of the user program.

According to the present invention, the controller can easily confirm the trace of the operation status of the user program and the determination of the cause of the error of the user program while operating the user program described in the embedded high-level language program. . Therefore, since data at the time of occurrence of a malfunction of the user program can be confirmed in the controller, it is possible to shorten the time for preparing an environment for preventing the reoccurrence of debugging.

  Embodiments of a controller according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

Embodiment 1 FIG.
FIG. 1 is a system configuration diagram of a debugging system including a controller according to Embodiment 1 of the present invention. The debug system is a system for temporarily diagnosing a problem in a program written in a high-level language such as C language (hereinafter referred to as a high-level language program). As shown in FIG. 1, the debug system includes a production system 3 that executes devices in a production line, and a network device 1 that is connected to the production system 3 via a communication network such as the Internet 2.

  The production system 3 includes a power supply 41, a controller 10, and a plurality of units 42 connected to a PLC (Programmable Logic Controller) bus 45. The controller 10 controls each unit 42 via the PLC bus 45.

  The network device 1 has a display function such as a liquid crystal display, and is composed of, for example, a personal computer. The network device 1 acquires high-level language program operation information, high-level language program error factors (error factor candidates), and the like acquired by the controller 10 in the production system 3.

  FIG. 2 is a block diagram illustrating a configuration of the controller according to the first embodiment. The controller 10 controls the unit 42 connected to the PLC bus 45 and temporarily diagnoses a malfunction of the user program for controlling the unit 42 created by the built-in high-level language program.

  The controller 10 is a control device of a production system such as a PLC (Programmable Logic Controller), and includes a personal computer or the like. The controller 10 includes a CPU (Central Processing Unit) bus 9, a CPU 11, a peripheral device connection unit 12, a transmission / reception unit 13, a data storage unit 14, a trace information storage unit 15, a program storage unit 16, a data conversion unit 18, and a storage medium connection unit. 19 is provided.

  The CPU bus 9 is a bus (transmission path for exchanging data) connecting the CPU 11 to the transmission / reception unit 13, the data storage unit 14, the trace information storage unit 15, the program storage unit 16, the data conversion unit 18, and the storage medium connection unit 19. It is. The CPU 11 is a microprocessor that executes a program.

  The peripheral device connection unit 12 includes, for example, RS-232C (Recommended Standard 232 version C), and performs serial communication with external devices such as a printer, a modem, and a scanner. The peripheral device connection unit 12 receives an error factor determination file and a trace data file, which will be described later, acquired by a system program or the like serving as an OS (Operating System) of the controller 10 as necessary, such as a peripheral device such as a printer. Send to.

  The transmission / reception unit 13 includes a PHY chip or the like that is connected by 100Base-TX / 100Base-T, and is connected to an external device by Ethernet (registered trademark) or the like to transmit and receive information. The transmission / reception unit 13 transmits an error factor determination file and a trace data file via the Internet 2 in response to a request from the network device 1. In addition, the transmission / reception unit 13 transmits an error factor determination file and a trace data file to an external device (not shown) having a display function such as a liquid crystal monitor as necessary.

  The data storage unit 14 includes a work RAM (Random Access Memory) and the like, and stores programs (user programs and system programs) executed by the CPU 11 and data used by the programs. The CPU 11 executes the system program and the user program by expanding the system program and the user program stored in the program storage unit 16 in the data storage unit 14. Here, the process in which the CPU 11 executes the system program by developing the system program in the data storage unit 14 corresponds to the process of the program information acquisition unit described in the claims.

  The trace information storage unit 15 includes a backup RAM having an internal power source such as an SRAM (Static RAM) and the like, and has a storage function capable of holding data even after the controller 10 is reset.

  The data converter 18 includes an ASIC (Application Specific Integrated Circuit) for the PLC bus 45 and the like, and converts data when accessing the unit 42 via the PLC bus 45. The storage medium connection unit 19 connects to a storage medium such as a CF (Compact Flash) card or a flexible disk.

  The program storage unit 16 includes a ROM (Read Only Memory) such as a FLASH memory and the like, and stores a system program serving as the OS of the controller 10, a user program created in a high-level language such as C language, an error factor candidate D6 described later Remember (save). In the first embodiment, a system program serving as an OS performs a temporary diagnosis (error analysis) for a user program failure.

  Here, a system program serving as the OS of the controller 10 will be described. FIG. 3 is a diagram illustrating an example of functional blocks of the system program according to the first embodiment. The system program includes a storage medium I / F function block 20, a script function block 21, an error factor diagnosis function block 22, a server function block 23, a trace function block 24, a system area storage function block 25, and an external device I / F function block 27. It has.

  The script function block 21 is a function block that executes the contents described in the file to start the user program. The error factor diagnosing function block 22 is a functional block for determining an error factor from information (trace information 100 to be described later) regarding user program trace when an error of the user program occurs. The error cause diagnosis function block 22 uses the trace information 100 held when an error occurs to check the back trace and task information from the error occurrence location, and lists candidates that can cause the error occurrence location. Save to.

  The server function block 23 is a functional block that accepts the acquisition request information of the information related to the trace acquired by the controller 10 from the external device and transmits response information to the acquisition request information of the information related to the trace to the external device (network device 1). . The trace function block 24 is a functional block that performs real-time trace of the operation of the user program and stores the traced information in the trace information storage unit 15 as the trace information 100. The system area storage functional block 25 is a functional block for storing an area of the data storage unit 14 used by the system program.

  The storage medium I / F functional block 20 is a functional block for accessing a storable storage medium attached to the storage medium connection unit 19. The external device I / F function block 27 is a function block having an I / F driver function that can be connected to the Internet, serial, modem, and PLC bus 45. When the server function block 23 receives the acquisition request information on the trace information from the external device, the external device I / F function block 27 transmits the trace information to the external device via the Internet 2 or the like.

  The CPU 11 expands and operates the system program in the data storage unit 14 to thereby operate the storage medium I / F function, script function, error factor diagnosis function, server function, trace function, system area storage function, and external device I. / F function is achieved. In the first embodiment, the CPU 11 develops the system program in the data storage unit 14 and operates it to perform the processing of the program analysis unit described in the claims.

  Next, the operation of the controller 10 will be described. FIG. 4A is a flowchart illustrating an operation procedure of the controller, and FIG. 4B is a flowchart illustrating a procedure for registering an error address.

  A system program or user program serving as an OS stored in the program storage unit 16 is expanded in the data storage unit 14 when the controller 10 is started, and a predetermined operation based on the system program or user program (high-level language program) is started. . When the system program is activated, the trace function of the system program starts storing the trace information 100 in the trace information storage unit 15.

  FIG. 5 is a diagram illustrating a configuration of trace information stored in the trace information storage unit. The trace information 100 includes an error occurrence address D1 that stores an address where an error has occurred, an access address that is always collected while the controller 10 is operating by the trace function, access data, and an S / W that stores a program counter ( Software) Trace information D2, function call history information D3 storing function call history (program counter, function name, argument) of high-level language program including system program to be OS, data used by system program to be OS The information stored in each area of the system program use area information D4 storing the RAM area of the storage unit 14 is included.

  The error occurrence address D1 corresponds to the error information described in the claims, the S / W trace information D2 and the function call history information D3 correspond to the operation information described in the claims, and the system program use area information D4 Corresponds to the program area information described in the claims. The error occurrence address D1, S / W trace information D2, function call history information D3, and system program use area information D4 are stored in the trace information storage unit 15 as trace information 100. The trace information 100 is used when automatically listing error factor candidates by the system program.

  Here, the S / W trace information D2, the function call history information D3, and the system program use area information D4 will be described. FIG. 6A is a diagram for explaining the S / W trace information, FIG. 6B is a diagram for explaining the function call history information, and FIG. 6C is the system program use area information. It is a figure for demonstrating.

  As shown in FIG. 6A, the S / W trace information D2 includes a plurality of one frame composed of one program counter (PrgCounter), one access address (Address), and one access data (Data). Each frame has a frame number. It is included. The S / W trace information D2 is acquired by the trace function of the system program based on information exchanged between the data storage unit 14 and the CPU 11.

  As shown in FIG. 6B, the function call history information D3 includes one program counter, a function name (symbol information (Symbol)), a first argument (Data “0”) to an nth (n is a natural number) argument ( A plurality of function call data consisting of Data “n−1”) is included. In the function call history information D3, the program counter, the function name, and the arguments passed to the function are collected by the system program when the user program calls the function.

  In the function call history information D3, when the data that can be stored in the stack at the time of data registration is full (full), the oldest data is deleted and new data is registered (FIFO (Fast In Fast Out)), and at the time of data reference New data is taken out of the stack and referenced (FILO (Fast In Last Out)).

  As shown in FIG. 6C, the data structure of the system program use area information D4 is information indicating the number of system use areas used by the system program and the RAM area of the data storage unit 14 used by the system program. As system usage area data. The system use area data includes a plurality of sets of information related to an address including one start address (StartAddr) and one last address (EndAddr).

  When the CPU 11 activates the system program, before the user program is started, information on the RAM area of the data storage unit 14 used by the system program is acquired from the data storage unit 14 and the system program use area information D4 is obtained. Store.

  When the CPU 11 starts processing by the user program, the access address, access data, and program counter are collected as S / W trace information D2 while the controller 10 is operating. When the CPU 11 starts processing by the user program, the function call history of the high-level language program is collected while the controller 10 is operating. The collected S / W trace information D2 and function call history information D3 are stored in the trace information storage unit 15 as trace information 100.

  When an error such as an illegal address access (address error) or system WDT (watch dog timer) occurs while the program processing is being executed by the CPU 11, the system program will cause an error such as an illegal access to this address or a system WDT occurrence. Is detected as a fatal error that may cause the system program to malfunction. At this time, when an illegal address access or system WDT occurs, an event is generated, and an error is detected by the system program detecting this event. The address where the error has occurred is stored in the trace information 100 of the trace information storage unit 15 as the error occurrence address D1.

  Thereafter, when an event occurs due to an illegal access of the address and the like and the trace information 100 of the trace information storage unit 15 is updated, the error factor cannot be determined accurately. Therefore, once an event occurs, the system program stores the trace execution flag stored in the program storage unit 16 in order to stop updating the trace information 100 to the trace information storage unit 15 (end collection of the trace information 100). Is set to OFF (step S100). Thereby, collection of the trace information 100 by the system program is once ended (stopped), and the trace information 100 is not updated.

  Here, the configuration in the program storage unit 16 and the configuration of the data storage unit 14 will be described. FIG. 7A is a diagram illustrating a memory map of the program storage unit according to the first embodiment, and FIG. 7B is a diagram illustrating a memory map of the data storage unit according to the first embodiment.

  The program storage unit 16 includes an area for storing system programs (system program storage area 28), an area for storing user programs (user program storage area 30), and an area for storing trace execution flags (trace execution flag 39). It is configured.

  The system program storage area 28 and the user program storage area 30 are stored in an area of the standard ROM 37, and the trace execution flag 39 is stored in an area other than the standard ROM 37.

  The trace execution flag 39 is information indicating whether or not to collect the trace information 100, and is turned on when the system program as the OS is executed. When the trace execution flag is set to ON, the CPU 11 collects the trace information 100 by the system program of the data storage unit 14, and when the trace execution flag is set to OFF, the system of the data storage unit 14 is collected. Trace information is not collected by the program.

  As shown in FIG. 7-2, the data storage unit 14 includes a system program data area 32, a system program storage area 33, a user program use area 34, a system memory / data storage area for storing data used for system program execution. The stack securing area 36 is included.

  A system program data area 32, a system program storage area 33, a user program use area 34, and a system memory / stack securing area 36 are stored in the work RAM 38 area of the data storage unit 14.

  The system memory / stack securing area is an area used when the system program operates. The system program is expanded in the work RAM 38 at the time of activation, and operates using the system program data area 32, the system program storage area 33, and the system memory / stack securing area 36.

  If the occurrence of an event is based on an error due to the destruction of data in the RAM area, an address error often occurs. Therefore, the system program of the data storage unit 14 stores the address at which illegal access was made. A value is acquired from the error occurrence address D1 of the area in the trace information storage unit 15. Then, the system program determines whether an address error has occurred based on whether an address other than 0x00000000 (NULL) is stored in the error occurrence address D1 (step S110).

  If the system program determines that an address error has occurred (step S110, Yes), an error address registration process is performed (step S120).

Here, the procedure of error address registration processing will be described with reference to the flowchart of FIG. The CPU 11 acquires the access address where the error has occurred from the error occurrence address D1 of the trace information storage unit 15 based on the system program, and has the latest access address having the same access address as the address where the error has occurred from the S / W trace information D2. Information (data) is acquired (step S300). Data (access address, access data, program counter) acquired from this S / W trace information D2 becomes data when an address error occurs, and is referred to during debugging. When the data at the time of the address error occurrence is acquired, it is stored in the past access address information D5 for storing the access to the past address error occurrence place. The past access address information D5 is stored in the data storage unit 14, for example. The system program checks whether there is an access to the same address as the address where the error occurred before the error occurs (step S310).

  The access address of each piece of information stored in the S / W trace information D2 is searched, and if an access to the same address as the address where the error has occurred exists before the error occurs (Yes in step S310), the error occurrence address D1 The data having the same address as the address stored in is added to the past access address information D5 (step S320).

  It is confirmed whether or not all access addresses existing in the S / W trace information D2 have been checked (step 330). When it is determined that all access addresses existing in the S / W trace information D2 are not checked (when it is determined that the access address of each information stored in the S / W trace information D2 is not the last one) (step (S330, No), the process of step 310 and step S320 is repeated.

  On the other hand, if it is determined that all access addresses existing in the S / W trace information D2 have been checked (step S330, Yes), the S / W trace is determined from the program counter of the data of the past access address information D5 registered in the trace information storage unit 15. A back trace is performed based on the information D2. Then, the function name and task name moved to the address where the error occurred (moved to the error address) are acquired. That is, first, a program counter registered in the past access address information D5 is acquired, and operation information (access address, access data, program data) indicating the program counter before the program counter is acquired from the S / W trace information D2. (Step S340).

  The system program searches the function call history information D3 in the trace information storage unit 15 for the same program counter as the program counter acquired from the S / W trace information D2. Then, when the function call history information D3 includes the same program counter as the program counter acquired from the S / W trace information D2, the task name and function name corresponding to the searched program counter are acquired from the function call history information D3 ( Step S350).

  The system program determines whether function information (program counter, function name, argument) has been acquired from the function call history information D3 (step S360). When the system program determines that the function information has been acquired from the function call history information D3 (the function in which the error has occurred is found) (Yes in step S360), the information obtained by adding the function information to the access address information is acquired information Are registered in the error cause candidate D6 of the trace information storage unit 15 together with information (address error) for identifying the error cause (step S370). When registering error factors in step S370, it is considered that new operations are more likely to be a direct cause of errors. Therefore, the operations are registered in the higher order of error occurrence factor candidates D6 in order of newest operations.

  On the other hand, when the system program determines that the function information cannot be acquired from the function call history information D3 (No in step S360), the registration to the error occurrence factor candidate D6 is not performed.

  Search the program counter until the same program counter as the program counter acquired from the S / W trace information D2 is found from the function call history information D3 or the oldest data stored in the S / W trace information D2 is checked. (Repeat search of the program counter). That is, if the same program counter as the program counter acquired from the S / W trace information D2 cannot be found from the function call history information D3, it is confirmed whether all access addresses existing in the S / W trace information D2 have been checked. (Step 380). When it is determined that all access addresses existing in the S / W trace information D2 are not checked (when it is determined that the access address of each information stored in the S / W trace information D2 is not the last one) (step (S380, No), the processing of step 350 to step S370 is repeated.

  On the other hand, if it is determined that all the access addresses existing in the S / W trace information D2 have been checked (step S380, Yes), all the program counters registered in the past access address information D5 are programmed before this program counter. It is confirmed whether or not the operation information indicating the counter is checked from the S / W trace information D2 (step S390). When it is determined that the operation information is not checked for all program counters registered in the past access address information D5 (when it is determined that the program counter registered in the past access address information D5 is not the last one). (Step S390, No), the processing of Step 340 to Step S380 is repeated. If it is determined that all program counters registered in the past access address information D5 have been checked (step S390, Yes), the error address registration process is terminated.

  In step S110 of FIG. 4-1, when it is determined by the system program that no address error has occurred (step S110, No), or when the error address registration process (step S120) is completed, the system program in operation The stack information of all existing tasks is acquired from, and it is checked whether stack overflow has occurred. It is checked whether or not the data in the RAM area is destroyed by this stack overflow.

  If a stack overflow has occurred, it is clear that the data in the RAM area has been destroyed due to the stack overflow, which is the cause of the error. Therefore, the task acquired by the system program is positioned at the top of the error cause candidate D6. Name and final execution function name are stored (step S130).

  Then, it is confirmed whether or not a check for stack overflow has been performed for all tasks of the system program (step S140). If the stack overflow is not checked for all tasks, the process of step S130 is repeated. On the other hand, when the stack overflow is checked for all tasks, it is confirmed whether there is a task in which the stack overflow has occurred (step S150).

  As a result of checking the stack overflow, if it is determined that there is no task in which a stack overflow has occurred (No in step S150), a WDT error or the like occurs due to the existence of an infinite loop task. Therefore, it is confirmed whether or not there is a suspended task (step S160).

  In order to check whether there is a suspended task, task information is obtained from the system program that is the OS, and it is determined whether there is a suspended task. If it is determined that there is a suspended task (step S160, Yes), there is a possibility that an infinite loop has occurred, so it is checked whether there is a place where an infinite loop has occurred.

  Specifically, it obtains the priority (priority) of the suspended task from the system program that is the OS (obtains the highest priority when there are multiple suspended tasks), and operates at the above priority or higher. Since there is a high possibility that an infinite loop has occurred in the task with the lowest priority among the tasks being executed, for example, the current execution position of the task with the lower priority is acquired by the system program that is the OS.

  After acquiring the task execution position that may be in an infinite loop, whether or not the same value as the task execution position that may be in an infinite loop exists from the program counter of the S / W trace information D2 Investigate. If there are many (for example, 100 or more) program counters with the same value in the S / W trace information D2, it is determined that an infinite loop has occurred, and the error cause (suspend), task name, and program counter are the cause of the error. The candidate D6 is registered (step S170).

  Here, since the cause (suspend) of the error occurrence is clear and is considered to be detected only when no address error or stack overflow is detected, the error occurrence factor candidate D6 is positioned and stored.

  It is determined whether the access address and program counter of all the information stored in the error occurrence factor candidate D6 are within the range of the system program use area information D4 of the trace information. If the access address or the program counter is within the range of the system program use area information D4, it is determined that the cause of the error is the system program, and if it is outside the range of the system program use area information D4, It is determined that the generation factor is a user program.

  The determination result as to whether the error cause for each error cause item is a system program or a user program is added to each error cause candidate D6 and stored (step S180).

  Error cause determination that is a file that stores error cause candidates D6 listed as error cause candidates in a program storage unit (standard ROM) 16 or a storage medium (such as a CF card) attached to the storage medium connection unit 19 A trace data file which is a file storing the file and the trace information (D1 to D4) is saved (step S190).

  The error cause determination file and the trace data file stored by the program storage unit 16 are stored as, for example, a WEB (web) page. Then, in response to a request from the network device 1 connected to the controller 10 and the Internet 2, information on the WEB page is transmitted from the transmission / reception unit 13 to the network device 1. The network device 1 that is remote from the controller 10 can acquire an error occurrence factor determination file and a trace data file via the Internet 2.

  As a result, it is possible to easily confirm the trace of the operation status of the user program (high-level language program) and the cause determination at the time of error based on the error occurrence cause determination file and the trace data file.

  Further, based on whether the access address and the program counter are within the range of the system program use area information D4, information indicating whether the error cause is a system program or a user program is registered in the error cause candidate D6. Therefore, it is possible to easily determine whether a failure occurs in a system program that is an OS or a user program.

  As described above, according to the first embodiment, it is possible to easily check the trace of the operation status and the cause determination at the time of the error by operating the embedded high-level language program without the controller 10 being in the cross development environment. It becomes. In addition, since the controller 10 narrows down (specifies) the occurrence of a defect in a high-level language program such as C language, it is possible to reduce the time required for specifying the defect part during debugging. Further, since data at the time of occurrence of a failure can be confirmed in the controller 10, it is possible to shorten the time for preparing an environment for preventing the reoccurrence of debugging.

Embodiment 2. FIG.
A controller according to the second embodiment will be described with reference to FIGS. 4-1, 4-2, 6-1 and 8. FIG. In the second embodiment, the controller 10 includes a trace circuit (operation information acquisition circuit) 40, and the trace circuit 40 assists tracing by S / W.

  FIG. 8 is a block diagram illustrating a configuration of a controller according to the second embodiment. Of the constituent elements in FIG. 8, constituent elements having the same functions as those of the controller of the first embodiment shown in FIG. 2 are denoted by the same reference numerals, and redundant description is omitted.

  As shown in FIG. 8, the controller 10 according to the second embodiment includes a trace circuit 40. The trace circuit 40 writes program operation information such as instructions and data from the data storage unit 14 to the CPU 11 in the trace information storage unit 15. That is, when the CPU 11 starts processing by the user program, the trace circuit 40 collects access addresses, access data, and program counters while the controller 10 is operating, and stores them in the H / W trace information D7 (not shown). Store.

In the first embodiment, the S / W trace information D2 is stored in the trace information storage unit 15 by the system program. In the second embodiment, the trace circuit 40 stores the H / W (hardware) trace information D7. The information is stored in the trace information storage unit 15. The H / W trace information D7 includes the same information (access address, access data, program counter) as the S / W trace information D2 of the first embodiment shown in FIG.

  The controller 10 of the second embodiment also performs error determination processing according to the same operation procedure as that of the controller of the first embodiment described with reference to FIGS. 4A and 4B. That is, when the system program is started, the system program use area information D4 is stored in the trace information 100 of the trace information storage unit 15 by the system program. When the user program is executed, data is traced by the trace circuit 40, and this information is stored in the trace information 100 of the trace information storage unit 15 as H / W trace information D7. Further, the function call history information D3 is acquired by the trace function of the system program and stored in the trace information 100 of the trace information storage unit 15. When an error occurs during execution of the user program, error factor determination processing is performed based on the error occurrence address D1, system program use area information D4, H / W trace information D7, and function call history information D3. The determination file and the trace data file are stored in the program storage unit 16 or the like. Trace processing by the trace circuit 40 (hardware) makes it possible to reduce the load on the CPU 11 and prevent performance deterioration as a control device.

  As described above, according to the second embodiment, since the trace circuit 40 acquires the access address, access data, and program counter with a large amount of trace information as the H / W trace information D7, the trace collected by the system program (software) Information can be reduced. Therefore, it is possible to efficiently perform trace and error determination (specification of a defect occurrence point of a high-level language program) while reducing the load at the time of collecting trace information on the CPU 11 when the program is executed by the controller 10. It becomes possible.

Embodiment 3 FIG.
The controller according to the third embodiment will be described with reference to FIGS. 2, 4-2 and FIGS. 9-1 to 11-2. In the third embodiment, when an error occurs that prevents the system program (main OS, which will be described later) from operating, an error analysis or the like is performed by switching to an OS (sub-OS, which will be described later) that can operate even when an error occurs. Do.

  In the third embodiment, trace or error factor determination is performed by the controller 10 according to the first embodiment shown in FIG. 2 or the controller 10 according to the second embodiment shown in FIG.

  The controller 10 stores in the program storage unit 16 a system program that operates as an OS during normal operation (hereinafter referred to as a main OS) and a system program that operates as an OS during an error (hereinafter referred to as a sub OS).

  The main OS is expanded in the work RAM of the data storage unit 14 when the system program is activated, and operates using the corresponding area of the work RAM and the system memory / stack securing area 36.

  FIG. 9A is a diagram illustrating an example of functional blocks of the main OS according to the third embodiment, and FIG. 9B is a diagram illustrating an example of functional blocks of the sub OS according to the third embodiment. Of the components shown in FIGS. 9-1 and 9-2, components that achieve the same functions as those of the system program according to the first embodiment shown in FIG. To do.

  As shown in FIG. 9A, the main OS includes a storage medium I / F function block 20, a script function block 21, an error factor diagnosis function block 22, a server function block 23, a trace function block 24, and a system area storage function block 25. In addition to the external device I / F function block 27, an OS switching function block 26 is provided.

  The OS switching function block 26 is a functional block for switching the OS from the main OS to the sub-OS in order to stably operate the error factor diagnosis function when an error that causes the main OS to stop functioning occurs.

  As illustrated in FIG. 9B, the sub OS includes a storage medium I / F function block 20, an error factor diagnosis function block 22, a server function block 23, and an external device I / F function block 27. Since the sub-OS is an OS for analyzing error information, it does not have a function of collecting trace information (trace function block 24, system area storage function block 25). Since the sub-OS does not include the script function block 21, the trace function block 24, and the system area storage function block 25, even if an error that causes the system program to not operate occurs, Discrimination can be performed.

  Next, the operation of the controller 10 will be described with reference to FIGS. FIG. 10 is a flowchart illustrating an operation procedure of the controller according to the third embodiment. Note that, in the operation procedure illustrated in FIG. 10, detailed description of the operation processing that performs the same operation as the operation of the controller according to the first embodiment illustrated in FIG. 4A is omitted.

  When the controller 10 is activated, the main OS stored in the program storage unit 16 is expanded in the data storage unit 14. When the user program is activated, the main OS stored in the program storage unit 16 is expanded in the data storage unit 14.

  When the CPU 11 activates the system program (main OS), before the user program is started, information on the RAM area of the data storage unit 14 used by the main OS is acquired from the data storage unit 14 and the system program is used. Store in area information D4.

  When the CPU 11 starts processing by the user program, the S / W trace information D2 and the function call history information D3 are collected and stored as the trace information 100 in the trace information storage unit 15 while the controller 10 is operating.

  When an error that causes the main OS to stop functioning while the program processing is being executed by the CPU 11, the address in which the error has occurred before the main OS is completely stopped is set as the error occurrence address D1 in the trace of the trace information storage unit 15. Store in the information 100.

  Even when the OS is switched from the main OS to the sub-OS by the OS switching function, the error occurrence address D1, H / W trace information D2, function call history information D3, and system program use area information D4 are stored in order to refer to the trace information 100. Each is stored using a fixed area. After the error occurs, the main OS turns on a sub-OS activation signal 31 (to be described later) in the program storage unit 16 before the main OS is completely stopped, and reboots the OS.

  Here, the configuration in the program storage unit 16 and the configuration of the data storage unit 14 according to the third embodiment will be described. 11A is a diagram illustrating a memory map of the program storage unit according to the third embodiment, and FIG. 11B is a diagram illustrating a memory map of the data storage unit according to the third embodiment. Among the constituent elements in FIG. 11A, constituent elements having the same functions as those in the memory map of the program storage unit of the first embodiment shown in FIG. To do. In addition, among the constituent elements in FIG. 11B, constituent elements having the same functions as those in the memory map of the data storage unit of the first embodiment shown in FIG. Is omitted.

  The program storage unit 16 includes an area for storing the main OS (main OS storage area 58), an area for storing the sub OS (sub OS storage area 59), a user program storage area 30, and an area for storing the sub OS activation signal (sub The OS start signal 31) and an area for storing a trace execution flag (trace execution flag 39) are included.

  The main OS storage area 58, the sub OS storage area 59, and the user program storage area 30 are stored in the standard ROM area 37, and the sub OS activation signal 31 and the trace execution flag 39 are stored in areas other than the standard ROM.

  The sub OS activation signal 31 is information for determining whether or not to change from the main OS to the sub OS. When the sub OS activation signal 31 is ON, the user program is executed by the sub OS, and when the sub OS activation signal 31 is OFF, the user program is executed by the main OS.

  As shown in FIG. 11B, the data storage unit 14 includes a main OS data area 52, a main OS storage area 53, a user program use area 34, and a sub OS for storing data used for executing the main OS. The sub-OS data area 35, which is an area for storing data used for execution, and a system memory / stack securing area 36 are configured.

  A main OS data area 52, a main OS storage area 53, a user program use area 34, a sub OS data area 35, and a system memory / stack securing area 36 are stored in the work RAM 38 area of the data storage unit 14.

  When rebooting with the sub-OS activation signal 31 turned ON, the activation program retains the previous error state, and does not initialize the RAM area, but at the top address of the sub-OS on the standard ROM 37 of the program storage unit 16. Jump.

  The sub-OS here takes the form of a program that operates in a ROM-resident manner. That is, the sub OS secures only data necessary for the operation of the sub OS in the RAM area of the data storage unit 14, and executes the program with reference to the program storage unit 16 for portions other than the data of the sub OS.

  When the sub OS is executed, the trace execution flag 39 is turned OFF and the collection of the trace information is finished (step S100). Then, the sub-OS performs a function call to the processing described in the first embodiment after the OS is started, and determines the error factor of the high-level language program. That is, when the occurrence of an event is based on an error due to the destruction of data in the RAM area, the main OS of the data storage unit 14 generates an error in the area in the trace information storage unit 15 that stores the address where the illegal access was made. A value is acquired from the address D1 to determine whether an address error has occurred (step S110).

  If the sub OS determines that an address error has occurred, an error address registration process is performed (step S120). The error address registration process is performed by the same process as in the first embodiment shown in FIG. The error address registration process is performed based on the sub-OS in the third embodiment. Thus, the access address information added with function information (acquired information) is registered in the error cause candidate D6 of the trace information storage unit 15 together with the error cause (address error) (step S370).

  When it is determined by the sub-OS that no address error has occurred (No in step S110), or when the error address registration process (step S120) is completed, the access address of all the information stored in the error cause candidate D6, It is determined whether the program counter is within the range of the system program use area information D4 of the trace information. If the access address or the program counter is within the range of the system program use area information D4, it is determined that the cause of the error is the system program (main OS), and is outside the range of the system program use area information D4. In this case, it is determined that the error occurrence factor is the user program.

  Information indicating whether the error cause for each error cause item is a system program or a user program is added to each error cause candidate D6 (step S180). Error generation factor candidates D6 and trace information (D1 to D4) listed as error factor candidates in the program storage unit (standard ROM) 16 or a storage medium (CF card or the like) attached to the storage medium connection unit 19 An error occurrence factor determination file, which is a file in which the error cause candidate D6 is saved, and a trace data file, which is a file in which trace information is saved, are saved (step S190).

  Thus, when an error occurs, the error cause is determined by the sub-OS that does not include the script function block 21 for registering the user program, and therefore, the system program has removed unexpected external factors such as registration of the user program. The stable operation of the controller 10 is guaranteed.

In the third embodiment, when an error that prevents the main OS from operating normally is detected, the sub OS activation signal is turned on to execute the reboot.
When the reboot process of the main OS is executed or when a system WDT occurs, the sub OS activation signal may be turned on to execute the reboot.

  When the main OS detects the system WDT, the sub-OS activation signal is turned ON from the program registered in the interrupt vector, and the OS is rebooted. In addition, WDT is provided for each server function and error factor diagnosis function, and the main OS monitors whether the operation of these functions is normal, and turns on the sub-OS activation signal when WDT occurs. The OS may be rebooted.

  As described above, according to the third embodiment, even when a program error that causes the main OS to stop functioning is performed, the program is temporarily diagnosed by switching to a sub-OS that can operate in a stable state. It becomes possible.

  As described above, the controller according to the present invention is suitable for tracing a high-level language program.

1 is a system configuration diagram of a debug system including a controller according to a first embodiment. 2 is a block diagram illustrating a configuration of a controller according to Embodiment 1. FIG. 3 is a diagram showing functional blocks of a system program according to Embodiment 1. FIG. It is a flowchart which shows the operation | movement procedure of a controller. It is a flowchart which shows the procedure which registers an error address. It is a figure which shows the structure of trace information. It is a figure for demonstrating S / W trace information. It is a figure for demonstrating function call log information. It is a figure for demonstrating system program use area information. 4 is a diagram showing a memory map of a program storage unit according to Embodiment 1. FIG. 4 is a diagram showing a memory map of a data storage unit according to Embodiment 1. FIG. FIG. 6 is a block diagram illustrating a configuration of a controller according to a second embodiment. FIG. 10 is a diagram illustrating functional blocks of a main OS according to a third embodiment. FIG. 10 is a diagram illustrating functional blocks of a sub OS according to a third embodiment. 10 is a flowchart illustrating an operation procedure of the controller according to the third embodiment. FIG. 10 is a diagram showing a memory map of a program storage unit according to the third embodiment. FIG. 10 is a diagram showing a memory map of a data storage unit according to the third embodiment.

Explanation of symbols

1 Network equipment 2 Internet 3 Production system 9 CPU bus 10 Controller 11 CPU
DESCRIPTION OF SYMBOLS 12 Peripheral device connection part 13 Transmission / reception part 14 Data storage part 15 Trace information storage part 16 Program storage part 18 Data conversion part 19 Storage medium connection part 20 Storage medium I / F functional block 21 Script function block 22 Error factor diagnostic function block 23 Server Function block 24 Trace function block 25 System area storage function block 26 Switching function block 27 External device I / F function block 28 System program storage area 30 User program storage area 31 Sub OS activation signal 32 System program data area 33 System program storage area 34 User program use area 35 Sub OS data area 36 System memory / stack allocation area 37 Standard ROM area 38 Work RAM
39 Trace execution flag 40 Trace circuit 41 Power supply 42 Unit 45 PLC bus 52 Main OS data area 53 Main OS storage area 58 Main OS storage area 59 Sub OS storage area 100 Trace information

Claims (7)

In a controller that controls its own operation by a system program that is an operating system and controls a unit that operates an external device by a user program described in a high-level language program.
A data storage unit in which the system program and the user program are stored when the system program and the user program are executed;
A CPU that executes the system program and the user program by expanding the system program and the user program in the data storage unit;
With
The CPU
By executing the system program, it is accessed as program area information which is an address range of an area used by the system program in the data storage unit, and information used during execution of the system program and the user program Program information acquisition processing for acquiring operation information associated with an address, access data, and a program counter, and an error address of an error that occurred during execution of the system program and the user program,
A program analysis process for performing an error analysis of the system program and the user program based on the program area information, the operation information, and the error address by executing the system program;
Do
The program area information is acquired by the CPU before the user program is started, and the operation information is acquired by the CPU while its controller is operating,
In the program analysis process, the CPU stops acquiring the program area information, the operation information, and the error address, and then whether or not an address error has occurred based on the presence or absence of the error address. If an address error has occurred, the access address where the error has occurred is acquired from the error address, and operation information having the same access address as the access address where the error has occurred is acquired, and this acquisition is performed. A controller for determining whether an error occurrence factor is the user program or the system program based on whether the access address of the operation information is within the range of the program area information. The system program has a trace function for acquiring the operation information and the error address by tracing the operation of the user program in real time, and a system area storage function for acquiring the program area information.
The controller according to claim 1, wherein the CPU performs the program information acquisition process using a trace function and a system area storage function of the system program during the program information acquisition process. The operation information has a plurality of function call data in which a program counter, a function name, and an argument are associated,
As the program analysis process, the CPU acquires operation information having the same access address as the access address where the error has occurred, and acquires function call data having the same program counter as the program counter of the acquired operation information And determining whether the cause of the error is the user program or the system program based on whether or not the program counter of the acquired function call data is within the range of the program area information. The controller according to claim 1 or 2 . The operating system is
A main operating system that performs registration of the user program and control of the program analysis processing;
A sub-operating system for controlling the program analysis process;
Have
The CPU
In the program information acquisition process, the main operating system is executed, and when an error occurs during execution of the user program, the program analysis process is performed by switching from the main operating system to the sub operating system. The controller according to claim 1 or 2. The trace information storage part which memorize | stores the said error address which generate | occur | produced during execution of the said user program with the error analysis result of the said user program analyzed by the said program analysis process of Claim 1-4 further characterized by the above-mentioned. The controller according to any one of the above. The trace information storage unit stores the error analysis result as a web page,
It further includes a transmission unit that transmits the web page stored in the trace information storage unit to a network device that is connected to the trace information storage unit via a communication network and displays the web page. The controller according to claim 5 .   In a controller that controls its own operation by a system program that is an operating system and controls a unit that operates an external device by a user program described in a high-level language program.
  A data storage unit in which the system program and the user program are stored when the system program and the user program are executed;
  A CPU that executes the system program and the user program by expanding the system program and the user program in the data storage unit;
  An operation information acquisition circuit for acquiring operation information associated with an access address, access data, and a program counter as information used during execution of the system program and the user program;
  With
  The CPU
  By executing the system program, program area information that is an address range of an area used by the system program in the data storage unit, and an error address of an error that occurs during execution of the system program and the user program And a program information acquisition process for acquiring
  A program analysis process for performing an error analysis of the system program and the user program based on the program area information, the operation information, and the error address by executing the system program;
  Do
  The program area information is acquired by the CPU before the user program is started, and the operation information is acquired by the operation information acquisition circuit while its own controller is operating,
  During the program analysis process, the operation information acquisition circuit stops acquiring the operation information and the CPU stops acquiring the program area information and the error address, and then the CPU detects the error address. Whether or not an address error has occurred, and if an address error has occurred, obtain the access address where the error occurred from the error address, and The operation information having the same access address is acquired, and based on whether or not the access address of the acquired operation information is within the range of the program area information, whether the error occurrence factor is the user program or the system program A controller characterized by determining whether or not there is.

Images