JP2018041130A - Method for acquiring execution time data on on-vehicle control program and on-vehicle control device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To minimize an amount of increase in a CPU load and an amount of change in original processing timing caused by processing itself especially when execution time data on short-cycle processing is created/transmitted in order for operation verification of an on-vehicle control program.SOLUTION: An on-vehicle control device includes: a CPU for executing an on-vehicle control program including a plurality of processes; and a DMAC including a plurality of channels and capable of DMA transfer, without using the CPU, of data in an address space which the CPU can access. The on-vehicle device executes at least one of creation of execution time data and transmission of the execution time data by DMA transfer without using the CPU.SELECTED DRAWING: Figure 1

Description

  The present invention obtains runtime data for monitoring the execution timing or execution content of each of the plurality of processes for the purpose of performing operation verification of the in-vehicle control program having a plurality of processes. The present invention relates to an acquisition method and an in-vehicle control device.

  In recent vehicle-mounted control devices, the scale of the control program has increased, and the structure has become complicated and diversified. Along with this, the CPU that executes the control program also adopts a configuration in which the architecture is complicated and a cache memory is provided for higher functionality and higher speed. This makes it difficult to predict the execution result of the control program.

  In addition to these hardware changes, there are also software changes. In order to reduce the development cost of the control program, it is necessary to improve the reusability of the software. As one means, the software reusability is improved by adopting a real-time operating system (hereinafter referred to as “RTOS”) as a basic part of the control program.

  A basic execution unit in the RTOS is a task, which is normally created so as to operate in plural on the RTOS, and each task is set to operate based on the priority. The task priority is evaluated by a scheduler in the RTOS, and a CPU is assigned to a task with a higher priority.

  The behavior of an RTOS scheduler based on such priorities is often different from the behavior of a conventional scheduler that does not use RTOS. Therefore, when RTOS is newly adopted, the execution timing of each process in the control program may change, for example, the timing at which the process starts and ends. As a result, the control program may not operate correctly.

  In addition, even in the case of differential development of products using the same RTOS without using a new RTOS, due to factors such as changing the microcomputer, changing the specifications of the control program, adding functions, etc. The execution timing of each process changes.

  In the hardware and software changes as described above, it is difficult to predict the behavior or execution timing of each process in the control program with sufficient accuracy in advance. Even if it is considered that the prediction can be made with high accuracy, it is necessary to confirm that the prediction is appropriate.

  For this reason, it is necessary to confirm that there is no problem in the behavior and execution timing of the control program while operating the in-vehicle control device and the control program under actual use conditions.

  As an example of means used for confirmation, a real-time trace function is known. As a specific example, for example, “Super Trace Probe” commercialized by Green Hills Software is cited, and in the following description, the technology corresponding to “Super Trace Probe” is referred to as Conventional Technology 1. To do.

  This prior art 1 shows the execution timing of each process from the on-chip debugger during execution of the control program and the execution contents at the time of the process execution by connecting to an on-chip debugger provided in the microcomputer via a dedicated pin. Real-time trace function is realized by acquiring variable values. Here, the execution timing of each process, the value of a variable indicating the execution content at the time of executing the process, and the like will be referred to as “execution time data” in the following description.

  According to the prior art 1, it is possible to obtain execution data of the CPU of the microcomputer, such as an address executed by the CPU and its time. Therefore, by transferring the runtime data to the PC and analyzing and visualizing it on the PC, it is possible to know which process of the program was executed when.

  The prior art 1 stores runtime data in a RAM called a trace memory or a trace buffer provided in an on-chip debugger. Further, in the prior art 1, when the RAM becomes full, the accumulation of the runtime data is terminated, or the acquisition of the runtime data is continued while overwriting the old data with the new data.

  For example, an in-vehicle control device that controls a motor drive inverter or a lighting drive converter may require a plurality of short cycle processes such as several tens to several hundreds of microseconds for the control. In the following description, the in-vehicle control device that performs such control is simply referred to as “ECU”, and the short cycle processing described above is referred to as “short cycle processing”.

  When such short-cycle processing execution data is acquired by the prior art 1, there is a problem that the trace buffer becomes full before the amount of data that can confirm the behavior of the control program is obtained.

  For example, consider a case in which 20 bytes of runtime data are transmitted to a PC at a cycle of 100 μs. In this case, a trace buffer of 200 kbytes per second is consumed, and generally the capacity of the trace buffer provided in the on-chip debugger is insufficient. For this reason, it is necessary to use an expensive debugging device having a function of storing data while adding a large-capacity trace buffer outside the on-chip debugger and communicating with the on-chip debugger at high speed.

  Further, when using the prior art 1, it is necessary to perform wiring in order to communicate with the on-chip debugger of the microcomputer. However, in the development of the ECU, the ECU at the time of performing the test is incorporated in the apparatus, and it is often difficult to extend the signal line for performing high-speed communication to the outside of the apparatus.

  Therefore, as another means for confirming the control program while operating under actual use conditions, there is, for example, Tracerizer for FreeRTOS (see, for example, Non-Patent Document 1). This Tracealizer for FreeRTOS incorporates means for providing runtime data into the required location in the control program, and transfers the runtime data to the PC using the external communication interface provided in the microcomputer when the control program is executed. It is to be visualized.

  FIG. 10 is a flowchart showing a procedure for creating runtime data at the start and end of each process when the conventional runtime data acquisition method in Non-Patent Document 1 is applied. FIG. 11 is a flowchart showing a procedure for transferring runtime data to the external communication interface when the conventional runtime data acquisition method in Non-Patent Document 1 is applied.

  According to Non-Patent Document 1, as illustrated in FIG. 10 and FIG. 11, a buffer for storing data at the time of execution is provided in a RAM provided in the microcomputer, and when the RAM buffer is filled with data, the microcomputer Means are provided for transmitting data to a PC.

  The process for executing FIG. 11 is usually executed using the CPU idle time at a timing different from the process for executing FIG. Therefore, when the RTOS is used, the process shown in FIG. 11 is executed as a task having the lowest priority so as not to affect the original control process as much as possible.

  By limiting the runtime data provided from the microcomputer to a part, the amount of runtime data stored in the RAM buffer per unit time can be made smaller than the data transfer amount of the external communication interface. In such a case, the RAM buffer for accumulating runtime data is divided into two areas, and while the process in FIG. 11 is transferring one area, the process in FIG. Data can be accumulated. By performing such parallel processing, it is possible to continue to provide runtime data without delay.

