Method and apparatus for monitoring abnormal reset of multi-core microcontroller unit

Abstract

An embodiment of the present invention relates to the technical field of microcontrollers and discloses a method for monitoring abnormal resets in a multi-core microcontroller unit, the method including the steps of: detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, obtaining abnormal program information at the corresponding program abnormality site, and writing the processing core identification information and the abnormal program information to a designated storage area in a non-clear random access memory, the designated storage area in the non-clear random access memory being configured so that after a software reset of the microcontroller unit is performed, the data in the designated storage area remains the same as the data stored before the reset. In the method for monitoring abnormal resets in a multi-core microcontroller unit in this embodiment, the non-clear random access memory is designed so that when an abnormality occurs in the operation of the entire program, information on the abnormality is stored in a designated area in the non-clear random access memory to protect the data, and the data in the protected area is not cleared when a subsequent reset is performed.

Description

[Technical Field]

[0001] The present invention relates to the technical field of microcontrollers, and particularly to a method and apparatus for monitoring abnormal reset of a multi-core microcontroller unit. [Background technology]

[0002] Currently, in automotive controllers, if the MCU system operates abnormally due to improper user use of MCU resources or a fault in the MCU itself, the software will enter an abnormal program (TRAP) branch. At this time, the typical software approach is to reset the software (passive reset) when the watchdog times out, thereby restoring the software to a normal state. Some designers record this fault information in read-only memory (ROM), i.e., an NVM module under the AUTOSAR specification, before resetting the software, and then reset the MCU, so that the cause of the fault can be easily queried after the reset.

[0003] As a result, the following problems exist: 1. The occurrence of a TRAP may be due to an error in the NVM (or its associated modules, MemIf, Fee, and Fls). In practice, such errors are common, and operating the NVM in this case may result in a new fault. 2. This passive reset method using a watchdog typically requires a long time, from tens to hundreds of milliseconds, not to mention the time required for NVM operation itself (especially when switching the Fee sector), making it unfavorable for rapid fault recovery of the MCU. 3. In a multi-core MCU system, the NVM typically runs on only one core (e.g., Core0). Obviously, if another core (e.g., Core1) enters a trap program branch, Core1 cannot directly access the NVM interface. 4. A passive reset typically requires a certain filtering time (e.g., the watchdog timeout time), making it unfavorable for rapid fault recovery. Therefore, a method for quickly resetting a fault and being able to query the cause of the fault after the reset is a technical challenge that must be addressed by those skilled in the art. Summary of the Invention [Problem to be solved by the invention]

[0004] In response to the above-mentioned defects, an embodiment of the present invention discloses an abnormal reset monitoring method for a multi-core microcontroller unit, which uses random access memory (RAM) to record corresponding information, thereby enabling faster recovery from the fault, and uses voluntary reset instead of passive reset, making the microcontroller unit reset faster and more controllable in software flow. [Means for solving the problem]

[0005] According to a first aspect of an embodiment of the present invention, a method for monitoring abnormal reset of a multi-core microcontroller unit is disclosed, the method for monitoring abnormal reset of a multi-core microcontroller unit includes: After detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, obtaining abnormal program information of the corresponding program abnormality location, including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; and obtaining current processing core identification information related to the abnormal program information, writing the processing core identification information and the abnormal program information into a designated storage area of ​​a no-clear random access memory (RAM is not cleared after reset, hereinafter abbreviated as "no-clear RAM"), and performing a microcontroller unit reset operation, wherein the designated storage area in the no-clear RAM is configured so that after a software reset of the microcontroller unit is performed, the data in the designated storage area remains the same as the data stored before the reset.

[0006] In one alternative embodiment, in the first aspect of the embodiment of the present invention, before the step of performing the microcontroller unit reset operation, The method further includes adjusting a flag state of an abnormal flag position, which includes a first state and a second state, to the first state.

[0007] After recording the fault information, the flag status needs to be adjusted. In this way, when the application program is initialized next time, the flag status information can be used to directly determine whether to perform the next operation, thereby improving the fluency of the entire program operation.

