Gatekeeper restart trigger cause positioning method, device and equipment and storage medium

Abstract

The application provides a watchdog restart trigger cause positioning method, device and equipment and a storage medium, relates to the technical field of fault detection, and the watchdog restart trigger cause positioning method comprises the following steps: in response to the completion of watchdog restart, obtaining the abnormal scene information of a target task stored in advance, the target task being an executing task of watchdog timeout operation exception, and the abnormal scene information comprising stack information and runtime length information; and positioning the watchdog restart trigger cause according to the abnormal scene information. The application can greatly improve the positioning efficiency of the watchdog restart trigger cause.

Description

Technical Field

[0001] This application relates to the field of fault detection technology, and in particular to a method, apparatus, device and storage medium for locating the cause of a watchdog restart. Background Technology

[0002] To ensure high system reliability, a watchdog module is typically used to monitor system operation and prevent functional failures due to system anomalies. The typical workflow of a watchdog module is as follows: set a watchdog timeout period; feed the watchdog through one or more periodic tasks within the timeout period; reset the watchdog timeout period after feeding; if the watchdog times out, it indicates a system anomaly, triggering a watchdog restart.

[0003] Currently, watchdog timer restarts are typically analyzed manually by attempting to reproduce the anomaly. For example, if the anomaly occurs in a manually operated environment, the anomaly can be reproduced by repeating the actions performed before the watchdog timer restart. However, this method of locating the cause of a watchdog timer restart is inefficient. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for locating the cause of a watchdog restart, in order to solve the problem that the current method of locating the cause of a watchdog restart is inefficient.

[0005] Firstly, this application provides a method for locating the cause of a watchdog restart, including:

[0006] In response to the watchdog restart completion, retrieve the pre-stored exception context information of the target task. The target task is the task that was running when the watchdog timeout occurred. The exception context information includes stack information and runtime information.

[0007] Based on the abnormal scene information, the cause of the watchdog restart was located.

[0008] Optionally, the abnormal situation information is stored in the following way: in response to the watchdog timeout, the task execution is interrupted, and the first runtime and the second runtime of the task execution are obtained. The first runtime is the total runtime of the task execution, and the second runtime is the runtime of the task execution between the current time and the last watchdog feeding time. A first average runtime is determined based on the first runtime, and a second average runtime is determined based on the second runtime. Based on the first average runtime and the second average runtime, the target task that is running abnormally in the task execution is determined, and the abnormal situation information of the target task is saved. The runtime information includes the first average runtime and the second average runtime.

[0009] Optionally, tasks can be executed according to a preset priority.

[0010] Optionally, based on the first average runtime and the second average runtime, the target task that is running abnormally during the execution of the task is determined, including: determining the difference between the first average runtime and the second average runtime; determining the target task that is running abnormally during the execution of the task as a task whose difference is greater than a set threshold.

[0011] Optionally, determining the first average runtime based on the first runtime includes: determining the first system runtime before the current time; and determining the first average runtime as the ratio of the first runtime to the first system runtime.

[0012] Optionally, determining the second average runtime based on the second runtime includes: determining the second system runtime between the current time and the last time the dog was fed; and determining the second average runtime as the ratio of the second runtime to the second system runtime.

[0013] Optionally, in response to a watchdog timeout, the method for locating the cause of the watchdog restart also includes resetting the runtime of the task between the current watchdog feeding time and the previous watchdog feeding time.

[0014] Optionally, runtime information is used to determine the task that triggers the watchdog restart; stack information is used to determine the function being executed by the task that triggered the watchdog restart at the time of watchdog timeout.

[0015] Optionally, based on the abnormal scene information, locate the cause of the watchdog restart, including: outputting the abnormal scene information to locate the cause of the watchdog restart manually.

[0016] Secondly, this application provides a device for locating the cause of a watchdog restart, comprising:

[0017] The acquisition module is used to acquire the pre-stored exception context information of the target task in response to the completion of the watchdog restart. The target task is the task that was executed when the watchdog timeout occurred. The exception context information includes stack information and runtime information.

[0018] The processing module is used to locate the cause of the watchdog restart based on the abnormal situation information.