Traceryzer for FreeRTOS, Internet <URL: http://percepio.com/docs/FreeRTOS/manual>

However, the prior art has the following problems.
Consider a case in which the execution timing is confirmed using Non-Patent Document 1 in an ECU that controls an inverter and converter for motor control. In this case, for example, when a certain process starts and ends as runtime data, as shown in steps S1003 to S1005 in FIG. 10, a number that can identify the start of the process and the end of the process are displayed. It is necessary to store the identifiable number in the RAM buffer together with the time when each process is executed.

  In the following description, a number that can identify which process has started is referred to as a “process start identification number”, and a number that can identify which process has ended is referred to as “process It will be referred to as an “end identification number”.

  The runtime data needs to be created when each process of the control program starts and ends. As an example of the process of acquiring the process execution time in the execution time data as in step S1003, the control program counts the hardware timer provided in the microcomputer at a period at which sufficient time resolution is obtained. Keep it running at all times.

  In addition, when starting or ending each process, the control program reads the count value of the hardware timer at that time, adds a process start identification number or a process end identification number to this value, and stores it in the RAM buffer. The process to be added to is performed at the beginning and end of each task or process.

  According to the data creation processing example described above, the control program needs to add the count value of the created hardware timer and the processing start identification number or the processing end identification number to the RAM buffer. Consider a case where such a creation process is applied to, for example, both a task executed in an interrupt enabled state and a task capable of interrupting this task.

  In such a case, immediately before the former task stores the runtime data at the head of the RAM buffer, that is, immediately before executing step S1004, the latter task is started by interrupting it. Is added to the top of the RAM buffer.

  When such a situation occurs, after the latter task ends, the former task resumes processing, and the execution time data of the latter task is added to the top of the RAM buffer. Is overwritten and disappears.

  In order to avoid such loss of runtime data due to overwriting, task processing that adds runtime data to the RAM buffer should not be interrupted by other task processing that similarly adds runtime data to the buffer. An operation for disabling the interrupt is required before adding the run-time data to the RAM buffer (corresponding to step S1001), and after the data is added to the RAM buffer, the interrupt prohibition is canceled (corresponding to step S1006).

  In particular, the task processing of a control program using RTOS often sets the CPU operation mode to the user mode. Accordingly, it is necessary to execute the interrupt prohibition and prohibition cancel processing in this case after switching the operation mode of the CPU from the user mode to the supervisor mode, and then return to the user mode again. For this reason, interrupt prohibition and prohibition cancellation may occupy much of the CPU time required for execution-time data acquisition.

  As described above, the process of adding data at the time of execution accompanied by the interrupt prohibition process and the prohibition cancellation process itself adds a certain processing time to the CPU. For this reason, when the execution timing is acquired by the method of Non-Patent Document 1, there is a problem that the original processing timing of the control program is significantly changed.

  In particular, when the above-described execution time data addition process is performed in the short-cycle process necessary for the ECU, the ratio of the execution time data acquisition process to the originally executed process increases. For this reason, this problem is serious.

  Further, when the original processing of the control program is already operating under a high CPU load, low priority processing is executed for the CPU time that is additionally consumed for acquisition of runtime data. The CPU time cannot be secured, and the control program may not operate correctly.

  Furthermore, under a high CPU load, there is a problem that a sufficient time cannot be secured for executing the runtime data transmission process of FIG.

  The present invention has been made to solve the above-described problems. In particular, when creating and transmitting execution data of short-cycle processing, the amount of increase in CPU load caused by the processing itself and the original amount are reduced. In-vehicle control program execution-time data acquisition method capable of continuously acquiring data necessary for confirming ECU behavior and operation timing with a minimum RAM buffer while minimizing the amount of change in processing timing It aims at obtaining a vehicle-mounted control apparatus.

  An in-vehicle control program runtime data acquisition method according to the present invention includes a CPU for executing an in-vehicle control program having a plurality of processes, and data in an address space having a plurality of channels and accessible by the CPU. DMAC that is a direct access memory controller that can perform DMA transfer without using it, a hardware timer that can acquire a count value by DMA transfer, an in-vehicle control program, and a ROM that can be accessed by DMA transfer; When executing an in-vehicle control program in an in-vehicle control device equipped with a RAM accessible by DMA transfer and an external communication interface for data communication with an external device, the execution timing or execution contents of each of a plurality of processes are monitored. And sending runtime data to do An in-vehicle control program execution time data acquisition method for performing at least one of creation of execution time data and transmission of execution time data by DMA transfer without using a CPU. When the execution time data is created by DMA transfer, the time data is collected by reading the count value of the hardware timer by the first DMA transfer by the first channel when the execution time data is acquired. Then, after collecting the time data, the second DMA transfer by the second channel reads out the identification number for identifying the plurality of processes stored in the ROM in advance according to the execution order of the plurality of processes, and the time data By collecting the identification numbers corresponding to each, the runtime data is created and the runtime data is transmitted by DMA transfer. In this case, after execution time data corresponding to a predetermined control cycle is created, the execution time data for one control cycle is obtained by DMA transfer using a channel other than the first channel and the second channel. Is transmitted to the external device via the external communication interface.

  In addition, the in-vehicle control device according to the present invention includes a CPU that executes an in-vehicle control program having a plurality of processes, and a plurality of channels, and data in an address space that can be accessed by the CPU without using the CPU. DMAC, which is a direct access memory controller that can perform DMA transfer, a hardware timer that can acquire a count value by DMA transfer, an in-vehicle control program, a ROM that can be accessed by DMA transfer, and access by DMA transfer And an external communication interface that performs data communication with an external device. When executing an in-vehicle control program, creation of runtime data for monitoring the execution timing or execution content of each of a plurality of processes In-vehicle control device that performs transmission, and DMAC executes When executing at least one of data creation and execution-time data transmission by DMA transfer without going through the CPU, the execution-time data is acquired when the execution-time data creation is performed by DMA transfer. At this point, time data is collected by reading the count value of the hardware timer by the first DMA transfer by the first channel, and after collecting the time data, a plurality of times are obtained by the second DMA transfer by the second channel. Reading the identification number for identifying a plurality of processes stored in the ROM in advance according to the execution order of the processes, collecting the identification numbers corresponding to the time data, and creating the runtime data, When transmission is executed by DMA transfer, runtime data corresponding to one predetermined control cycle is created. Later, the DMA transfer by the first channel and a second channel other than the channel, the run-time data of the control one cycle, and transmits to the external device via the external communication interface.

  According to the present invention, at least one of creation of runtime data and transmission of runtime data is performed by DMA transfer without using a CPU. With such a configuration, when DMA transfer is applied to the creation of runtime data, the creation of runtime data by the CPU becomes unnecessary, and the CPU time required for creating runtime data is minimized. It can be suppressed. Further, when DMA transfer is applied to transmission of runtime data, the CPU does not need to transfer runtime data to the external communication interface, and the CPU time required for data transfer can be minimized. As a result, especially when creating / transmitting execution data for short-cycle processing, the amount of increase in CPU load caused by the processing itself and the amount of change in the original processing timing are minimized, and the behavior and operation timing of the ECU are reduced. It is possible to obtain an on-vehicle control program execution time data acquisition method and an on-vehicle control device capable of continuously acquiring data necessary for confirmation with a minimum RAM buffer.

