Methods and devices for monitoring exceptional restarts used for multi-core microcontroller units, electronic devices, and storage media readable by non-forwarding computers.

Abstract

The invention relates to a method for monitoring exception restarts for multi-core microcontrollers, comprising a step of collecting exception program information at the location where the exception occurred after detecting that a processing core in the multi-core microcontroller has entered the exception program branch; writing the processing core identifier and exception program information to a dedicated storage area of ​​non-erase random access memory. The method for monitoring exception restarts for multi-core microcontrollers is designed with non-erase random access memory to allow that when an exception occurs during full program execution, the generated exception information can be stored in a dedicated area of ​​non-erase random access memory to protect the data, and the data in the protected area will not be erased during the subsequent restart.The invention also relates to electronic devices and storage media readable by non-transferable computers.

Description

Abnormal reset monitoring method and device for multi-core microcontroller unit Technical Field

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

[0002] Currently, in automotive controllers, when the MCU system operates abnormally due to improper user use of MCU resources or a fault within the MCU itself, the software will enter the exception routine (TRAP) branch. In this case, the software typically resets the software via a watchdog timeout (passive reset) to restore it to normal. Some designers record this fault information in read-only memory (ROM), typically the AUTOSAR standard NVM module, before resetting the software. This then allows for easier troubleshooting after the MCU is reset. Technical issues

[0003] This approach presents the following problems: 1. TRAP may be caused by an error in the NVM (or its subordinate modules MemIf, Fee, and Fls). This error is quite common, and manipulating the NVM in this situation may introduce new faults. 2. This passive reset method using the watchdog timer takes a long time, typically tens or even hundreds of milliseconds. Furthermore, NVM operations themselves take time (especially during Fee sector switching), which hinders rapid MCU recovery. 3. In a multi-core MCU system, NVM is typically executed by only one core (e.g., Core0). When another core (e.g., Core1) enters the trap program branch, Core1 cannot directly call the NVM interface. 4. Passive resets typically require a certain filtering time (e.g., the watchdog timeout), which hinders rapid fault recovery. Therefore, designing a solution that can quickly reset faults and query the fault cause after reset has become a pressing technical problem for those skilled in the art. Technical Solutions

[0004] To address the above-mentioned shortcomings, an embodiment of the present invention discloses a method for monitoring abnormal reset of a multi-core microcontroller unit. The method can utilize random access memory (RAM) to implement corresponding information recording, making fault recovery faster; and adopts active reset instead of passive reset, making the microcontroller unit reset faster and the software process more controllable.

[0005] A first aspect of an embodiment of the present invention discloses a method for monitoring abnormal reset of a multi-core microcontroller unit, comprising:

[0006] After detecting that a processing core in the multi-core microcontroller unit enters an abnormal program branch, abnormal program information of the corresponding program abnormality scene is obtained, wherein the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level;

[0007] Obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into a designated storage area of ​​a non-clear random access memory (RAM that is not cleared after reset, hereinafter referred to as "non-clear RAM"), and perform a microcontroller reset operation, wherein the designated storage area in the non-clear RAM is configured so that after the microcontroller software is reset, the data in the designated storage area remains the storage data before the reset.

[0008] As an optional implementation manner, in the first aspect of the embodiment of the present invention, before performing the micro control unit reset operation, the method further includes:

[0009] The flag state of the abnormal identification position is adjusted to a first state, where the flag state includes a first state and a second state.

[0010] After recording the fault information, the identification status needs to be adjusted. In this way, the next time the application is initialized, the identification status information can be used to directly determine whether to proceed to the next operation, which can improve the smoothness of the overall program operation.

[0011] As an optional implementation manner, in the first aspect of the embodiment of the present invention, after obtaining the current processing core identity information associated with the abnormal program information, the method further includes:

[0012] A first check value of the processing core identity information and the abnormal program information is calculated according to a cyclic check algorithm, and the first check value is written into a designated storage area of ​​a non-clear random access memory.

[0013] By using the CRC32 algorithm to perform redundant calculations on the corresponding information to obtain a checksum value, this checksum value serves as the basis for subsequent redundant verification. This way, after a software reset, the CRC32 value of the non-clear RAM is recalculated and compared with the CRC32 value recorded before the reset to determine whether the non-clear RAM has been tampered with. This can further improve the accuracy of subsequent fault data output.