[0019] Optionally, the device for locating the cause of watchdog restart also includes a storage module for storing abnormal situation information in the following ways: in response to watchdog timeout, interrupting the execution task and obtaining a first runtime and a second runtime of the execution task, wherein the first runtime is the total runtime of the execution task and the second runtime is the runtime of the execution task between the current time and the last time the watchdog was fed; determining a first average runtime based on the first runtime and determining a second average runtime based on the second runtime; determining the target task that is running abnormally in the execution task based on the first average runtime and the second average runtime, and saving the abnormal situation information of the target task, wherein the runtime information includes the first average runtime and the second average runtime.

[0020] Optionally, tasks can be executed according to a preset priority.

[0021] Optionally, when the storage module determines the target task that is running abnormally in the execution task based on the first average runtime and the second average runtime, it is specifically used to: determine the difference between the first average runtime and the second average runtime; and determine that the target task that is running abnormally in the execution task is a task whose difference is greater than a set threshold.

[0022] Optionally, when the storage module is used to determine the first average runtime based on the first runtime, it is specifically used to: determine the first system runtime before the current time; and determine the first average runtime as the ratio of the first runtime to the first system runtime.

[0023] Optionally, when the storage module is used to determine the second average runtime based on the second runtime, it is specifically used to: determine the second system runtime between the current time and the last time the dog was fed; and determine the second average runtime as the ratio of the second runtime to the second system runtime.

[0024] Optionally, the watchdog restart trigger location device also includes a reset module for resetting the runtime of the task between the current watchdog feeding time and the previous watchdog feeding time before responding to a watchdog timeout.

[0025] Optionally, runtime information is used to determine the task that triggers the watchdog restart; stack information is used to determine the function being executed by the task that triggered the watchdog restart at the time of watchdog timeout.

[0026] Optionally, the processing module is specifically used to: output abnormal situation information so as to locate the cause of the watchdog restart trigger manually.

[0027] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0028] The memory stores instructions that the computer executes;

[0029] The processor executes computer execution instructions stored in memory to implement the watchdog restart trigger cause location method as described in the first aspect of this application.

[0030] Fourthly, this application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the method for locating the cause of a watchdog restart as described in the first aspect of this application.

[0031] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method for locating the cause of a watchdog restart as described in the first aspect of this application.

[0032] The watchdog restart trigger cause location method, apparatus, device, and storage medium provided in this application, in response to the completion of a watchdog restart, acquires pre-stored abnormal situation information of a target task. The target task is an executing task that experienced a watchdog timeout exception. The abnormal situation information includes stack information and runtime information. Based on the abnormal situation information, the cause of the watchdog restart is located. Because this application stores the abnormal situation information of the executing task when it encounters an abnormality before the watchdog restart, it can acquire this abnormal situation information upon completion of the watchdog restart to locate the cause of the watchdog restart, eliminating the need for manual analysis by attempting to reproduce the exception. Therefore, it can greatly improve the efficiency of locating the cause of the watchdog restart and effectively reduce the time and labor costs spent in locating the cause of the watchdog restart. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram illustrating an application scenario provided in one embodiment of this application;

[0035] Figure 2 A flowchart illustrating a method for locating the cause of a watchdog restart provided in an embodiment of this application;

[0036] Figure 3 This is a schematic diagram illustrating the priority of a task in execution, as provided in an embodiment of this application.

[0037] Figure 4A flowchart illustrating a method for storing abnormal scene information provided in an embodiment of this application;

[0038] Figure 5 A flowchart illustrating a method for locating the cause of a watchdog restart, as provided in another embodiment of this application;

[0039] Figure 6 This is a schematic diagram of the structure of a watchdog restart trigger cause locating device provided in an embodiment of this application;

[0040] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0043] Systems typically use watchdog timers to monitor their operational status and ensure high reliability. Taking an automotive embedded system as an example, to meet the functional safety requirements of vehicles, these systems are generally equipped with watchdog timers to prevent functional failures caused by system malfunctions. Based on the current watchdog timer workflow, after a watchdog restart, the information about the abnormal state is lost because the system has recovered. Typically, the cause of the watchdog restart is analyzed manually by attempting to reproduce the abnormality. If the abnormality occurred in a manually operated environment, it can be reproduced by repeating the operations before the watchdog restart; however, if the abnormality occurred without monitoring, reproduction is difficult. Therefore, the current method for locating the cause of a watchdog restart is inefficient.