In the vehicle-mounted control apparatus of Embodiment 1 of this invention, it is a figure which shows an example of a structure of ECU which performs control of control object, and produces and transmits transmission data at the time of execution. It is the figure which illustrated each process of the program stored in ROM in Embodiment 1 of this invention. It is the figure which illustrated the execution timing of the process memorize | stored in ROM in Embodiment 1 of this invention. It is the figure which illustrated the identification number table | surface provided in ROM in Embodiment 1 of this invention. It is the figure which illustrated the runtime data storage part provided in RAM in Embodiment 1 of this invention. It is the flowchart which showed the process sequence of the initialization process in ECU which concerns on Embodiment 1 of this invention. FIG. 4 is a table showing an example of initial settings of the first DMA channel and the second DMA channel in the ECU according to the first embodiment of the present invention. FIG. 4 is a table showing an example of initial settings of the third to sixth DMA channels in the ECU according to the first embodiment of the present invention. It is the flowchart which showed the process sequence in the time of the data acquisition at the time of execution in ECU which concerns on Embodiment 1 of this invention. It is the flowchart which showed the procedure which produces runtime data at the time of the start and completion | finish of each process at the time of applying the conventional runtime data acquisition method in a nonpatent literature 1. It is the flowchart which showed the procedure which transfers the runtime data at the time of applying the conventional runtime data acquisition method in a nonpatent literature 1 to an external communication interface.

    Hereinafter, preferred embodiments of an in-vehicle control program execution data acquisition method and an in-vehicle control device according to the present invention will be described with reference to the drawings. More specifically, in the following embodiment, an example in which the timings at which the four periodic processes in the control program start and end are acquired as runtime data will be described in detail. In all the drawings, the same reference numerals are given to the same and corresponding parts in the drawings.

