Method and system for monitoring running state of multi-core controller and storage medium

Abstract

The invention relates to the technical field of automotive electronics, and provides a monitoring method and system for the running state of a multi-core controller and a storage medium. The method comprises the steps that under the condition that an external watchdog is started and a timer is triggered to start timing, program running states of all CPUs in a controller are monitored every preset period; when it is detected that the program running states of all the CPUs are normal, the timer is reset, and the timer is made to conduct timing again; and when it is detected that the program running state of at least one CPU is abnormal, a timer of the external watchdog is not reset, so that the external watchdog automatically resets each CPU after timing of the timer is finished. According to the monitoring method, the running state of each CPU is monitored through the external watchdog, and the external watchdog still has normal monitoring capability under the condition that the clock source of the CPU fails, so that the reliability of running state monitoring can be improved.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a method, system, and storage medium for monitoring the operating status of a multi-core controller. Background Technology

[0002] In the field of automotive electronics, the Electronic Control Unit (ECU) is the core control center of a vehicle, responsible for executing key functions such as engine control, vehicle stability control, and autonomous driving decisions. Its operational reliability directly determines vehicle driving safety. Currently, vehicle ECUs are increasingly adopting multi-core microcontrollers (MCUs) as their core hardware carrier. A multi-core controller refers to a controller that internally contains multiple CPU cores capable of independently running tasks.

[0003] In related technologies, each CPU core is typically configured with an independent internal watchdog. This internal watchdog monitors the running status of each CPU core and can promptly reset each CPU core in the event of abnormal operation (such as program crashing or getting stuck in an infinite loop).

[0004] However, the internal watchdog relies on the CPU core's own clock. If the CPU core's clock fails, the corresponding internal watchdog will also fail. This will result in the internal watchdog being unable to trigger the CPU core's reset when a program exception occurs in the CPU core, causing the faulty CPU core to continue to malfunction and resulting in insufficient monitoring reliability. Summary of the Invention

[0005] In view of this, this application aims to propose a method for monitoring the operating status of a multi-core controller, so as to improve the reliability of monitoring the operating status of the multi-core controller.

[0006] To achieve the above objectives, the technical solution of this application is implemented as follows: A method for monitoring the operating status of a multi-core controller, using an external watchdog connected to the controller, wherein the external watchdog has a built-in timer, and the controller has multiple CPUs, and the method includes: When the external watchdog is activated and the timer is triggered to start counting, the program running status of each CPU in the controller is monitored at preset intervals. If the program running status of each CPU is detected to be normal, the timer is reset so that the timer starts counting again; If an abnormal program running state is detected in at least one of the CPUs, the timer of the external watchdog is not reset, so that the external watchdog automatically resets each of the CPUs after the timer expires.

[0007] Furthermore, the controller's memory stores CPU status identifiers corresponding to each CPU, and each CPU is used to reset the CPU status identifiers every reset cycle. The step of monitoring the program execution status of each CPU within the controller at preset intervals includes: The controller's memory is accessed every preset period to read the CPU status identifier corresponding to each CPU, and the stored values ​​of each CPU status identifier are iteratively adjusted based on a preset step size. Based on the CPU status identifiers adjusted in each iteration, determine whether each CPU can reset the value of the CPU status identifier according to the reset cycle. If the value of the CPU status identifier fails to be reset, the corresponding CPU operation is determined to be abnormal, thereby enabling monitoring of the program operation status of each CPU within the controller; The reset period is longer than the preset period.

[0008] Furthermore, the iterative adjustment of the stored values ​​of each CPU state identifier based on a preset step size includes: Subtract a preset step size from the value of each CPU status identifier; or... The value of each CPU status identifier is increased by the preset step size.

[0009] Furthermore, determining whether each CPU can reset the value of the CPU status identifier according to the reset cycle based on the CPU status identifier adjusted in each iteration includes: Determine whether the adjusted value of the CPU status identifier is a preset termination threshold; If the adjusted CPU status identifier is the preset termination threshold, it is determined that the CPU failed to reset the value of the CPU status identifier. If the adjusted CPU status identifier is not the preset termination threshold, it is determined that the CPU can reset the value of the CPU status identifier.

[0010] Furthermore, during normal operation of the CPU, the value of the CPU status identifier is reset to a preset starting reference value according to the reset cycle; The preset termination threshold is the value obtained by iteratively adjusting a preset number of times, starting from the preset starting reference value, according to the preset adjustment direction, and with the preset step size as the reference. The preset number of times is greater than the ratio of the reset period to the preset period.

[0011] Furthermore, the step of resetting the timer when it is detected that the program running status of each CPU is normal, causing the timer to start counting again, includes: If the program running status of each CPU is detected to be normal, the external watchdog and the logical operation capability of each CPU are verified. If the external watchdog timer and the logic operation capabilities of each CPU are normal, the timer is reset so that the timer starts counting again.

[0012] Furthermore, the verification of the external watchdog timer and the logical operation capabilities of each CPU includes: Output a dog-feeding signal to the CPU, causing the CPU to perform calculation operations according to a preset algorithm logic, and write the CPU calculation result into the first preset register; When the CPU's calculation result is written into the first preset register, the calculation operation is performed according to the preset algorithm logic to obtain the watchdog calculation result; The watchdog calculation result is written into the second preset register, so that the CPU reads the watchdog calculation result in the second preset register and compares the watchdog calculation result with the CPU calculation result; If the watchdog timer calculation result is consistent with the CPU calculation result, it is determined that the external watchdog timer and the logic operation capabilities of each CPU are normal.

[0013] Furthermore, among the tasks to be processed by the CPU, the task for which the CPU resets the value of the CPU status identifier according to the reset cycle has the lowest priority.

