Software exception recovery method and embedded system

Abstract

The application discloses a software exception recovery method and an embedded system, and relates to the technical field of embedded systems.The method comprises the following steps: after a watchdog exception occurs in a first processor core, the exception is synchronized to each slave core through an inter-core interrupt and a shared memory variable; each slave core executes a WFI instruction to enter hibernation; the master core resets all the slave cores and sets the mepc of the master core to an operating system firmware initialization entry address loaded in a random access memory; the master core directly jumps to the entry to execute a first initialization operation through an instruction for returning from exception processing and jumping to a specified address; the master core resets all the slave cores during the first initialization operation; and each slave core executes a second initialization operation from the same entry in response to the reset. Since the master core directly jumps to the initialization entry of the OS firmware, the OS firmware does not need to be reloaded, and the recovery delay is significantly shortened; and reliable multi-core synchronization is achieved through the inter-core interrupt and the shared memory global variable.

Description

Technical Field

[0001] This application relates to the field of embedded system technology, specifically to a software anomaly recovery method and an embedded system. Background Technology

[0002] Embedded real-time systems based on the RISC-V Symmetric Multiprocessing (SMP) architecture can execute more tasks within a specific time frame by dividing tasks among multiple cores (processor cores), thereby improving the system's processing power and real-time response performance. During system operation, individual cores may experience software exceptions such as memory access violations, stack overflows, null pointer dereferences, and / or algorithm logic errors, leading to operating system (OS) exceptions. This can cause watchdog timeouts, preventing the core from continuing to execute its current task. To restore the system to a normal state, an effective exception handling and recovery mechanism is needed. Currently, common exception handling methods for multi-core systems include triggering a global reset through a watchdog timeout exception to restart the entire system.

[0003] The above-mentioned exception handling schemes achieve exception recovery to a certain extent, but they suffer from long recovery delays. The traditional watchdog timeout exception triggering a global reset requires a complete bootloader process, including initializing hardware resources such as the system clock, storage controller, and peripherals, as well as copying the OS firmware from non-volatile memory such as Flash to volatile memory such as Static Random-Access Memory (SRAM) or Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM). This process can take tens of milliseconds or even longer, which is unacceptable for embedded systems with high real-time requirements. Summary of the Invention

[0004] This application provides a software anomaly recovery method and an embedded system to solve the problem that existing embedded multi-core system anomaly handling methods require system-level restarts, resulting in long recovery delays.

[0005] According to a first aspect, one embodiment provides a software anomaly recovery method applied to an embedded system employing a RISC-V symmetric multiprocessing architecture, the embedded system comprising a master core and at least one slave core, the method comprising:

[0006] In response to a watchdog exception occurring in the first processor core of the embedded system, the first processor core synchronizes its exception state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables. The first processor core is either the master core or one of the at least one slave core.

[0007] Each of the slave cores executes a first instruction to put the processor core into a wait state, thereby entering a sleep state;

[0008] The master core resets all the slave cores and sets the value of the master core's mepc register to the initialization entry address of the operating system firmware. The program code pointed to by the initialization entry address is located in the random access memory where the operating system firmware has been loaded.

[0009] The main core executes a second instruction to return from exception handling and jump to a specified address, so as to directly jump to the initialization entry address to perform the first initialization operation;

[0010] During the execution of the first initialization operation, the master core resets all the slave cores.

[0011] In response to being de-reset, each of the slave kernels performs a second initialization operation from the initialization entry address.

[0012] In one embodiment, the first processor core synchronizes its abnormal state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables, including:

[0013] The first processor core sets the value of the shared memory global variable to a value indicating that an anomaly has occurred in the embedded system;

[0014] The first processor core sends an inter-core interrupt to the other processor cores by writing to the software interrupt pending bit in the MSIP register resource corresponding to the other processor cores, so that the other processor cores can read the shared memory global variable.

[0015] In one embodiment, when the first processor core is the master core, each of the slave cores executes the first instruction including:

[0016] After receiving the inter-core interrupt, each slave core reads the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, executes the first instruction.

[0017] In one embodiment, when the first processor core is one of the at least one slave core, each slave core executing the first instruction includes:

[0018] The first processor core executes the first instruction after sending the inter-core interrupt to the other processor cores;

[0019] Upon receiving the inter-core interrupt, the slave cores in each of the other processor cores read the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, execute the first instruction.

[0020] In one embodiment, the method further includes:

[0021] In response to the triggering of the exception / interrupt function of the first processor core, the value of the mcause register of the first processor core is read, wherein the exception / interrupt function is an exception handling function or an inter-core interrupt function;

[0022] Determine whether bit 63 of the mcause register is 0;

[0023] When bit63 is 0, confirm that the exception / interrupt function is the exception handling function, and determine whether the value of the EXCCODE field of the mcause register is 0xFFF;

[0024] When the value of the EXCCODE field is 0xFFF, it is confirmed that a watchdog exception has occurred in the first processor core.

[0025] In one embodiment, the response to a watchdog exception occurring in the first processor core further includes:

[0026] The value of the hardware thread identifier register of the first processor core is read to determine whether the first processor core is the master core or one of the at least one slave core.

[0027] In one embodiment, before the master core resets all the slave cores, the method further includes:

[0028] The master core polls the bits in the sleep state register corresponding to each slave core to determine whether each slave core has entered the sleep state;

[0029] Accordingly, the master core resets all the slave cores, including: for each slave core, the master core resets each slave core after confirming that each slave core has entered a sleep state.

[0030] In one embodiment, the master core resets all the slave cores and de-resets all the slave cores, respectively, by writing to the reset / de-reset control register corresponding to each slave core.

[0031] In one embodiment, the master core resets each of the slave cores individually or in parallel, and de-resets each of the slave cores individually or in parallel.

[0032] According to a second aspect, one embodiment provides an embedded system employing a RISC-V symmetric multiprocessing architecture, including a master core and at least one slave core, wherein the embedded system is configured to execute a software exception recovery method as described in any embodiment of the first aspect of this application when a watchdog exception occurs in any processor core.