[0014] As an optional implementation manner, in the first aspect of the embodiment of the present invention, after performing the micro control unit reset operation, the method further includes:

[0015] Acquire, at a main processing core (Core0), the processing core identity information and abnormal program information of the designated storage area of ​​the non-clear random access memory;

[0016] calculating, at the main processing core (Core0), a second check value for the processing core identity information and the abnormal program information according to a cyclic check algorithm, and comparing the second check value with a first check value stored in a non-clear random access memory; and determining, after the comparison passes, a corresponding fault diagnostic code and snapshot information according to the processing core identity information, the abnormal program information, and a set condition;

[0017] The fault diagnostic code and snapshot information are transmitted to a diagnostic event management module so that a user can obtain the corresponding fault diagnostic code through a diagnostic interface.

[0018] The above steps can be used to analyze and record abnormal fault information, and provide corresponding diagnostic interfaces for corresponding users to directly obtain corresponding fault diagnosis information, greatly improving the possibility of analyzing the root cause of the fault.

[0019] As an optional implementation manner, in the first aspect of the embodiment of the present invention, after detecting that a processing core in the multi-core microcontroller unit enters an abnormal program branch, the method further includes:

[0020] Determine abnormality category information according to the abnormal program branch; the abnormality category information has at least two items;

[0021] Determining an abnormal program level according to the abnormal category information, wherein there is a fixed mapping relationship between each abnormal category information and the abnormal program level;

[0022] When it is detected that the abnormal program level is the first abnormal level, the first abnormal address information is obtained from the register EIPC and the first abnormal reason code is obtained from the register EIIC;

[0023] When it is detected that the abnormal program level is the second abnormal level, the second abnormal address information is obtained from the register FEPC and the second abnormal reason code is obtained from the register FEIC.

[0024] In the specific implementation, the exception category information is associated with the exception program level. This allows any type of exception to be mapped to the corresponding exception level, and the corresponding exception address and exception reason code to be obtained, which facilitates subsequent information recording and simplifies the recording of exception categories based on the actual structure.

[0025] As an optional implementation manner, in the first aspect of the embodiment of the present invention, the abnormal time information is obtained by the following steps:

[0026] After entering the abnormal program branch, system time information is acquired and the system time information is determined as abnormal time information, where the abnormal time information is timestamp information at the time of the abnormality.

[0027] The above steps are specific time acquisition steps, through which the information of the time point when the abnormality occurred can be determined; thus, the convenience of obtaining time information is improved.

[0028] As an optional implementation, in the first aspect of the embodiment of the present invention, the space size of the designated storage area is at least 200 bytes; and the non-clear RAM is configured to be shared by multiple-core microcontroller units.

[0029] Since random access memory (RAM) has the characteristics of fast reading speed and user-allocated, it makes it possible to quickly access data and share it with multi-core microcontroller units. By using multi-core shared non-clear RAM, it can be ensured that one core handles the fault while the other cores only record the fault information. At the same time, the "non-clear" feature can also ensure that the recorded fault information is still retained after a fast reset.

[0030] When setting the space for a specific storage area, sufficient space can be reserved because RAM is generally much more abundant than NVM resources and its allocation is more flexible.

[0031] A second aspect of an embodiment of the present invention discloses an abnormal reset monitoring device for a multi-core microcontroller unit, comprising:

[0032] An acquisition module is configured to acquire abnormal program information of a corresponding program abnormality site after detecting that a processing core in a multi-core microcontroller unit enters an abnormal program branch, wherein the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level;

[0033] Storage module: used to obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into the designated storage area of ​​the non-clear RAM, and perform a micro-control unit reset operation, wherein the designated storage area in the non-clear RAM is configured so that after the micro-control unit software is reset, the data in the designated storage area remains the storage data before the reset.

[0034] A third aspect of an embodiment of the present invention discloses an electronic device, comprising: a memory storing executable program code; a processor coupled to the memory; the processor calling the executable program code stored in the memory to execute the abnormal reset monitoring method of a multi-core microcontroller unit disclosed in the first aspect of the embodiment of the present invention.

[0035] A fourth aspect of an embodiment of the present invention discloses a computer-readable storage medium storing a computer program, wherein the computer program enables a computer to execute the abnormal reset monitoring method of a multi-core microcontroller unit disclosed in the first aspect of the embodiment of the present invention. Beneficial effects

