A fault processing method, vehicle operating system and electronic device

CN122884725APending Publication Date: 2026-10-09DISHUI ZHIXING TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610841887.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-11
Publication Date
2026-10-09

AI Technical Summary

Technical Problem

[0006]本申请实施例的目的是提供一种故障处理方法、车辆操作系统及电子设备,能够解决现有技术中某些处理芯片内部的存储介质发生硬件级故障时,可能会导致系统无法启动的问题

Benefits of technology

[0008]由此可知,在本申请的实施例中,能够在第一处理芯片的第一存储介质发生硬件级故障的情况下,确认第一处理芯片发生MAE异常,并重启第一处理芯片,记录第一处理芯片连续由于MAE异常导致重启的第一次数;从而可以在第一次数的数值达到第一阈值的情况下,屏蔽对第一存储介质的Dataflash操作,并启动第一处理芯片的第一模块,其中,第一模块包括第一处理芯片中不依赖所述第一存储介质的基础功能模块。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122884725A_ABST
    Figure CN122884725A_ABST
Patent Text Reader

Abstract

The application discloses a fault processing method, a vehicle operating system and electronic equipment. The method is applied to the vehicle operating system, and the vehicle operating system comprises a first processing chip. The method comprises the following steps: in the case that a hardware-level fault occurs in a first storage medium of the first processing chip, it is confirmed that the first processing chip has a machine check abort (MAE) exception, and the first processing chip is restarted; a first number of times that the first processing chip is continuously restarted due to the MAE exception is recorded; in the case that the value of the first number of times reaches a first threshold value, a non-volatile data flash (Dataflash) operation on the first storage medium is shielded, and a first module of the first processing chip is started, and the first module comprises a basic function module in the first processing chip which does not depend on the first storage medium. Therefore, the embodiment of the application can solve the problem that the system cannot be started when a hardware-level fault occurs in the storage medium in some processing chips in the prior art.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of intelligent vehicle operating system technology, specifically relating to a fault handling method, a vehicle operating system, and electronic equipment. Background Technology

[0002] Processing chips play a crucial role in some communication systems. For example, in an in-vehicle intelligent cockpit system, the microcontroller unit (MCU) is responsible for the underlying control tasks. The MCU's flash memory is divided into two areas: code flash and non-volatile data flash.

[0003] During long-term use, DataFlash may experience hardware-level failures. In this case, during the ReadAll phase of system power-on, reading DataFlash using Fls_MainFunction will result in a Machine check Abort Exception (MAE). ReadAll represents the batch read operation of the module responsible for managing non-volatile data read and write (i.e., the Non-Volatile Memory (NVM) module); Fls_MainFunction represents the main function of the Flash driver module (Fls).

[0004] MAE (Maximum Error) is the most serious type of hardware exception in a chip. Once it occurs, the MCU will enter the exception handling process. Because hardware failures in DataFlash are persistent, a MAE will occur at the same location every time ReadAll is powered on, leading to the following vicious cycle: MCU power on → ReadAll reads DataFlash → MAE exception occurs → Watchdog reset → MCU restarts → ReadAll again → MAE again → Reset again...

[0005] Therefore, it can be seen that in the existing technology, when a hardware-level failure occurs in the storage medium inside certain processing chips, it may cause the system to fail to boot. Summary of the Invention

[0006] The purpose of this application is to provide a fault handling method, a vehicle operating system, and an electronic device that can solve the problem that a hardware-level fault in the storage medium inside certain processing chips may cause the system to fail to start.

[0007] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a fault handling method applied to a vehicle operating system, the vehicle operating system including a first processing chip; the method includes: In the event of a hardware-level failure in the first storage medium of the first processing chip, confirm that the first processing chip has experienced a Machine Check (MAE) interruption abnormality, and restart the first processing chip. Record the first number of times the first processing chip restarts due to MAE anomaly. When the value of the first number of times reaches the first threshold, operations on the non-volatile data flash memory of the first storage medium are blocked, and the first module of the first processing chip is started, wherein the first module includes basic functional modules of the first processing chip that do not depend on the first storage medium.

[0008] Therefore, in the embodiments of this application, when a hardware-level fault occurs in the first storage medium of the first processing chip, it can be confirmed that the first processing chip has experienced a MAE anomaly and restart the first processing chip, and record the first number of consecutive restarts caused by the MAE anomaly; thus, when the value of the first count reaches a first threshold, the Dataflash operation on the first storage medium can be blocked and the first module of the first processing chip can be started, wherein the first module includes basic functional modules in the first processing chip that do not depend on the first storage medium.

[0009] As can be seen, in this embodiment, by recording the first number of consecutive restarts caused by the first processing chip due to MAE anomalies, the Dataflash operation on the first storage medium is skipped when the value of the first number reaches a first threshold. Thus, after the first number reaches the first threshold, access to the first storage medium, which has already experienced a hardware-level failure, is no longer attempted. This avoids repeated MAE anomalies caused by reading the first storage medium every time power is powered on, allowing the first processing chip to bypass the faulty area and start normally, while at least ensuring the availability of the aforementioned first module. Therefore, the embodiments of this application break the infinite restart loop caused by MAE anomalies, enabling the first processing chip to achieve degraded startup (i.e., only starting the basic functional modules of the first processing chip that do not depend on the first storage medium), solving the technical problem that the system cannot start completely due to hardware-level failures of the first storage medium in the first processing chip.