[0033] According to the software exception recovery method and embedded system of the above embodiments, firstly, when a watchdog exception occurs in the first processor core (representing any processor core, master core or slave core), the first processor core synchronizes the exception state to all other processor cores in the system through inter-core interrupts and shared memory global variables. Inter-core interrupts can immediately notify other cores, ensuring real-time communication; shared memory global variables provide reliable status indicators, enabling other cores to confirm that the system has entered an exception state, avoiding misinterpreting inter-core communication messages as exception notifications. The combination of these two ensures that all cores consistently enter the recovery process synchronously, improving the reliability of multi-core exception state synchronization. Secondly, after each slave core executes its first instruction to enter a sleep state, the master core performs a reset operation on all slave cores. This sleep-then-reset approach ensures that the slave cores are reset in a controlled, static state, avoiding timing conflicts or state inconsistencies that may occur when resetting while the slave cores are still executing instructions or in an uncontrollable state, thus ensuring the safety and determinism of the reset process. Subsequently, the main core directly sets the value of the mepc register to the initialization entry address of the operating system firmware within the exception handling function, and jumps to this entry point to perform the first initialization operation by executing the second instruction. Since the program code pointed to by this initialization entry address is located in the random access memory already loaded with the OS firmware, and the watchdog exception does not cause data loss in volatile memory, the main core does not need to reload the OS firmware from Flash, nor does it need to re-execute the traditional multi-level firmware boot process. The exception recovery path is shortened from the traditional complete chain to a direct jump from the exception handling function to the OS firmware initialization entry point, significantly reducing recovery latency. Finally, during the execution of the first initialization operation, the main core de-resets all slave cores. After de-resetting, the slave cores begin executing the second initialization operation from the same initialization entry point. All processor cores ultimately converge to a unified OS firmware initialization entry point for recovery, without the need to introduce additional external firmware or privileged software to take over the exception process, nor to modify the operating system scheduler logic. The recovery path is centralized, the logic is simple, and the implementation cost is low. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of a conventional two-level boot architecture exception recovery process according to one embodiment;

[0035] Figure 2 This is a schematic diagram of an abnormal recovery process of the secondary boot architecture of this application according to one embodiment;

[0036] Figure 3 This is a flowchart illustrating a software anomaly recovery method according to one embodiment.

[0037] Figure 4 This is a schematic flowchart of a watchdog anomaly detection method according to one embodiment;

[0038] Figure 5 This is a schematic flowchart of a main core software anomaly recovery method according to one embodiment;

[0039] Figure 6 This is an example diagram of a main core anomaly recovery process in a dual-core embedded system according to one embodiment;

[0040] Figure 7 This is an example diagram of the exception handling function in a dual-core embedded system when the main core fails, according to one embodiment.

[0041] Figure 8 This is an example diagram of the inter-core interrupt function handling process in a dual-core embedded system when the main core fails, according to one embodiment.

[0042] Figure 9 This is a schematic diagram of a method for recovering from a kernel software anomaly according to one embodiment;

[0043] Figure 10 This is an example diagram of a recovery process from a core anomaly in a dual-core embedded system according to one embodiment;

[0044] Figure 11 This is an example diagram of the exception handling function in a dual-core embedded system when a slave core fails, as one embodiment.

[0045] Figure 12 This is an example diagram illustrating the inter-core interrupt function handling process in a dual-core embedded system when a core exception occurs, according to one embodiment.

[0046] Figure 13 This is a schematic diagram of the structure of an embedded system according to one embodiment. Detailed Implementation

[0047] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments. Similar elements in different embodiments are referred to by related similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of the present application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to the present application are not shown or described in the specification. This is to avoid obscuring the core parts of the present application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0048] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the order of the steps or actions in the method description can be changed or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for clearly describing a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0049] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0050] Understandably, for embedded systems using a RISC-V SMP architecture, the system boot components typically involve multi-level firmware boot mechanisms. For a simplified explanation, please refer to [link to documentation / reference]. Figure 1 Taking a two-level boot architecture as an example: the first-level boot firmware (Bootloader1, BL1) is responsible for initializing the basic hardware and loading the second-level boot firmware (Bootloader2, BL2). The second-level boot firmware is responsible for loading the OS firmware from non-volatile storage media into memory and executing it. Figure 1 In the abnormal recovery process shown, when an abnormality occurs in the OS firmware, a system reset is triggered. The program flow starts from the primary boot firmware and restarts, passing through BL1 and BL2 in sequence, reloading and starting the OS.

[0051] In the storage architecture of embedded systems, volatile random access memory such as SRAM or DDR has the advantage of fast access speed, but data is lost after power failure; non-volatile storage media such as Flash can retain data after power failure, but the access speed is relatively slow. To balance execution efficiency and data persistence, the OS firmware is usually stored in Flash; during system startup, the bootloader copies the OS firmware from Flash to SRAM or DDR, and then the processor jumps to the initialization entry address of the OS firmware in SRAM or DDR to execute.

[0052] In embedded system designs with anomaly recovery mechanisms, a watchdog monitoring module is typically integrated. This module relies on the normally operating system to periodically feed the watchdog (i.e., refresh the timer); once an anomaly occurs in the system (such as deadlock or crash), the watchdog will time out and output a reset signal to reset the entire system, thereby achieving reinitialization (i.e., the system restarts from BL1) and restoring normal operation.

[0053] Figure 1 While the traditional anomaly recovery scheme shown is simple in mechanism and thorough in recovery, it has significant shortcomings: the entire recovery path covers the entire process from hardware initialization of BL1 to complete loading of the OS firmware in BL2, involving heavyweight recovery operations such as full system state reconstruction, peripheral reinitialization, and memory reallocation. The loading process of copying the OS firmware from Flash to SRAM or DDR is particularly time-consuming—Flash read bandwidth is much lower than SRAM, and OS firmware is typically large; the time spent loading the OS firmware accounts for a significant proportion of the total recovery latency. In real-world applications, anomaly recovery latency is often extremely sensitive (e.g., real-time control systems require millisecond or even microsecond-level recovery responses). The downtime under this traditional scheme cannot meet this strict real-time constraint, severely impacting business continuity.