[0044] To address the aforementioned issues, this application provides a method, apparatus, device, and storage medium for locating the cause of a watchdog restart. It saves the abnormal situation information before the watchdog restart by storing runtime information and stack information of the executed task. Upon completion of the watchdog restart, this abnormal situation information is retrieved, and the cause of the watchdog restart is located based on this information. This avoids the difficulty of reproducing the abnormality after a watchdog restart, effectively reduces the time and manpower costs spent locating the cause of the watchdog restart, and significantly improves the efficiency of locating the cause of the watchdog restart.

[0045] The following section provides examples illustrating the application scenarios of the solution provided in this application.

[0046] Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. For example... Figure 1 As shown, in this application scenario, the vehicle's microcontroller unit (MCU) 101 is equipped with a watchdog module 1011, used to monitor multiple tasks being performed in the vehicle's embedded system (i.e., Figure 1 The MCU 101 monitors the running status of tasks 1 to N and interrupts 1 to M, with each task having a corresponding execution priority. In response to a watchdog timeout, the MCU 101 interrupts the executing task and saves the exception context information. In response to a watchdog restart completion, the MCU 101 retrieves the exception context information to pinpoint the cause of the watchdog restart.

[0047] It should be noted that, Figure 1 This is merely a schematic diagram illustrating one application scenario provided by an embodiment of this application. This embodiment does not necessarily represent... Figure 1 The included equipment is not limited, nor is it restricted. Figure 1 The positional relationships between the devices are defined.

[0048] The technical solution of this application will now be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0049] Figure 2 This is a flowchart illustrating a method for locating the cause of a watchdog restart according to an embodiment of this application. This method for locating the cause of a watchdog restart can be executed by software and / or hardware devices. For example, the hardware device can be a watchdog restart cause locating device, which can be an electronic device or a processing chip within an electronic device. Figure 2 As shown, the method in this application embodiment includes:

[0050] S201. In response to the watchdog restart completion, obtain the pre-stored exception context information of the target task. The target task is the task being executed when the watchdog timeout occurred. The exception context information includes stack information and runtime information.

[0051] In this embodiment, the abnormal situation information of the target task is stored, for example, in non-volatile memory, such as flash memory. The target task is an execution task that has encountered a watchdog timeout error; optionally, the execution task is executed according to a preset priority.

[0052] For example, Figure 3 This is a schematic diagram illustrating the priority of a task in an embodiment of this application, as shown below. Figure 3 As shown, taking an in-vehicle embedded system as an example, there are multiple tasks executing in an in-vehicle embedded system. These tasks include tasks and interrupts, each with a corresponding preset priority. Tasks and interrupts are executed according to their preset priorities. Specifically, the execution of tasks and interrupts follows these rules: when a high-priority task and a low-priority task coexist, the high-priority task executes first; an interrupt can interrupt a currently executing task, and the interrupted task can continue execution after the interrupt is completed; a high-priority interrupt can interrupt a low-priority interrupt, and the interrupted interrupt will continue execution after the high-priority interrupt is completed. Based on these rules, when a task or interrupt gets stuck, tasks or interrupts with lower priorities cannot execute, causing the watchdog timer to restart. Therefore, the cause of the watchdog timer restart can be located by analyzing the changes in the runtime of tasks and interrupts.

[0053] In this step, the abnormal situation information includes stack information and runtime information. Optionally, the runtime information is used to determine the task that triggered the watchdog restart; the stack information is used to determine the function being executed by the task that triggered the watchdog restart at the time of watchdog timeout.

[0054] For example, when a task in execution gets stuck, tasks or interrupts with lower priority cannot be executed, causing the watchdog timer to restart. At this time, the runtime of the stuck task changes abnormally, which can be used to determine the task that triggered the watchdog timer restart. Then, based on the stack information of the stuck task, the function that the stuck task was executing at the time of the watchdog timeout can be determined.