Embodiment 1 FIG.
FIG. 1 is a diagram illustrating an example of a configuration of an ECU that executes control of a control target and executes creation and transmission of runtime data in the in-vehicle control device according to the first embodiment of the present invention. The ECU 1 shown in FIG. 1 includes an input circuit 2, a microcomputer 3, and a drive circuit 11. The ECU 1 controls the motor 12 and is connected to an external communication line 13.

  The microcomputer 3 in the ECU 1 includes an I / O (input / output interface) 4, a CPU 5, a ROM 6, a RAM 7, a timer 8, a DMAC (Direct Memory Access Controller) 9, and an external communication interface 10.

  The input circuit 2 reads an external signal or a sensor signal from the motor 12 to be controlled as a voltage. The I / O 4 takes in the voltage read by the input circuit 2 into the microcomputer 3 and outputs a control signal to the drive circuit 11.

  The drive circuit 11 drives the motor 12 in the first embodiment. The external communication interface 10 is connected to a general communication line used in the ECU, such as CAN, CAN FD, FlexRay, Ethernet (registered trademark), or the like.

  In the first embodiment, an example in which the ECU 1 drives the motor 12 is shown, but the configuration of the ECU 1 to which the present invention can be applied is not limited to this example. For example, when the drive circuit 11 is a converter and the object to be controlled is changed from the motor 12 to the LED and the illuminance control of the LED is performed, short cycle processing may be necessary. The invention according to the first embodiment can be effectively applied.

  Further, the external communication interface 10 is not limited to any one described above. For example, a case where a combination of the above-described configurations is applied or a case where a plurality of the same communication methods are used may be considered. When wiring can be added to the ECU 1, various serial communications (UART, SPI, etc.) included in the microcomputer 3, general-purpose digital input / output (GPIO), etc. can be applied as the external communication interface 10.

  In the first embodiment, an example of controlling a motor is shown. For this reason, although omitted in FIG. 1, in the I / O 4, when the sensor voltage is taken into the microcomputer 3, the AD converter is used, and when the control output is performed to the drive circuit 11, the PWM is performed. It is assumed to be used.

  However, the present invention is not applicable only to the first embodiment. For example, even if the factor of the control processing is a simple timer interrupt, the present invention can be effectively applied as the processing cycle is shorter in view of the processing capability of the microcomputer.

  The CPU 5 is a microprocessor using a known architecture, and can execute a control program 60 stored in the ROM 6. The CPU 5 may be a single core or a plurality of cores as long as it can access the RAM 7, the timer 8, and the DMAC 9.

  The ROM 6 can be read from each channel of the CPU 5 and the DMAC 9 and includes a control program 60. FIG. 2 is a diagram illustrating each process of the program 60 stored in the ROM 6 according to the first embodiment of the present invention. As the processing of the control program 60, as illustrated in FIG. 2, the initialization processing 61, the periodic interrupt processing 62 to 63, the short cycle processing 64 executed in a short cycle, and the cycle longer than the short cycle processing 64 are executed. Long cycle processing 65 is stored. In the following description, unless otherwise specified, the processing is simply expressed as “processing 61 to 65”.

  As the fixed value data of the control program 60, as exemplified in FIG. 2, an identification number table 66, a sixth DMA permission value 67, and a transmission request instruction value 68 are stored.

  FIG. 3 is a diagram illustrating the execution timing of the processes 62 to 65 stored in the ROM 6 according to the first embodiment of the present invention. In the first embodiment, it is assumed that the processes 62 to 65 are statically designed so as to operate like the timing chart illustrated in FIG. Further, the priority of the processing is processing 62> processing 63> processing 64> processing 65.

  In FIG. 3, the rising edge of the timing chart of each of the processes 62 to 65 means the start or continuation of the process, and the falling edge means the interruption or end of the process. Also, assume that the processing cycles are 50 μsec for processing 62 to 63, 100 μsec for short cycle processing 64, and 1 ms for long cycle processing 65.

  In FIG. 3, the behavior of the processes 62 to 65 will be described along the passage of time. The process 62 starts, the process 62 ends, and the process 64 starts. Next, the process 64 is interrupted due to the start of the process 63 during execution, and the process 63 starts. Next, the process 63 ends, the process 64 resumes, the process 64 ends, and the process 65 starts.

  Next, the process 65 is interrupted to start the process 62 during execution, and the process 62 starts. Next, the process 62 ends, and the process 65 resumes. Next, the process 65 is interrupted because the process 63 starts during execution, the process 63 starts, the process 63 ends, the process 65 resumes, and the process 65 ends.

  Regarding the processing 62 to 64, after the two cycles of the above-described processing 62 are executed, that is, after 100 μsec has elapsed, the above-described behavior is repeated from the point where the processing 62 starts again. On the other hand, since the processing period of the processing 65 is 1 millisecond, the processing 62 to 64 starts and ends at the timing shown in FIG. 3 every time the behavior of 100 μs shown in FIG. 3 is repeated 10 times. And

  In the first embodiment, as an example, a 1-millisecond period starting from the first start time of the process 62 is regarded as one cycle of control. However, it is not necessary to take one cycle of control as described above. For example, a period of 100 μs starting from the first start time of the process 62 may be regarded as one cycle of control by the processes 62 to 64.

  Next, the identification number table 66 will be described. FIG. 4 is a diagram illustrating an identification number table 66 provided in the ROM 6 according to the first embodiment of the present invention. As illustrated in FIG. 4, the identification number table 66 according to the first embodiment includes an identification number table 660 to 663 for the processes 62 to 65 and an invalid identification number 664.

  The identification number table 660 alternately holds a process start identification number that can identify the start of the process 62 and a process end identification number that can identify the end of the process 62. Although omitted in FIG. 4, the identification number tables 661 to 663 have the same configuration as the identification number table 660 except that the stored processing start identification numbers and processing end identification numbers are different. ing.

  The processes 62 to 65 start and end for each cycle. For this reason, a pair of process start identification numbers and process end identification numbers are referred to during one cycle of each process.

  The length of the identification number table for each process is determined from the relationship between the above-described control period and the process periods of the processes 62 to 65, and is a fixed length. For example, in the first embodiment, the period of the process 62 is 50 μs, and one period of control of the control program is 1 millisecond. Accordingly, the process 62 is executed 20 times within 1 millisecond, and the total number of the start and end is 40 times. Therefore, the length of the identification number table 660 is 40.

  Similarly, the lengths of the identification number tables 661 to 663 corresponding to the processes 63 to 65 are also calculated from the relationship between one control cycle and each process cycle, and each has a fixed length.

  The RAM 7 can be accessed from each of the DMA channels of the CPU 5 and the DMAC 9. FIG. 5 is a diagram illustrating a runtime data storage unit provided in the RAM 7 according to the first embodiment of the present invention. In the first embodiment, as illustrated in FIG. 5, as the execution time data storage unit, as shown in FIG. 5, the identification number storage array 711 of the interrupt process 62, the corresponding time storage array 712, and the periodic processes 63 to 65 In this example, identification number storage arrays 721, 731, and 741 and time storage arrays 722, 732, and 742 corresponding to these are secured.

  Similar to the identification number tables 660 to 663 described with reference to FIG. 4, the runtime data storage units 71 to 74 corresponding to the processes 62 to 65 each have one control cycle and each processing cycle of the processes 62 to 65. The fixed length.

  For example, in the first embodiment, the period of the process 64 is 100 μs, and one period of control of the control program is 1 millisecond. Therefore, the process 64 is executed 10 times within 1 millisecond, and the number of elements in the identification number storage array 731 and the time storage array 732 is 10 respectively.

  Similarly, the storage arrays 711, 721, and 741 of the runtime data storage units 71, 72, and 74 are respectively 20, 20, and 2 from the relationship between one control cycle and the processing cycle of each processing. Calculated. Therefore, the total number of elements in each array in the runtime data storage unit 70 is 104 in this embodiment. In the first embodiment, 1 byte is assigned to each element, which is 104 bytes.

  The arrangement order of the array units in the runtime data storage unit 70 is arbitrary. However, the arrangement units are arranged adjacent to each other so that the runtime data storage unit 70 is not divided into a plurality of regions.

  The timer 8 is a hardware timer composed of a plurality of channels. The timer 8 is used to detect the time when the RTOS scheduler or the conventional scheduler starts processing. In the first embodiment, the timer 8 generates a time stamp indicating the time when the runtime data is acquired. Also used to do.

  The DMAC 9 is a hardware function composed of a plurality of DMA channels, and can transfer data in an address space accessible by the CPU 5 without using the CPU 5. Further, the DMAC 9 can set in advance whether the internal or external hardware factor of the microcomputer 3 or a software instruction is the timing for starting the execution of the transfer.

  When setting the hardware factor, it is possible to specify from among the hardware factors that the DMAC 9 can handle. In addition to being able to set various interrupt requests from peripheral functions provided in the microcomputer, it is possible to set completion of DMA transfer processing for another DMA channel in the DMAC 9 as a cause of hardware that the DMAC 9 can handle. It is.

  Each DMA channel can specify the transfer count, and when the final DMA transfer is completed, the transfer source address, transfer destination address, and transfer count are reset to the values specified in advance. Has a reload function.

  Each DMA channel has a single transfer mode and a block transfer mode, and either one can be selected and set. The single transfer mode is a transfer mode in which the number of transfers is 1 per DMA cycle (that is, data read from the transfer source and data write to the transfer destination). In the block transfer mode, the DMA cycle is repeated until transfer of a preset continuous data area (block transfer size) is completed, and the transfer count is set to 1 when transfer of all data in the data area is completed. Transfer mode. In the first embodiment, only the DMA channel that is used in the block transfer mode is clearly indicated, and the DMA channel that is not specified for the transfer mode is used in the single transfer mode.

  Each DMA channel has a register for permitting or prohibiting DMA transfer, and a permission state or a prohibition state can be set by the CPU 5 and the DMAC 9. In addition, each DMA channel can set whether to prohibit the subsequent DMA transfer or continue the permitted state when the last DMA transfer is completed.

  The external communication interface 10 transmits and receives information between the microcomputer 3 and the outside. When the data transmission / reception is completed, the external communication interface 10 can notify that the transmission / reception is completed as an interrupt factor to the CPU 5. Further, the external communication interface 10 can notify the DMAC 9 of completion of transmission / reception as a hardware factor, and can start transfer of each DMA channel.

  Next, a processing procedure example of the initialization processing 61 according to the present invention in the control program 60 executed by the ECU 1 will be described. FIG. 6 is a flowchart showing a processing procedure of initialization processing 61 in ECU 1 according to Embodiment 1 of the present invention.

  First, in step S601, the ECU 1 initializes the timer 8 for acquiring the processing time and starts counting. Here, the count period of the hardware timer is set so as to obtain a sufficient time resolution with respect to the processing time.

  Next, Steps S603 to S605 are repeated to initialize the first DMA channel and the second DMA channel necessary for each process. FIG. 7 summarizes an example of the initial setting of the first DMA channel and the second DMA channel in the ECU 1 according to the first embodiment of the present invention in a table format. As illustrated in FIG. 7, the ECU 1 sets each DMA channel for each of the processes 62 to 65.

  The first DMA channel and the second DMA channel are always used for setting the permission state. Further, each first DMA channel corresponding to the processing 62 to 65 sets the transfer source address to an address from which the count value of the timer 8 can be read, and is fixed without being incremented when each transfer is completed. And

  The transfer destination address is set at the head of the time storage arrays 712, 722, 732, and 742 corresponding to each process, and incremented each time transfer of each DMA channel is completed, that is, the transfer destination address is set to the next array. Set to point to the element.

  In the first embodiment, the processing cycle of processing 62 and processing 63 is 50 μsec, the processing cycle of processing 64 is 100 μsec, the processing cycle of processing 65 is 1 msec, and the control cycle is 1 msec. From this, the transfer count of the process 62 and the process 63 is set to 40 times, which is the sum of the start count and the end count, because the process starts and ends 20 times in one control cycle. The same calculation is performed, and the number of first DMA transfers in process 64 is set to 20, and the number of first DMA transfers in process 65 is set to 2.

  Each time the first DMA channel of each process completes the transfer, the second DMA channel corresponding to each process is started. Further, when the final transfer of the above transfer count is completed, the transfer destination address and the transfer count are reloaded.

  Each of the second DMA channels corresponding to the processes 62 to 65 sets the transfer source address to the head of the identification number table 660 to 663 of each process, and is set to increment when each DMA transfer is completed. To do.

  The transfer destination address is set at the head of the identification number storage arrays 711, 721, 731 and 741 corresponding to each process, and is set to be incremented when each DMA transfer is completed.

  The number of transfers is set to the same value as the first DMA corresponding to each process.

  When the final DMA transfer of the second DMA channel of each process is completed, the transfer source address, the transfer destination address, and the transfer count are reloaded.

  In the first embodiment, the end of the last process 63 in one cycle of control is the last execution time data stored in the execution time data storage unit 70. Therefore, the second DMA channel corresponding to the process 63 is set so that the third DMA channel is started when the final transfer of the second DMA corresponding to the process 63 is completed.

  Returning to the description of the flowchart of FIG. 6, the third to sixth DMA channels are initialized in step S606 after step S605. FIG. 8 summarizes an example of the initial setting of the third DMA channel to the sixth DMA channel in the ECU 1 according to the first embodiment of the present invention in a table format. Each DMA channel is set, for example, as illustrated in FIG.

  Only the sixth DMA channel is set to prohibit the channel after the transfer is completed, and the other channels are always used for setting the permission state.

  The third DMA channel is the first DMA channel that transfers the contents of the runtime data storage unit 70 for one cycle of control to the external communication interface 10. Therefore, the transfer source address of the third DMA channel is set in the runtime data storage unit 70, and the transfer destination address of the third DMA channel is set in the transmission buffer of the external communication interface 10.

  The third DMA channel performs block transfer once. Therefore, the block transfer size is set to the transmission buffer length of the external communication interface 10 and the transfer count is set to 1.

  For example, when the external communication interface 10 is CAN FD and the data length of the transmission frame can be maximized, the block transfer size is set to 64 bytes. When each transfer is completed, the transfer source address and the transfer destination address are set to be incremented.

  When the third DMA transfer is completed, the transfer source address and the transfer destination address are reloaded to initialization values, and the fourth DMA channel is set to start.

  The fourth DMA channel executes DMA transfer for setting a value permitting the transfer to the sixth DMA channel in order to set the sixth DMA channel to the permitted state.

  The transfer source address is set to the sixth DMA permission value 67, and the transfer destination address is set to the transfer permission register of the sixth DMA channel. The transfer source and transfer destination addresses at the completion of each transfer are set to be fixed.

  The transfer number of the fourth DMA channel is set to one, and when the DMA transfer is completed, the transfer number is reloaded and the fifth DMA channel is started.

  The fifth DMA channel performs DMA transfer for requesting transmission of data transferred to the transmission buffer of the external communication interface 10 by the third DMA transfer.

  The transfer source address is set in the transmission request instruction value 68 and the transfer destination address is set in the transmission request register of the external communication interface 10. The transfer source and transfer destination addresses at the completion of each transfer are set to be fixed.

  The number of transfers of the fifth DMA channel is set to one, and the number of transfers is set to be reloaded when the DMA transfer is completed.

  The sixth DMA channel is started by the hardware factor when the data transmission requested to the external communication interface 10 by the fifth DMA transfer is completed, and the third DMA channel is not yet transmitted to the runtime data storage. The data of the unit 70 is transferred.

  The start of the sixth DMA channel is a hardware factor, and the factor is set to completion of transmission of the external communication interface 10.

  The transfer source address of the sixth DMA channel is set in the data location of the runtime data storage unit 70 that is not transferred by the third DMA channel. For example, according to the setting example of the third DMA channel described above, it is the top +64 of the runtime data storage unit 70.

  The transfer destination address of the sixth DMA channel is set in the transmission buffer of the external communication interface 10. The transfer source and transfer destination addresses are set to be incremented.

  The sixth DMA channel is used in the block transfer mode. Therefore, the block transfer size is set to the transmission buffer length of the external communication interface 10. In addition, as the number of transfers, the number of block transfers required to complete transmission of all untransmitted data in the runtime data storage unit 70 is set. In the first embodiment, the runtime data storage unit 70 is 104 bytes, and according to the above setting example of the third DMA channel, transfer of 64 bytes of the DMA channel is completed at the start of the DMA channel. doing. For this reason, the remaining is 40 bytes, which is a size that can be included in the transmission buffer of the external communication interface 10, so the number of transfers is set to 1.

  When the sixth DMA transfer is completed, the number of transfers is reloaded, the fifth DMA channel is started, and the channel is set to the prohibited state.

  Next, operations for the start and end of each process of the first to sixth DMA channels in the first embodiment will be described in detail.

  When the process 62 is started due to an interrupt factor, the transfer by the first DMA channel is started by software. The transfer by the first DMA channel is started, the value of the counter of the timer 8 is read and stored in the first element of the time storage array 712, and then the transfer destination address is incremented and the location of the second element of the time storage array 712 To start the second DMA channel.

  The second DMA channel reads the process 62 start number stored at the head of the identification number table 660 of the interrupt process 62 and stores it in the first element of the identification number storage array 711. Thereafter, the transfer source address is incremented to be the location of the process 62 end identification number which is the second element of the identification number table 660 of the interrupt process 62, the transfer destination address is incremented, and the second element of the identification number storage array 711 is obtained. It is assumed that

  At the end of process 62, the first DMA channel is started from software. In the first DMA transfer, the value of the counter of the timer 8 is read out and stored in the second element of the time storage array 712, as in the case of starting the process 62. Thereafter, the transfer destination address is incremented to be the third element location of the time storage array 712, and the second DMA channel is started.

  The second DMA channel reads the process 62 end identification number, which is the second element of the identification number table 660 of the interrupt process 62, and stores it in the second element of the identification number storage array 711. Thereafter, the transfer source address is incremented to be the location of the process 62 start identification number, which is the third element of the identification number table 660 of the interrupt processing 62, and the transfer destination address is incremented to be the location of the third element of the identification number storage array 711. And

  The first DMA transfer and the second DMA transfer at the start and end of the processing 62 are repeated until the number of transfers set for each DMA channel is completed. After the completion of the final DMA transfer, the transfer destination address and the transfer count of the first DMA channel are set to the address of the first element of the time storage array 712 and 40 times, that is, to the value at the completion of initialization. It is automatically reset by the channel reload function.

  Similarly to the first DMA channel, the second DMA channel is automatically initialized by the DMA channel reload function after the final DMA transfer, and the transfer source address, transfer destination address, and transfer count are each completed. Reset to hour value.

  In the processes 63 to 65, the start and end methods of the first DMA transfer and the second DMA transfer are the same as those in the process 62. In the first embodiment, the final second DMA transfer executed at the end of the process 63 is the second DMA transfer executed last in one cycle of control. Therefore, the completion of the DMA transfer is set to start the third DMA transfer.

  When processing is started by an interrupt factor as in processing 62 and processing 63 and the first DMA transfer can be started by an interrupt factor, the first DMA transfer start factor is The first DMA transfer can be started without instructing the start of the first DMA transfer by software by setting the interrupt factor for starting the processes 62 and 63.

  If both software and hardware cannot be set for the DMA transfer start factor in the first DMA channel, a first 1 'DMA start by hardware factor is prepared in addition to the first DMA started by software. However, the first ′ DMA transfer and the second DMA transfer may be executed at the start of the process, and the first DMA transfer and the second DMA transfer may be executed at the end of the process.

  The third DMA channel performs block transfer of data of the length of the transmission buffer possessed by the external communication interface 10 from the head of the runtime data 70 to the transmission buffer.

  When the third DMA transfer is completed, the transfer source address, transfer destination address, and transfer count of the third DMA channel are automatically reset to the values at the completion of initialization by the reload function of the DMA channel. 4 DMA channel transfer is started.

  The fourth DMA channel transfers a sixth DMA permission value 67 for changing the sixth DMA channel to be started later to a permission state from the ROM 6 to the channel transfer permission register of the sixth DMA channel.

  When the completion of the fourth DMA transfer is completed, the number of transfers of the fourth DMA channel is automatically reset to the value at the completion of initialization by the reload function of the DMA channel, and the transfer of the fifth DMA channel is started. .

  The fifth DMA channel transfers the transmission request instruction value 68 to the external communication interface 10 from the ROM 6 to the transmission request register of the external communication interface 10.

  When the fifth DMA transfer is completed, the transfer number of the fifth DMA channel is automatically reset to the value at the completion of initialization by the reload function of the DMA channel.

  The sixth DMA channel starts with a hardware factor of completion of data transmission of the external communication interface 10. The sixth DMA channel takes over the data transfer from the untransferred address in the third DMA transfer of the runtime data storage unit 70, and blocks the data of the length of the transmission buffer of the external communication interface 10 in the transmission buffer. Forward.

  Each time the sixth DMA transfer is completed once, transfer of the fifth DMA channel is started and a transmission request is made to the external communication interface 10. When the sixth DMA transfer is completed a specified number of times, the sixth DMA channel is disabled. Therefore, the sixth DMA channel is not started due to the completion of the transmission from the external communication interface 10 this time.

  As described above, the first DMA transfer and the second DMA transfer prepared for each process are executed at the timing when the processes 62 to 65 start and end the processes. This eliminates the need to create and store the contents of the runtime data storage unit 70 by program processing at the start and end of each process, and it is only necessary to start the first DMA instead.

  Here, when the start of the process is a hardware factor, the factor is set as the first DMA start condition so that the program instructs the start of the first DMA at the start of the process. Is also unnecessary.

  FIG. 9 is a flowchart showing a processing procedure for obtaining runtime data in ECU 1 according to Embodiment 1 of the present invention. The processing illustrated in FIG. 10 that is necessary in Non-Patent Document 1 is one instruction to start the first DMA transfer in step S901 in Embodiment 1, as illustrated in FIG. Or it can be omitted.

  In the first embodiment, the third DMA channel is started when the second DMA transfer for finally transferring data to the runtime data storage unit 70 is completed. This eliminates the need to transfer the contents of the runtime data storage unit 70 to the external communication interface 10 by program processing in order to transmit the contents of the runtime data storage unit 70. As a result, the processing illustrated in FIG. 11 that is necessary in Non-Patent Document 1 is not necessary in the first embodiment.

  As described above, according to the first embodiment, it is possible to minimize the software processing as shown in FIG. 10 to be added to the portion where the execution time data needs to be acquired. As a result, it is possible to minimize the CPU time due to the process itself for acquiring the execution time data and to minimize the change in the processing timing of the original control program.

  In particular, in a control device such as an in-vehicle inverter control device that executes processing in a short processing cycle, when acquiring execution timing including processing start time and end time, CPU time required for the acquisition processing itself It can be used as a countermeasure to keep the change in the execution timing due to.

  Further, according to the first embodiment, the software processing as shown in FIG. 11 for transferring the runtime data can be eliminated. As a result, even when the CPU load of the original control program is high and the CPU time for executing the data transfer process cannot be secured, it is possible to transfer the runtime data.

  In the first embodiment described above, the case where the DMA transfer is applied without using the CPU for both the creation of the runtime data and the transmission of the runtime data has been described. However, it is also possible to apply DMA transfer only to either creation or transmission.

  For example, when the number of DMA channels provided in the microcomputer is smaller than the number used in the first embodiment, the runtime data creation unit using the first and second DMA channels or the runtime data using the third to sixth DMA channels In the transmission section, some DMA channels can be replaced by a transfer process by software.

  Moreover, in Embodiment 1 mentioned above, the process 62-the process 65 demonstrated the case where it was set as all the periodic processes. On the other hand, if you want to acquire in addition to the periodic processing the execution data of the aperiodic processing that starts aperiodically due to an event that occurs outside the microcomputer or a specific condition in the control program is satisfied, A seventh DMA channel corresponding to the processing is added, and when the sixth DMA transfer is completed, the seventh DMA channel is started.

  The seventh DMA transfers the invalid identification number 664 to the first element of the identification number storage array of the aperiodic process execution data storage unit. As a result, when the non-periodic process is not executed in the period of one cycle of control, the invalid identification number 664 remains stored in the first element of the identification number storage array of the non-periodic process. For this reason, it can be determined that the non-periodic processing has never been executed within this period.

  Such countermeasures for non-periodic processing can be applied, for example, when investigating a problem in which periodic processing is sometimes not executed according to the cycle.

  In the first embodiment, in order to show an example of application of the runtime data acquisition method according to the present invention, the start and end timings of the process are acquired. However, the data that can be acquired by the runtime data acquisition method according to the present invention is not limited to this. For example, when acquiring an AD conversion value of a sensor or an input level of digital I / O at the time of starting processing, Applicable.

  Further, the location where data is acquired is not limited to the time when processing starts and ends. By starting the first DMA channel at an arbitrary point in the control program process, it is possible to acquire data at that time, and the CPU processing time for data acquisition and data transfer at that time Can be minimized.

  DESCRIPTION OF SYMBOLS 1 In-vehicle control apparatus (ECU), 2 input circuit, 3 microcomputer, 4 I / O, 5 CPU, 6 ROM, 7 RAM, 8 timer, 9 DMAC, 10 external communication interface, 11 drive circuit, 12 motor, 13 external communication Line, 60 control program (in-vehicle control program), 61 initialization process, 62, 63 period interrupt process, 64 short period process, 65 long period process, 66 identification number table, 67 sixth DMA permission value, 68 transmission request instruction value, 70 execution time data storage unit, 71 process 62 execution data storage unit, 72 process 63 execution data storage unit, 73 process 64 execution data storage unit, 74 process 65 execution data storage unit, 660 process 62 identification number table 661, identification number table of processing 63, 662, identification number table of processing 64, 663 identification number table of processing 65, 6 4 invalid identification number, 711,721,731,741 identification number storage array, 712, 722, 732, 742 time storage array.