[0036] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0037] The abnormal reset monitoring method of the multi-core microcontroller unit in the embodiment of the present invention designs a non-clear random access memory (non-clear RAM) instead of NVM, so that when an exception occurs during the entire program operation, the generated exception information can be quickly stored in a designated area of ​​the non-clear RAM for data protection. Moreover, through reasonable design, the data in the protected area will not be cleared during a subsequent reset. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0039] FIG1 is a flow chart of a method for monitoring abnormal reset of a multi-core microcontroller unit disclosed in an embodiment of the present invention;

[0040] FIG2 is a schematic diagram of a specific flow chart of a method for monitoring abnormal reset of a multi-core microcontroller unit disclosed in an embodiment of the present invention;

[0041] FIG3 is a schematic diagram of a process for performing fault analysis according to an embodiment of the present invention;

[0042] FIG4 is a schematic diagram of a process for determining an abnormality level and obtaining an abnormality cause according to an embodiment of the present invention;

[0043] 5 is a schematic diagram of the information recording process after the software disclosed in an embodiment of the present invention enters an abnormal program branch;

[0044] 6 is a flowchart of a non-clear RAM reset method disclosed in an embodiment of the present invention;

[0045] 7 is a schematic structural diagram of an abnormal reset monitoring device for a multi-core microcontroller unit provided by an embodiment of the present invention;

[0046] FIG8 is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. Best Mode for Carrying Out the Invention

[0047] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0048] It should be noted that the terms "first," "second," "third," "fourth," etc. in the description and claims of the present invention are used to distinguish different objects rather than to describe a specific order. The terms "including" and "having," as well as any variations thereof, in the embodiments of the present invention, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0049] When an MCU operation failure causes the program to enter the exception program (TRAP) branch, the normal program cannot feed the watchdog, and the watchdog timeout causes the MCU to reset (passive reset), restoring the software to a normal state. This is the most common method for handling MCU exceptions. In order to obtain the cause of the abnormal reset, the fault information is usually recorded in non-volatile memory (the AUTOSAR architecture uses NVM) after the software enters TRAP; after the software resets, the fault analysis is performed by reading the information obtained from the NVM. NVM has its inherent problems and is not suitable for abnormal reset handlers; the "passive reset" method is also not conducive to time control of software recovery. The embodiment of the present invention discloses an abnormal reset monitoring method, device, electronic device and storage medium for a multi-core microcontroller unit. By designing a non-clear random access memory, when an exception occurs during the entire program operation, the generated exception information can be stored in a designated area of ​​the non-clear random access memory for data protection, so that the data in the protected area will not be cleared during a subsequent reset. Example 1

[0050] Please refer to Figure 1, which is a flow chart of the abnormal reset monitoring method of a multi-core micro control unit disclosed in an embodiment of the present invention. Among them, the execution subject of the method described in the embodiment of the present invention is an execution subject composed of software and / or hardware, and the execution subject can receive relevant information by wired or / and wireless means, and can send certain instructions. Of course, it can also have certain processing functions and storage functions. The execution subject can control multiple devices, such as a remote physical server or cloud server and related software, or it can be a local host or server and related software that performs related operations on a device placed somewhere. In some scenarios, multiple storage devices can also be controlled, and the storage devices can be placed in the same place or different places as the devices. As shown in Figures 1 and 2, the abnormal reset monitoring method based on a multi-core micro control unit includes the following steps:

[0051] S101: After detecting that a processing core in a multi-core microcontroller unit enters an abnormal program branch, abnormal program information of the corresponding program abnormality scene is obtained, where the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level;

[0052] S102: Obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into a designated storage area of ​​a non-clear random access memory, and perform a microcontroller unit reset operation, wherein the designated storage area in the non-clear random access memory is configured so that after the microcontroller unit software is reset, the data in the designated storage area remains the storage data before the reset.

[0053] During implementation, applications may encounter exceptions during execution. When a core enters the exception procedure (TRAP) branch, obtaining information about the exception scene is crucial. This information includes the exception address, exception time, exception type, exception core source (which core caused the exception), and exception severity. The specific information available varies depending on the MCU.

[0054] In this embodiment of the present invention, "non-clear RAM" is used instead of NVM to record TRAP-related information, avoiding issues caused by NVM defects. Active reset is used instead of passive reset to control software reset timing and program flow. This approach makes software recovery time controllable, and corresponding fault information is not cleared after reset, ensuring data storage stability. In this implementation, non-clear RAM refers to RAM that is not cleared after reset. Specifically, non-clear RAM retains its pre-reset value after an MCU soft reset.