[0054] However, for watchdog timer anomalies caused by software defects, the OS firmware data in SRAM or DDR is not actually lost, and the system does not need to reload the OS firmware from Flash. Based on this, this application proposes a fast software anomaly recovery scheme.

[0055] The core of this application's solution lies in the following: When a watchdog exception occurs in the system, a global reset is not triggered. Instead, the exception handling mechanism of the RISC-V architecture is utilized. Within the exception handling function, the value of the mepc (Machine ExceptionProgram Counter) register is directly modified to point to the initialization entry address of the OS firmware already loaded in SRAM or DDR. Then, instructions for returning from the exception handling function and jumping to the specified address are executed, bypassing the complete bootloader boot process. Simultaneously, inter-core interrupts and shared memory global variables are used to synchronize the exception states of multiple cores, ensuring that all cores in the SMP system consistently enter the recovery process, avoiding hardware-level problems caused by state asynchrony.

[0056] Please refer to Figure 2 The paper also uses a two-level boot architecture as an example to illustrate the abnormal recovery process of this application. In the traditional solution, after the system is reset due to an abnormality, the complete boot chain of BL1→BL2→OS needs to be executed sequentially. However, in the solution of this application, after an abnormality is triggered, the system directly jumps to the initialization entry address of the OS firmware in the abnormality handling function, which eliminates the execution process of BL1 and BL2, and in particular, eliminates the time-consuming operation of copying the OS firmware from Flash to SRAM / DDR.

[0057] Please refer to Figure 3 Some embodiments disclose a software exception recovery method 100, which is applicable to solving the problem of long recovery latency of traditional global reset schemes when a watchdog exception occurs in an embedded system using a RISC-V SMP architecture and including one master core and at least one slave core. This method can be executed collaboratively by the master core and slave core in the embedded system. Figure 3 As shown, the software anomaly recovery method 100 includes the following steps:

[0058] Step 110: In response to a watchdog exception occurring in the first processor core of the embedded system, the first processor core synchronizes its exception state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables. The first processor core is either the master core or one of the at least one slave core.

[0059] In this context, the primary core refers to the processor core in a RISC-V SMP system that is designated to perform global initialization, hardware reset management, and system-level coordination tasks.

[0060] A secondary core refers to any processor core in the system other than the main core, which is managed and coordinated by the main core.

[0061] It is understandable that, since each processor core in a multi-core system executes its own tasks in parallel, if abnormal states are not synchronized, processor cores that are unaware of the abnormality may continue to execute invalid contexts, which can lead to inconsistencies in the multi-core states and cause more serious hardware problems.

[0062] To address the aforementioned multi-core state synchronization issue, this application employs a combination of inter-core interrupts and shared-memory global variables to achieve abnormal state synchronization. Inter-core interrupts are used to immediately notify other processor cores, ensuring the real-time nature of inter-core communication. Shared-memory global variables provide reliable status indicators, allowing other processor cores to verify whether the system has truly entered an abnormal state upon receiving an inter-core interrupt by reading these variables. This prevents the misinterpretation of normal inter-core communication messages as abnormal notifications, ensuring the correctness of inter-core communication. The combination of these two methods ensures that all cores consistently enter the recovery process.

[0063] It should be noted that if only inter-core interrupts are used in this application without setting shared memory global variables, other processor cores cannot distinguish whether the inter-core interrupt is a notification of an exception or other normal inter-core communication message; if only shared memory global variables are used without sending inter-core interrupts, other processor cores cannot be informed of system abnormal states in a timely manner and can only rely on polling for detection, resulting in response delays. The combination of both can achieve inter-core state synchronization that balances real-time performance with correctness.

[0064] Step 120: Each of the slave cores executes a first instruction to put the processor core into a wait state, thereby entering a sleep state.

[0065] In one embodiment, the first instruction is the Wait For Interrupt (WFI) instruction in the RISC-V architecture. After the WFI instruction is executed, the processor core will pause execution and enter a low-power wait state until an interrupt or other wake-up event is received.

[0066] Understandably, by putting the slave kernel into a sleep state, the slave kernel can suspend the execution of an invalid context, thereby providing a safe precondition for the master kernel to reset the slave kernel later. Only by resetting the slave kernel while it is in a sleep state can timing conflicts between the reset operation and the instructions being executed by the slave kernel be avoided.

[0067] Step 130: The master core resets all the slave cores and sets the value of the master core's mepc register to the initialization entry address of the operating system firmware. The program code pointed to by the initialization entry address is located in the random access memory where the operating system firmware has been loaded.

[0068] Understandably, after responding to the master core's inter-core interrupt synchronization, the slave core executes its first instruction and enters sleep mode. In sleep mode, the slave core retains its internal state at the time of the exception. A hardware reset can completely reset all internal states of the slave core, providing a clean and definite starting point for subsequent re-initialization.

[0069] Furthermore, during SMP system failure recovery, the master core expects all slave cores to begin initialization operations from the OS firmware's initialization entry address. However, if a slave core is simply woken from sleep mode, its program counter (PC) pointer will continue execution from the first instruction instead of jumping to the OS firmware's initialization entry address. A hardware reset can be used to make the slave core's PC pointer point to a reset vector address. This reset vector allows the slave core's PC pointer to be redirected to the OS firmware's initialization entry address.

[0070] Furthermore, after resetting the slave core, the master core begins the initialization process. If the slave core is still in an executable state at this time (e.g., woken up from a hibernation state by an interrupt), it may conflict with the master core's initialization process (e.g., the slave core accesses a region that the master core is initializing after being woken up). Therefore, a hardware reset is required to completely stop the slave core from executing until the master core actively unresets it, thus ensuring the safety of the global initialization process.