Claims (6)

A CPU for executing an in-vehicle control program having a plurality of processes;
A DMAC which is a direct access memory controller having a plurality of channels and capable of performing DMA transfer of data in an address space accessible by the CPU without using the CPU;
A hardware timer capable of obtaining a count value by the DMA transfer;
ROM storing the in-vehicle control program and accessible by the DMA transfer;
RAM accessible by the DMA transfer;
In an in-vehicle control device provided with an external communication interface that performs data communication with an external device, when executing the in-vehicle control program, the execution time data for monitoring each execution timing or execution content of the plurality of processes An in-vehicle control program runtime data acquisition method for creating and transmitting,
In executing at least one of the creation of the runtime data and the transmission of the runtime data by the DMA transfer without passing through the CPU, the DMAC
When creating the runtime data by the DMA transfer,
At the time of obtaining the runtime data, the time data is collected by reading the count value of the hardware timer by the first DMA transfer by the first channel,
After collecting the time data, the second DMA transfer by the second channel reads out the identification number for identifying the plurality of processes stored in the ROM in advance according to the execution order of the plurality of processes. By collecting the identification number corresponding to the time data, create the runtime data,
When executing the execution time data transmission by the DMA transfer,
After execution time data corresponding to a predetermined control cycle is created, the execution time data for the control cycle is transferred by DMA transfer using a channel other than the first channel and the second channel. An in-vehicle control program runtime data acquisition method for transmitting to the external device via the external communication interface. The DMAC is
A first step of starting the first DMA transfer by the first channel when the processing of the in-vehicle control program acquires runtime data;
A second step of reading the count value of the hardware timer by the first DMA transfer, and transferring the read result to a time storage array in a runtime data storage area provided in the RAM;
A third step of initiating the second DMA transfer over the second channel upon completion of the first DMA transfer;
A fourth step of reading the identification number of the runtime data from the ROM by the second DMA transfer and transferring it to the identification number storage array in the runtime data storage area provided in the RAM; The execution time data acquisition method of the in-vehicle control program according to claim 1, wherein the execution time data including the time storage array and the identification number storage array is created by executing the DMA transfer. The DMAC is
A fifth step of starting the third DMA transfer by the third channel after the execution time data for one period of the control is created;
A sixth step of transferring execution data for one control cycle from the beginning of the third DMA transfer by an amount corresponding to the transmission buffer of the external communication interface;
A seventh step of initiating a fourth DMA transfer over a fourth channel upon completion of the third DMA transfer;
An eighth step of transferring, by the fourth DMA transfer, a value for enabling the sixth channel stored in advance in the ROM to a register of the sixth channel;
A ninth step of starting a fifth DMA transfer over a fifth channel upon completion of the fourth DMA transfer;
A tenth step of transferring, from the ROM, a transmission request value to the external communication interface stored in advance in the ROM by the fifth DMA transfer;
An eleventh step of starting a sixth DMA transfer by the sixth channel when the external communication interface has completed data transmission of the transmission buffer;
A twelfth step of transferring the untransferred data in the third DMA transfer to the external communication interface among the execution data for the one control cycle by the sixth DMA transfer;
A thirteenth step of initiating the fifth DMA transfer over the fifth channel upon completion of the sixth DMA transfer;
Thereafter, the fourteenth step of repeating the fifth DMA transfer and the sixth DMA transfer until the provision of all of the execution time data for the one control period to the external communication interface is completed.
The in-vehicle control program according to claim 1, further comprising: a fifteenth step of setting the sixth channel to a prohibited state when all of the execution time data for the one control cycle is completed by the sixth DMA transfer. Runtime data acquisition method. The DMAC is
A fifth step of starting the third DMA transfer by the third channel after the execution time data for the one control period is created by the completion of the second DMA transfer by the fourth step;
A sixth step of transferring execution-time data for one control cycle from the top by the third DMA transfer by an amount corresponding to the transmission buffer of the external communication interface;
A seventh step of initiating a fourth DMA transfer over a fourth channel upon completion of the third DMA transfer;
An eighth step of transferring, by the fourth DMA transfer, a value for enabling the sixth channel stored in advance in the ROM to a register of the sixth channel;
A ninth step of starting a fifth DMA transfer over a fifth channel upon completion of the fourth DMA transfer;
A tenth step of transferring, from the ROM, a transmission request value to the external communication interface stored in advance in the ROM by the fifth DMA transfer;
An eleventh step of starting a sixth DMA transfer by the sixth channel when the external communication interface has completed data transmission of the transmission buffer;
A twelfth step of transferring the untransferred data in the third DMA transfer to the external communication interface among the execution data for the one control cycle by the sixth DMA transfer;
A thirteenth step of initiating the fifth DMA transfer over the fifth channel upon completion of the sixth DMA transfer;
Thereafter, the fourteenth step of repeating the fifth DMA transfer and the sixth DMA transfer until the provision of all of the execution time data for the one control period to the external communication interface is completed.
The vehicle-mounted control program according to claim 2, further comprising: a fifteenth step of setting the sixth channel to a prohibited state when all of the execution-time data for the one control cycle is completed by the sixth DMA transfer. Runtime data acquisition method. When the DMAC creates runtime data for aperiodic processing that starts aperiodically,
When the sixth DMA transfer is completed, the seventh DMA transfer by the seventh channel corresponding to the aperiodic process is started, and the identification number storage corresponding to the aperiodic process in the runtime data storage area The in-vehicle control program runtime data acquisition method according to claim 4, further comprising a sixteenth step of transferring an invalid identification number to the first element of the array. A CPU for executing an in-vehicle control program having a plurality of processes;
A DMAC which is a direct access memory controller having a plurality of channels and capable of performing DMA transfer of data in an address space accessible by the CPU without using the CPU;
A hardware timer capable of obtaining a count value by the DMA transfer;
ROM storing the in-vehicle control program and accessible by the DMA transfer;
RAM accessible by the DMA transfer;
An external communication interface that performs data communication with an external device, and when executing the in-vehicle control program, creates and transmits runtime data for monitoring the execution timing or execution content of each of the plurality of processes. An in-vehicle control device,
The DMAC executes at least one of creation of the runtime data and transmission of the runtime data by the DMA transfer without using the CPU.
When creating the runtime data by the DMA transfer,
At the time of obtaining the runtime data, the time data is collected by reading the count value of the hardware timer by the first DMA transfer by the first channel,
After collecting the time data, the second DMA transfer by the second channel reads out the identification number for identifying the plurality of processes stored in the ROM in advance according to the execution order of the plurality of processes. By collecting the identification number corresponding to the time data, create the runtime data,
When executing the execution time data transmission by the DMA transfer,
After execution time data corresponding to a predetermined control cycle is created, the execution time data for the control cycle is transferred by DMA transfer using a channel other than the first channel and the second channel. A vehicle-mounted control device that transmits to the external device via the external communication interface.

Images