[0010] Secondly, embodiments of this application provide a vehicle operating system, the vehicle operating system including a first processing chip; the first processing chip including a first storage medium and a first module; the first module including basic functional modules in the first processing chip that do not depend on the first storage medium; The first processing chip is used for: In the event of a hardware-level failure in the first storage medium, confirm that the first processing chip has experienced a Machine Check (MAE) interruption abnormality, and restart the first processing chip. Record the first number of times the first processing chip restarts due to MAE anomaly. When the value of the first number of times reaches the first threshold, operations on the non-volatile data flash memory of the first storage medium are blocked, and the first module of the first processing chip is started.

[0011] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0012] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the application embodiments, the drawings used in the description of the application embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating a fault handling method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the vehicle operating system architecture in a specific embodiment provided in this application; Figure 3 This is a flowchart illustrating the fault handling method in a specific embodiment provided in this application; Figure 4 This is a structural block diagram of the vehicle operating system provided in the embodiments of this application; Figure 5 A structural block diagram of the electronic device provided in the application embodiment. Detailed Implementation

[0015] In the application embodiments, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0016] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] In a first aspect, embodiments of this application provide a fault handling method that can be applied to a vehicle operating system, the vehicle operating system including a first processing chip, the first processing chip including a first storage medium.

[0019] In some embodiments, the first processing chip may be an MCU, wherein the MCU may include one of the following: an MCU in industrial equipment, an MCU in an Internet of Things device, an in-vehicle MCU, an MCU in a body controller, or an ECU in a domain controller.

[0020] In some embodiments, the first storage medium may be one of the following: DataFlash, electrically erasable programmable read-only memory (EEPROM), or serial peripheral interface flash (SPI Flash).

[0021] like Figure 1 As shown, the method includes the following steps 101 to 103: Step 101: In the event of a hardware-level failure in the first storage medium of the first processing chip, confirm that the first processing chip has experienced a Machine Check Abrupt (MAE) exception, and restart the first processing chip.

[0022] The hardware-level faults may include at least one of the following: storage unit aging, uncorrectable error correction code (ECC) errors, and internal abnormalities of the flash controller.

[0023] In addition, MAE (Master of Equipment) exceptions are the most serious type of hardware exceptions in the processing chip. MAE exceptions occur when an unrecoverable hardware failure is detected.

[0024] Step 102: Record the first number of times the first processing chip restarts due to MAE anomaly.

[0025] In this embodiment, when the first processing chip experiences a MAE (Multi-Level Error) due to a hardware-level fault in the first storage medium and restarts, the MAE will repeatedly occur during the restart process due to reading the first storage medium. In this embodiment, the first number of consecutive restarts caused by the first processing chip due to the MAE can be recorded to determine whether the value of the first count reaches a first threshold.

[0026] For example, when the first processing chip is an MCU and the first storage medium is a DataFlash, a hardware-level fault will occur in the DataFlash, causing the MCU to experience a MAE (Motion Execution) error, which will then wait for the watchdog timer to reset and restart the MCU. In this embodiment, after the MCU restarts due to the MAE error, the number of times the MCU restarts due to the MAE error is recorded to determine whether the number of restarts reaches the first threshold.

[0027] It should be noted that a watchdog timer is a hardware timer that automatically triggers a system reset when the MCU software malfunctions.

[0028] Step 103: When the value of the first number of times reaches the first threshold, disable the operation of the non-volatile data flash memory of the first storage medium and start the first module of the first processing chip.

[0029] If the value of the first count reaches the first threshold, it can indicate that the first storage medium has a persistent failure. In this case, the Dataflash operation on the first storage medium can be blocked (in this embodiment, blocking can be understood as skipping) to avoid repeated MAE exceptions caused by performing Dataflash operations on the first storage medium, thereby breaking out of the infinite restart loop caused by the MAE exception.

[0030] For example, when the first processing chip is an MCU and the first storage medium is DataFlash, the shielding of operations on the first storage medium may include at least one of the following: The ReadAll operation for Non-Volatile Memory (NvM) can be disabled. For example, when the value of the first number reaches the first threshold, a first flag (also called a mask flag) can be set. This allows the ReadAll call in BswM_Callout_Stubs.c to check the first flag. If the first flag is set, NvM_ReadAll_CallOut is skipped, and the NVM data uses the default value. It should be noted that the ReadAll operation refers to the batch read operation of the NvM module, that is, reading all NVM data blocks from DataFlash into RAM at once during system power-on initialization. BswM_Callout_Stubs.c represents a user-defined stub file provided by the Basic Software Mode Manager (BswM) module in the AUTOmotive Open System Architecture (AUTOSAR) Basic Software (BSW). NvM_ReadAll_CallOut represents a callback function (CallOut) that the NvM module allows users to insert during the ReadAll operation. By disabling the NvM read and write interfaces, a disabling check can be added to the common NvM call interface. Read operations return default values, and write operations are discarded directly, ensuring that the application layer code will not crash due to NvM interface failure. By shielding the main function (Fls_MainFunction) of the flash drive module in the operating system (OS) scheduling, Fls_MainFunction can be wrapped (Fls_MainFunction_Wrapper). In the wrapper function, the first flag is checked. If the first flag is set, the function returns directly to avoid the MAE exception from occurring again during OS periodic scheduling.