[0014] Compared with related technologies, this application has at least the following advantages: The multi-core controller operation status monitoring method described in this application monitors the operation status of each CPU by setting an external watchdog. Since the clock source of the external watchdog does not depend on the clock source of each CPU, even if the clock source of any CPU in the controller fails, the external watchdog can still monitor normally according to the preset cycle, and will not fail synchronously due to the failure of the CPU clock source of the controller. It can still monitor the CPU operation status normally, thereby improving the reliability of multi-core controller operation status monitoring.

[0015] Meanwhile, in the multi-core controller operation status monitoring method of this application, the program operation status of each CPU is monitored at preset intervals. When all CPUs are running normally, the timer is reset to feed the watchdog. When there is a CPU operation abnormality, the timer is not reset, that is, the watchdog is not fed. This allows the external watchdog to automatically reset each CPU when the timer expires, thereby enabling the forced execution of the reset operation after a CPU abnormality, so as to help the abnormal CPU to quickly resolve the fault state.

[0016] Meanwhile, in the multi-core controller operation status monitoring method of this application, the operation status of each CPU is monitored separately through each CPU status identifier, so as to identify the CPU with abnormal program operation through abnormal CPU status identifier, thereby achieving the effect of abnormal location.

[0017] Meanwhile, in the multi-core controller operation status monitoring method of this application, the CPU program operation is judged by iteratively adjusting the CPU status identifier and determining whether the CPU status identifier has been reset by the CPU. In this way, when a software failure occurs, such as the program crashing or getting stuck in an infinite loop, the CPU will not be able to execute the CPU status identifier reset operation according to the reset cycle, causing the external watchdog to trigger the fault reset controller operation. For hardware failures, such as power fluctuations, wire lock-up, internal damage to the controller chip, etc., when the CPU cannot operate normally, the CPU will also be unable to complete the CPU status identifier reset, which will also cause the external watchdog to trigger the fault reset control operation.

[0018] In other words, regardless of whether the controller experiences a hardware or software failure, the multi-core controller operation status monitoring method of this application can promptly reset the controller to resolve the fault state, thereby improving the reliability of multi-core controller operation status monitoring.

[0019] Another objective of this application is to provide a computer-readable storage medium storing a computer program that, when executed by a processor, can perform the aforementioned method for monitoring the operating status of a multi-core controller.

[0020] Another objective of this application is to provide a monitoring system for the operating status of a multi-core controller, the system comprising: A multi-core controller includes multiple CPUs, each of which operates independently; An external watchdog timer is connected to the multi-core controller, and the external watchdog timer is capable of performing the aforementioned method for monitoring the operating status of the multi-core controller.

[0021] The computer storage medium and operating status monitoring system described in this application, by executing the multi-core controller operating status monitoring method, can monitor the operating status of each CPU core of the multi-core controller, can reset in a timely manner when each CPU is abnormal, and does not depend on the CPU clock source, still has normal operating status monitoring capability when the clock source of each CPU is abnormal, thereby improving the reliability of monitoring the operating status of each CPU of the multi-core controller. Attached Figure Description

[0022] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the method for monitoring the operating status of a multi-core controller as described in an embodiment of this application. Figure 2 This is a flowchart illustrating the process of detecting the program running status of each CPU at preset intervals in the multi-core controller operation status monitoring method described in this application embodiment. Figure 3 This is a flowchart illustrating the process of determining whether the CPU can normally reset the CPU status identifier in the multi-core controller operation status monitoring method described in this application embodiment. Figure 4 This is a flowchart illustrating the process of resetting a timer when the program is running normally in the multi-core controller operation monitoring method described in this application embodiment; Figure 5 This is a flowchart illustrating the process of verifying the logical operation capabilities of the CPU and external watchdog in the multi-core controller operation status monitoring method described in this application embodiment. Detailed Implementation

[0023] To make the technical solution and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0025] Furthermore, it should be noted that in the description of this application, if terms such as "upper," "lower," "inner," or "outer" appear, indicating orientation or positional relationship, these are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, if terms such as "first" or "second" appear, they are also used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0026] Furthermore, in the description of this application, unless otherwise expressly defined, the terms "installation," "connection," "joining," and "connector" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application in light of the specific circumstances.

[0027] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0028] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments.

[0029] An embodiment of the first aspect of this application provides a method for monitoring the operating status of a multi-core controller, using an external watchdog connected to the controller. The controller has multiple CPUs (Central Processing Units). The method for monitoring the operating status of the multi-core controller in this embodiment monitors the operating status of each CPU by setting an external watchdog. Since the clock source of the external watchdog does not depend on the clock source of each CPU, even if any CPU of the controller is damaged or fails, or the clock of the controller fails, the external watchdog can still monitor each CPU of the controller normally according to a preset cycle, without synchronously failing due to the failure of a CPU of the controller, and can still monitor the operating status of the CPU, thereby improving the reliability of the multi-core controller operating status monitoring.

[0030] In related technologies, the watchdog timer (WDT) is a crucial functional safety mechanism in the software development of automotive electronic control units. The core function of a watchdog timer is to monitor the execution status of the software.

[0031] The watchdog timer is essentially the first independent timer module, with a built-in counter and reset trigger unit. After the watchdog timer is started, the counter will continuously accumulate pulses according to the frequency of the clock source. For example, the counter will increment from 0 until it reaches the overflow threshold, or the counter will decrement from a preset threshold until it drops to 0.

[0032] When the monitored software is running normally, it will perform a watchdog timer operation every preset feeding cycle (i.e., reset the watchdog timer so that it starts to increment from 0 or decrement from the preset threshold). In other words, when the software is running normally, it will continuously interrupt the watchdog's counting process, so that it can never reach the overflow threshold or drop to 0, thus proving to the watchdog that it is in a normal state.

[0033] If the software malfunctions (such as program crashing, program getting stuck in an infinite loop, task blocking, etc.) and fails to "feed" the watchdog timer on time, the watchdog will continue counting until it reaches the overflow threshold or decreases to 0, causing the counter to overflow. After the counter overflows, the watchdog will trigger a software reset, forcing the software to restart to resolve the fault state, thereby ensuring the robustness and reliability of the system and ultimately ensuring the safe operation of the vehicle.