[0071] When the master core resets all slave cores, it can set the value of the mepc (Machine Exception ProgramCounter) register to the initialization entry address of the OS firmware, such as the __start symbol address in the RISC-V architecture of the Zephyr system. The program code pointed to by this initialization entry address is located in the SRAM (or DDR) where the OS firmware is loaded. Since the OS firmware has been loaded into the SRAM / DDR by the bootloader before the exception occurs, and the OS firmware data in the SRAM / DDR is not lost during the exception recovery process (the watchdog timeout caused by the software exception does not involve power loss), there is no need to copy the OS firmware from Flash to the SRAM / DDR again.

[0072] Step 140: The main core executes a second instruction to return from exception handling and jump to a specified address, so as to directly jump to the initialization entry address to perform the first initialization operation.

[0073] In one embodiment, the second instruction is the mret (Machine Return) instruction in the RISC-V architecture. The mret instruction is an instruction in the RISC-V privileged architecture used to return from an exception handling function, and its execution effect includes: setting the value of the PC pointer to the value in the mepc register and restoring the previous privilege level.

[0074] The first initialization operation refers to the global initialization operation performed by the master kernel after jumping to the OS firmware initialization entry point, which is used to establish the entire operating system runtime environment. This process covers the initial establishment of all hardware and software resources shared by all slave kernels and is also the basis for subsequent second initialization operations performed by slave kernels. Specifically, it may include: the readiness of the memory subsystem, the establishment of kernel data structures, the configuration of the interrupt system, and the preparation of slave kernel boot conditions, etc.

[0075] In step 140, the main core is not restarted via a hardware reset signal, but rather by modifying the program execution entry point in software, restarting execution from the OS firmware initialization entry point. Compared to the traditional global reset scheme, this process completely bypasses the hardware initialization and security verification steps of BL1 and the OS firmware loading steps of BL2. The abnormal recovery path is shortened from the traditional complete "BL1→BL2→OS" chain to a direct jump from "abnormal handling function → OS firmware initialization entry point", thus significantly reducing recovery latency.

[0076] Step 150: During the execution of the first initialization operation, the master core resets all the slave cores.

[0077] It is understandable that the master core will de-reset the slave core during the initialization process. This is because the initialization process of the SMP system follows a hierarchical logic of "master core boots first, slave core starts under control", and the master core needs to complete some initialization preparation work before starting the slave core.

[0078] After completing the necessary initialization operations, the master core releases the reset signal of the slave core through a de-reset operation. In response to being de-reset, the slave core begins fetching instructions from the reset vector. If the de-reset step is omitted, the slave core will remain in the reset state indefinitely and cannot participate in exception recovery.

[0079] Step 160: In response to being de-reset, each of the slave kernels performs a second initialization operation from the initialization entry address.

[0080] The second initialization operation refers to a series of local initialization operations executed by each slave core after reset, starting from the initialization entry address of the operating system firmware. Its core characteristic is that it only involves the private resources of that slave core itself, without repeating the one-time global resource initialization already completed by the master core. The goal of the second initialization operation is to enable each slave core to independently participate in operating system scheduling and task execution, and ultimately synchronize with the master core to enter a normal operating state.

[0081] Understandably, in response to being de-reset, the slave kernel executes a second initialization operation starting from the OS firmware's initialization entry address. After both the master and slave kernels complete their own initialization, the system returns to normal operation.

[0082] According to the software exception recovery method of the above embodiments, firstly, when a watchdog exception occurs in the first processor core representing any processor core (master core or slave core), the first processor core synchronizes the exception state to all other processor cores in the system through inter-core interrupts and shared memory global variables. Inter-core interrupts can immediately notify other cores, ensuring real-time communication; shared memory global variables provide reliable status indicators, enabling other cores to confirm that the system has entered an exception state, avoiding misinterpreting inter-core communication messages as exception notifications. The combination of these two ensures that all cores consistently enter the recovery process synchronously, improving the reliability of multi-core exception state synchronization. Secondly, after each slave core executes its first instruction to enter a sleep state, the master core performs a reset operation on all slave cores. This sleep-then-reset approach ensures that slave cores are reset in a controlled, static state, avoiding timing conflicts or state inconsistencies that may occur when resetting while slave cores are still executing instructions or in an uncontrollable state, thus ensuring the safety and determinism of the reset process. Subsequently, the main core directly sets the value of the mepc register to the initialization entry address of the operating system firmware within the exception handling function, and jumps to this entry point to perform the first initialization operation by executing the second instruction. Since the program code pointed to by this initialization entry address is located in the random access memory already loaded with the OS firmware, and the watchdog exception does not cause data loss in volatile memory, the main core does not need to reload the OS firmware from Flash, nor does it need to re-execute the traditional multi-level firmware boot process. The exception recovery path is shortened from the traditional complete chain to a direct jump from the exception handling function to the OS firmware initialization entry point, significantly reducing recovery latency. Finally, during the execution of the first initialization operation, the main core de-resets all slave cores. After de-resetting, the slave cores begin executing the second initialization operation from the same initialization entry point. All processor cores ultimately converge to a unified OS firmware initialization entry point for recovery, without the need to introduce additional external firmware or privileged software to take over the exception process, nor to modify the operating system scheduler logic. The recovery path is centralized, the logic is simple, and the implementation cost is low.

[0083] Furthermore, based on the above embodiments, before the master core resets all the slave cores, the method further includes:

[0084] The master core polls the bits in the sleep state register corresponding to each slave core to determine whether each slave core has entered the sleep state;

[0085] Accordingly, the master core resets all the slave cores, including: for each slave core, the master core resets each slave core after confirming that each slave core has entered a sleep state.

[0086] The sleep state register is used to indicate whether the slave core has entered sleep state after executing the first instruction.

