Exception-based reset monitoring method for multi-core microcontroller unit

Abstract

An exception-based reset monitoring method for a multi-core microcontroller unit comprises acquiring the exception program information from a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; writing the processing core identity information and the exception program information to a specific storage area of ​​a non-erasable random-access memory.The restart-by-exception monitoring method for a multi-core microcontroller unit is designed with non-erasable random access memory in order to allow that, when an exception occurs during the execution of an entire program, the generated exception information can be stored in a specific area of ​​the non-erasable random access memory for data protection, and the data present in a protected area is not erased during the subsequent restart.

Description

EXCEPTIONAL RESTART MONITORING METHOD FOR UNIT MULTI-CORE MICROCONTROLLER Technical field This application relates to the technical field of microcontrollers and, in particular, relates to a method and device for monitoring restart by exception for a multi-core microcontroller unit. Background of the technique Currently, in an automotive controller, when an exception occurs during the execution of an MCU system due to improper use of MCU resources by a user or a failure of the MCU itself, the software enters an exception program branch (TRAP). At this point, a common software practice is to reset the software (passive reset) to a normal state using a watchdog timer. The fault information is recorded in a read-only memory (ROM), i.e., an NVM module compliant with the AUTOSAR standard, by some designers before the software reset, and then the MCU is restarted, making it easy to identify the cause of the fault after the reset. The problems with this practice are as follows: 1. The generation of a TRAP can be caused by an error in the NVM itself (or its submodules MemIf, Fee, and Fls); in fact, this is a very common error; and, in this case, the operation of the NVM can cause a new failure; 2. This passive restart method using a watchdog consumes a long amount of time, usually tens or even hundreds of milliseconds, and the operation of the NVM itself also consumes time (especially during sector switching in the Fee module), which is not conducive to a quick recovery from the MCU failure; 3. In a multi-core MCU system, the NVM can normally only be executed by one core (e.g., Core0), and when another core (e.g., Core1) accesses the TRAP program branch, it is clear that an interface of the NVM cannot be invoked directly by Core1; 4.Passive restarts typically require a certain amount of time for waveform filtering (for example, the time corresponding to the watchdog timeout), which is not conducive to rapid fault recovery. Therefore, the technical problem that urgently requires a solution for people with average technical knowledge is the design of a solution that allows for rapid restart after a fault and enables the investigation of the fault's cause after the restart. Brief description of the invention In view of these defects, an embodiment of the present application discloses an exception-based restart monitoring method for a multi-core microcontroller unit, which allows the use of random access memory (RAM) to perform the corresponding information logging and accelerate fault recovery; as well as using an active restart instead of a passive restart to speed up the microcontroller unit restart and make the software flow more controllable. In the first aspect, the present application discloses a method for monitoring restarts by exception for a multi-core microcontroller unit, comprising: acquire the exception program information of a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information includes one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level; acquire the current processing core identity information associated with the exception program information, write the processing core identity information and the exception program information to a specific storage area of ​​a non-erasable random access memory (a RAM that is not erased upon reboot, hereinafter referred to as "non-erasable RAM") and execute the microcontroller unit reboot operation, wherein the specific storage area of ​​the non-erasable RAM is configured so that, once the microcontroller unit software has been rebooted, the data present in the specific storage area is preserved as the data stored before the reboot. As an optional embodiment, in the first aspect of the implementation of this application, the method further comprises the following step before performing the microcontroller unit reset operation: adjust a brand state of an exception identifier position to a first state, where the brand state includes a first state and a second state. Once the fault information has been recorded, the flag state must be adjusted. This allows the system to determine whether a subsequent operation is required based on the flag state information during the next initialization of an application program, thus improving overall program execution fluidity. As an optional embodiment, in the first aspect of the implementation of this application, the method further comprises the following steps after acquiring the current processing core identity information associated with the exception program information: Calculate a first check value of the processing core identity information and exception program information according to a cyclic check algorithm and write the first check value to the specified storage area of ​​non-erasable random access memory. A CRC32 algorithm is used to perform a redundancy calculation on the relevant information to obtain a check value. This check value is then used as the baseline for subsequent redundancy checks. In this way, a CRC32 value for the non-erasable RAM is recalculated after the software has been restarted. By comparing this value to a CRC32 value recorded before the restart, it is possible to determine if the non-erasable RAM has been altered. Consequently, the accuracy of the subsequent fault data output can be further improved. As an optional embodiment, in the first aspect of the implementation of this application, the method further comprises the following steps after performing the microcontroller unit reset operation: acquire the processing core identity information and exception program information from the specific storage area of ​​non-erasable random access memory in a primary processing core (Core0); Calculate a second check value of the processing core identity information and exception program information according to a cyclic check algorithm on the main processing core (Core0), compare the second check value with the first check value stored in non-erasable random access memory and, once the comparison is passed, determine the corresponding diagnostic fault codes and snapshot information according to the processing core identity information, exception program information and the established conditions; transmit diagnostic fault codes and snapshot information to a diagnostic event management module so that a user can acquire the corresponding diagnostic fault codes through a diagnostic interface. Exception failure information can be analyzed and recorded through the aforementioned steps, and a corresponding diagnostic interface can be provided so that a corresponding user can directly acquire the corresponding fault diagnostic information, greatly improving the possibility of analyzing a root cause of the failure. As an optional embodiment, in the first aspect of the implementation of this application, the method further comprises the following steps after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch: determine the exception category information according to the exception program branch, where the exception category information is of at least two types; determine the exception program level according to the exception category information, where there is a fixed mapping relationship between each type of exception category information and the exception program level; When the detected exception program level is a first exception level, acquire a first exception address information in an EIPC register and acquire a first exception cause code in an EIIC register; When the detected exception program level is a second exception level, acquire a second exception address information in a FEPC register and acquire a second exception cause code in a FEIC register, respectively. In a specific implementation, exception category information is associated with the exception program level, making it possible to map the corresponding exception levels, regardless of the type of exception that occurred, and to acquire the corresponding exception addresses and exception cause codes, which is convenient and practical for subsequent information recording and simplified recording of exception categories based on actual structures. As an optional implementation, in the first aspect of implementing this application, the exception time information is acquired through the following steps: acquire system timing information after accessing the exception program branch and identify the system timing information as the exception timing information, wherein the exception timing information is timestamp information that indicates when an exception occurs. The above steps are specific time acquisition steps, through which information about a specific point in time when an exception occurs can be determined, thus improving the convenience and practicality of acquiring time information. As an optional embodiment, in the first aspect of the implementation of the present application, a specific storage area space size of at least 200 bytes; and the non-erasable RAM is configured to be shared by the multi-core microcontroller unit. Random access memory (RAM) features high-speed read speeds and user-defined allocation, enabling rapid data access and sharing by the multi-core microcontroller. By using non-erasable RAM shared by multiple cores, it's possible to ensure that one core processes a fault while other cores simply record fault information. Simultaneously, the recorded fault information is preserved after a fast reboot due to its non-erasable nature. When configuring a specific storage area, it is possible to reserve a sufficient amount of space, since RAM usually has much more abundant resources and is more flexible in terms of allocation than an NVM. Secondly, the present application discloses an exception restart monitoring device for a multi-core microcontroller unit, comprising: an acquisition module: used to acquire exception program information from a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information includes one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level; A storage module: used to acquire the current processing core identity information associated with the exception program information, write the processing core identity information and the exception program information to a specified storage area of ​​a non-erasable RAM, and execute the microcontroller unit reset operation, wherein the specified storage area of ​​the non-erasable RAM is configured so that, once the microcontroller unit software has been reset, the data present in the specified storage area is preserved as the data stored before the reset. In a third aspect, the implementation of this application discloses an electronic device comprising a memory that stores executable program codes and a processor that is coupled to the memory; the executable program codes stored in the memory are invoked by the processor to execute the reset-by-exception monitoring method for a multi-core microcontroller unit disclosed in the first aspect of the implementation of this application. In a fourth aspect, the implementation of this application discloses a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and the computer program enables a computer to execute the reset-by-exception monitoring method for a multi-core microcontroller unit disclosed in the first aspect of implementing this application. Compared to the state of the art, the filing of this application presents the following beneficial effects: The method of monitoring restart by exception for a multi-core microcontroller unit of the implementation of this application is designed with non-erasable random access memory (non-erasable RAM) instead of NVM in order to allow that, when an exception occurs during the execution of an entire program, the generated exception information can be stored in a specific area of ​​the non-erasable RAM for data protection and, through reasonable design, the data present in a protected area is not erased during the subsequent restart. Brief description of the drawings To describe more clearly the technical solutions of the embodiments of this application, the drawings required for use in the embodiments are presented below in a simplified manner. As is evident, the drawings in the following description are only some embodiments of this application; persons with ordinary skill in the art can obtain other drawings based on these drawings without any additional creative effort. Fig. 1 is a flowchart of an exception-based reset monitoring method for a multi-core microcontroller unit disclosed in an embodiment of the present application. Fig. 2 is a flowchart specific to an exception-based restart monitoring method for a multi-core microcontroller unit disclosed in an embodiment of the present application. Fig. 3 is a flowchart of the failure analysis disclosed in an embodiment of the present application. Figure 4 is a flowchart of the exception level determination and exception cause acquisition disclosed in an implementation of this application. Fig. 5 is a diagram of an information logging process disclosed in an implementation of the present application after the software has accessed an exception program branch. Figure 6 is a flowchart of a method for preserving non-erasable RAM without erasing after a reboot disclosed in an embodiment of the present application. Fig. 7 is a structural schematic diagram of an exception reset monitoring device for a multi-core microcontroller unit provided in an embodiment of the present application. Fig. 8 is a structural schematic diagram of an electronic device provided in an embodiment of the present application. Detailed description of the invention The technical solutions of the embodiments covered by this application will be described below clearly and completely, and in conjunction with the drawings of the embodiments covered by this application. As is evident, the embodiments described are only some of the embodiments covered by this application, not all of them. All other embodiments obtained by persons of ordinary skill in the art and based on the embodiments covered by this application without contributing creative effort will fall within the scope of protection of this application. It is important to note that, as used in the description and claims of this application, terms such as "first," "second," "third," "fourth," and the like are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "having," as well as any variants thereof, are intended, in the embodiments of this application, to cover a non-exclusive inclusion; for example, processes, methods, systems, products, or devices comprising a series of steps or units are not limited to the steps and units explicitly listed, but include other steps or units that are not explicitly mentioned or that are inherent in these processes, methods, products, or devices. When a program accesses an exception program branch (TRAP) due to an MCU runtime fault, a normal program cannot feed a watchdog timer, and the MCU is reset (passive reset) due to the watchdog timeout, so the software restarts to a normal state. This is a common processing method for an MCU exception. To acquire the cause of an exception reset, fault information is typically logged to non-volatile memory (in an AUTOSAR architecture, an NVM is used) after the software has accessed the TRAP branch. Fault analysis is then performed by reading the information acquired by the NVM after the software reset. The NVM has inherent problems and is not suitable for an exception reset processing program. Furthermore, the "passive reset" method is not conducive to timing control of the software reset.The embodiments of this application disclose an exception-based restart monitoring method, a device, an electronic device, and a storage medium for a multi-core microcontroller unit, all of which are designed with non-erasable random-access memory to allow, when an exception occurs during the execution of a complete program, the generated exception information to be stored in a specific area of ​​the non-erasable random-access memory for data protection, and the data present in the protected area is not erased during the subsequent restart. Implementation 1 Referring to Figure 1, Figure 1 is a flowchart of an exception-based reset monitoring method for a multi-core microcontroller unit disclosed in an embodiment of this application. An executor of the method in the embodiment of this application consists of software and / or hardware and can receive relevant information via wired and / or wireless means, as well as send certain instructions. The executor may also possess certain processing and storage functions. The executor can control multiple devices, such as a remote physical server or a cloud server and related software, or a local host or server and related software, which perform related operations on a device located somewhere.In some scenarios, the executor body may also control multiple storage devices, and the storage devices may be located in the same place or in different places. As shown in Fig. 1 and Fig. 2, the reset-by-exception monitoring method for a multi-core microcontroller unit comprises the following steps: S101: Acquire exception program information from a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information includes one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level; S102: acquire the current processing core identity information associated with the exception program information, write the processing core identity information and the exception program information to a specified storage area of ​​a non-erasable random access memory and execute the microcontroller unit reset operation, wherein the specified storage area of ​​the non-erasable random access memory is configured so that, once the microcontroller unit software has been reset, the data present in the specified storage area is preserved as the data stored before the reset. In a specific implementation, an exception condition may occur during the execution of an application program. When a kernel accesses an exception program branch (TRAP), an important aspect is acquiring related information from a program exception point. This information includes the exception's address, the time of the exception, the exception category, the exception source kernel (which kernel the exception originated from), the exception level, and so on. The specific information that can be obtained varies from one MCU to another. In the implementation of this application, non-erasable RAM is used instead of NVM to record TRAP-related information, thus avoiding problems caused by inherent NVM defects. Active reset is used instead of passive reset to control the software reset timing and program flow direction. This allows for precise control of the software reset timing, and the corresponding fault information is not erased upon reset, thereby ensuring data storage stability. In the implementation of this application, non-erasable RAM refers to RAM that is not erased upon reset. Specifically, once the MCU software is reset, the non-erasable RAM retains the same value it held before the reset. Specifically, after software running on any of the MCU cores accesses the TRAP program branch, a large amount of fault-related information can be logged into non-erasable RAM, and the MCU can then be actively reset by the software; the process typically takes a few microseconds. More preferably, the method further comprises the following step before performing the microcontroller unit reset operation: adjust a brand state of an exception identifier position to a first state, where the brand state includes a first state and a second state. Once the fault information has been recorded, the flag state must be adjusted. This allows the system to determine whether a subsequent operation is required based on the flag state information during the next initialization of an application program, thus improving overall program execution fluidity. More preferably, the method further comprises the following steps after acquiring the current processing core identity information associated with the exception program information: Calculate a first check value of the processing core identity information and exception program information according to a cyclic check algorithm and write the first check value to the specified storage area of ​​non-erasable random access memory. A CRC32 algorithm is used to perform a redundancy calculation on the relevant information to obtain a check value. This check value is then used as the baseline for subsequent redundancy checks. In this way, a CRC32 value for the non-erasable RAM is recalculated after the software has been restarted. By comparing this value to a CRC32 value recorded before the restart, it is possible to determine if the non-erasable RAM has been altered. Consequently, the accuracy of the subsequent fault data output can be further improved. More preferably, Fig. 3 is a flowchart of a failure analysis disclosed in an embodiment of the present application; as shown in Fig. 3, the method further comprises the following steps after performing the reset operation of the microcontroller unit: S103: Acquire processing core identity information and exception program information from the specific storage area of ​​non-erasable random access memory on a primary processing core; S104: Calculate a second check value of the processing core identity information and exception program information according to a cyclic check algorithm on the main processing core, compare the second check value with the first check value stored in the non-erasable random access memory and, once the comparison is passed, determine the corresponding diagnostic fault codes and snapshot information according to the processing core identity information, exception program information and the set conditions; S105: Transmit diagnostic fault codes and snapshot information to a diagnostic event management module so that a user can acquire the corresponding diagnostic fault codes via a diagnostic interface. Exception failure information can be analyzed and recorded through the aforementioned steps, and a corresponding diagnostic interface can be provided so that a corresponding user can directly acquire the corresponding fault diagnostic information, greatly improving overall convenience and practicality and the universality of application scenarios. Once the software has restarted and Core0 has verified that the information present in the non-erasable RAM is correct, the source of the fault (e.g., which core the fault originates from), the fault category, the address of the program that presents the fault, etc., can be extracted, the fault is reported to a Dem module according to the information, and then the user can read a fault code through the diagnostic interface. In this application, the analysis of Trap fault information is performed during an application initialization phase, as shown in Fig. 2. The Trap fault information input is the information stored in non-erasable RAM, and the Trap fault information output consists of the DTC codes and snapshot information to be reported to the Dem module. The number of DTC codes corresponding to a Trap can be large or small and can be assigned according to system requirements, which are not described in detail herein.Specifically, first, the Trap_Flag setting is checked to see if it is TRUE. Data in non-erasable RAM only needs to be analyzed when Trap_Flag is TRUE. Next, the CRC32 value of the non-erasable RAM data is checked to see if it is correct. Data only needs to be processed when the CRC32 value is correct. Finally, the CRC is sorted, and the snapshot data is allocated according to actual needs. If the DTC codes are set according to CoreID, two DTC codes can be set. A snapshot of the DTC codes can be selected from all or part of the information present in non-erasable RAM. In this way, an automotive diagnostic engineer can determine information such as the location and timing of a program error, as well as the core to which the program error belongs, by reading the fault code and its snapshot. More preferably, Fig. 4 is a flowchart of the exception level determination and exception cause acquisition disclosed in an embodiment of this application; Fig. 5 is a flowchart of an information logging process disclosed in an embodiment of this application after the software has accessed an exception program branch; as shown in Fig. 4 and Fig. 5, the method further comprises the following steps after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch: S1011: Determine exception category information according to the exception program branch, wherein the exception category information is of at least two types; S1012: Determine the exception program level according to the exception category information, where there is a fixed mapping relationship between each type of exception category information and the exception program level; S1013: When the detected exception program level is a first exception level, acquire a first exception address information in an EIPC register and acquire a first exception cause code in an EIIC register; S1014: When the detected exception program level is a second exception level, acquire a second exception address information in a FEPC register and acquire a second exception cause code in a FEIC register, respectively. In a specific implementation, exception category information is associated with the exception program level, making it possible to map the corresponding exception levels, regardless of the type of exception that occurred, and to acquire the corresponding exception addresses and exception cause codes, which is convenient and practical for subsequent information recording and simplified recording of exception categories based on actual structures. More preferably, exception time information is acquired through the following steps: acquire system timing information after accessing the exception program branch and identify the system timing information as the exception timing information, wherein the exception timing information is timestamp information that indicates when an exception occurs. The above steps are specific time acquisition steps, through which information about a specific point in time when an exception occurs can be determined, thus improving the convenience and practicality of acquiring time information. In preparing this application, the Renesas RH850 P1H-C MCU is used as an example to illustrate a corresponding design solution. The Renesas RH850 P1H-C MCU primarily uses two exception levels: EI and FE, as well as 15 exception categories. Each exception category has a separate exception program branch; that is, each exception program branch activates a corresponding exception category. There is a fixed mapping relationship between the exception category and the exception program level; therefore, when a program throws an exception and accesses an exception program branch, its exception category is also known.When the exception program level is EI, the exception address (ExpAddr) and the exception cause code (CauseCode) can be acquired from the EIPC register and the EIIC register, respectively; when the exception program level is FE, the exception address (ExpAddr) and the exception cause code (CauseCode) can be acquired from the FEPC register and the FEIC register, respectively. In the execution of this application, the exception time, i.e., the timestamp at which the exception occurs, can be obtained by acquiring the system time (SystemTimer) after entering the exception program branch. All previously acquired information is summarized and finally written to non-erasable RAM, along with the current kernel ID (which indicates the kernel from which the program accesses the Trap), and the Trap access flag position information (Trap_Flag) is set to TRUE. Finally, the CRC32 value of all the written information is calculated and recorded in a final portion of non-erasable RAM. In this way, the CRC32 value of the non-erasable RAM is recalculated once the software has been restarted, and by comparing it with the CRC32 value recorded before the restart, it is possible to determine if the non-erasable RAM has been altered. A process for acquiring Trap fault information is shown in Fig. 5. More preferably, a specific storage area space size of at least 200 bytes; and the non-erasable random access memory is configured to be shared by the multi-core microcontroller unit. Random access memory (RAM) offers high read speeds and convenient operation, allowing it to be shared by a multi-core microcontroller. By using non-erasable RAM shared by multiple cores, it's possible to ensure that one core processes a fault while other cores simply record fault information. By allocating a specific storage area, adequate space can be reserved to facilitate future expansion of the solution, for example, by increasing the number of cores and the amount of fault information stored. In this application, non-erasable RAM refers to a segment of the RAM address block whose contents are not reset to a default value after a software reboot. Non-erasable RAM must be implemented using a combination of software and hardware. From the MCU reboot to the application's use of non-erasable RAM, three phases are required: RAM module reset (hardware guarantee), RAM initialization by the bootloader software (software guarantee), and RAM initialization by the application (software guarantee). Only when the data in the specific RAM area is not erased during these three phases can the application's diagnostic software acquire the pre-reboot TRAP information from the non-erasable RAM.The MCU reboot is divided into hard reboot, system reboot, and software reboot; only when a soft reboot is selected and STAC_LM0 register = 1, is the last 1 KB of SelfRam space (hereafter referred to as SelfRam_Last) not reset to a hardware default value after the reboot. During the bootloader and application initialization phases, SelfRam_Last is not initialized, and the non-erasable RAM can be designed as shown in Fig. 6.In other words, the Bootloader software and the application program are provided with a corresponding instruction segment, respectively; when executed, the two instruction segments do not perform an operation to erase the data present in the specific storage area of ​​the non-erasable RAM, but only perform an operation to erase the data present in the areas that are outside the specific storage area of ​​the non-erasable RAM, so that the specific data information can be acquired in a later application program initialization phase. In implementing this application, non-erasable RAM is used instead of NVM to record TRAP-related information, thus avoiding problems caused by inherent NVM defects; an active restart is used instead of a passive restart to control software restart time and program flow direction; by using shared multi-core non-erasable RAM, it can be ensured that one core processes a fault while the other cores only record fault information; and CheckSum is used to ensure the consistency of the non-erasable RAM data.To implement the exception monitoring method, the first step is to design the "non-erasable RAM"; second, to acquire as much critical information as possible after accessing the Trap; and finally, to analyze the cause of the failure, obtain the fault code and snapshot information, and report this fault code and the corresponding information to the Dem module after the software restart. A software flow is shown in Fig. 2 below. The design of the solution for the implementation of this application comprises three key steps: the design of the non-erasable RAM, the acquisition of Trap fault information, and the analysis of the Trap fault information. Although the developed exception-based reset monitoring method can, in theory, be used on any automotive-grade MCU, the corresponding fault acquisition may need to be performed specifically for different MCUs, since a software exception (TRAP) is closely related to the MCU itself; specifically, the types of TRAPs and the TRAP generation mechanisms vary among different MCUs. The solution proposed in this application offers the following advantages: first, by using RAM instead of the NVM to record information, fault recovery is faster; second, by using RAM with relatively abundant resources instead of the NVM, a greater amount of fault information can be recorded, and analysis is convenient and practical; third, by using an active reset instead of a passive reset, the MCU restart is faster, and the software flow is more controllable; fourth, an analyzed fault is reported to the Dem module, rather than being stored directly in the NVM, which is more in line with automotive software standards. The method of monitoring restart by exception for a multi-core microcontroller unit of the implementation of this application is designed with non-erasable random access memory in order to allow that, when an exception occurs during the execution of an entire program, the generated exception information can be stored in a specific area of ​​the non-erasable random access memory for data protection and the data present in a protected area is not erased during the subsequent restart. Implementation 2 With reference to Fig. 7, Fig. 7 is a structural schematic diagram of an exception reset monitoring device for a multi-core microcontroller unit disclosed in an embodiment of this application. As shown in Fig. 7, the exception reset monitoring device for a multi-core microcontroller unit may comprise: an acquisition module 21: used to acquire exception program information from a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information includes one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level;n storage module 22: used to acquire the current processing core identity information associated with the exception program information, write the processing core identity information and the exception program information to a specified storage area of ​​a non-erasable RAM and execute the microcontroller unit reset operation, wherein the specified storage area of ​​the non-erasable RAM is configured so that, once the microcontroller unit software has been reset, the data present in the specified storage area is preserved as the data stored before the reset.; The method of monitoring restart by exception for a multi-core microcontroller unit of the implementation of this application is designed with non-erasable random access memory in order to allow that, when an exception occurs during the execution of an entire program, the generated exception information can be stored in a specific area of ​​the non-erasable random access memory for data protection and the data present in a protected area is not erased during the subsequent restart. Implementation 3 With reference to Fig. 8, Fig. 8 is a schematic structural diagram of an electronic device disclosed in an embodiment of this application. The electronic device may be a computer, a server, etc. Of course, in certain cases, the electronic device may also be a smart device, such as a mobile phone, a tablet, and a monitoring terminal, as well as an image capture device with a processing function. As shown in Fig. 8, the electronic device may comprise: a 510 memory that stores executable program codes; a 520 processor that is coupled to the 510 memory; The executable program codes stored in memory 510 are invoked by the processor 520 to execute some or all of the steps of the reset-by-exception monitoring method for a multi-core microcontroller unit of realization 1. The implementation of this application discloses a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and the computer program enables a computer to execute some or all of the steps of the reset-by-exception monitoring method for a multi-core microcontroller unit of embodiment 1. The filing of this application also discloses a computer program product, wherein, when the computer program product is run on a computer, the computer can execute some or all of the steps of the reset-by-exception monitoring method for a multi-core microcontroller unit of embodiment 1. The execution of this application also discloses an application publishing platform, wherein the application publishing platform is used to publish the computer program product, and when the computer program product is executed on a computer, the computer may execute some or all of the steps of the reset-by-exception monitoring method for a multi-core microcontroller unit of embodiment 1. In various embodiments of this application, it should be understood that the serial number values ​​of the processes do not imply a mandatory execution order, and the execution order of the processes will be determined by their internal functions and logic, and will not constitute any limitation for the implementation process of the embodiments of this application. 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; that is, the components may be located in a single place or distributed across several network units. The purpose of the solution in the present implementation can be achieved by selecting some or all of the units according to actual needs. Furthermore, each functional unit of the various embodiments of this application may be integrated into a processing unit, or each unit may exist physically as an individual unit, or two or more units may be integrated into a single unit. The integrated unit may be implemented in a hardware form or as a software functional unit. If implemented as a functional software unit and sold or used as a standalone product, the integrated unit can be stored in computer-accessible memory. Based on this understanding, the technical solutions in this application can be reflected, in essence, in the form of a software product or as a contributing part of the prior art. The computer software product is stored in memory and includes various instructions to enable a computing device (which may be a personal computer, a server, a network device, etc.) to execute some or all of the steps of the methods in various embodiments of this application. In the realizations provided in this application, it is necessary to understand that "B corresponds to A" indicates that B is associated with A, and that B can be determined in accordance with A. However, it should also be understood that determining B in accordance with A does not mean that B is determined solely in accordance with A, but that B can also be determined in accordance with A and / or other information. People with ordinary technical knowledge will understand that some or all of the steps in the various methods of implementation can be completed by means of programs that instruct the corresponding hardware. These programs can be stored on a computer-readable storage medium. Storage media include 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 (CD-ROM), or other optical disc memory, disk memory, magnetic tape memory, or any other computer-readable medium that can be used to transport or store data. The exception-based reset monitoring method, device, electronic device, and storage medium for a multi-core microcontroller unit disclosed in the embodiments of this application have been described in detail above. Specific examples are used herein to illustrate the principle and embodiments of this application. The illustrations of the above embodiments are used only to aid in understanding the method and central idea of ​​this application. Furthermore, for persons of ordinary skill in the art, the specific embodiments and scope of application may be modified in accordance with the concept of this application. Ultimately, the content of the description should not be construed as a limitation of this application.