[0034] A multi-core microcontroller (MCU) is a microcontroller that contains multiple independent cores (CPU cores, referred to as CPUs hereafter for ease of description), such as the TC377TX multi-core microcontroller. Each CPU within a multi-core microcontroller can run independent software tasks or operating systems. Therefore, it is necessary to monitor the operating status of each independent CPU in order to reset it promptly when an abnormality occurs during kernel operation.

[0035] In related technologies, there are two types of status monitoring strategies for multi-core microcontrollers (MCUs). One strategy is to set up a global watchdog for each CPU and use the global watchdog to monitor the entire microcontroller (MCU).

[0036] However, in this strategy, since each CPU can run and crash independently, a failure in one CPU may not directly affect the operating status of other CPUs. If only a global watchdog is used to monitor the entire chip, other normal CPUs may still be feeding the watchdog on time when a certain CPU fails. This makes it difficult to detect the failure of that CPU in a timely manner and to reset the faulty CPU, thus affecting the reliability of the microcontroller.

[0037] Therefore, most related technologies adopt the second status monitoring strategy, which involves configuring an independent internal watchdog timer in each CPU and using it to monitor the status of each CPU individually. This allows for timely detection of individual faults in each CPU and also helps pinpoint the faulty kernel for later repair.

[0038] An internal watchdog timer is a hardware module integrated into the CPU of a microcontroller. It is driven by the CPU's own clock. If the CPU fails to periodically feed the watchdog timer to reset its counter, the internal watchdog timer will reset the microcontroller in an attempt to recover from a malfunction.

[0039] However, the internal watchdog timer's clock source is the same as the CPU's main clock. If the CPU's clock malfunctions, the internal watchdog timer will not function properly and will lose its ability to monitor the CPU. In this situation, even if the CPU program runs abnormally, the internal watchdog timer will not trigger a reset, leaving the CPU in a faulty state.

[0040] Furthermore, the internal watchdog timer is entirely dependent on the CPU's operating state. If the CPU fails completely for some reason, the internal watchdog timer will also fail, and the CPU will not be able to be effectively reset.

[0041] Furthermore, internal watchdogs can typically only monitor software-level faults, such as programs getting stuck in infinite loops or tasks being suspended. For hardware faults (such as power fluctuations, bus lock-up, or internal damage to the MCU chip), hardware faults may cause the microcontroller MCU to completely fail, and the internal watchdog cannot detect hardware faults, thus failing to trigger a reset.

[0042] Therefore, this method of monitoring the CPU's operating status by setting an internal watchdog in each CPU is less reliable.

[0043] In view of this, to overcome the shortcomings of related technologies, in the multi-core controller operation status monitoring method of this embodiment, an external watchdog is set outside the controller. This external watchdog can specifically be a separate hardware watchdog located outside the controller. For example, a dedicated watchdog chip (such as the SC900719 chip), or a watchdog module integrated into a power management chip, etc. This external watchdog has a built-in timer.

[0044] An external watchdog relies on its own independent clock source, rather than on the controller's clock source.

[0045] This controller is a multi-core controller with multiple CPU cores. An external watchdog is connected to the controller and is used to monitor the operating status of the multi-core controller, specifically the operating status of each CPU within the controller.

[0046] Specifically, the monitoring method for the operating status of this multi-core controller, combined with... Figure 1 In terms of overall design, it includes the following steps S110-S130.

[0047] Step S110: When the external watchdog is started and the timer is triggered to start counting, the program running status of each CPU in the controller is monitored at preset intervals.

[0048] Specifically, when the external watchdog timer is activated, the timer set within it starts counting down from a preset threshold. When the timer counts down to 0, the timer ends, and the external watchdog timer outputs a reset signal to reset the controller and restart. Alternatively, the timer can start counting from 0, and when it reaches a preset overflow threshold, the timer ends, and the external watchdog timer outputs a reset signal to reset the controller.

[0049] In this embodiment, when the external watchdog timer is activated, a timer is triggered to start counting down. For example, the timer inside the external watchdog timer starts counting down from 320ms. When the timer counts down to 0ms, the countdown ends and a reset signal is output to the controller.

[0050] When the timer starts counting down, the external watchdog monitors the program running status of each CPU within the controller at preset intervals to check whether the programs of each CPU are running normally. For example, the external watchdog monitors the program running status of each CPU every 10ms.

[0051] Step S120: If the program running status of each CPU is detected to be normal, reset the timer so that the timer starts counting again.

[0052] Step S130: If an abnormal program running state is detected in at least one CPU, the external watchdog timer is not reset, so that the external watchdog automatically resets each CPU after the timer expires.

[0053] Specifically, during each monitoring session, if the CPU is detected to be running normally, the timer will be reset so that it starts counting down again. For example, if the timer counts down from 320ms to 280ms and it is detected that all CPUs are running normally, the timer will be reset so that it starts counting down again from 320ms.

[0054] Assuming all CPUs are running normally, the watchdog timer will monitor the status of each CPU every 10ms. Under normal conditions, it will periodically reset the timer to 320ms, so that the timer will not overflow and the countdown will not end, thus preventing the CPUs from being reset and allowing each CPU to run normally.

[0055] If at least one CPU is detected to be malfunctioning during any monitoring process, the timer will not be reset. As the timer continues to count down, when the countdown reaches 0 (or reaches the preset overflow threshold), the countdown ends, and the external watchdog will automatically output a reset signal to the controller, causing each CPU of the controller to automatically reset and rerun the program, so that the malfunctioning CPU can be discharged from the fault state.

[0056] Therefore, by setting an external watchdog to monitor the operating status of each CPU, since the clock source of the external watchdog does not depend on the clock source of each CPU, even if any CPU of the controller is damaged or fails, or the controller's clock fails, the external watchdog can still monitor normally according to the preset cycle, and will not fail synchronously due to the failure of the controller's CPU, and can still monitor the operating status of the CPU, thereby improving the reliability of multi-core controller operating status monitoring.