[0087] In one embodiment, the hibernation status register is the wfi_status register, which is used to indicate whether the slave core has entered hibernation state after executing the WFI instruction.

[0088] Understandably, by confirming that the slave kernel has entered a hibernation state before resetting it, potential timing conflicts that might occur if the slave kernel were reset before it had paused its current task are avoided, thus ensuring the safety of the reset operation. Simultaneously, the reset operation puts the slave kernel in a reset state, preventing it from being accidentally woken up during system anomaly recovery and ensuring the determinism of the system anomaly recovery process.

[0089] Furthermore, based on the above embodiments, the master core resets all the slave cores and de-resets all the slave cores, respectively, by writing the reset / de-reset control register corresponding to each slave core.

[0090] In one embodiment, each slave core is configured with a dedicated reset / de-reset control register. The reset / de-reset control register is used to receive a reset signal written by the master core to put the corresponding slave core into a reset state, and to release the corresponding slave core from the reset state after receiving a de-reset signal from the master core.

[0091] Furthermore, based on the above embodiments, regarding the execution methods of reset and de-reset, the master core can reset each slave core individually or in parallel, and de-reset each slave core individually or in parallel. In embodiments containing multiple slave cores, the master core can reset each slave core individually (i.e., reset each slave core after confirming that it has entered a sleep state), or it can reset all slave cores in parallel after confirming that all slave cores have entered a sleep state. Similarly, the de-reset operation can also be executed individually or in parallel, depending on the system design requirements.

[0092] Furthermore, before responding to a watchdog exception occurring in the first processor core of the embedded system, the watchdog exception needs to be identified. Please refer to [reference needed]. Figure 4Some embodiments disclose a watchdog anomaly detection method 200, which can be executed by any processor core in an embedded system. For example... Figure 4 As shown, the watchdog anomaly detection method 200 includes the following steps:

[0093] Step 210: In response to the triggering of the exception / interrupt function of the first processor core, read the value of the mcause register of the first processor core, wherein the exception / interrupt function is an exception handling function or an inter-core interrupt function.

[0094] In the RISC-V architecture, when an exception or interrupt occurs, each processor core automatically records the cause of the exception in the mcause (Machine Cause) register. Since the exception handling function and the inter-core interrupt handling function in the RISC-V SMP system share the same entry point, when an exception / interrupt function is triggered, it is necessary to further determine whether the trigger is an exception or an interrupt.

[0095] Step 220: Determine whether bit 63 of the mcause register is 0.

[0096] In one embodiment, bit 63 of the mcause register is an interrupt / exception indicator bit. A value of 1 indicates an interrupt, and a value of 0 indicates an exception. By checking whether bit 63 is 0, it is possible to distinguish whether the current interrupt is triggered by an exception handler or an inter-core interrupt handler, thereby avoiding misclassifying normal peripheral interrupts as exceptions.

[0097] Step 230: When bit 63 is 0, confirm that the exception / interrupt function is the exception handling function, and determine whether the value of the EXCCODE field of the mcause register is 0xFFF.

[0098] In one embodiment, the EXCCODE field is bits [11:0] of the mcause register, used to encode the specific exception type. When bit 63 is 0, it is confirmed that the exception handling function has been triggered. At this time, it is necessary to further determine the specific type of the exception to determine whether it is a watchdog exception.

[0099] Step 240: When the value of the EXCCODE field is 0xFFF, it is confirmed that the first processor core has experienced a watchdog exception.

[0100] When the value of the EXCCODE field is 0xFFF, it indicates that the exception is a watchdog exception, meaning that a watchdog timeout has occurred. Through the multi-layered judgment logic of the mcause register, watchdog exceptions can be accurately identified, eliminating interference from other types of exceptions and normal interrupts.

[0101] Furthermore, based on the above embodiments, the response to a watchdog exception occurring in the first processor core further includes:

[0102] The value of the hardware thread identifier register of the first processor core is read to determine whether the first processor core is the master core or one of the at least one slave core.

[0103] The hardware thread identifier register is a register used to store the hardware ID identifier of the current processor core.

[0104] Understandably, in RISC-V SMP systems, the system initialization process follows a hierarchical logic of "booting first and secondary cores being controlled to start". This application further designs a differentiated recovery path based on core role awareness for the fast recovery process. By introducing hardware ID identification logic in the exception handling function, the consistency and stability of the overall system recovery sequence can be ensured.

[0105] In one embodiment, the hardware thread identifier register is the mhartid register in the RISC-V architecture. After confirming that a watchdog exception has occurred on the first processor core, the identity of the first processor core is determined by reading the value of the mhartid register, thereby determining the differentiated recovery path to be executed subsequently. For example, in a dual-core system, if the value of mhartid is 0, the first processor core is confirmed as the master core; if the value of mhartid is 1, the first processor core is confirmed as slave core 1. This core role determination provides a basis for determining the differentiated recovery path based on core role awareness.

[0106] Please refer to Figure 5 Some embodiments disclose a method for recovering from a master core software exception. This method is applicable to solving the problem of long recovery latency in traditional global reset schemes when a watchdog exception occurs in an embedded system using a RISC-V SMP architecture and including one master core and at least one slave core. This method can be executed collaboratively by the master core and slave cores in the embedded system. This embodiment... Figure 3Based on the illustrated embodiment, the first processor core synchronizes its abnormal state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables. Specifically, the first processor core sets the value of the shared memory global variable to a value indicating that an abnormality has occurred in the embedded system, and sends an inter-core interrupt to the other processor cores by writing the software interrupt pending bit corresponding to each of the other processor cores in the MSIP register resource, so that the other processor cores can read the shared memory global variable. The execution of the first instruction by each slave core is specified as follows: after receiving the inter-core interrupt, each slave core reads the shared memory global variable, and after confirming that the shared memory global variable indicates that an abnormality has occurred in the embedded system, executes the first instruction. Figure 5 As shown, the main core software anomaly recovery method 300 includes the following steps:

[0107] Step 310: In response to a watchdog exception occurring in the first processor core of the embedded system, the first processor core sets the value of the shared memory global variable to a value indicating that an exception has occurred in the embedded system, and sends an inter-core interrupt to the other processor cores by writing the software interrupt pending bit in the MSIP register resource corresponding to the other processor cores, so that the other processor cores can read the shared memory global variable; the first processor is the master core.

[0108] Understandably, when an exception occurs in the main core's program, the watchdog timeout triggers the main core's exception handling function. After confirming that a watchdog exception has occurred, the main core needs to synchronize the exception status to the other processor cores in the system (i.e., slave cores) to ensure that all processor cores enter the exception recovery process.

[0109] The MSIP (Machine Software Interrupt Pending) register is the machine software interrupt pending register in the RISC-V privileged architecture. Writing a bit in the MSIP register sends a software interrupt (i.e., an inter-core interrupt) to the corresponding processor core.

[0110] For example, when a watchdog exception occurs on the master core (core0), the master core (core0) sets the value of the shared memory global variable g_ex_flag to 1, indicating that an exception has occurred in the system. At the same time, the master core (core0) sends an inter-core interrupt to each slave core by writing the software interrupt pending bits (bit1, bit2, ..., bitN) in the MSIP register corresponding to slave cores (core1, core2, ..., coreN), so that each slave core can read the value of g_ex_flag.

[0111] Step 320: After receiving the inter-core interrupt, each slave core reads the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, executes the first instruction to enter a sleep state.

[0112] For example, after receiving the inter-core interrupt sent by the master core core0, each slave core enters the inter-core interrupt handling function. First, it reads the value of the shared memory global variable g_ex_flag to confirm whether it is 1. When it is confirmed that g_ex_flag is 1, it means that the system has entered an abnormal state, and each slave core executes the WFI instruction to enter a sleep state.

[0113] Step 330: The master core polls the bits in the sleep state register corresponding to each slave core to confirm whether each slave core has entered the sleep state.

[0114] For example, after each slave core executes the WFI instruction and enters a sleep state, the bits corresponding to each slave core in the wfi_status register, bit1, bit2, ..., bitN, will be set to 1. The master core, core0, determines whether each slave core has entered the sleep state by polling the bits corresponding to each slave core in the wfi_status register to see if they are 1.

[0115] Step 340: For each slave core, after confirming that each slave core has entered a hibernation state, the master core resets each slave core and sets the value of the master core's mepc register to the initialization entry address of the operating system firmware. The program code pointed to by the initialization entry address is located in the random access memory where the operating system firmware has been loaded.

[0116] For example, after confirming that each slave core has entered sleep mode, the master core (core0) writes to the reset / de-reset control register corresponding to each slave core (e.g., the reset / de-reset control register for slave core 1 is the soc_misc_core1_rst register), resetting each slave core. Simultaneously or subsequently, the master core (core0) sets the value of the mepc register to the initialization entry address of the OS firmware, for example, to the __start symbol address under the RISC-V architecture in the Zephyr system.

[0117] In one embodiment, after resetting the slave core, the master core clears the shared memory global variable g_ex_flag to zero in order to clear the system error flag and avoid misjudgment during subsequent normal communication.

[0118] Step 350: The main core executes a second instruction to return from exception handling and jump to a specified address, so as to directly jump to the initialization entry address to perform the first initialization operation.

[0119] Step 360: During the execution of the first initialization operation, the master core resets all the slave cores.

[0120] Step 370: In response to being de-reset, each of the slave kernels performs a second initialization operation from the initialization entry address.

[0121] For example, let's take a main core exception in a dual-core embedded system (including main core 0 and slave core 1) as an example: Figure 6 An example of an exception recovery process when the main core (core0) fails is given. Figure 7 An example of the exception handling function's processing flow when the main core (core0) encounters an exception is given. Figure 8 An example of the inter-core interrupt handling process when the main core (core0) experiences an exception is given. The specific process of exception recovery is as follows:

[0122] 1) When an exception occurs in the main core 0 program, the exception handling function of the main core 0 is triggered. In the exception handling function of the main core 0, the RISC-V mcause register is read and it is determined whether bit 63 is 0. This confirms that the exception is an exception and not another normal peripheral interrupt. Then, the EXCCODE field bit[11:0] of the mcause register is 0xFFF (watchdog exception). After confirming that it is a watchdog exception, the fast exception recovery process is entered.

[0123] 2) The master core 0 first writes the shared memory global variable g_ex_flag=1 to indicate that the system has encountered an error and needs to be recovered. At the same time, it writes bit 1 of the MSIP register of RISC-V to send an interrupt information to the slave core 1, notifying the slave core 1 that the system has encountered an error.

[0124] 3) When core1 receives an inter-core interrupt from core0, it first checks whether the g_ex_flag variable is 1 to confirm that the system has entered an abnormal state, so as to avoid affecting other normal inter-core communication messages. After core1 confirms that the system has entered an abnormal state, it executes the WFI instruction to enter a sleep state.

[0125] 4) After the master core 0 notifies the slave core 1 via an interrupt in the exception handling function, it continuously polls the wfi_status register to check if bit 1 is 1, confirms the status of core 1, and ensures that the slave core 1 has entered the sleep state.

[0126] 5) After the master core (core0) reads that bit 1 of the wfi_status register is 1, and confirms that the slave core (core1) has entered sleep mode, it writes to the soc_misc_core1_rst register implemented by the chip's SOC to reset the slave core (core1), putting it in a reset state to prevent it from being accidentally woken up during abnormal recovery. At the same time, it writes g_ex_flag=0 to clear the system abnormal flag.

[0127] 6) The main core (core0) writes the RISC-V mepc register value to point to the SRAM address where the Zephyr system firmware is initialized, such as the __start symbol address of the RISC-V architecture in the Zephyr system. It then executes the mret instruction and jumps to the SRAM at the initialization location to run.