[0031] The Flash Driver (Fls) operation in the upgrade module can be disabled. This means that a blocking judgment can be added to the Fls erase / write / read interface in the upgrade module to reject the upgrade request when the Flash is unavailable.

[0032] Furthermore, the first module includes: a basic functional module in the first processing chip that does not depend on the first storage medium. Therefore, when the value of the first number of attempts reaches a first threshold, the first module is activated, that is, only the basic functional modules in the first processing chip that do not depend on the first storage medium are activated. This allows the first processing chip to bypass the fault area and start normally, while at least ensuring the availability of the aforementioned first module. Therefore, activating the first module can be understood as a downgraded startup of the first processor.

[0033] In some embodiments, the first module may include at least one of the following: a Controller Area Network (CAN) communication module, a diagnostic protocol stack module, a Serial Peripheral Interface (SPI) driver module, and a power management module.

[0034] As can be seen from steps 101 to 103 above, in this embodiment, the number of consecutive restarts caused by the first processing chip due to MAE anomalies can be recorded. When the value of the first number reaches a first threshold, the Dataflash operation on the first storage medium is skipped. Thus, after the first number reaches the first threshold, access to the first storage medium, which has already experienced a hardware-level failure, is no longer attempted. This avoids repeated MAE anomalies due to reading the first storage medium every time power is applied, allowing the first processing chip to bypass the faulty area and start normally, while at least ensuring the availability of the aforementioned first module. Therefore, this embodiment breaks the infinite restart loop caused by MAE anomalies, enabling the first processing chip to achieve degraded startup (i.e., only starting the basic functional modules in the first processing chip that do not depend on the first storage medium), solving the technical problem that the system cannot start completely due to hardware-level failures of the first storage medium in the first processing chip.

[0035] Optionally, the vehicle operating system further includes a second processing chip; the second processing chip is a system-level processing chip, and the first processing chip is a control chip; the method further includes: When the value of the first number of times reaches the first threshold, first fault information is generated, wherein the first fault information is used to indicate that a hardware-level fault has occurred in the first storage medium. The first fault information is sent to the second processing chip; The second processing chip performs a first prompt operation based on the first fault information. The first prompt operation is used to prompt that a hardware-level fault has occurred in the first storage medium.

[0036] The first fault information may include a Diagnostic Trouble Code (DTC) indicating that a hardware-level fault has occurred in the first storage medium.

[0037] Therefore, when the value of the first number of times reaches the first threshold, that is, when it is confirmed that the first storage medium has a persistent failure, the first processing chip can generate the first fault information and send the first fault information to the second processing chip, so that the second processing chip can perform the above-mentioned first prompt operation to prompt that the first storage medium has a hardware-level failure.

[0038] In some embodiments, the second processing chip may be a system-on-a-chip (SOC) chip.

[0039] The second processing chip can communicate with the first processing chip. For example, when the second processing chip is a System-on-a-Chip (SoC) and the first processing chip is an MCU, the SoC and the MCU can communicate via a Serial Peripheral Interface (SPI).

[0040] Optionally, generating first fault information when the value of the first number of times reaches the first threshold includes: If the value of the first number of times reaches the first threshold, a first flag is generated, wherein the first flag is used to indicate that Dataflash operations on the first storage medium are blocked. If the first flag is detected during the startup of the first module, the first fault information is generated.

[0041] As can be seen, in some embodiments, when the value of the first number of times reaches a first threshold, a first flag can be generated to indicate that the Dataflash operation on the first storage medium is blocked, thereby enabling the first processing chip to block the Dataflash operation on the first storage medium and start the first module of the first processing chip. If the first flag is detected during the startup process, first fault information is generated and then the first fault information can be sent to the second processing chip.

[0042] It should be noted that the presence of the first flag indicates that the first processing chip is performing a downgraded boot, which in turn confirms that the first storage medium has experienced a hardware-level failure. Therefore, if the first flag is detected during the boot process of the first module of the first processing chip, first fault information indicating that the first storage medium has experienced a hardware-level failure can be generated.

[0043] Optionally, the second processing chip performs a first prompt operation based on the first fault information, including the following steps H-1, H-2, or H-3: Step H-1: The second processing chip displays a first prompt message and executes a power-down procedure. The first prompt message indicates that a hardware-level fault has occurred in the first storage medium. Thus, through the first prompt message, the user can be informed that a hardware-level fault has occurred in the first storage medium. If a hardware-level fault occurs in the first storage medium, the second processing chip cannot rely on the data in the first storage medium to perform the corresponding functions. In this case, the second processing chip can execute a power-down procedure.

[0044] It should be noted that the method of alerting to hardware-level failures in the first storage medium as described in step H-1 can be applied to scenarios where there is a strong dependence on the data in the first storage medium.

[0045] Specifically, the first processing chip can send instruction information to the second processing chip to instruct the execution of the power-down process.

[0046] In addition, in some embodiments, after receiving the aforementioned first fault information, the second processing chip may display a first pop-up window to indicate that a hardware-level fault has occurred in the first storage medium, and then execute a power-down procedure. That is, the aforementioned first prompt information may include the first pop-up window.

[0047] Step H-2: The second processing chip displays the first prompt message and continues to run the second module, wherein the second module includes a module in the second processing chip that does not depend on the data in the first storage medium; thus, through the first prompt message, the user can be informed that the first storage medium has experienced a hardware-level failure; wherein, if the first storage medium experiences a hardware-level failure, the second processing chip cannot rely on the data in the first storage medium to perform the corresponding functions. In this case, the second module in the second processing chip that does not depend on the data in the first storage medium can continue to run, so as to preserve the functions corresponding to the second module, that is, to preserve a part of the user experience.