[0057] At the same time, the program running status of each CPU is monitored at preset intervals. If the running is normal, the timer is reset to feed the watchdog. If there is a CPU running abnormality, the timer is not reset, that is, the watchdog is not fed. This allows the external watchdog to automatically reset each CPU when the timer expires, so that the reset operation can be forcibly executed after the CPU is abnormal, so as to help the abnormal CPU to quickly get rid of the fault state.

[0058] Continue by Figure 1 and combined Figure 2As shown, in some exemplary embodiments, the program running status of each CPU in the controller is monitored at preset intervals in step S110, which may specifically include the following steps S111-S113.

[0059] Step S111: Access the controller's memory every preset period, read the CPU status identifier corresponding to each CPU, and iteratively adjust the value of each stored CPU status identifier based on a preset step size.

[0060] Step S112: Based on the CPU status identifiers adjusted in each iteration, determine whether each CPU can reset the value of the CPU status identifier according to the reset cycle.

[0061] Step S113: If the value of the CPU status identifier fails to be reset, determine the corresponding CPU operation abnormality and realize the monitoring of the program operation status of each CPU in the controller.

[0062] The preset period is shorter than the reset period of the CPU status identifier within the controller.

[0063] Specifically, the controller stores the CPU status identifier corresponding to each CPU in its memory, and each CPU can reset the value of the CPU status identifier stored in memory every reset cycle when it is running normally.

[0064] More specifically, a shared memory region (DLUM, Distributed Local Memory Unit) is set up in the controller's memory, accessible to all CPUs, to enable data sharing and synchronization among multiple CPUs in the MCU. This shared memory region resides in the global address space, rather than in the CPU's private local RAM (ScratchPad RAM).

[0065] In this shared memory region, each CPU has a corresponding DLMU RAM. This allows each CPU to access not only its own DLMU RAM, but also the DLMU RAM of other CPUs via address offsets, thus enabling data sharing.

[0066] Within this shared memory region, a new segment is defined based on the DLMU address to store variables representing the operating status of each CPU. For example, the defined segment could be "WDG_FLAG".

[0067] Each CPU core has a variable defined to monitor its running status, and this variable is used as a CPU status identifier, allocated to the "WDG_FLAG" segment. For example, the CPU status identifier is "wdg_corex", where "x" is the CPU core number. For instance, if the controller has three CPU cores, CPU0, CPU1, and CPU2 (corresponding to numbers 0, 1, and 2), then for CPU0, its corresponding CPU status identifier is "wdg_core0", and this CPU status identifier is written into the "WDG_FLAG" segment of this shared memory region.

[0068] Each CPU contains an internal program that resets its corresponding CPU status identifier. During normal CPU operation, these instructions are executed sequentially. Each time the loop reaches the reset instruction, a CPU status identifier reset operation is performed. Thus, each CPU resets its corresponding CPU status identifier every reset cycle during normal operation. For example, with a reset cycle of 100ms, CPU0 will set its corresponding CPU status identifier to N every 100ms, that is, execute the "wdg_core0=N" reset instruction, causing the CPU status identifier stored in the shared memory area to be reset to N every 100ms.

[0069] For an external watchdog timer, the controller's memory (more specifically, the shared memory region) is accessed every preset period. The CPU status identifiers stored in this shared memory region are read, and their values ​​are iteratively adjusted using a preset step size. Each CPU status identifier is then adjusted individually. For example, for a single CPU status identifier, the preset step size is increased or decreased based on the currently read value to obtain the adjusted CPU status identifier.

[0070] Then, based on the adjusted value of the CPU status identifier, it is determined whether the corresponding CPU can reset the value of the CPU status identifier according to the reset cycle.

[0071] If the CPU status identifier cannot be reset, the corresponding CPU is determined to be malfunctioning. If the CPU status identifier can be reset, the corresponding CPU is determined to be functioning normally.

[0072] Specifically, taking a preset period of 10ms as an example, the external watchdog will access the controller's memory every 10ms to iteratively adjust the status identifiers of each CPU. Under normal operation of each CPU, the value of each CPU status identifier will be reset to N every 100ms (reset period). If there is an abnormality in the CPU, the value of each CPU status identifier cannot be reset to N in time, and will increase or decrease continuously as the external watchdog adjusts the CPU status identifiers.

[0073] For example, an external watchdog timer decrements the value of each CPU status identifier by 1 every 10ms. If the CPU is running normally, it sets the CPU status identifier to N every 100ms. The value of the CPU status identifier will be reset to N by the CPU before it reaches 0. If the CPU is not running normally, the external watchdog timer will continuously decrement (or increment) the CPU status identifier, causing the CPU status identifier to become 0 after a certain decrement (or reach a preset value after a certain increment). Thus, it can be determined whether each CPU can reset the value of the CPU status identifier according to the reset cycle by checking whether the value of the CPU status identifier is 0 (or whether it has reached the preset value).

[0074] If each CPU can reset the value of its status identifier according to the reset cycle, for example, if the adjusted value of each CPU status identifier is not 0, it indicates that each CPU is running normally. If one or more CPUs fail to reset the value of their status identifiers according to the reset cycle, that is, if the value of one or more CPU status identifiers is 0, it indicates that the program of one or more CPUs has malfunctioned, thereby enabling the monitoring of the program running status of each CPU.

[0075] Therefore, by monitoring the operating status of each CPU through its status identifier, the CPU that is causing the program to malfunction can be identified through the abnormal CPU status identifier, thus achieving the effect of anomaly localization.