[0055] Specifically, after the software running on any MCU core enters the TRAP program branch, a large amount of fault-related information can be recorded in the non-clearable RAM, and then the MCU is actively reset through the software. This process usually takes several microseconds.

[0056] More preferably, before performing the micro control unit reset operation, the method further includes:

[0057] The flag state of the abnormal identification position is adjusted to a first state, where the flag state includes a first state and a second state.

[0058] After recording the fault information, the identification status needs to be adjusted. In this way, the next time the application is initialized, the identification status information can be used to directly determine whether to proceed to the next operation, which can improve the smoothness of the overall program operation.

[0059] More preferably, after obtaining the current processing core identity information associated with the abnormal program information, the method further includes:

[0060] A first check value of the processing core identity information and the abnormal program information is calculated according to a cyclic check algorithm, and the first check value is written into a designated storage area of ​​a non-clear random access memory.

[0061] By using the CRC32 algorithm to perform redundant calculations on the corresponding information to obtain a check value, the check value is used as the basic comparison data for subsequent redundant 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 to determine whether the non-clear RAM has been tampered with. This can further improve the accuracy of subsequent fault data output.

[0062] More preferably, FIG3 is a flow chart of a fault analysis process disclosed in an embodiment of the present invention. As shown in FIG3 , after the microcontroller unit reset operation is performed, the process further includes:

[0063] S103: Acquire, at the main processing core, the processing core identity information and abnormal program information of the designated storage area of ​​the non-clear random access memory;

[0064] S104: Calculating, at the main processing core, a second check value for the processing core identity information and the abnormal program information according to a cyclic check algorithm, and comparing the second check value with a first check value stored in a non-clear random access memory. After the comparison passes, determining a corresponding fault diagnostic code and snapshot information according to the processing core identity information, the abnormal program information, and a set condition.

[0065] S105: 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.

[0066] The above steps can be used to analyze and record abnormal fault information, and a corresponding diagnostic interface can be provided to the corresponding users to directly obtain the corresponding fault diagnosis information, which greatly improves the overall convenience and the breadth of application scenarios.

[0067] After the software is reset, Core0 verifies that the information in the non-clear RAM is true, and then extracts information such as the source of the fault (such as which core it comes from), the fault type, the program address where the fault occurs, etc. Based on this information, the fault is reported to the Dem module, and the user can read the fault code through the diagnostic interface.

[0068] In an embodiment of the present invention, the Trap fault information analysis occurs during the App initialization phase, as shown in FIG2 . The Trap fault information input is the information left in the non-clear RAM, and the output is the DTC code and snapshot information to be reported to the Dem module. The number of DTC codes corresponding to the Trap can be more or less, and is allocated according to the needs of the system, which will not be described in detail here. Specifically, first determine whether Trap_Flag is TRUE. Only when it is TRUE does it need to analyze the data in the non-clear RAM; then determine whether the CRC32 of the non-clear RAM data is correct. Only when it is correct does it need to be processed; finally, classify the CRC and allocate snapshot data according to actual needs. If the DTC is set according to CoreId, two DTCs can be set. The DTC snapshot can select all or part of the information in the non-clear RAM. In this way, automotive diagnostic engineers can determine the location, time, core to which the program error belongs, and other information by reading the fault code and its snapshot.

[0069] More preferably, FIG4 is a flow chart of determining an abnormality level and obtaining an abnormality cause according to an embodiment of the present invention; FIG5 is a diagram of a process of recording information after software enters an abnormal program branch according to an embodiment of the present invention; as shown in FIG4 and FIG5 , after detecting that a processing core in a multi-core microcontroller unit enters an abnormal program branch, the process further includes:

[0070] S1011: Determine abnormality category information according to the abnormal program branch; the abnormality category information may be at least two;

[0071] S1012: Determine an abnormal program level according to the abnormal category information, wherein a fixed mapping relationship exists between each abnormal category information and the abnormal program level;

[0072] S1013: When it is detected that the abnormal program level is the first abnormal level, first abnormal address information is obtained from register EIPC and first abnormal reason code is obtained from register EIIC;

[0073] S1014: When it is detected that the abnormal program level is the second abnormal level, second abnormal address information is obtained from register FEPC and second abnormal reason code is obtained from register FEIC.