[0008] As an alternative embodiment, in the first aspect of the embodiment of the present invention, after the step of acquiring current processing core identification information related to the abnormal program information, The method further includes calculating a first check value of the processing core identification information and the abnormal program information based on a cycle check algorithm, and writing the first check value into a designated storage area of ​​a non-clear random access memory.

[0009] The CRC32 algorithm is used to perform redundancy calculations on the corresponding information to obtain a check value, which is used as the basic comparison data for subsequent redundancy checks. In this way, after the software is reset, the CRC32 value of the non-clear RAM is recalculated and compared with the CRC32 value recorded before the reset, thereby determining whether the non-clear RAM has been tampered with, further improving the accuracy of subsequent fault data output.

[0010] In one alternative embodiment, in the first aspect of the embodiment of the present invention, after the step of performing the microcontroller unit reset operation, acquiring processing core identification information and abnormal program information from a designated storage area of ​​the non-clear random access memory in a main processing core (Core0); calculating a second check value of the processing core identification information and the abnormal program information in the main processing core (Core0) based on a cycle check algorithm, comparing the second check value with a first check value stored in a non-clear random access memory, and determining a corresponding fault diagnosis code and snapshot information based on the processing core identification information, the abnormal program information, and a setting condition if the comparison is successful; The method further includes transmitting the fault diagnostic code and snapshot information to a diagnostic event management module so that a user can obtain the corresponding fault diagnostic code through a diagnostic interface.

[0011] The above steps realize the analysis and recording of abnormal fault information, and provide corresponding diagnostic interfaces for corresponding users to directly obtain corresponding fault diagnosis information, which greatly improves the possibility of analyzing the root cause of the fault.

[0012] In one alternative embodiment, in the first aspect of the embodiment of the present invention, after detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, determining at least two abnormality type information based on the abnormal program branch; determining an abnormal program level that has a certain mapping relationship with each abnormal type information based on the abnormal type information; When detecting that the abnormal program level is a first abnormal level, acquiring first abnormal address information in a register EIPC and acquiring a first abnormal cause code in a register EIIC; The method further includes the steps of, when detecting that the abnormal program level is the second abnormal level, respectively obtaining second abnormal address information in the register FEPC and obtaining a second abnormal cause code in the register FEIC.

[0013] In specific implementation, by associating the abnormality type information with the abnormal program level, any type of abnormality can be mapped to the corresponding abnormality level, and the corresponding abnormality address and abnormality cause code can be obtained, which facilitates subsequent information recording, and the abnormality type can be simplified and recorded based on the actual structure.

[0014] As one alternative embodiment, in the first aspect of the embodiment of the present invention, the abnormal time information is The system time information is acquired after entering the abnormal program branch, and the system time information is determined as abnormal time information, which is time stamp information at the time of the abnormality.

[0015] The above step is a specific time acquisition step, which can determine the information on the time point when an abnormality occurs and improve the convenience of acquiring time information.

[0016] In one alternative embodiment, in a first aspect of the present invention, the size of the space in the designated memory area is at least 200 bytes, and the non-clear RAM is configured to be shared by a multi-core microcontroller unit.

[0017] Random Access Memory (RAM) has the characteristics of fast read speed and user-allocated memory, allowing data to be accessed quickly and shared by multi-core microcontroller units. The use of multi-core shared no-clear RAM ensures that only one core processes faults while the other cores only record fault information. The "no-clear" feature also ensures that the recorded fault information remains reserved after a quick reset.

[0018] Generally, RAM is much more ample than NVM resources and its allocation is more flexible, so when setting the space for a specific designated storage area, sufficient space can be reserved.

[0019] A second aspect of the present invention discloses an abnormal reset monitoring device for a multi-core microcontroller unit, and the abnormal reset monitoring device for a multi-core microcontroller unit includes: an acquiring module for acquiring abnormal program information of a corresponding program abnormality site after detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, the abnormal program information including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; and a storage module for obtaining current processing core identification information related to the abnormal program information, writing the processing core identification information and the abnormal program information to a designated storage area in a non-clear RAM, and performing a microcontroller reset operation, wherein the designated storage area in the non-clear RAM is configured so that after a software reset of the microcontroller unit is performed, the data in the designated storage area remains as the data stored before the reset.