[0076] Meanwhile, in this embodiment, the CPU program's abnormal operation is also determined by iteratively adjusting the CPU status identifier and judging whether the CPU status identifier has been reset by the CPU. In this way, when a software-level fault occurs, such as the program crashing or getting stuck in an infinite loop, the CPU will not be able to perform the CPU status identifier reset operation according to the reset cycle, causing the external watchdog to trigger the fault reset controller operation. For hardware-level faults, such as power fluctuations, wire lock-up, or internal damage to the controller chip, the CPU will not be able to operate normally or access memory, which will also cause the CPU to fail to complete the CPU status identifier reset, and will also cause the external watchdog to trigger the fault reset control operation.

[0077] In other words, regardless of whether the controller experiences a hardware or software failure, the multi-core controller operation status monitoring method of this embodiment can promptly reset the controller to resolve the fault state, thereby improving the reliability of multi-core controller operation status monitoring.

[0078] Continue by Figure 1 and Figure 2 As shown, in some exemplary embodiments, step S111 iteratively adjusts the values ​​of the stored CPU status identifiers based on a preset step size, including subtracting the preset step size from the values ​​of the CPU status identifiers. For example, an external watchdog accesses memory once every preset period (every 10ms) to subtract the preset step size from the values ​​of each CPU status identifier stored in memory, performing a decrement operation once every preset period.

[0079] For example, assuming the current value of the CPU status identifier for CPU0 is 100, and the preset step size is 1, the current value of the CPU status identifier is decremented by 1 to 99, and the CPU status identifier of CPU0 stored in memory is updated to 99. After 10ms, it is decremented by 1 again from 99 to 98, and the CPU status identifier of CPU0 stored in memory is updated to 98, and so on, subtracting the preset step size from the current value of the CPU status identifier. If the CPU status identifier is adjusted to 98, and then reset to 100 during the 10ms wait, the next time the preset identifier adjustment verification policy is executed, the current CPU status identifier will be 100, subtracted by the preset step size, and become 99.

[0080] Alternatively, in another possible implementation, the above-mentioned iterative adjustment of the value of the CPU status identifier stored in memory based on a preset step size may specifically include: increasing the value of the CPU status identifier by a preset step size.

[0081] For example, assuming the current value of the CPU status identifier for CPU0 is 10, and the preset step size is 1, the current value of the CPU status identifier is incremented by 1 to become 11, and the CPU status identifier for CPU0 stored in memory is updated to 11. After 10ms, it is incremented by 1 again to become 12, and the CPU status identifier for CPU0 stored in memory is updated to 12, and so on, each time increasing the preset step size based on the value of the read CPU status identifier. Assuming that after adjusting the CPU status identifier to 12, during the 10ms wait, the CPU resets the CPU status identifier to 10. Thus, the next time the preset identifier adjustment verification policy is executed, the read CPU status identifier will be 10, and after increasing the preset step size, it will become 11.

[0082] Therefore, by adjusting each CPU status identifier using an iterative adjustment method that increases or decreases the preset step size, the CPU status identifier can be updated without complex calculation logic, which helps to reduce the hardware computation consumption and monitoring latency of the external watchdog.

[0083] Continue by Figure 1-2 and combined Figure 3 As shown, in some exemplary embodiments, in step S112 above, it is determined whether each CPU can reset the value of the CPU status identifier according to the reset cycle based on the value of each CPU status identifier after each iteration. Specifically, it may include the following steps S1121-S1123.

[0084] Step S1121: Determine whether the value of the adjusted CPU status identifier is the preset termination threshold.

[0085] Step S1122: If the adjusted CPU status identifier is the preset termination threshold, determine that the CPU failed to reset the value of the CPU status identifier.

[0086] Step S1123: If the adjusted CPU status identifier is not the preset termination threshold, determine that the CPU can reset the value of the CPU status identifier.

[0087] For example, the preset termination threshold can be determined based on the aforementioned preset step size. For instance, suppose the external watchdog decrements the CPU status identifier by 1 every 10ms, and the CPU resets the CPU status identifier to 100 every 100ms. Normally, the CPU should reset the value to 100 after the external watchdog adjusts the CPU status identifier to 90 10 times. However, if the CPU malfunctions and fails to reset to 100 after 10 adjustments, the value is adjusted to 89 on the 11th adjustment. The preset termination threshold can be set to 89 or lower, for example, it could be 0.

[0088] For example, assuming that the external watchdog increments the CPU status identifier by 1 every 10ms, and the CPU resets the CPU status identifier to 100 every 100ms, then the preset termination threshold can be set to a value of 111 or higher, such as 200.

[0089] If the adjusted CPU status identifier value is detected to be the preset termination threshold, it indicates that the CPU has failed to reset the CPU status identifier value every reset cycle, meaning the CPU is malfunctioning. If the adjusted CPU status identifier value is not the preset termination threshold, it indicates that the CPU can reset the CPU status identifier value every reset cycle, meaning the CPU is operating normally.

[0090] Therefore, by using a preset termination threshold as the criterion for judging whether the CPU is running abnormally, it is possible to detect and reset the CPU in a timely manner when it is running abnormally, thus realizing the abnormality judgment.

[0091] In some embodiments, the preset termination threshold needs to meet the following conditions: First, during normal CPU operation, the CPU status identifier value is reset to a preset starting reference value according to the reset cycle. The preset termination threshold is the value obtained by iteratively adjusting a preset number of times, starting from the preset starting reference value, following a preset adjustment direction, and using a preset step size. The preset number of adjustments is greater than the ratio of the reset cycle to the preset cycle.

[0092] The preset adjustment direction is the direction in which the external watchdog adjusts the CPU status identifier each time, such as increasing or decreasing the preset step size.

[0093] For example, if the reset period is 100ms and the preset period is 10ms, the ratio of the reset period to the preset period is 10. Therefore, the preset number of iterations should be greater than 10, such as 11 or 12, which are positive integers greater than 10. For instance, the preset number of iterations could be 100. Taking the example of an external watchdog timer decreasing by a preset step size each time, assuming the preset starting base value is 100 and the preset number of iterations is 100, then after 100 adjustments, it will be 0. This preset termination threshold can be set to 0.