[0074] In the specific implementation, the exception category information is associated with the exception program level. This allows any type of exception to be mapped to the corresponding exception level, and the corresponding exception address and exception reason code to be obtained, which facilitates subsequent information recording and simplifies the recording of exception categories based on the actual structure.

[0075] More preferably, the abnormal time information is obtained by the following steps:

[0076] After entering the abnormal program branch, system time information is acquired and the system time information is determined as abnormal time information, where the abnormal time information is timestamp information at the time of the abnormality.

[0077] The above steps are specific time acquisition steps, through which the information of the time point when the abnormality occurred can be determined; thus, the convenience of obtaining time information is improved.

[0078] In the embodiments of the present invention, the corresponding design scheme is described using the Renesas MCU RH850 P1H-C as an example. The Renesas MCU RH850 P1H-C has two main exception levels, EI and FE, and 15 exception categories. Each exception category has a separate exception program branch, meaning that each exception program branch triggers the corresponding exception category. There is a fixed mapping relationship between exception categories and exception levels. Therefore, when a program exception enters a certain exception program branch, its exception category is also known. When the exception program level is EI, the exception address (ExpAddr) and exception cause code (CauseCode) can be obtained from registers EIPC and EIIC, respectively. When the exception program level is FE, the exception address (ExpAddr) and exception cause code (CauseCode) can be obtained from registers FEPC and FEIC, respectively.

[0079] The exception time in this embodiment of the present invention, i.e., the timestamp of the exception, can be obtained by acquiring the system time (SystemTimer) after entering the exception branch program. All of this acquired information is finally aggregated and written to the "non-clear RAM," along with the current core ID (indicating which core entered the trap), and the entry trap flag (Trap_Flag) is adjusted to TRUE. Finally, the CRC32 value of all this written information is calculated and written to the end of the non-clear RAM. This way, after a software reset, the non-clear RAM CRC32 value is recalculated and compared with the CRC32 value recorded before the reset to determine whether the non-clear RAM has been tampered with. Trap fault information acquisition is shown in Figure 5 below.

[0080] More preferably, the space size of the designated storage area is at least 200 bytes; and the non-clear random access memory is configured to be shared by multiple core micro control units.

[0081] Because random access memory (RAM) boasts fast read speeds and ease of use, it can be shared by multiple microcontrollers. By using multi-core shared non-clearable RAM, only one processing core handles the fault, while the others simply record the fault information. When specifying the storage area, reserve some space to facilitate future expansion, such as increasing the number of cores and the amount of fault information.

[0082] In the embodiments of the present invention, non-clear RAM refers to a RAM address block whose contents are not restored to default values ​​after a software reset. Non-clear RAM requires a combination of software and hardware implementation. From MCU reset to APP use of non-clear RAM, three stages must occur: RAM module reset (hardware guarantee), bootloader software initialization of RAM (software guarantee), and APP initialization of RAM (software guarantee). Only when the data in the specific RAM area is not cleared during these three stages can the APP diagnostic software retrieve pre-reset TRAP information from the non-clear RAM. MCU resets can be categorized as hard reset, system reset, and software reset. Only when a soft reset is selected and register STAC_LM0 = 1, the last 1KB of SelfRam (hereinafter referred to as SelfRam_Last) will not be restored to default by hardware after reset. SelfRam_Last is not initialized during the bootloader and app startup phases, and the non-clear RAM can be designed as shown in Figure 6 below. That is, both the bootloader software and the application are equipped with corresponding command segments. When executed, these two command segments will not clear the data in the specified storage area of ​​the non-clear RAM. They will only clear the data in the area outside the specified storage area of ​​the non-clear RAM. In this way, specific data information can be obtained in the subsequent application initialization stage.

[0083] In this embodiment of the present invention, "non-clear RAM" is used instead of NVM to record TRAP-related information, avoiding issues arising from inherent NVM defects. Active reset is used instead of passive reset to control software reset timing and program flow. Multi-core shared non-clear RAM ensures that only one core handles faults, while the others simply record fault information. CheckSum is used to ensure consistency of non-clear RAM data. Implementing this exception monitoring method requires the design of "non-clear RAM." Secondly, after entering the trap, as much critical information as possible must be captured. Finally, after the software reset, the cause of the fault must be analyzed, and fault codes and snapshot information must be obtained and reported to the Dem module. The software flow is shown in Figure 2 below.