Claims

1. A method for monitoring a restart by exception for a multi-core microcontroller unit, comprising: acquiring the exception program information of a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information comprising one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level; acquiring the current processing core identity information associated with the exception program information,Writing the processing core identity information and the exception program information to a specific storage area of ​​a non-erasable random access memory and executing the microcontroller unit reset operation, wherein the non-erasable random access memory refers to RAM that is not erased upon reset, the specific storage area of ​​the non-erasable random access memory is configured such that, once the microcontroller unit software has been reset, the data present in the specific storage area is preserved as the data stored before the reset.

2. Exception Reset Monitoring Method for a Multi-Core Microcontroller Unit according to Claim 1,wherein the method further comprises the following step before executing the microcontroller unit reset operation: setting a flag state of an exception identifier position to a first state, wherein the flag state comprises a first state and a second state.

3. Exception reset monitoring method for a multi-core microcontroller unit according to claim 2,wherein the method further comprises the following steps after acquiring the current processing core identity information associated with the exception program information: calculating a first check value of the processing core identity information and the exception program information according to a cyclic check algorithm and writing the first check value to the designated storage area of ​​the non-erasable random access memory.

4. Exception Reset Monitoring Method for a Multi-Core Microcontroller Unit according to claim 3,wherein the method further comprises the following step after performing the microcontroller unit reset operation: acquiring the processing core identity information and the exception program information from the specific storage area of ​​the non-erasable random access memory in a main processing core; calculating a second check value from the processing core identity information and the exception program information according to a cyclic check algorithm in the main processing core, comparing the second check value with the first check value stored in the non-erasable random access memory and, once the comparison is passed, determining the corresponding diagnostic fault codes and snapshot information according to the processing core identity information,the exception program information and the established conditions; transmit the diagnostic fault codes and snapshot information to a diagnostic event management module so that a user can acquire the corresponding diagnostic fault codes through a diagnostic interface.