[0094] Therefore, by setting the relationship between the preset termination threshold and the preset starting reference value, it is ensured that the normally operating CPU has enough time to complete the reset of the CPU status identifier, thereby enabling reliable monitoring of the CPU operating status and reducing the probability of accidental reset under normal operating conditions.

[0095] Continue by Figures 1-3 and combined Figure 4 As shown, in some exemplary embodiments, in step S120 above, when it is detected that the program running status of each CPU is normal, the timer is reset so that the timer starts counting again. Specifically, this may include the following steps S121-S122.

[0096] Step S121: If the program running status of each CPU is detected to be normal, verify the external watchdog and the logical operation capability of each CPU.

[0097] Step S122: If the external watchdog timer and the logic operation capabilities of each CPU are normal, reset the timer so that the timer starts counting again.

[0098] For example, if none of the adjusted CPU status identifiers are at the preset termination threshold, it indicates that all CPUs are operating normally. When all CPUs are operating normally, the external watchdog timer and the logical operation capabilities of each CPU are verified to determine if their functionality is normal. If the verification passes, the timer within the external watchdog timer is reset, and a watchdog feed operation is performed, causing the timer to restart, for example, from 320ms.

[0099] If each CPU program is running normally, the external watchdog timer and the CPU's logic computing capability are first verified. If the logic computing capability verification passes, the timer is then reset. This allows for timely reset even when the CPU program is running normally but the logic computing capability is abnormal, thus improving the reliability of monitoring the operating status of the multi-core controller.

[0100] Continue by Figures 1-4 and combined Figure 5 As shown, in some exemplary embodiments, the verification of the external watchdog and the logical operation capabilities of each CPU in step S121 may specifically include the following steps S1211-S1214.

[0101] Step S1211: Output a dog feed signal to the CPU, so that the CPU performs calculation operations according to the preset algorithm logic and writes the calculation result of the CPU into the first preset register.

[0102] Specifically, in step S310, the preset algorithm logic can be pre-written into the CPU's program. When the external watchdog detects that none of the adjusted CPU status identifiers are at the preset termination threshold, each CPU executes the preset calculation operation according to the preset algorithm logic. More specifically, each CPU calculates the 16-bit ALU (Arithmetic Logic Unit) value. The ALU is the core component responsible for performing basic arithmetic operations (such as addition, subtraction, multiplication, and division) and logical operations (such as AND, OR, NOT, and XOR).