[0055] In this step, in response to the watchdog restart completion, the pre-stored abnormal situation information of the target task can be obtained, namely stack information and runtime information. How the abnormal situation information of the target task is stored can be referred to subsequent embodiments, and will not be repeated here.

[0056] S202. Based on the abnormal scene information, locate the cause of the watchdog restart.

[0057] In this step, after obtaining the abnormal situation information of the target task, the cause of the watchdog restart can be located based on the abnormal situation information.

[0058] In one possible implementation, locating the cause of the watchdog restart based on the abnormal scene information may include: outputting the abnormal scene information to manually locate the cause of the watchdog restart.

[0059] For example, the target task runtime information could be a first average runtime of the target task obtained in response to a watchdog timeout, and a second average runtime of the target task between the watchdog timeout time and the last watchdog feed time. By comparing the first and second average runtimes, the task that triggered the watchdog restart can be determined, and by using the target task's stack information, the function being executed by the task that triggered the watchdog restart at the time of the watchdog timeout can be determined, thereby pinpointing the cause of the watchdog restart.

[0060] In another possible implementation, the electronic device executing this method embodiment can automatically locate the cause of the watchdog restart based on abnormal situation information. For example, it can determine the task that triggered the watchdog restart based on runtime information, and determine the function being executed by the task that triggered the watchdog restart at the time of watchdog timeout based on stack information, thereby locating the cause of the watchdog restart.

[0061] The watchdog restart trigger cause location method provided in this application embodiment obtains pre-stored abnormal situation information of a target task in response to the completion of the watchdog restart. The target task is an executing task that experienced a watchdog timeout exception. The abnormal situation information includes stack information and runtime information. Based on the abnormal situation information, the watchdog restart trigger cause is located. Since this application embodiment stores the abnormal situation information when the executing task experiences an abnormality before the watchdog restart, this abnormal situation information can be obtained upon completion of the watchdog restart to locate the watchdog restart trigger cause. This eliminates the need for manual analysis of the watchdog restart trigger cause by attempting to reproduce the exception. Therefore, it can greatly improve the efficiency of locating the watchdog restart trigger cause and effectively reduce the time and labor costs spent in locating the watchdog restart trigger cause.

[0062] Based on the above embodiments, Figure 4 A flowchart of a method for storing abnormal scene information provided in an embodiment of this application is shown below. Figure 4 As shown, the method in this application embodiment may include:

[0063] S401. In response to the watchdog timeout, interrupt the task being executed and obtain the first runtime and the second runtime of the task being executed. The first runtime is the total runtime of the task being executed, and the second runtime is the runtime of the task being executed between the current time and the last time the watchdog was fed.

[0064] For example, in response to a watchdog timeout, a watchdog timeout interrupt can be invoked to interrupt the executing task. It should be noted that the watchdog timeout interrupt can be configured to a higher priority to ensure that the executing task can be interrupted or interrupted when the watchdog times out. For each executing task, the electronic device executing this method embodiment records its start time when each executing task begins execution and its end time when execution ends or is interrupted, thereby determining the single runtime of each executing task as the difference between the end time and the start time. Summing up the single runtimes yields a first runtime and a second runtime.

[0065] Optionally, in response to the watchdog timeout, the abnormal scene information storage method provided in this application embodiment may further include: resetting the runtime of the task between the current time of feeding the watchdog and the previous time of feeding the watchdog.

[0066] For example, before the watchdog times out, while the task is running normally, the watchdog can be fed in one or more tasks, and after feeding the watchdog, the runtime of the task between the current feeding time and the previous feeding time is reset.

[0067] If the watchdog is not fed within the watchdog timeout period, the task execution is interrupted in response to the watchdog timeout, and the first and second runtimes of the task execution are obtained.

[0068] S402. Determine a first average running time based on a first running time, and determine a second average running time based on a second running time.

[0069] In this step, after obtaining the first runtime and the second runtime of the task, the first average runtime can be determined based on the first runtime, and the second average runtime can be determined based on the second runtime.

[0070] Further, optionally, determining the first average runtime based on the first runtime may include: determining the first system runtime before the current time; and determining the first average runtime as the ratio of the first runtime to the first system runtime.