[0020] A third aspect of an embodiment of the present invention discloses an electronic device, the electronic device including a memory in which executable program code is stored and a processor coupled to the memory, the processor calling the executable program code stored in the memory to execute the abnormal reset monitoring method for a multi-core microcontroller unit disclosed in the first aspect of an embodiment of the present invention.

[0021] A fourth aspect of the present invention discloses a computer-readable storage medium storing a computer program, which causes a computer to execute the abnormal reset monitoring method for a multi-core microcontroller unit disclosed in the first aspect of the present invention. [Effects of the Invention]

[0022] The embodiment of the present invention has the following advantageous effects compared to the prior art.

[0023] In an embodiment of the present invention, the method for monitoring abnormal reset of a multi-core microcontroller unit is designed using no-clear random access memory (no-clear RAM) instead of NVM, so that when an abnormality occurs in the operation of the entire program, the abnormality information is quickly stored in a designated area of ​​the no-clear RAM to protect the data, and a rational design prevents the data in the protected area from being cleared when a subsequent reset is performed. [Brief explanation of the drawings]

[0024] In order to more clearly explain the technical solutions in the embodiments of the present invention, the following briefly describes the drawings that need to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without paying creative labor. [Figure 1] 4 is a flowchart of a method for monitoring abnormal reset of a multi-core microcontroller unit disclosed in an embodiment of the present invention; [Figure 2]3 is a detailed flowchart of a method for monitoring abnormal reset of a multi-core microcontroller unit disclosed in an embodiment of the present invention; [Figure 3] 3 is a flowchart of a fault analysis disclosed in an embodiment of the present invention. [Figure 4] 1 is a flowchart for determining an abnormality level and obtaining an abnormality cause disclosed in an embodiment of the present invention. [Figure 5] 1 is a schematic diagram of an information recording process after the software disclosed in the embodiment of the present invention enters an abnormal program branch; [Figure 6] 1 is a flowchart of a method for a no-clear RAM that does not clear upon resetting disclosed in an embodiment of the present invention. [Figure 7] 1 is a structural schematic diagram of a device for monitoring abnormal reset of a multi-core microcontroller unit according to an embodiment of the present invention; [Figure 8] 1 is a structural schematic diagram of an electronic device according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0025] The following clearly and completely describes the technical solutions in the embodiments of the present invention, in conjunction with the drawings in the embodiments of the present invention, and obviously, the described embodiments are only some embodiments of the present invention, not all embodiments, and all other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative work fall within the scope of protection of the present invention.

[0026] It should be explained that the terms "first," "second," "third," "fourth," etc. in the present specification and claims are used to distinguish between different objects, rather than to describe a particular order. The terms "comprise" and "have" and any variations thereof in the embodiments of the present invention are intended to cover a non-exclusive inclusion, and illustratively, a process, method, system, product, or apparatus comprising a series of steps or units need not be limited to those steps or units expressly recited, but may include other steps or units not expressly recited or inherent to those processes, methods, products, or apparatus.

[0027] When an MCU operation failure causes a program to enter an abnormal program (TRAP) branch, the normal program fails to feed the watchdog, and the watchdog times out. This resets the MCU (passively) to restore the software to its normal state. This is the most common method for handling MCU abnormalities. To identify the cause of the abnormal reset, when software enters a TRAP, the error information is typically recorded in nonvolatile memory (the AUTOSAR architecture uses NVM). After the software is reset, the error analysis is performed by reading the information retrieved from the NVM. NVM has inherent problems and is not applicable to abnormal reset processing programs. The "passive reset" method is also not advantageous for time control of software recovery. Embodiments of the present invention disclose a method, device, electronic device, and storage medium for monitoring abnormal resets in multi-core microcontroller units. By designing a non-clear random access memory, when an abnormality occurs in the overall program operation, the error information can be stored in a designated area of ​​the non-clear random access memory to protect the data. The data in the protected area is not cleared during subsequent resets.