[0128] 7) During program initialization, the master core 0 writes to the soc_misc_core1_rst register to reset the slave core 1.

[0129] 8) After the slave core 1 is de-reset, the master core 0 and slave core 1 each complete their own initialization and enter normal operation.

[0130] Please refer to Figure 9 Some embodiments disclose a method for recovering from a kernel software exception. This method is applicable to solving the problem of long recovery latency in traditional global reset schemes when a watchdog exception occurs in a slave core in an embedded system employing a RISC-V SMP architecture and including one master core and at least one slave core. This embodiment... Figure 3 Based on the illustrated embodiment, this method can be executed collaboratively by the master core and slave cores in an embedded system. Specifically, the execution of the first instruction by each slave core is as follows: the first processor core executes the first instruction after sending the inter-core interrupt to the other processor cores; the slave cores among the other processor cores, upon receiving the inter-core interrupt, read the shared memory global variable, and, after confirming that the shared memory global variable indicates an exception has occurred in the embedded system, execute the first instruction. Figure 9 As shown, the method 400 for recovering from a kernel software anomaly includes the following steps:

[0131] Step 410: In response to a watchdog exception occurring in the first processor core of the embedded system, the first processor core sets the value of the shared memory global variable to a value indicating that an exception has occurred in the embedded system, and sends an inter-core interrupt to the other processor cores by writing the software interrupt pending bit in the MSIP register resource corresponding to the other processor cores, so that the other processor cores can read the shared memory global variable; the first processor is one of the at least one slave core.

[0132] Understandably, when an exception occurs in the slave core's program, the watchdog timeout triggers the slave core's exception handling function. After confirming that a watchdog exception has occurred, the slave core also needs to synchronize the exception status to other processor cores in the system (i.e., the master core and other slave cores) to ensure that all processor cores enter the exception recovery process.

[0133] For example, when core1 confirms that a watchdog exception has occurred, it sets the shared memory global variable g_ex_flag to 1, indicating that an exception has occurred in the system. At the same time, core1 writes the software interrupt pending bits bit0, bit2, bit3, ..., bitN corresponding to the master core0 and other slave cores in the MSIP register, and sends an inter-core interrupt to the master core0 and other slave cores to notify the master core0 and other slave cores that an exception has occurred in the system.

[0134] Step 420: After sending the inter-core interrupt to the other processor cores, the first processor core executes the first instruction; after receiving the inter-core interrupt, the slave cores among the other processor cores read the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, they execute the first instruction.

[0135] Understandably, unlike the main core failure scenario, the slave core that experiences the failure also needs to enter a hibernation state.

[0136] For example, after slave core 1 sends an inter-core interrupt to master core 0 and all other slave cores, it directly executes the WFI instruction to enter a sleep state, and its corresponding wfi_status register bit is set to 1. When the system contains multiple slave cores, the inter-core interrupt sent by the abnormal slave core 1 can also be received by the other slave cores. After the other slave cores read the g_ex_flag variable in their inter-core interrupt handlers to confirm that the system has entered an abnormal state, they also execute the WFI instruction to enter a sleep state.

[0137] Step 430: The master core polls the bits in the sleep state register corresponding to each slave core to confirm whether each slave core has entered the sleep state.

[0138] Step 440: For each slave core, after confirming that each slave core has entered a hibernation state, the master core resets each slave core and sets the value of the master core's mepc register to the initialization entry address of the operating system firmware. The program code pointed to by the initialization entry address is located in the random access memory where the operating system firmware has been loaded.

[0139] Step 450: The main core executes a second instruction to return from exception handling and jump to a specified address, so as to directly jump to the initialization entry address to perform the first initialization operation.

[0140] Step 460: During the execution of the first initialization operation, the master core resets all the slave cores.

[0141] Step 470: In response to being de-reset, each of the slave kernels performs a second initialization operation from the initialization entry address.

[0142] For example, let's take a slave core exception in a dual-core embedded system (including master core 0 and slave core 1) as an example: Figure 10 An example of an exception recovery process when core1 fails is given. Figure 11 An example of the exception handling function's processing flow when a core1 exception occurs is given. Figure 12 An example of the inter-core interrupt handling process when a core1 core exception occurs is given. The specific process of exception recovery is as follows:

[0143] 1) When an exception occurs in the core1 program, the exception handling function of core1 is triggered. In the exception handling function of core1, the mcause register of RISC-V is read and it is determined whether bit 63 is 0. This confirms that the exception is an exception and not another normal peripheral interrupt. Then, the EXCCODE field bit[11:0] of the mcause register is checked to see if it is 0xFFF (watchdog exception). After confirming that it is a watchdog exception, the fast exception recovery process is entered.

[0144] 2) Core1 first writes the shared memory global variable g_ex_flag=1 to indicate that the system has encountered an error and needs to be recovered. At the same time, it writes bit 0 of the RISC-V MSIP register and sends an interrupt message to Core0 to notify the main Core0 that the system has encountered an error.

[0145] 3) Execute the WFI instruction from core1 to enter sleep mode.

[0146] 4) After an inter-core interrupt is issued from core1, the master core0, in its inter-core interrupt handler, first checks whether the global variable g_ex_flag is 1 to ensure that it is an exception notification. Then, it polls bit1 of the wfi_status register to confirm the status of slave core1 and ensures that slave core1 enters a sleep state.

[0147] 5) After confirming that slave core1 has entered sleep mode, master core0 writes to the soc_misc_core1_rst register to reset slave core1. At the same time, it writes g_ex_flag=0 to clear the system exception flag.

[0148] 6) Write the RISC-V mepc register value to the SRAM address where the OS firmware is initialized, such as the __start symbol address of the RISC-V architecture in the Zephyr system. Execute the mret instruction to jump to the SRAM at the initialization location for execution.

[0149] 7) During the initialization process, the master core0 writes to the soc_misc_core1_rst register to de-reset the slave core1.