[0071] For example, taking an in-vehicle embedded system as an example, a system time interrupt can be invoked to determine the first system runtime of the in-vehicle embedded system before the current moment, and the first average runtime can be determined as the ratio of the first runtime to the first system runtime. It should be noted that the system time interrupt can be configured to a higher priority for periodically calculating the first average runtime during task execution.

[0072] Further, optionally, determining the second average runtime based on the second runtime may include: determining the second system runtime between the current time and the last time the dog was fed; and determining the second average runtime as the ratio of the second runtime to the second system runtime.

[0073] For example, taking an in-vehicle embedded system as an example, the system time interrupt can be called to determine the second system runtime of the in-vehicle embedded system between the current time and the last time the watchdog was fed, and the watchdog timeout interrupt can be called to determine the second average runtime as the ratio of the second runtime to the second system runtime.

[0074] S403. Based on the first average runtime and the second average runtime, determine the target task that is running abnormally during task execution, and save the abnormal situation information of the target task. The runtime information includes the first average runtime and the second average runtime.

[0075] In this step, after determining the first average runtime and the second average runtime, the watchdog timeout interrupt can be invoked to determine the target task that is running abnormally during task execution based on the first average runtime and the second average runtime, and save the abnormal context information of the target task, namely stack information, the first average runtime, and the second average runtime.

[0076] Further, optionally, determining the target task that is running abnormally during task execution based on the first average runtime and the second average runtime may include: determining the difference between the first average runtime and the second average runtime; determining the target task that is running abnormally during task execution as a task whose difference is greater than a set threshold.

[0077] For example, based on the above Figure 3 The cause of the watchdog restart can be located by analyzing the changes in the runtime of the task. Therefore, after determining the first average runtime and the second average runtime, the watchdog timeout interrupt can be called to determine the difference between the first average runtime and the second average runtime. Then, the target task that is running abnormally during task execution can be determined to be the task whose difference is greater than the set threshold, and the stack information of the target task can be saved.

[0078] The method for storing abnormal situation information provided in this application embodiment interrupts the execution of a task in response to a watchdog timeout and obtains a first runtime and a second runtime of the execution task. The first runtime is the total runtime of the execution task, and the second runtime is the runtime of the execution task between the current time and the last watchdog timeout. A first average runtime is determined based on the first runtime, and a second average runtime is determined based on the second runtime. Based on the first and second average runtimes, a target task that is running abnormally in the execution task is determined, and the abnormal situation information of the target task is saved. The runtime information includes the first average runtime and the second average runtime. Because this application embodiment determines the target task that is running abnormally in the execution task based on the first and second average runtimes at the watchdog timeout time and saves the abnormal situation information of the target task, it can accurately obtain the abnormal situation information, which can then be used to accurately locate the cause of the watchdog restart trigger, improving the location efficiency.

[0079] Based on the above embodiments, Figure 5 A flowchart of a method for locating the cause of a watchdog restart provided in another embodiment of this application is shown below. Figure 5 As shown, the method in this application embodiment may include:

[0080] S501. Obtain the runtime of the task.

[0081] For example, the start time of each task can be recorded when it begins execution, and the end time can be recorded when it ends or is interrupted. This allows us to determine the single runtime of each task as the difference between the end time and the start time. Summing up the single runtimes yields the total runtime of the task. It can be understood that if the system is in normal operation before the watchdog timeout, the total runtime (i.e., the first runtime) and the runtime between two watchdog feeds can be obtained using the above method. Conversely, if the system is in an abnormal operation state at the watchdog timeout point, the first runtime and the runtime between the watchdog timeout point and the last watchdog feed can be obtained using the above method.

[0082] S502, Determine the first average running time.

[0083] For example, a system time interrupt can be invoked to periodically determine the first average runtime.

[0084] S503. Determine whether to feed the dog before the watchdog timeout period.

[0085] For example, if feeding the dog is performed in one or more tasks, and it is determined that the dog was not fed before the watchdog timeout, then steps S504 to S506 are executed; if it is determined that the dog was fed before the watchdog timeout, then step S507 is executed.

[0086] S504. In response to a watchdog timeout, interrupt the execution of the task, determine the second average runtime, and based on the first average runtime and the second average runtime, determine the target task that is running abnormally during the execution of the task, and save the abnormal situation information of the target task.