[0028] Example 1 Referring to FIG. 1, FIG. 1 is a flowchart of a method for monitoring abnormal reset of a multi-core microcontroller unit disclosed in an embodiment of the present invention. The execution entity of the method described in the embodiment of the present invention is a software and / or hardware execution entity that can receive relevant information and send certain commands via wired and / or wireless methods. Of course, it can also have certain processing and storage functions. The execution entity can control multiple devices, such as a remote physical server or cloud server and associated software, or a local host computer or server and associated software that performs related operations on devices located in a certain location. In some scenarios, it can also control multiple storage devices, which can be located in the same location as the devices or in different locations. As shown in FIGS. 1 and 2, the method for monitoring abnormal reset of a multi-core microcontroller unit includes: After detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, step S101 obtains abnormal program information of the corresponding program abnormality location, including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; and step S102 of obtaining current processing core identification information related to the abnormal program information, writing the processing core identification information and the abnormal program information into a designated storage area of ​​a non-clear random access memory, and performing a microcontroller unit reset operation, wherein the designated storage area in the non-clear random access memory is configured so that after the software reset of the microcontroller unit is performed, the data in the designated storage area remains as the data stored before the reset.

[0029] In a specific implementation, an application program may encounter an abnormality during operation. When any core enters an abnormal program (TRAP) branch, it is important to obtain information related to the program abnormality location. This information includes the abnormality address, abnormality time, abnormality type, abnormal core source (which core the abnormality originates from), abnormality level, etc. The specific information that can be obtained varies depending on the MCU.

[0030] In an embodiment of the present invention, a "no-clear RAM" is used instead of an NVM to record TRAP-related information, thereby avoiding problems caused by defects in the NVM itself, and a voluntary reset is used instead of a passive reset to control the software reset time and program flow, thereby making it possible to control the software recovery time and ensuring the stability of data storage without clearing the corresponding fault information after reset. In the implementation of the present invention, no-clear random access memory refers to RAM that is not cleared after reset, and specifically means that no-clear RAM still maintains the value before reset after resetting the MCU software.

[0031] Specifically, after software running on one of the MCU cores enters the TRAP program branch, it records a large amount of fault-related information in non-clear RAM, and then the MCU can be voluntarily reset by software, which usually takes several microseconds.

[0032] More preferably, before the step of performing the microcontroller unit reset operation, The method further includes adjusting a flag state of an abnormal flag position, which includes a first state and a second state, to the first state.

[0033] After recording the fault information, the flag status needs to be adjusted. In this way, when the application program is initialized next time, the flag status information can be used to directly determine whether to perform the next operation, thereby improving the fluency of the entire program operation.

[0034] More preferably, after the step of acquiring current processing core identification information related to the abnormal program information, The method further includes calculating a first check value of the processing core identification information and the abnormal program information based on a cycle check algorithm, and writing the first check value into a designated storage area of ​​a non-clear random access memory.

[0035] A check value is obtained by performing a redundancy calculation on the corresponding information using the CRC32 algorithm, and the check value is used as the basic comparison data for subsequent redundancy checks. In this way, after the software is reset, the CRC32 value of the non-clear RAM is recalculated and compared with the CRC32 value recorded before the reset, thereby determining whether the non-clear RAM has been tampered with, and thus further improving the accuracy of subsequent fault data output.

[0036] More preferably, FIG. 3 is a flowchart of the fault analysis disclosed in the embodiment of the present invention. As shown in FIG. 3, after the step of performing the micro control unit reset operation described above, a step S103 in which the main processing core acquires processing core identification information and abnormal program information of a designated storage area of ​​the non-clear random access memory; Step S104: calculating a second check value of the processing core identification information and the abnormal program information in the main processing core based on a cycle check algorithm, comparing the second check value with the first check value stored in the non-clear random access memory, and if the comparison is successful, determining a corresponding fault diagnosis code and snapshot information based on the processing core identification information, the abnormal program information, and a setting condition; The method further includes step S105, in which the fault diagnosis code and snapshot information are transmitted to a diagnostic event management module, so that a user obtains the corresponding fault diagnosis code through a diagnostic interface.

[0037] The above steps realize the analysis and recording of abnormal fault information, and provide corresponding diagnostic interfaces for corresponding users to directly obtain corresponding fault diagnosis information, which greatly improves the overall convenience and wide range of application scenarios.

[0038] After resetting the software, Core0 checks whether the information in the no-clear RAM is true, and then extracts information such as the fault source (e.g., which core it comes from), the fault type, and the program address where the fault occurred. Based on this information, the fault can be reported to the Dem module, and the user can read the fault code through the diagnostic interface.