[0048] It should be noted that the method of alerting the first storage medium to a hardware-level fault as described in step H-2 can be applied to scenarios where user experience is the priority.

[0049] Step H-3: Do not power on the second processing chip; in this way, the display screen connected to the second processing chip will show a black screen, which can prompt the user that the first storage medium has a hardware-level failure; it can be seen that in some embodiments, the second processing chip can also be powered off, thereby prompting the user that the first storage medium has a hardware-level failure by displaying a black screen.

[0050] It should be noted that the method of alerting the first storage medium to a hardware-level fault as described in step H-3 can be applied to scenarios with high functional safety requirements.

[0051] Optionally, the method further includes: The first fault information is stored in the persistent storage medium of the second processing chip.

[0052] The first fault information is stored in the persistent storage medium of the second processing chip, which allows relevant personnel to obtain fault logs through remote export tools, Universal Serial Bus (USB) interfaces, or diagnostic interfaces on the second processing chip, thereby confirming hardware-level faults in the first storage medium.

[0053] Optionally, the method further includes step B-1 or step B-2: Step B-1: If the value of the first number of times reaches the second threshold, perform at least one of partial erase and partial rewrite operations on the first storage medium, and if the first storage medium is successfully repaired, set the value of the first number of times to zero; wherein, the first threshold is greater than the second threshold.

[0054] As can be seen, in some embodiments, when the value of the first number reaches the second threshold, at least one of the partial erase and partial rewrite operations can be performed on the first storage medium before the first processing chip performs the batch read operation on the first storage medium in order to attempt to repair the damaged storage cells in the first storage medium. In this way, after the repair is successful, the value of the first number can be set to zero.

[0055] In some embodiments, at least one of partial erase and partial rewrite operations may be performed on a first storage area in a first storage medium, wherein the data in the first storage area is related to the business currently being executed by the first processing chip, and the data in the first storage area belongs to a predetermined non-critical data type.

[0056] Step B-2: If the value of the first number of times reaches the third threshold, restart the first processing chip, the first processing chip performs a batch read operation on the first storage medium, and if the first storage medium is successfully repaired, set the value of the first number of times to zero; the first threshold is greater than the third threshold.

[0057] In some embodiments, the second threshold is greater than the third threshold.

[0058] Most temporary ECC errors can be automatically recovered after the first processing chip restarts without manual intervention. Therefore, in some embodiments, when the value of the first number of errors reaches the third threshold, the first processing chip can perform a batch read operation on the first storage medium, thus preserving the opportunity for the first processing chip to automatically repair itself.

[0059] Optionally, the first processing chip further includes a second storage medium; the method further includes the following step C-1: Step C-1: If it is confirmed that the first processing chip has experienced a MAE (Multi-Error) anomaly, a second flag is recorded in the second storage medium, wherein the second flag is used to indicate that the first processing chip has experienced a MAE anomaly. The recording of the first number of consecutive restarts caused by the first processing chip due to MAE anomaly includes the following step C-2: Step C-2: After restarting the first processing chip, if the second flag is read in the second storage medium, read the value of the first counter in the second storage medium, increase the value of the first counter by a first preset value, and write the updated value of the first counter back to the second storage medium; wherein, the value of the first counter represents the value of the first count.

[0060] Optionally, the first preset value can be 1.

[0061] The second flag is used to indicate that the first processing chip has experienced a MAE exception. The second flag can also be called the valid MAE exception restart (MAE_RESTART_VALID) flag, which means that the first processing chip has restarted due to the MAE exception.

[0062] As can be seen from the above, when a MAE (Management Error) occurs in the first processing chip, a second flag can be recorded in the second storage medium to indicate that a MAE has occurred in the first processing chip. After the first processing chip restarts, the second flag can be read from the second storage medium to know that the restart of the first processing chip was caused by the MAE. Then, the value of the first counter in the second storage medium can be increased by a first preset value, and the updated value of the first counter can be written back to the second storage medium.

[0063] Therefore, in this embodiment of the application, the number of times the first processing chip is restarted due to MAE abnormality can be effectively recorded by the second flag and the first counter, avoiding the accumulation of the number of times the first processing chip is restarted due to non-MAE abnormality, which would affect the subsequent fault handling process.

[0064] Optionally, the method further includes the following steps C-3 to C-4: Step C-3: If the first processing chip does not experience another MAE exception after this restart and before the next restart, delete the second flag in the second storage medium. Step C-4: If the second flag is not read from the second storage medium after the first processing chip is restarted next time, the value of the first counter is set to zero.

[0065] As mentioned above, the value of the first counter represents the value of the first count, which represents the number of times the first processing chip has been restarted consecutively due to a MAE (Multiple Actions Exceeded) error. Therefore, the first counter records the number of times the first processing chip has been restarted consecutively due to a MAE error. Thus, if the first processing chip does not experience a MAE error between the current restart and the next restart, the second flag in the second storage medium can be deleted. In this way, the second flag will not be read from the second storage medium after the next restart, and the value of the first counter can be set to zero.