[0087] The abnormal situation information includes stack information, first average runtime, and second average runtime.

[0088] For example, a watchdog timeout interrupt can be invoked to determine the second average runtime, and the difference between the first average runtime and the second average runtime can be determined. Then, the target task that is running abnormally during task execution is determined to be the task whose difference is greater than a set threshold, and the abnormal situation information of the target task is saved.

[0089] S505, In response to the watchdog restart completion, obtain the pre-stored abnormal situation information of the target task.

[0090] S506. Based on the abnormal situation information, locate the cause of the watchdog restart.

[0091] S507. Reset the runtime of the task between the current dog-feeding time and the previous dog-feeding time.

[0092] The watchdog restart trigger location method provided in this application stores abnormal scene information when the task execution fails before the watchdog restarts. This allows the abnormal scene information to be obtained when the watchdog restart is completed, which can then be used to locate the watchdog restart trigger cause. This eliminates the need for manual analysis of the watchdog restart trigger cause by attempting to reproduce the abnormality. Therefore, it can greatly improve the efficiency of locating the watchdog restart trigger cause and effectively reduce the time and manpower costs spent in locating the watchdog restart trigger cause.

[0093] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0094] Figure 6 This is a schematic diagram of the structure of a watchdog restart trigger cause locating device provided in an embodiment of this application, as shown below. Figure 6 As shown, the watchdog restart trigger cause locating device 600 in this embodiment includes: an acquisition module 601 and a processing module 602. Wherein:

[0095] The acquisition module 601 is used to acquire the pre-stored exception context information of the target task in response to the completion of the watchdog restart. The target task is the task being executed when the watchdog timeout occurred. The exception context information includes stack information and runtime information.

[0096] The processing module 602 is used to locate the cause of the watchdog restart based on the abnormal scene information.

[0097] In some embodiments, the device for locating the cause of a watchdog restart further includes a storage module 603, used to store abnormal situation information in the following manner: in response to a watchdog timeout, interrupting the execution task and obtaining a first runtime and a second runtime of the execution task, wherein the first runtime is the total runtime of the execution task and the second runtime is the runtime of the execution task between the current time and the last time the watchdog was fed; determining a first average runtime based on the first runtime and determining a second average runtime based on the second runtime; determining the target task that is running abnormally in the execution task based on the first average runtime and the second average runtime, and saving the abnormal situation information of the target task, wherein the runtime information includes the first average runtime and the second average runtime.

[0098] Optionally, tasks can be executed according to a preset priority.

[0099] Optionally, when the storage module 603 is used to determine the target task that is running abnormally in the execution task based on the first average runtime and the second average runtime, it can be specifically used to: determine the difference between the first average runtime and the second average runtime; and determine that the target task that is running abnormally in the execution task is a task whose difference is greater than a set threshold.

[0100] Optionally, when the storage module 603 is used to determine the first average runtime based on the first runtime, it may specifically be used to: determine the first system runtime before the current moment; and determine the first average runtime as the ratio of the first runtime to the first system runtime.

[0101] Optionally, when the storage module 603 is used to determine the second average runtime based on the second runtime, it can be specifically used to: determine the second system runtime between the current time and the last time the dog was fed; and determine the second average runtime as the ratio of the second runtime to the second system runtime.

[0102] In some embodiments, the device for locating the cause of watchdog restart further includes a reset module 604, which is used to reset the runtime of the task between the current watchdog feeding time and the previous watchdog feeding time before the watchdog timeout.

[0103] Optionally, runtime information is used to determine the task that triggers the watchdog restart; stack information is used to determine the function being executed by the task that triggered the watchdog restart at the time of watchdog timeout.

[0104] Optionally, the processing module 602 can be specifically used to: output abnormal scene information to locate the cause of the watchdog restart trigger manually.

[0105] The apparatus of this application embodiment can be used to execute the technical solutions of any of the method embodiments shown above. Its implementation principle and technical effect are similar, and will not be repeated here.

[0106] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 700 may include at least one processor 701 and a memory 702.