[0039] In an embodiment of the present invention, as shown in FIG. 2, trap fault information analysis occurs during the App initialization phase. The trap fault information input is information reserved in the non-clear RAM, and the output is a DTC code and snapshot information reported to the Dem module. The number of DTC codes corresponding to traps can be large or small and can be assigned according to system needs, and will not be further described here. Specifically, first determine whether the Trap_Flag is TRUE. Only if TRUE is true, analyze the data in the non-clear RAM. Then determine whether the CRC32 of the data in the non-clear RAM is correct. Only if correct, process it. Finally, classify the CRC and assign snapshot data according to actual needs. When setting a DTC based on Core ID, two DTCs can be set. The DTC snapshot can be all or part of the information in the non-clear RAM. In this way, by reading the fault code and its snapshot, automotive diagnostic engineers can determine information such as the location, time, and core to which the program error occurred.

[0040] More preferably, FIG. 4 is a flowchart of determining the abnormality level and obtaining the abnormality cause disclosed in the embodiment of the present invention, and FIG. 5 is a schematic diagram of the information recording process after the software enters into the abnormal program branch disclosed in the embodiment of the present invention. As shown in FIG. 4 and FIG. 5, after detecting that any processing core in the multi-core microcontroller unit has entered into the abnormal program branch, Step S1011: determining at least two abnormality type information based on the abnormal program branch; Step S1012: determining an abnormal program level that has a certain mapping relationship with each abnormal type information based on the abnormal type information; Step S1013: if it is detected that the abnormal program level is the first abnormal level, acquire first abnormal address information in the register EIPC and acquire first abnormal cause code in the register EIIC; The method further includes step S1014 of obtaining second abnormality address information in the register FEPC and obtaining a second abnormality cause code in the register FEIC when detecting that the abnormal program level is the second abnormality level.

[0041] In specific implementation, by associating the abnormality type information with the abnormal program level, any type of abnormality can be mapped to the corresponding abnormality level, and the corresponding abnormality address and abnormality cause code can be obtained, which facilitates subsequent information recording, and the abnormality type can be simplified and recorded based on the actual structure.

[0042] More preferably, the abnormality time information is The system time information is acquired after entering the abnormal program branch, and the system time information is determined as abnormal time information, which is time stamp information at the time of the abnormality.

[0043] The above step is a specific time acquisition step, which can determine the information on the time point when an abnormality occurs and improve the convenience of acquiring time information.

[0044] In this embodiment, the Renesas MCU RH850 P1H-C is used as an example to describe the corresponding design. The Renesas MCU RH850 P1H-C has two main abnormality levels, EI and FE, and 15 abnormality types. Each abnormality type has a separate abnormal program branch; that is, each abnormal program branch triggers a corresponding abnormality type. Because there is a fixed mapping relationship between the abnormality type and the abnormality level, when a program becomes abnormal and enters an abnormal program branch, the abnormality type can also be determined. When the abnormal program level is EI, the abnormality address (ExpAddr) and abnormality cause code (CauseCode) can be obtained from registers EIPC and EIIC, respectively. When the abnormal program level is FE, the abnormality address (ExpAddr) and abnormality cause code (CauseCode) can be obtained from registers FEPC and FEIC, respectively.

[0045] In this embodiment of the present invention, the abnormal time, i.e., the timestamp of the abnormality, can be obtained by acquiring the system time (SystemTimer) after entering the abnormal branch program. Finally, all of the acquired information is written together to the "no-clear RAM," and the current core ID (indicating which core the trap is being entered from) is written, and the entered trap flag position (Trap_Flag) information is adjusted to TRUE. Finally, the CRC32 value of all of this written information is calculated and written to the end of the no-clear RAM. In this way, after resetting the software, the no-clear RAM CRC32 value is recalculated and compared with the CRC32 value recorded before the reset, making it possible to determine whether the no-clear RAM has been tampered with. The process of acquiring trap fault information is shown in Figure 5 below.

[0046] More preferably, the size of the space of the designated storage area is at least 200 bytes, and the non-clear random access memory is configured to be shared by a multi-core microcontroller unit.