[0066] To facilitate understanding of steps C-1 to C-4 above, the following example is provided: For example, when the first processing chip experiences a MAE (Multi-Error) anomaly, a second flag is recorded in the second storage medium. After the first processing chip is restarted for the first time, if the second flag is read from the second storage medium, the first counter is incremented by 1. If it is determined that a second restart of the first processing chip is required, but the first processing chip does not experience another MAE anomaly between the first and second restarts, then the second flag can be deleted before the second restart of the first processing chip. If the second flag cannot be read after the first processing chip is restarted for the second time, the first counter is set to zero.

[0067] It should be noted that each time the value of the first counter is updated, it can be determined whether its value has reached the corresponding threshold mentioned above (such as at least one of the third threshold, the second threshold, and the first threshold mentioned above).

[0068] To facilitate understanding of the fault handling method of this application embodiment, a vehicle system is used as an example to describe the following specific implementation method of the fault handling method of this application embodiment: like Figure 2 As shown, the in-vehicle system includes an MCU and a SOC; The MCU includes an MAE exception handling module, an AUTOSAR application layer, an AUTOSAR bus-sleep mode (BSM) layer, a microcontroller abstraction layer (MCAL), a data flash, and a resistive random-access memory (RRAM). The AUTOSAR application layer includes a diagnostic module, a health monitoring module, and a power management module. The AUTOSAR BSM layer includes the NVM module, the Diagnostic Event Manager (Dem) module, and the Operating System (Os) module. The NVM module manages data that needs to be retained after power loss (such as configuration parameters, fault codes, mileage information, etc.). The Dem module is used for fault detection, debouncing, storage, aging, and reporting. The Os module, as the real-time operating system, is responsible for task scheduling, resource management, and interrupt handling. MCAL includes a Flash EEPROM Emulation (Fee) module, an Fls module, and a RAM Driver (Ram) module. The Fee module implements the flash memory and simulates the functions of an EEPROM. The Fls module handles the actual flash erase, write, and read operations and is the foundational support module for the Fee module. The Ram module manages the read, write, and testing of the internal Static Random-Access Memory (SRAM). DataFlash is used for ECC protection; it also stores diagnostic fault codes, vehicle calibration parameters, configuration information, mileage data, and other data crucial for normal vehicle operation. Furthermore, in the AUTOSAR architecture, DataFlash data management is accomplished collaboratively by multiple software modules: the NVM module is responsible for data management and scheduling; the Fee module is responsible for EEPROM emulation and address management on the Flash; and the Fls module is responsible for the actual Flash erase, write, and read operations. Upon system power-up, the NVM module executes a ReadAll operation, using Fls_MainFunction to read all data blocks from DataFlash into RAM in batches to complete initialization. RRAM is a SRAM area where data is not lost after a soft reset, and it is used for restart counting and recording exception information.

[0069] The SOC includes a Health Service module, a Human-Machine Interface (HMI) module, a Log storage module, and a Power Management module.