[0103] In step S1211, the ALU (Arithmetic Logic Unit) of each CPU executes the preset algorithm logic to obtain a 16-bit result, and writes the 16-bit result (i.e., the CPU's calculation result) into the first preset register. Specifically, the first preset register may be the WDMR (Watchdog MCU Result) register.

[0104] Step S1212: With the CPU's calculation result written into the first preset register, the calculation operation is performed according to the preset algorithm logic to obtain the watchdog calculation result.

[0105] Specifically, when the CPU's calculation result is detected in the first preset register, the external watchdog also performs a calculation operation according to the same preset algorithm logic as the CPU to obtain the watchdog calculation result.

[0106] Step S1213: Write the watchdog calculation result into the second preset register, so that the CPU reads the watchdog calculation result in the second preset register and compares the watchdog calculation result with the CPU calculation result.

[0107] Step S1214: If the watchdog calculation result is consistent with the CPU calculation result, it is confirmed that the external watchdog and the logic operation capabilities of each CPU are normal.

[0108] Specifically, after obtaining the watchdog calculation result in step S1212, the watchdog calculation result is written into the second preset register in step S1213. The second preset register may be the WDAR (Watchdog 900719Result) register.

[0109] Then each CPU reads the second preset register to obtain the watchdog calculation result, and compares whether the watchdog calculation result is consistent with the CPU's calculation result. If they are consistent, it indicates that the external watchdog and the logic operation capability of each CPU are normal, and the above-mentioned steps of resetting the timer in the external watchdog to perform the watchdog feeding operation are executed.

[0110] Conversely, if the CPU fails to calculate the corresponding result and write it into the first preset register within the first preset time period when the CPU is executing the preset algorithm logic for calculation, it indicates that the CPU's ALU algorithm logic calculation unit is malfunctioning. In this case, the step of resetting the external watchdog timer will not be executed, that is, the watchdog feeding operation will not be performed until the timer expires, causing the CPU to reset.

[0111] Furthermore, assuming that the CPU calculates the corresponding result and writes it into the first preset register within the first preset time period, if the external watchdog fails to calculate the corresponding result and write it into the second preset register within the second preset time period, it indicates that the external watchdog is malfunctioning. In this case, the step of resetting the external watchdog timer will not be executed, that is, the watchdog feeding operation will not be executed until the timer ends.

[0112] Furthermore, assuming that the CPU calculates the corresponding result and writes it into the first preset register within the first preset time period, and the external watchdog calculates the corresponding result and writes it into the second preset register within the second preset time period, if the watchdog calculation result is inconsistent with the CPU calculation result, it indicates that there is an abnormality in the external watchdog or the CPU. In this case, the step of resetting the external watchdog timer will not be executed, that is, the watchdog feeding operation will not be executed until the timer ends and a reset is triggered.

[0113] Therefore, by verifying the logic operation capabilities of the external watchdog and the CPU, the watchdog feeding operation is performed only when it is confirmed that the functions of both the CPU and the external watchdog are normal. If the functions of both are abnormal, the watchdog feeding operation is not performed, so that the external watchdog can reset the CPU in time and improve the reliability of CPU status monitoring.

[0114] Continue by Figures 1-5 As shown, in some of the exemplary embodiments, among the tasks to be processed by the CPU, the task for which the CPU resets the value of the CPU status identifier according to the reset cycle has the lowest priority.

[0115] Specifically, in automotive ECU software development, priority-based task preemption is a common scheduling strategy. This mechanism allows high-priority tasks to interrupt low-priority tasks that are currently executing, thereby ensuring that the system can respond quickly to important events or requests, improving the system's real-time performance and reliability.

[0116] In other words, high-priority tasks will be processed first. In this embodiment, within the CPU, the task that resets the value of the CPU status identifier is set to the lowest priority.

[0117] In this way, within each cycle, the task of resetting the CPU status identifier can be executed only after the CPU has finished processing all other tasks, thus enabling monitoring of the execution status of multiple tasks. In other words: When a high-priority task fails, the lowest-priority task related to feeding the dog (i.e., resetting the CPU status identifier) ​​cannot execute, thus triggering a CPU reset. When every task runs normally, the lowest-priority task resetting the CPU status identifier will execute according to the normal reset cycle, and the CPU will not reset.

[0118] Therefore, by setting the CPU status identifier reset task to the lowest priority, the CPU is ensured to execute core control tasks first. This guarantees that the CPU status identifier reset task will only be executed after all other tasks have completed normally, thus enabling comprehensive monitoring of the execution status of all pending CPU tasks. In other words, if any high-priority core task or low-priority auxiliary task experiences anomalies such as crashes or infinite loops, the lowest-priority CPU status identifier reset task will fail to execute on time, triggering the external watchdog timer's reset operation. This improves the reliability of the controller's operational status monitoring.

[0119] It is worth noting that, regarding the monitoring method for the multi-core controller's operating status in this embodiment, based on the above exemplary implementations, in specific implementation, as a preferred embodiment, it is still based on... Figure 1-5 As shown, it may include, for example: The following example illustrates the controller, which includes three CPUs: CPU0, CPU1, and CPU2. Each CPU resets its CPU status identifier to 100 every 100ms, and an external watchdog decrements the CPU status identifier by 1 every 10ms. The preset termination threshold is 0.

[0120] The watchdog timer starts counting down from 320ms. During this time, CPU0, CPU1, and CPU2 set the CPU status identifiers stored in the shared memory area to 100, that is, wdg_core0=100, wdg_core1=100, and wdg_core2=100. Then, the countdown restarts for 100ms.

[0121] The external watchdog is monitored for the first time (at 10ms): The external watchdog is currently reading the shared memory area in memory and reads three CPU status identifiers, all of which are 100. After decrementing by 1, each CPU status identifier becomes 99.

[0122] If it is determined that the values ​​of the CPU status identifiers are not at the preset termination threshold, then it is determined that all CPUs are running normally. At this time, each CPU starts to execute the preset algorithm logic and calculates the CPU's calculation result within the first preset time period and writes it into the first preset register. The external watchdog also executes the preset algorithm logic and calculates the watchdog's calculation result within the second preset time period and writes it into the second preset register. Each CPU determines that its own calculation result is consistent with the watchdog's calculation result, so it performs a watchdog feed operation to reset the watchdog timer, so that the watchdog timer starts counting down again from 320ms.

[0123] The second to ninth monitoring: Every 10ms, the external watchdog repeats the process of reading - decrementing by 1 - judging. For example, at 20ms, the status identifier of each CPU changes from 99 to 98; at 30ms, the status identifier of each CPU changes from 98 to 97, etc.; at 90ms, the status identifier of each CPU changes from 92 to 91.

[0124] During the tenth monitoring, the external watchdog changed the status identifiers of each CPU from 91 to 90. After that, the CPU reset cycle of 100ms expired. If the program on CPU0 crashes, wdg_core0 will not be reset to 100, while wdg_core1 and wdg_core2 will be reset to 100 normally.

[0125] Repeat the above process until the status identifier of CPU0 is reduced to 0 for the 100th time. If the CPU status identifier of CPU0 reaches the preset termination threshold, the watchdog timer reset operation will not be performed. This will cause the external watchdog timer to automatically trigger the reset of each CPU after the 320ms countdown ends, so as to resolve the program runaway fault state of CPU0.

[0126] In the above preferred embodiments, the specific implementation process of each step can still be referred to the description in the above exemplary embodiments, and the beneficial effects brought about by the preferred embodiments can also be referred to the description in the above exemplary embodiments.

[0127] The multi-core controller operation status monitoring method in this embodiment adopts the above design. An external watchdog is set to monitor the operation status of each CPU. Since the clock source of the external watchdog does not depend on the clock source of each CPU, even if any CPU of the controller is damaged or fails, or the controller's clock fails, the external watchdog can still monitor normally according to the preset cycle, and will not fail synchronously due to the failure of the controller's CPU. It can still monitor the CPU's operation status, thereby improving the reliability of multi-core controller operation status monitoring.

[0128] Meanwhile, in this embodiment, the operating status of each CPU is monitored by each CPU status identifier, thereby identifying the CPU that is running abnormally through the abnormal CPU status identifier, so as to achieve the effect of anomaly localization.

[0129] Meanwhile, in this embodiment, the CPU program's abnormal operation is determined by iteratively adjusting the CPU status identifier and judging whether the CPU status identifier has been reset by the CPU. In this way, when a software-level fault occurs, such as a program crashing or getting stuck in an infinite loop, the CPU will not be able to perform the CPU status identifier reset operation according to the reset cycle, causing the external watchdog to trigger the fault reset controller operation. For hardware-level faults, such as power fluctuations, wire lock-up, or internal damage to the controller chip, the CPU will not be able to operate normally or access memory, which will also cause the CPU to fail to complete the CPU status identifier reset, and will also cause the external watchdog to trigger the fault reset control operation.

[0130] In other words, regardless of whether the controller experiences a hardware or software failure, the multi-core controller operation status monitoring method of this embodiment can promptly reset the controller to resolve the fault state, thereby improving the reliability of multi-core controller operation status monitoring.

[0131] Meanwhile, this embodiment also verifies the logic computing capabilities of the external watchdog and the CPU. If the functions of both the CPU and the external watchdog are confirmed to be normal, the watchdog feeding operation is performed. If the functions of both are abnormal, the watchdog feeding operation is not performed, so that the external watchdog can reset the CPU in time and improve the reliability of CPU status monitoring.

[0132] An embodiment of the second aspect of this application provides a monitoring system for the operating status of a multi-core controller, the monitoring system including a multi-core controller and an external watchdog.

[0133] The multi-core controller includes multiple CPUs, each operating independently. The external watchdog can execute corresponding application code to implement the functionality described in the foregoing method embodiments.

[0134] The external watchdog in the multi-core controller operation status monitoring system of this embodiment can monitor the operation status of each CPU core of the multi-core controller by executing the multi-core controller operation status monitoring method in the above method embodiment. It can reset in time when each CPU is abnormal, and it does not depend on the CPU clock source. It still has normal operation status monitoring capability when the clock source of each CPU is abnormal, which helps to improve the reliability of operation status monitoring.

[0135] An embodiment of the third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the content shown in the above-described method embodiments. Furthermore, by running this computer program, it is possible to monitor the operating status of each CPU of a multi-core controller, promptly reset any CPU malfunctions, and maintain normal operating status monitoring capabilities even when the clock sources of the CPUs are abnormal, regardless of the CPU's clock source, thereby improving the reliability of operating status monitoring.

[0136] The above are merely some embodiments of this application and are not intended to limit this application. The technical features or structures in the foregoing different embodiments can be arbitrarily combined to form other specific technical solutions as needed. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the protection scope of the claims of this application.

Claims

1. A method for monitoring the operating status of a multi-core controller, using an external watchdog connected to the controller, characterized in that, The external watchdog timer has a built-in timer, the controller has multiple CPUs, and the method includes: When the external watchdog is activated and the timer is triggered to start counting, the program running status of each CPU in the controller is monitored at preset intervals. If the program running status of each CPU is detected to be normal, the timer is reset so that the timer starts counting again; If an abnormal program running state is detected in at least one of the CPUs, the timer of the external watchdog is not reset, so that the external watchdog automatically resets each of the CPUs after the timer expires.

2. The method for monitoring the operating status of a multi-core controller according to claim 1, characterized in that, The controller stores CPU status identifiers corresponding to each CPU in its memory, and each CPU is used to reset the CPU status identifiers every reset cycle. The step of monitoring the program execution status of each CPU within the controller at preset intervals includes: The controller's memory is accessed every preset period to read the CPU status identifier corresponding to each CPU, and the stored values ​​of each CPU status identifier are iteratively adjusted based on a preset step size. Based on the CPU status identifiers adjusted in each iteration, determine whether each CPU can reset the value of the CPU status identifier according to the reset cycle. If the value of the CPU status identifier fails to be reset, the corresponding CPU operation is determined to be abnormal, thereby enabling monitoring of the program operation status of each CPU within the controller; The reset period is longer than the preset period.

3. The method for monitoring the operating status of a multi-core controller according to claim 2, characterized in that, The step of iteratively adjusting the value of the CPU status identifier stored in the memory based on a preset step size includes: Subtract the preset step size from the value of each CPU status identifier; or... The value of each CPU status identifier is increased by the preset step size.

4. The method for monitoring the operating status of a multi-core controller according to claim 3, characterized in that, The step of determining whether each CPU can reset the value of the CPU status identifier according to the reset cycle based on the CPU status identifier adjusted in each iteration includes: Determine whether the adjusted value of the CPU status identifier is a preset termination threshold; If the adjusted CPU status identifier is the preset termination threshold, it is determined that the CPU failed to reset the value of the CPU status identifier. If the adjusted CPU status identifier is not the preset termination threshold, it is determined that the CPU can reset the value of the CPU status identifier.

5. The method for monitoring the operating status of a multi-core controller according to claim 4, characterized in that: When the CPU is running normally, the value of the CPU status identifier is reset to a preset starting reference value according to the reset cycle. The preset termination threshold is the value obtained by iteratively adjusting a preset number of times, starting from the preset starting reference value, according to the preset adjustment direction, and with the preset step size as the reference. The preset number of times is greater than the ratio of the reset period to the preset period.

6. The method for monitoring the operating status of a multi-core controller according to claim 1, characterized in that, The step of resetting the timer when it is detected that the program running status of each CPU is normal, causing the timer to start counting again, includes: If the program running status of each CPU is detected to be normal, the external watchdog and the logical operation capability of each CPU are verified. If the external watchdog timer and the logic operation capabilities of each CPU are normal, the timer is reset so that the timer starts counting again.

7. The method for monitoring the operating status of a multi-core controller according to claim 6, characterized in that, The verification of the external watchdog timer and the logical operation capabilities of each CPU includes: Output a dog-feeding signal to the CPU, causing the CPU to perform calculation operations according to a preset algorithm logic, and write the CPU calculation result into the first preset register; When the CPU's calculation result is written into the first preset register, the calculation operation is performed according to the preset algorithm logic to obtain the watchdog calculation result; The watchdog calculation result is written into the second preset register, so that the CPU reads the watchdog calculation result in the second preset register and compares the watchdog calculation result with the CPU calculation result; If the watchdog timer calculation result is consistent with the CPU calculation result, it is determined that the external watchdog timer and the logic operation capabilities of each CPU are normal.

8. The method for monitoring the operating status of a multi-core controller according to any one of claims 1 to 7, characterized in that: Among the tasks to be processed by the CPU, the task for which the CPU resets the value of the CPU status identifier according to the reset cycle has the lowest priority.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it can perform the monitoring method for the operating status of the multi-core controller as described in any one of claims 1-8.

10. A monitoring system for the operating status of a multi-core controller, characterized in that, The system includes: A multi-core controller includes multiple CPUs, each of which operates independently; An external watchdog, connected to the multi-core controller, is capable of executing the monitoring method for the operating status of the multi-core controller as described in any one of claims 1-8.

Images