[0047] Random access memory has the characteristics of fast read speed and easy operation, so it can be shared by multi-core microcontroller units. The use of multi-core shared no-clear RAM ensures that only one processing core handles faults, while the other processing cores only record fault information. When setting the specific designated storage space, some space can be appropriately reserved to facilitate future expansion, such as when the number of cores increases or the amount of fault information increases.

[0048] In this embodiment of the present invention, no-clear RAM refers to a RAM address block whose contents are not restored to default values ​​after a software reset. No-clear RAM must be implemented using a combination of software and hardware. Three steps are required between an MCU reset and the application's use of no-clear RAM: RAM module reset (reserved by hardware), initialization of RAM by the bootloader software (reserved by software), and initialization of RAM by the application (reserved by software). The application diagnostic software can obtain pre-reset trap information from no-clear RAM only if these three steps have been completed and data in a specific area of ​​RAM has not been cleared. MCU resets can be divided into hardware reset, system reset, and software reset. Only when software reset is selected and register STAC_LM0 = 1 is the last 1K of SelfRam (hereinafter referred to as SelfRam_Last) not restored to default values ​​by hardware after a reset. Without initializing SelfRam_Last during the bootloader and application startup phases, no-clear RAM can be designed as shown in Figure 6 below. That is, the bootloader software and the application program both have corresponding command segments set, and when these two command segments are executed, they do not perform a clear operation on the data in the designated memory area in the no-clear RAM, but only perform a clear operation on the data in areas other than the designated memory area in the no-clear RAM, thus enabling the acquisition of specific data information at the subsequent initialization stage of the application program.

[0049] In this embodiment, a "no-clear RAM" is used instead of NVM to record trap-related information, avoiding problems caused by defects in the NVM itself. A voluntary reset is used instead of a passive reset to control the software reset time and program flow. A multi-core shared no-clear RAM ensures that only one core handles the fault while the other cores only record the fault information. A checksum ensures the consistency of data in the no-clear RAM. The premise for implementing this anomaly monitoring method is to design a no-clear RAM and obtain as much important information as possible after a trap is triggered. Finally, after a software reset, the cause of the fault is analyzed, and the fault code and snapshot information are obtained and reported to the Dem module. The software flow is shown in Figure 2 below.

[0050] The design of the embodiment of the present invention involves three key steps: designing a non-clear RAM, acquiring trap fault information, and analyzing the trap fault information. Theoretically, the developed abnormal reset monitoring method can be used for any automotive-level MCU. However, since software abnormalities (TRAPs) are closely related to the MCU itself, specifically, different MCUs have different types of TRAPs and mechanisms that generate TRAPs. In specific implementations, different MCUs can acquire corresponding faults.

[0051] The embodiment of the present invention has the following advantages. First, by using RAM instead of NVM to record information, fault recovery is faster. Second, by using RAM with sufficient resources instead of NVM, more fault information can be recorded and analyzed more easily. Third, by using voluntary reset instead of passive reset, MCU reset is faster and software flow is more controllable. Fourth, by reporting faults to the Dem module after analysis instead of storing them directly in NVM, it is possible to better meet automotive software specifications.

[0052] In an embodiment of the present invention, the method for monitoring abnormal reset of a multi-core microcontroller unit is designed with a no-clear random access memory. When an abnormality occurs in the operation of the entire program, the abnormality information is stored in a designated area of ​​the no-clear random access memory to protect the data, and when a subsequent reset is performed, the data in the protected area is not cleared.

[0053] Example 2 Referring to Figure 7, Figure 7 is a structural schematic diagram of a multi-core microcontroller unit abnormal reset monitoring device disclosed in an embodiment of the present invention. As shown in Figure 7, the multi-core microcontroller unit abnormal reset monitoring device includes: an acquisition module 21 for acquiring abnormal program information of a corresponding program abnormality site after detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, the abnormal program information including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; and a storage module (22) for obtaining current processing core identification information associated with the abnormal program information, writing the processing core identification information and the abnormal program information into a designated storage area in a non-clear random access memory, and performing a microcontroller unit reset operation, wherein the designated storage area in the non-clear random access memory is configured such that after performing a software reset of the microcontroller unit, the data in the designated storage area remains as the data stored before the reset.