5. Exception Reset Monitoring Method for a Multi-Core Microcontroller Unit according to any of claims 1-4, wherein the method further comprises the following steps after the detection that a processing core of a multi-core microcontroller unit has accessed an exception program branch: determine the exception category information according to the exception program branch, wherein the exception category information is of at least two types; determine the exception program level according to the exception category information,wherein there is a fixed mapping relationship between each type of exception category information and the exception program level; when the detected exception program level is a first exception level, acquire a first exception address information in an EIPC register and acquire a first exception cause code in an EIIC register; when the detected exception program level is a second exception level, acquire a second exception address information in a FEPC register and acquire a second exception cause code in a FEIC register, respectively.

6. Exception Reset Monitoring Method for a Multicore Microcontroller Unit according to any of claims 1-4,wherein the exception timing information is acquired by the following steps: acquiring system timing information after accessing the exception program branch and identifying the system timing information as the exception timing information, wherein the exception timing information is timestamp information indicating when an exception occurs.

7. Exception Reset Monitoring Method for a Multicore Microcontroller Unit according to claim 1, wherein the size of the specified storage area is at least 200 bytes; and the non-erasable random access memory is configured to be shared by the multicore microcontroller unit.

8. Exception Reset Monitoring Device for a Multicore Microcontroller Unit,comprising: an acquisition module: used to acquire the exception program information from a corresponding program exception point after detecting that a processing core of a multi-core microcontroller unit has accessed an exception program branch; the exception program information comprising one or more of the following: exception address information, exception time information, exception category information, exception source core information, and exception program level; a storage module: used to acquire the current processing core identity information associated with the exception program information, write the processing core identity information and the exception program information to a designated storage area of ​​non-erasable random-access memory, and execute the microcontroller unit reset operation,wherein non-erasable random access memory refers to RAM that is not erased upon reboot, the specific storage area of ​​the non-erasable random access memory is configured such that, once the microcontroller unit software has been rebooted, the data present in the specific storage area is preserved as the data stored before the reboot.

9. An electronic device comprising a memory that stores executable program codes and a processor coupled to the memory; the executable program codes stored in the memory are invoked by the processor to execute the reboot-by-exception monitoring method for a multi-core microcontroller unit of any of claims 1-7.

10. A computer-readable non-transient storage medium, wherein a computer program is stored on the computer-readable storage medium,and the computer program enables a computer to execute the reset-by-exception monitoring method for a multi-core microcontroller unit of any of claims 1-7.,

Images