[0084] The design of the embodiment of the present invention involves three key steps: non-clear RAM design, trap fault information acquisition, and trap fault information analysis. Although the developed abnormal reset fault monitoring method is theoretically applicable to any automotive-grade MCU, because software anomalies (TRAP) are strongly related to the MCU itself, specifically, different MCUs have different types of TRAPs and different mechanisms for generating TRAPs. Therefore, during specific implementation, corresponding fault acquisition can be performed based on different MCUs.

[0085] The solution of the embodiment of the present invention has the following advantages: First, RAM is used instead of NVM to record information, which makes fault recovery faster; second, RAM with relatively sufficient resources instead of NVM can record more fault information, which is convenient for analysis; third, active reset is used instead of passive reset, which makes MCU reset faster and software flow more controllable; fourth, the analyzed fault is reported to the Dem module instead of being directly stored in NVM, which is more in line with the standards of automotive software.

[0086] The abnormal reset monitoring method of the multi-core microcontroller unit in the embodiment of the present invention designs a non-clear random access memory so that when an exception occurs during the entire program operation, the generated exception information can be stored in a designated area of ​​the non-clear random access memory for data protection, so that the data in the protected area will not be cleared during subsequent reset. Modes for Carrying Out the Invention

[0087] Example 2

[0088] Please refer to Figure 7, which is a schematic diagram of the structure of the abnormal reset monitoring device of the multi-core micro control unit disclosed in an embodiment of the present invention. As shown in Figure 7, the abnormal reset monitoring device of the multi-core micro control unit may include:

[0089] Acquisition module 21: configured to acquire abnormal program information of the corresponding program abnormality scene after detecting that a processing core in the multi-core microcontroller unit enters an abnormal program branch, wherein the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level;

[0090] Storage module 22: used to obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into a designated storage area of ​​a non-clear random access memory, and perform a microcontroller unit reset operation, wherein the designated storage area in the non-clear random access memory is configured so that after the microcontroller unit software is reset, the data in the designated storage area remains the storage data before the reset.

[0091] The abnormal reset monitoring method of the multi-core microcontroller unit in the embodiment of the present invention designs a non-clear random access memory so that when an exception occurs during the entire program operation, the generated exception information can be stored in a designated area of ​​the non-clear random access memory for data protection, so that the data in the protected area will not be cleared during subsequent reset. Example 3

[0092] Please refer to Figure 8, which is a schematic diagram of the structure 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 circumstances, it can also be a smart device such as a mobile phone, a tablet computer, and a monitoring terminal, as well as an image acquisition device with processing functions. As shown in Figure 8, the electronic device may include:

[0093] A memory 510 storing executable program code;

[0094] a processor 520 coupled to the memory 510;

[0095] The processor 520 calls the executable program code stored in the memory 510 to execute part or all of the steps in the abnormal reset monitoring method of the multi-core micro control unit in the first embodiment.

[0096] An embodiment of the present invention discloses a computer-readable storage medium storing a computer program, wherein the computer program enables a computer to execute some or all of the steps in the abnormal reset monitoring method for a multi-core microcontroller unit in the first embodiment.

[0097] An embodiment of the present invention further discloses a computer program product, wherein when the computer program product is run on a computer, the computer is caused to execute some or all of the steps in the abnormal reset monitoring method of the multi-core micro control unit in the first embodiment.

[0098] An embodiment of the present invention also discloses an application publishing platform, wherein the application publishing platform is used to publish a computer program product, wherein when the computer program product runs on a computer, the computer executes some or all of the steps in the abnormal reset monitoring method of the multi-core micro control unit in embodiment one.

[0099] In various embodiments of the present invention, it should be understood that the size of the serial numbers of the processes does not necessarily mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0100] The units described as separate components may or may not be physically separate, 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. Some or all of these units may be selected based on actual needs to achieve the objectives of this embodiment.

[0101] In addition, the functional units in the embodiments of the present invention may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The integrated unit may be implemented in the form of hardware or software functional units.

[0102] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-accessible memory. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests for causing a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute some or all of the steps of the method described in various embodiments of the present invention.

[0103] In the embodiments provided herein, it should be understood that "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B based solely on A; B can also be determined based on A and / or other information.