[0070] based on Figure 2 The vehicle-mounted system shown in this application, and the fault handling method of this embodiment are as follows: Figure 3 As shown, the specific steps include steps 1 to 14 as follows: Step 1: When a MAE exception occurs after the MCU performs a DataFlash read operation, the MCU automatically jumps to the exception handling function; the process of the exception handling function is described in steps 2 to 17 below; Step 2: Set the MAE_RESTART_VALID flag in RRAM to indicate the existence of a valid MAE restart count record (i.e., a MAE exception has occurred). The RRAM also stores the following key information when the MAE exception occurred: exception type identifier (based on a DataFlash fault (MAE_DATAFLASH_FAULT)), the address of the instruction that triggered the exception (obtained from the Exception Instruction Program Counter (EIPC), and the accessed DataFlash address). It should be noted that this key information is helpful for fault location; for example, the code causing the MAE exception can be determined from the address of the instruction that triggered the exception, and the data address causing the MAE exception can be determined from the accessed DataFlash address. Step 3: Enter an infinite loop and wait for the watchdog timer (WDG) to reset; Step 4: After the MCU restarts, in the earliest stage of system initialization (e.g., in the EcuMDriverInitOne_Handle function), read the MAE_RESTART_VALID flag and the MAE abnormal restart (mae_restart_count) counter in RRAM, increment the mae_restart_count counter by 1, and write it back to RRAM; It should be noted that the EcuM_AL_DriverInitOne function is used to prepare the necessary hardware environment for the operating system to start. It should also be noted that if no MAE exception occurs again between the current MCU restart and the next MCU restart (i.e., the next MCU restart is not caused by a MAE exception), then the above MAE_RESTART_VALID flag can be deleted and the mae_restart_count counter can be set to zero. Step 5: After each increment of the mae_restart_count counter, determine whether the value of the mae_restart_count counter has reached a predetermined threshold; Step 6: Use the mae_restart_count counter. In the case of 2, restart the MCU normally and attempt ReadAll; if ReadAll completes successfully (that is, no MAE occurs again), reset the mae_restart_count counter to zero; it should be noted that most temporary ECC errors can recover automatically after restart without manual intervention; Step 7: When 2 < mae_restart_count ≤ 4, perform local erasure and rewriting on DataFlash before attempting ReadAll, then attempt to repair the damaged memory cell; if the repair is successful, reset the mae_restart_count counter to zero; It can be seen from steps 6 and 7 that when the mae_restart_count counter < 5, the fault can be considered as a possible temporary fault, and the ReadAll process can be attempted to give the system an opportunity for automatic recovery; if ReadAll completes successfully (that is, no MAE occurs again), it indicates that the fault has recovered automatically, and then the mae_restart_count counter can be reset to zero; Step 8: When the mae_restart_count counter ≥ 5, confirm that there is a persistent hardware fault in DataFlash, set the global Flash masking flag (that is, set g_fls_disabled = TRUE), thereby entering the degraded boot mode; It can be seen from steps 6 to 8 that this hierarchical strategy maximizes the opportunity for automatic recovery while ensuring the ultimate availability of the system; Step 9: After setting g_fls_disabled = TRUE, the following four types of Flash operations are masked: NvM ReadAll operation, operation of NvM read-write interface, Fls_MainFunction operation in Os scheduling, and Fls operation in the upgrade module; that is, the MCU skips the initialization related to DataFlash, and other basic functional modules (such as CAN communication, diagnostic protocol stack, SPI driver, power management and other functional modules) are initialized and started normally; Step 10: During the startup process of the MCU, after the diagnostic module of the MCU detects that g_fls_disabled = TRUE and confirms that the system is in degraded mode, it calls Dem_SetEventStatus to set the Flash damage DTC fault code (such as DTC 0x981804), indicating that a hardware fault has occurred in DataFlash; It should be noted that Dem_SetEventStatus refers to a core interface provided by the diagnostic event manager module in the AUTOSAR standard; Step 11: The MCU reports the Flash damage DTC to the SOC via SPI communication; the HealthService module on the SOC side receives the fault information (i.e., the Flash damage DTC), records and processes it, and the specific processing can be described in step 12, step 13, or step 14 below: Step 12: Trigger a pop-up alarm through the Health Service module to display a fault message to the user: "Flash hardware is damaged, please go to after-sales service for repair"; and call the power supply through the MCU to request the SOC to execute a safe power-down procedure; before powering down, the SOC saves the received fault information to the persistent storage on the SOC side, so that after-sales personnel can obtain the fault log through the remote export tool, USB interface or diagnostic interface on the SOC side to confirm the DataFlash damage fault; The execution process of step 12 is applicable to scenarios that strongly depend on DataFlash data; Step 13: After the SOC displays a fault message, it continues to run, retaining functions such as navigation and media that do not rely on MCU DataFlash data; however, vehicle mileage information may not be saved, and the user should be informed in a pop-up window. The execution process of step 13 is suitable for scenarios where user experience is the priority; Step 14: Do not power on the SOC. That is, when the mae_restart_count counter reaches 5, the MCU will not power on the SOC and will notify the user of the abnormality by displaying a black screen. The execution process of step 14 is applicable to scenarios with high functional safety requirements.

[0071] Furthermore, in existing technologies, once a MAE (Mastering Experience Expiration) error occurs, the MCU enters a vicious cycle: MCU power-on → ReadAll reads DataFlash → MAE error occurs → Watchdog reset → MCU restarts → ReadAll again → MAE error again → reset again…; this leads to the following consequences: (1) After the MAE abnormality is handled, the watchdog is reset and restarted. The MAE occurs again, making the vehicle unable to start at all. Users cannot use navigation, media, instrument display and other functions, which affects driving safety and user experience. (2) The MCU restarts repeatedly and cannot complete initialization, that is, it cannot enter the normal diagnostic mode. After-sales service cannot use diagnostic tools to read the DTC to determine the cause of the fault, which may cause users to blindly try to replace the hardware. (3) If the MCU cannot start and the SPI communication is not established, the fault information cannot be reported to the SOC, and the SOC cannot record and export the fault log, making it impossible to troubleshoot the fault. (4) Important data such as vehicle mileage and configuration may be lost due to damage to the DataFlash; (5) The existing solution has no intermediate degradation state, so it is impossible to achieve degradation operation and safe power-off when DataFlash is damaged.

[0072] As can be seen, the traditional solution directly enters an infinite loop in the MAE exception handling function, waiting for the watchdog timer to reset. After the reset, the same MAE occurs again, forming an infinite restart loop.

[0073] Furthermore, while faults can be recovered by erasing the DataFlash using professional tools connected through after-sales service, this requires the user to take the vehicle to a repair shop, and all non-volatile data is lost after erasure. Alternatively, some systems skip ReadAll after detecting a Flash error, but there is a lack of clear judgment criteria, which may also skip ReadAll in the event of a temporary fault, thus losing the opportunity for automatic recovery. Additionally, there is a lack of a fault information feedback mechanism.

[0074] Therefore, it can be seen that existing technologies cannot simultaneously meet the complete requirements of: breaking the infinite restart loop, preserving the opportunity for automatic recovery, completing diagnostic startup to read DTC, reporting fault information to the SOC to notify the user, and providing safe power-down protection.

[0075] In this embodiment, the core processing flow after a MAE exception occurs is as follows: MAE exception occurs → record the number of times the MCU restarts due to the MAE exception in the RRAM (i.e., the above-mentioned mae_restart_count counter) → watchdog reset → MCU restart → read the mae_restart_count counter in the RRAM → if the threshold is not reached, attempt to recover normally using ReadAll → if the threshold is reached (5 times), skip all Flash operations → diagnose downgrade startup → set Flash damage DTC → report to SOC via SPI → SOC pop-up alarm → request SOC to power down safely.