[0150] 8) After the slave core1 is de-reset, the master core0 and slave core1 each complete their initialization and enter normal operation.

[0151] Please refer to Figure 13 Some embodiments disclose an embedded system 500 that employs a RISC-V symmetric multiprocessing architecture. This system is suitable for executing the software exception recovery method described in any of the above embodiments of this application when a watchdog exception occurs in any processor core, in order to quickly restore normal system operation. Figure 13 As shown, the embedded system 500 includes a main core 510 and at least one slave core 520.

[0152] In some embodiments, the embedded system 500 further includes: shared memory for storing shared memory global variables (e.g., g_ex_flag) for read and write access by the master core 510 and slave core 520; a watchdog module for monitoring the operating status of each processor core and triggering a watchdog exception when any processor core times out abnormally; a SOC control module including a sleep state register and a reset / de-reset control register corresponding to each slave core 520, for monitoring the sleep state of each slave core 520 and controlling the reset and de-reset of each slave core 520, respectively; and a storage module including non-volatile memory (e.g., Flash) for storing OS firmware and volatile random access memory (e.g., SRAM or DDR) for loading and executing OS firmware.

[0153] In the above embodiments, implementation can be achieved, in whole or in part, by software, hardware, firmware, or any combination thereof. Furthermore, as those skilled in the art will understand, the principles herein can be reflected in a computer program product on a computer-readable storage medium pre-loaded with computer-readable program code. Any tangible, non-transitory computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CDs, DVDs, Blu-ray discs, etc.), flash memory, and / or the like. These computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine, such that instructions executing on the computer or other programmable data processing apparatus can generate means for performing a specified function. These computer program instructions can also be stored in a computer-readable storage medium that can instruct the computer or other programmable data processing apparatus to operate in a particular manner, such that instructions stored in the computer-readable storage medium can form an article of manufacture, including means for implementing the specified function. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to perform a series of operational steps on the computer or other programmable apparatus to produce a computer-implemented process, such that instructions executing on the computer or other programmable apparatus can provide steps for implementing the specified function.

[0154] This document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components for performing operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0155] While the principles herein have been illustrated in various embodiments, numerous modifications to the structures, arrangements, proportions, elements, materials, and components, particularly suited to specific environments and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document. Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the fundamental principles of this application.

Claims

1. A software anomaly recovery method, characterized in that, The method, applied to an embedded system employing a RISC-V symmetric multiprocessing architecture, wherein the embedded system includes a master core and at least one slave core, comprises: In response to a watchdog exception occurring in the first processor core of the embedded system, the first processor core synchronizes its exception state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables. The first processor core is either the master core or one of the at least one slave core. Each of the slave cores executes a first instruction to put the processor core into a wait state, thereby entering a sleep state; The master core resets all the slave cores and sets the value of the master core's mepc register to the initialization entry address of the operating system firmware. The program code pointed to by the initialization entry address is located in the random access memory where the operating system firmware has been loaded. The main core executes a second instruction to return from exception handling and jump to a specified address, so as to directly jump to the initialization entry address to perform the first initialization operation; During the execution of the first initialization operation, the master core resets all the slave cores. In response to being de-reset, each of the slave kernels performs a second initialization operation from the initialization entry address.

2. The method according to claim 1, characterized in that, The first processor core synchronizes its abnormal state to the other processor cores in the embedded system based on inter-core interrupts and shared memory global variables, including: The first processor core sets the value of the shared memory global variable to a value indicating that an exception has occurred in the embedded system, and sends an inter-core interrupt to the other processor cores by writing the software interrupt pending bit in the MSIP register resource corresponding to the other processor cores, so that the other processor cores can read the shared memory global variable.

3. The method according to claim 2, characterized in that, When the first processor core is the master core, each of the slave cores executes the first instruction including: After receiving the inter-core interrupt, each slave core reads the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, executes the first instruction.

4. The method according to claim 2, characterized in that, When the first processor core is one of the at least one slave core, each slave core executes the first instruction including: The first processor core executes the first instruction after sending the inter-core interrupt to the other processor cores; Upon receiving the inter-core interrupt, the slave cores in each of the other processor cores read the shared memory global variable, and after confirming that the shared memory global variable indicates that the embedded system has encountered an anomaly, execute the first instruction.

5. The method according to claim 1, characterized in that, Also includes: In response to the triggering of the exception / interrupt function of the first processor core, the value of the mcause register of the first processor core is read, wherein the exception / interrupt function is an exception handling function or an inter-core interrupt function; Determine whether bit 63 of the mcause register is 0; When bit63 is 0, confirm that the exception / interrupt function is the exception handling function, and determine whether the value of the EXCCODE field of the mcause register is 0xFFF; When the value of the EXCCODE field is 0xFFF, it is confirmed that a watchdog exception has occurred in the first processor core.

6. The method according to claim 1 or 5, characterized in that, The response to a watchdog exception occurring in the first processor core further includes: The value of the hardware thread identifier register of the first processor core is read to determine whether the first processor core is the master core or one of the at least one slave core.

7. The method according to claim 1, characterized in that, Before the master core resets all the slave cores, the following is also included: The master core polls the bits in the sleep state register corresponding to each slave core to determine whether each slave core has entered the sleep state; Accordingly, the master core resets all the slave cores, including: for each slave core, the master core resets each slave core after confirming that each slave core has entered a sleep state.

8. The method according to claim 1, characterized in that, The master core resets all the slave cores and de-resets all the slave cores, respectively, by writing to the reset / de-reset control register corresponding to each slave core.

9. The method according to claim 1, characterized in that, The master core resets each of the slave cores one by one or in parallel, and de-resets each of the slave cores one by one or in parallel.

10. An embedded system, characterized in that, The embedded system employs a RISC-V symmetric multiprocessing architecture, including a master core and at least one slave core, and is configured to execute the software exception recovery method as described in any one of claims 1 to 9 when a watchdog exception occurs in any processor core.

Images