[0107] The memory 702 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0108] The memory 702 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0109] The processor 701 executes computer execution instructions stored in the memory 702 to implement the watchdog restart trigger cause location method described in the foregoing method embodiments. The processor 701 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Specifically, when implementing the watchdog restart trigger cause location method described in the foregoing method embodiments, the electronic device may be, for example, an electronic control unit in a vehicle.

[0110] Optionally, the electronic device 700 may also include a communication interface 703. In specific implementations, if the communication interface 703, memory 702, and processor 701 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0111] Optionally, in a specific implementation, if the communication interface 703, memory 702, and processor 701 are integrated on a single chip, then the communication interface 703, memory 702, and processor 701 can communicate through an internal interface.

[0112] This application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implements the above-mentioned method for locating the cause of a watchdog restart.

[0113] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for locating the cause of a watchdog restart.

[0114] The aforementioned computer-readable storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0115] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in a watchdog timer restart trigger location device.

[0116] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A watchdog reboot trigger cause localization method, characterized in that, The method comprises: in response to completion of watchdog restart, obtaining pre-stored abnormal scene information of a target task, the target task being an in-execution task when the watchdog times out and runs abnormally, wherein the target task is determined by: calculating a first average running time length and a second average running time length of the in-execution task, and determining the in-execution task as the target task when a difference between the first average running time length and the second average running time length is greater than a set threshold; the first average running time length being a ratio of a total running time length of the task to a first system running time length before a current time; the second average running time length being a ratio of a second running time length to a second system running time length, the second system running time length being a time length between the current time and a last feeding time; the abnormal scene information comprising stack information and running time length information, the running time length information comprising the first average running time length and the second average running time length; and the second running time length being a running time length of the in-execution task between the current time and the last feeding time; locating a watchdog restart triggering cause according to the abnormal scene information.

2. The watchdog reboot trigger cause location method of claim 1, wherein, The abnormal scene information is stored by: in response to watchdog timeout, interrupting an in-execution task, and obtaining a first running time length and a second running time length of the in-execution task, determining a first average running time length according to the first running time length, and determining a second average running time length according to the second running time length; determining a target task running abnormally in the in-execution task according to the first average running time length and the second average running time length, and saving abnormal scene information of the target task.

3. The watchdog reboot trigger cause location method of claim 2, wherein, The in-execution task is executed according to a preset priority.

4. The watchdog reboot trigger cause location method according to claim 2 or 3, c h a r a c t e r i z e d by, Before the response to watchdog timeout, the method further comprises: resetting a running time length of the in-execution task between a current feeding time and a last feeding time.

5. The watchdog reboot trigger cause localization method according to any one of claims 1 to 3, characterized in that, The running time length information is used to determine a task triggering watchdog restart, and the stack information is used to determine a function being executed by the task triggering watchdog restart at a watchdog timeout time.

6. The watchdog reboot trigger cause localization method according to any one of claims 1 to 3, characterized in that, The locating of the watchdog restart triggering cause according to the abnormal scene information comprises: outputting the abnormal scene information to locate the watchdog restart triggering cause in an artificial manner.

7. A device for locating the cause of a watchdog restart, characterized in that, The method comprises: The acquisition module is configured to acquire pre-stored abnormal scene information of a target task in response to completion of the watchdog restart, the target task being an executing task when the watchdog times out and runs abnormally, wherein the target task is determined by calculating a first average running time length and a second average running time length of the executing task, and determining the executing task as the target task when a difference between the first average running time length and the second average running time length is greater than a set threshold; the first average running time length is a ratio of a total running time length of the task to a first system running time length before a current time; the second average running time length is a ratio of a second running time length to a second system running time length, the second system running time length being a time length between the current time and a last watchdog feeding time; the abnormal scene information includes stack information and running time length information, the running time length information including the first average running time length and the second average running time length; and the second running time length being a running time length of the executing task between the current time and the last watchdog feeding time; The processing module is configured to locate a watchdog restart trigger cause according to the abnormal scene information.

8. An electronic device, comprising: The method comprises: a processor, and a memory connected to the processor in communication; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method for locating the watchdog restart trigger cause according to any one of claims 1 to 6.

9. A computer readable storage medium characterized by, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the method for locating the watchdog restart trigger cause according to any one of claims 1 to 6.

10. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images