[0054] In an embodiment of the present invention, the method for monitoring abnormal reset of a multi-core microcontroller unit is designed with a no-clear random access memory. When an abnormality occurs in the operation of the entire program, the abnormality information is stored in a designated area of ​​the no-clear random access memory to protect the data, and when a subsequent reset is performed, the data in the protected area is not cleared.

[0055] Example 3 Referring to Figure 8, Figure 8 is a structural schematic diagram of an electronic device disclosed in an embodiment of the present invention. The electronic device can be a computer, a server, etc., and of course, in certain cases, it can also be a smart device such as a mobile phone, a tablet computer, a monitoring terminal, and an image collecting device with processing function. As shown in Figure 8, the electronic device can: a memory 510 in which executable program code is stored; a processor 520 coupled to the memory 510; The processor 520 calls the executable program code stored in the memory 510 to perform some or all of the steps of the method for monitoring abnormal reset of a multi-core microcontroller unit in the first embodiment.

[0056] An embodiment of the present invention discloses a computer-readable storage medium, which stores a computer program, and the computer program causes a computer to perform some or all of the steps of the abnormal reset monitoring method for a multi-core microcontroller unit in embodiment 1.

[0057] An embodiment of the present invention further discloses a computer program product, which, when executed on a computer, causes the computer to perform some or all of the steps in the abnormal reset monitoring method for a multi-core microcontroller unit in embodiment 1.

[0058] An embodiment of the present invention further discloses an application release platform for a release computer program product, in which, when the computer program product is executed on a computer, it causes the computer to perform some or all of the steps in the abnormal reset monitoring method for a multi-core microcontroller unit in embodiment 1.

[0059] In various embodiments of the present invention, it should be understood that the magnitude of the sequence number of each process does not imply a necessary order of execution, and the execution order of each process must be determined by its function and inherent logic, and does not constitute any limitation on the implementation process of the embodiments of the present invention.

[0060] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. To achieve the objectives of this embodiment, some or all of the units may be selected according to actual needs.

[0061] Furthermore, each functional unit in each embodiment of the present invention may be integrated into a single processing unit, each unit may exist physically independently, or two or more units may be integrated into a single unit. The integrated unit may be realized in the form of hardware or in the form of a software functional unit.

[0062] The integrated unit can be realized in the form of a software functional unit and stored in a computer-accessible memory when sold or used as an independent product. Based on this understanding, the technical solution of the present invention can essentially, or a portion contributing to the prior art, or all or a part of the technical solution can be embodied in the form of a software product, and this software product is stored in one memory and includes several requests to cause one computer device (which may be a personal computer, a server, a network device, etc., and particularly may be a processor in the computer device) to execute some or all of the steps of the methods described in various embodiments of the present invention.

[0063] In the embodiment according to the present invention, it should be understood that "B corresponding to A" means that B is related to A and B can be determined based on A. However, it should be further understood that determining B based on A does not only mean determining B based on A, but also means that B can be determined based on A and / or other information.

[0064] Those skilled in the art will understand that some or all of the steps of the various methods in the above embodiments can be performed by instructing associated hardware by a program that can be stored in a computer-readable storage medium, and the storage medium includes read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc memory, magnetic disk memory, magnetic tape memory, or any other computer-readable medium that can be used to carry or store data.

[0065] The above provides a detailed introduction to the method, device, electronic device, and storage medium for monitoring abnormal reset of a multi-core microcontroller unit disclosed in the embodiments of the present invention, and the present specification uses specific examples to describe the principles and embodiments of the present invention. However, the explanation of the above examples is only intended to assist in understanding the method of the present invention and its core idea. Furthermore, those skilled in the art will recognize that there may be changes in the specific embodiments and application scope based on the idea of ​​the present invention. As such, the contents of this specification should not be construed as a limitation on the present invention.

Claims