[0076] Therefore, the fault handling method of this application embodiment can achieve the following effects: (1) Break the infinite restart loop caused by DataFlash MAE: that is, by recording the number of MAE restarts and the threshold through RRAM, the Flash operation is skipped after confirming the persistent fault of DataFlash, so that the vehicle unit can complete the downgraded start-up; (2) Retain the opportunity for automatic recovery: that is, ReadAll is executed normally before the threshold is reached. For temporary ECC errors or occasional failures, the system has the opportunity to recover automatically and avoid misjudgment; (3) Implement diagnostic functions in degraded mode: Even if DataFlash is unavailable, the MCU can still start the diagnostic module and set the Flash damage DTC to provide clear fault information for after-sales service; (4) Fault information reporting to SOC: that is, DTC reports to SOC through SPI, SOC displays fault prompts to users, and after-sales can export fault logs for analysis through SOC; (5) Safe power-down protection: After confirming that the DataFlash is unavailable, the MCU requests the SOC to safely power down to avoid continuing to operate under unreliable data conditions; (5) Flexible degradation strategy: It supports graded degradation and multiple SOC response strategies, which can be flexibly configured according to vehicle type and scenario.

[0077] The above describes the fault handling method provided by the application embodiments. The following will describe the vehicle operating system provided by the application embodiments in conjunction with the accompanying drawings.

[0078] Secondly, the application embodiments also provide a vehicle operating system, such as an intelligent car operating system or an in-vehicle intelligent cockpit operating system.

[0079] like Figure 4 As shown, the vehicle operating system 400 includes a first processing chip 401; the first processing chip 401 includes a first storage medium 4011 and a first module 4012; the first module 4012 includes: a basic functional module in the first processing chip 401 that does not depend on the first storage medium 4011. The first processing chip 401 is used for: In the event of a hardware-level failure in the first storage medium 4011, the machine check interruption (MAE) abnormality is confirmed in the first processing chip 401, and the first processing chip 401 is restarted. Record the first number of times the first processing chip 401 restarts due to MAE anomaly. When the value of the first number of times reaches the first threshold, the Dataflash operation on the first storage medium 4011 is blocked, and the first module 4012 of the first processing chip 401 is started.

[0080] Optionally, the vehicle operating system 400 further includes a second processing chip 402; the second processing chip 402 is a system-level processing chip, and the first processing chip 401 is a control chip; the first processing chip 401 is further used for: When the value of the first number of times reaches the first threshold, first fault information is generated, wherein the first fault information is used to indicate that a hardware-level fault has occurred in the first storage medium. The first fault information is sent to the second processing chip 402; The second processing chip 402 is used to: perform a first prompting operation based on the first fault information, wherein the first prompting operation is used to prompt that a hardware-level fault has occurred in the first storage medium.

[0081] Optionally, when the value of the first number of times reaches the first threshold, the first processing chip 401 generates first fault information, including: If the value of the first number of times reaches the first threshold, a first flag is generated, wherein the first flag is used to indicate that Dataflash operations on the first storage medium are blocked. If the first flag is detected during the startup of the first module 4012, the first fault information is generated.

[0082] Optionally, the second processing chip 402 performs a first prompt operation based on the first fault information, including: The second processing chip 402 displays the first prompt message and executes the power-down procedure; or, The second processing chip 402 displays the first prompt message and continues to run the second module 4021, wherein the second module 4021 includes: a module in the second processing chip 402 that does not depend on the data in the first storage medium 4011; or, The second processing chip 402 is not powered on. The first prompt message is used to indicate that the first storage medium has experienced a 4011 hardware-level fault.

[0083] Optionally, the second processing chip 402 further includes a persistent storage medium 4022; the persistent storage medium 4022 is also used to store the first fault information.

[0084] Optionally, the first processing chip 401 is further configured to: If the value of the first number of times reaches the second threshold, at least one of partial erase and partial rewrite operations is performed on the first storage medium 4011, and if the first storage medium 4011 is successfully repaired, the value of the first number of times is set to zero; wherein, the first threshold is greater than the second threshold. Alternatively, if the value of the first number of times reaches the third threshold, the first processing chip 401 is restarted to perform a batch read operation on the first storage medium 4011, and if the first storage medium 4011 is successfully repaired, the value of the first number of times is set to zero; wherein, the first threshold is greater than the third threshold.

[0085] Optionally, the first processing chip 401 further includes a second storage medium 4013; the first processing chip 401 is further configured to: If it is confirmed that the first processing chip 401 has experienced a MAE (Multiple Actions Exceeded) error, a second flag is recorded in the second storage medium 4013, wherein the second flag is used to indicate that the first processing chip 401 has experienced a MAE error. The first processing chip 401 records the first number of consecutive restarts caused by the MAE anomaly, including: After restarting the first processing chip 401, if the second flag is read in the second storage medium 4013, the value of the first counter in the second storage medium 4013 is read, the value of the first counter is increased by a first preset value, and the updated value of the first counter is written back to the second storage medium 4013; wherein, the value of the first counter represents the value of the first count.

[0086] Optionally, the first processing chip 401 is further configured to: If the first processing chip 401 does not experience another MAE abnormality after this restart and before the next restart, the second flag in the second storage medium 4013 is deleted. If the second flag is not read from the second storage medium 4013 after the first processing chip 401 is restarted next time, the value of the first counter is set to zero.