[0104] Those skilled in the art will appreciate that some or all of the steps in the various methods of the embodiments may be performed by instructing related hardware through a program. The program may be stored in a computer-readable storage medium, including a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0105] The above is a detailed introduction to the abnormal reset monitoring method, device, electronic device and storage medium of the multi-core microcontroller unit disclosed in the embodiments of the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for general technical personnel in this field, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A method for monitoring abnormal reset of a multi-core microcontroller unit, characterized in that: include: After detecting that a processing core in a multi-core microcontroller unit enters an abnormal program branch, abnormal program information of a corresponding program abnormality scene is obtained, wherein the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level; Obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into a designated storage area of ​​a non-clear random access memory, and perform a microcontroller unit reset operation, wherein the non-clear random access memory refers to a reset that does not clear the RAM, and the designated storage area in the non-clear random access memory is configured so that after a microcontroller unit software reset is performed, the data in the designated storage area remains as the storage data before the reset.

2. The abnormal reset monitoring method of a multi-core microcontroller unit according to claim 1, characterized in that: Before the microcontroller unit reset operation is performed, the method further includes: The flag state of the abnormal identification position is adjusted to a first state, wherein the flag state includes a first state and a second state.

3. The abnormal reset monitoring method of a multi-core microcontroller unit as claimed in claim 2, characterized in that: After acquiring the current processing core identity information associated with the abnormal program information, the method further includes: A first check value of the processing core identity information and the abnormal program information is calculated according to a cyclic check algorithm, and the first check value is written into a designated storage area of ​​a non-clear random access memory.

4. The abnormal reset monitoring method of a multi-core microcontroller unit as claimed in claim 3, characterized in that: After the microcontroller unit reset operation is performed, the method further comprises: Acquiring, at the main processing core, the processing core identity information and the abnormal program information of the designated storage area of ​​the non-clear random access memory; Calculating a second check value of the processing core identity information and the abnormal program information at the main processing core according to a cyclic check algorithm, and comparing the second check value with a first check value stored in a non-clear random access memory, and after the comparison is passed, determining a corresponding fault diagnosis code and snapshot information according to the processing core identity information, the abnormal program information and the set conditions; The fault diagnostic code and the snapshot information are transmitted to a diagnostic event management module so that a user can obtain the corresponding fault diagnostic code through a diagnostic interface.

5. The abnormal reset monitoring method of a multi-core microcontroller unit according to any one of claims 1 to 4, characterized in that: After detecting that a processing core in the multi-core micro control unit enters an abnormal program branch, the method further includes: Determine abnormal category information according to the abnormal program branch; the abnormal category information has at least two; Determine the abnormal program level according to the abnormal category information, wherein there is a fixed mapping relationship between each abnormal category information and the abnormal program level; When it is detected that the abnormal program level is the first abnormal level, the first abnormal address information is obtained in the register EIPC and the first abnormal reason code is obtained in the register EIIC; When it is detected that the abnormal program level is the second abnormal level, the second abnormal address information is obtained in the register FEPC and the second abnormal reason code is obtained in the register FEIC.

6. The abnormal reset monitoring method of a multi-core microcontroller unit according to any one of claims 1 to 4, characterized in that: The abnormal time information is obtained by the following steps: After entering the abnormal program branch, the system time information is acquired, and the system time information is determined as the abnormal time information, where the abnormal time information is the timestamp information at the time of the abnormality.

7. The abnormal reset monitoring method of a multi-core microcontroller unit according to claim 1, characterized in that: The space size of the designated storage area is at least 200 bytes; the non-clear random access memory is configured to be shared by multiple core micro control units.

8. An abnormal reset monitoring device for a multi-core microcontroller unit, characterized in that: include: An acquisition module: used to acquire abnormal program information of a corresponding program abnormality scene after detecting that a processing core in a multi-core microcontroller unit enters an abnormal program branch, wherein the abnormal program information includes one or more of abnormal address information, abnormal time information, abnormal category information, abnormal core source information, and abnormal program level; Storage module: used to obtain the current processing core identity information associated with the abnormal program information, write the processing core identity information and the abnormal program information into a designated storage area of ​​a non-clear random access memory, and perform a micro-control unit reset operation, wherein the non-clear random access memory refers to a reset that does not clear the RAM, and the designated storage area in the non-clear random access memory is configured so that after the micro-control unit software is reset, the data in the designated storage area remains as the storage data before the reset.

9. An electronic device, characterized in that: include: A memory storing executable program code; a processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the abnormal reset monitoring method of the multi-core micro control unit according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program enables a computer to execute the abnormal reset monitoring method for a multi-core micro control unit according to any one of claims 1 to 7.

Images