1. A hardware-implemented method for abnormal reset monitoring of a multi-core microcontroller unit, comprising: After detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, obtaining abnormal program information of the corresponding program abnormality location, including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; obtaining current processing core identification information associated with the abnormal program information; calculating a first check value of the processing core identification information and the abnormal program information based on a cycle check algorithm; writing the first check value into a designated storage area of ​​a non-clear random access memory; and performing a microcontroller unit reset operation; acquiring, in a main processing core, processing core identification information and abnormal program information from a designated storage area of ​​the non-clear random access memory; calculating a second check value of the processing core identification information and the abnormal program information in the main processing core based on a cycle check algorithm, comparing the second check value with the first check value stored in the non-clear random access memory, and determining a corresponding fault diagnosis code and snapshot information based on the processing core identification information, the abnormal program information, and a setting condition if the comparison is successful; transmitting the fault diagnosis code and snapshot information to a diagnostic event management module, so that a user can obtain the corresponding fault diagnosis code through a diagnostic interface; The no-clear random access memory means a RAM that is not cleared after reset, and a designated storage area in the no-clear random access memory is configured so that after a software reset of the microcontroller unit is performed, the data in the designated storage area remains the same as the data stored before the reset.

2. before the step of performing the microcontroller unit reset operation; 2. The method for monitoring abnormal reset of a multi-core microcontroller unit as claimed in claim 1, further comprising: adjusting a flag state of an abnormal flag position including a first state and a second state to the first state.

3. After detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, determining at least two abnormality type information based on the abnormal program branch; determining the abnormal program level that has a corresponding mapping relationship with each of the abnormal type information based on the abnormal type information; When detecting that the abnormal program level is a first abnormal level, acquiring first abnormal address information in a register EIPC and acquiring a first abnormal cause code in a register EIIC; An abnormal reset monitoring method for a multi-core microcontroller unit as described in any one of claims 1 to 2, further comprising the steps of: when detecting that the abnormal program level is a second abnormal level, respectively acquiring second abnormal address information in register FEPC and acquiring a second abnormal cause code in register FEIC.

4. The abnormality time information is An abnormal reset monitoring method for a multi-core microcontroller unit described in any one of claims 1-2, characterized in that the method is obtained by a step of acquiring system time information after entering an abnormal program branch and determining the system time information as abnormal time information, which is timestamp information at the time of the abnormality.

5. 2. The method for monitoring abnormal reset of a multi-core microcontroller unit according to claim 1, wherein the space size of the designated memory area is at least 200 bytes, and the non-clear random access memory is configured to be shared by the multi-core microcontroller units.

6. An abnormal reset monitoring device for a multi-core microcontroller unit, comprising: an acquisition module for acquiring abnormal program information of a corresponding program abnormality site after detecting that any processing core in the multi-core microcontroller unit has entered an abnormal program branch, the abnormal program information including one or more of abnormal address information, abnormal time information, abnormal type information, abnormal core source information, and abnormal program level; a storage module for obtaining current processing core identification information related to the abnormal program information, calculating a first check value for the processing core identification information and the abnormal program information based on a cycle check algorithm, writing the first check value to a designated storage area of ​​a non-clear random access memory, performing a microcontroller reset operation, obtaining the processing core identification information and the abnormal program information in the designated storage area of ​​the non-clear random access memory in a main processing core, calculating a second check value for the processing core identification information and the abnormal program information based on a cycle check algorithm in the main processing core, comparing the second check value with the first check value stored in the non-clear random access memory, and if the comparison is successful, determining corresponding fault diagnostic code and snapshot information based on the processing core identification information, the abnormal program information and a setting condition, and transmitting the fault diagnostic code and snapshot information to a diagnostic event management module, thereby allowing a user to obtain the corresponding fault diagnostic code through a diagnostic interface; The no-clear random access memory means a RAM that is not cleared after reset, and the designated storage area in the no-clear random access memory includes a storage module configured so that after a software reset of the microcontroller unit is performed, the data in the designated storage area remains the same as the data stored before the reset.

7. 10. An electronic device comprising: a memory in which executable program code is stored; and a processor coupled to the memory, wherein the processor calls the executable program code stored in the memory to execute the abnormal reset monitoring method for a multi-core microcontroller unit according to claim 1.

8. 10. A computer-readable storage medium having a computer program stored therein, the computer program causing a computer to execute the method for monitoring abnormal reset of a multi-core microcontroller unit according to claim 1.

Images