[0087] It should be noted that the chip or module division in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional chips or modules in the various embodiments of this application can be integrated into one chip or module, or each chip or module can exist physically separately, or two or more chips or modules can be integrated into one chip or module. The integrated chips or modules described above can be implemented in hardware or as software functional chips or modules.

[0088] If the integrated chip or module is implemented as a software functional chip or module and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] It should be noted that the vehicle operating system provided in the application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail here.

[0090] Embodiments of the present invention also provide an electronic device, such as... Figure 5 As shown, the electronic device includes a memory 520, a transceiver 510, and a processor 500; Memory 520 is used to store computer programs; Transceiver 510 is used to receive and send data under the control of processor 500; The processor 500 is used to read the computer program in the memory 520 and execute the fault handling method described in the first aspect above.

[0091] Among them, Figure 5 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 500) and memory (memory 520). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 510 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over transmission media, including wireless channels, wired channels, optical fibers, etc. The processor 500 is responsible for managing the bus architecture and general processing, and the memory 520 can store data used by the processor 500 during operation.

[0092] The processor 500 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD). The processor 500 can also adopt a multi-core architecture.

[0093] Embodiments of the present invention also provide a processor-readable storage medium storing a computer program for causing the processor to perform the fault handling method described above.

[0094] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0095] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0096] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0097] These processor-executable instructions may also be stored in a processor-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0098] These processors can execute instructions that can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0099] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A fault handling method, characterized in that, Applied to a vehicle operating system, the vehicle operating system including a first processing chip; the method includes: In the event of a hardware-level failure in the first storage medium of the first processing chip, confirm that the first processing chip has experienced a Machine Check Abrupt (MAE) exception, and restart the first processing chip. Record the first number of times the first processing chip restarts due to MAE anomaly. When the value of the first number of times reaches the first threshold, operations on the non-volatile data flash memory of the first storage medium are blocked, and the first module of the first processing chip is started, wherein the first module includes basic functional modules of the first processing chip that do not depend on the first storage medium.

2. The method according to claim 1, characterized in that, The vehicle operating system further includes a second processing chip; the second processing chip is a system-level processing chip, and the first processing chip is a control chip. The method further includes: When the value of the first number of times reaches the first threshold, first fault information is generated, wherein the first fault information is used to indicate that a hardware-level fault has occurred in the first storage medium. The first fault information is sent to the second processing chip; The second processing chip performs a first prompt operation based on the first fault information. The first prompt operation is used to prompt that a hardware-level fault has occurred in the first storage medium.

3. The method according to claim 2, characterized in that, When the value of the first number of times reaches the first threshold, generating first fault information includes: If the value of the first number of times reaches the first threshold, a first flag is generated, wherein the first flag is used to indicate that Dataflash operations on the first storage medium are blocked. If the first flag is detected during the startup of the first module, the first fault information is generated.

4. The method according to claim 2, characterized in that, The second processing chip performs a first prompt operation based on the first fault information, including: The second processing chip displays the first prompt message and executes the power-down procedure; or, The second processing chip displays the first prompt message and continues to run the second module, wherein the second module includes: a module in the second processing chip that does not depend on the data in the first storage medium; or, Do not power on the second processing chip; The first prompt message is used to indicate that a hardware-level failure has occurred in the first storage medium.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: The first fault information is stored in the persistent storage medium of the second processing chip.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: If the value of the first number of times reaches the second threshold, at least one of partial erase and partial rewrite operations is performed on the first storage medium, and if the first storage medium is successfully repaired, the value of the first number of times is set to zero; wherein, the first threshold is greater than the second threshold; Alternatively, if the value of the first count reaches the third threshold, the first processing chip is restarted, the first processing chip performs a batch read operation on the first storage medium, and if the first storage medium is successfully repaired, the value of the first count is set to zero; wherein, the first threshold is greater than the third threshold.

7. The method according to any one of claims 1 to 4, characterized in that, The first processing chip also includes a second storage medium; The method further includes: If it is confirmed that the first processing chip has experienced a MAE (Multiple Actions Exceeded) error, a second flag is recorded in the second storage medium, wherein the second flag is used to indicate that the first processing chip has experienced a MAE error. The record of the first number of consecutive restarts caused by the first processing chip due to MAE anomalies includes: After restarting the first processing chip, if the second flag is read from the second storage medium, the value of the first counter in the second storage medium is read, the value of the first counter is increased by a first preset value, and the updated value of the first counter is written back to the second storage medium; wherein, the value of the first counter represents the value of the first count.

8. The method according to claim 7, characterized in that, The method further includes: If the first processing chip does not experience another MAE anomaly between the current restart and the next restart, the second flag in the second storage medium is deleted. If the second flag is not read from the second storage medium after the first processing chip is restarted next time, the value of the first counter is set to zero.

9. A vehicle operating system, characterized in that, The vehicle operating system includes a first processing chip; the first processing chip includes a first storage medium and a first module; the first module includes basic functional modules in the first processing chip that do not depend on the first storage medium. The first processing chip is used for: In the event of a hardware-level failure in the first storage medium, confirm that the first processing chip has experienced a Machine Check (MAE) interruption abnormality, and restart the first processing chip. Record the first number of times the first processing chip restarts due to MAE anomaly. When the value of the first number of times reaches the first threshold, operations on the non-volatile data flash memory of the first storage medium are blocked, and the first module of the first processing chip is started.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the fault handling method as described in any one of claims 1-8.