A cockpit domain controller fault identification device and method

Abstract

The application discloses a cockpit domain controller fault identification device and method, and relates to the technical field of automobile electronics.The device is based on a microcontroller and a system-level chip architecture, and the microcontroller is integrated with a nonvolatile flash memory and a reset-keeping random access memory.A layered storage strategy is adopted in the method: when the system is normal, key information is output to the system-level chip;when the system-level chip is abnormal, fault codes are written into the nonvolatile flash memory;when an operating system error or software lock occurs in the microcontroller, a hook function or a non-masked interrupt is used to extract a program counter address, which is written into the reset-keeping random access memory;after the microcontroller is reset, historical fault information is read and reported uniformly.The application uses the reset-keeping storage characteristic, effectively solves the data loss problem caused by slow flash writing under a fatal fault, realizes code line-level accurate positioning of a dead machine fault, and improves the system maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a cockpit domain controller fault identification device and method. Background Technology

[0002] With the rapid development of automotive intelligent technology, the functions of the Cockpit Domain Controller (CDC) have become increasingly complex. It has gradually evolved from a single information display and control system into a comprehensive computing platform integrating vehicle Ethernet gateway, diagnostic gateway, vehicle control, entertainment system, and edge computing. A typical cockpit domain controller usually adopts a dual-chip heterogeneous architecture of a microcontroller (MCU) and a system-on-a-chip (SoC). The MCU is responsible for power management, vehicle bus communication, and real-time control related to functional safety, while the SoC carries complex operating systems such as QNX and Android to handle high-computing-power entertainment and display tasks.

[0003] In the development, mass production, and maintenance of cockpit domain controllers, system stability and reliability are paramount. However, facing increasingly complex hardware and software environments, cockpit domain controllers frequently encounter faults such as screen blackouts, screen flickering, and intermittent automatic restarts. Currently, diagnosis of such faults relies on CAN bus diagnostics, Ethernet DoIP diagnostics, system operation logs, or data capture using external serial port debugging devices. This traditional diagnostic method is effective in handling routine functional logic errors, but it has significant limitations when facing serious system faults.

[0004] Specifically, when a microcontroller experiences a serious malfunction, such as an internal error in the real-time operating system or a software execution flow stuck in an infinite loop, the system will trigger a watchdog reset or crash directly. At this instant, the microcontroller's internal file system driver and the write service of non-volatile memory (such as Flash) typically cease to function properly. Furthermore, the slow write speed of Flash means the system cannot save critical data (such as program counter address, stack information, etc.) in time before the reset. This leaves the reset system untraceable, and developers cannot determine the exact cause of the restart. In addition, for SoC-level malfunctions, if the SoC fails to boot or crashes during boot, its own logging service will fail, resulting in the inability to record the specific reasons for power timing, heartbeat loss, or boot timeouts, creating a diagnostic blind spot.

[0005] On the other hand, existing troubleshooting methods rely excessively on external packet capture devices or debuggers. For intermittent faults occurring in actual vehicle operation, a large number of R&D personnel are required to conduct long-term on-vehicle testing to capture the moment the fault reproduces. This not only consumes manpower but also, due to the lack of precise fault scene data within the system (such as the execution location down to the line of code), even if the fault is reproduced, subsequent offline analysis struggles to pinpoint the specific software module or hardware anomaly, severely impacting troubleshooting efficiency and product iteration speed. Therefore, how to reliably capture and store critical fault data even under extreme conditions such as system near collapse or abnormal reset has become a pressing technical challenge in current cockpit domain controller design. Summary of the Invention

[0006] The purpose of this invention is to provide a cockpit domain controller fault identification device and method, which at least solves one of the technical problems in the prior art: when a cockpit domain controller experiences a serious fault such as a microcontroller crash or a system-level chip malfunction, the cause of the fault is difficult to trace because the key data of the fault scene cannot be stored in a timely manner; and the troubleshooting of intermittent faults relies too much on external devices and is difficult to locate the specific line of code.

[0007] A first aspect of the present invention provides a cockpit domain controller fault identification device. The cockpit domain controller adopts an architecture in which a microcontroller and a system-on-a-chip (SoC) work together. The microcontroller integrates non-volatile flash memory and reset-hold random access memory. The fault identification device includes an information acquisition module, a hierarchical storage control module, and an information output and reporting module.

[0008] The information acquisition module is used to collect key information related to fault identification. The hierarchical storage control module is configured to determine the real-time operating status of the cockpit domain controller based on preset judgment conditions. The judgment logic for the real-time operating status includes: determining the normal operating status of the cockpit domain controller based on whether the communication link with the system-on-a-chip is active; determining the abnormal status of the system-on-a-chip based on communication interruption, received reset command, or hardware status abnormality; and determining the abnormal status of the microcontroller based on internal errors in the real-time operating system or software execution flow freeze.

[0009] Based on the determined real-time operating status, the hierarchical storage control module executes differentiated storage strategies: When the cockpit domain controller is operating normally, the critical information is output to the system-on-a-chip (SoC) for processing; when the SoC is in an abnormal state, the critical information is written to the microcontroller's non-volatile flash memory; when the microcontroller is in an abnormal state, the critical information is written to the reset-hold random access memory (RRAM). The reset-hold RRAM has the characteristic of retaining data without loss after a reset, and the writing process does not rely on complex file system drivers.

[0010] The information output and reporting module is used to check and read the historical fault information stored in the non-volatile flash memory and the reset hold random access memory after the microcontroller completes the reset and startup, and output the historical fault information.

[0011] Furthermore, in response to abnormal states of the system-on-a-chip, the hierarchical storage control module has a fault coding function, which can identify and encode the specific cause of the abnormality of the system-on-a-chip into a digital code according to a predefined reset cause code table, and write the digital code into the non-volatile flash memory before performing the reset operation, thereby realizing offline tracing of system-on-a-chip faults.

[0012] Furthermore, to address internal errors in the real-time operating system during microcontroller anomalies, the hierarchical storage control module utilizes the ErrorHook mechanism of the real-time operating system to extract the program counter address value at the moment the error occurs. This address value is then written to the reset-hold random access memory. Preferably, this writing process employs a direct memory write operation to minimize microcontroller overhead and mitigate the risk of file system driver failure.

[0013] Furthermore, to address software execution flow freezes in abnormal microcontroller states, the fault identification device utilizes an external watchdog timer to trigger a non-maskable interrupt. Within the interrupt service routine of the non-maskable interrupt, the hierarchical storage control module directly reads the program counter address value at the moment of interruption from the stack and writes this address value into the reset-hold random access memory, thereby ensuring that the address of the last executed instruction can still be captured even when the main software loop completely stops responding.

[0014] Furthermore, the information output and reporting module can format the read historical fault information into log entries containing timestamps. The log entries include an absolute timestamp from the real-time clock, a relative timestamp from the microcontroller's internal timer, and the message text. After the microcontroller and the system-on-a-chip (SoC) restore communication, the log entries are sent to the SoC for unified recording.

[0015] Furthermore, the program counter address value output by the information output and the reporting module can be compared with the linker mapping file corresponding to the microcontroller software version to determine the specific function location that caused the microcontroller malfunction.

[0016] A second aspect of the present invention provides a cockpit domain controller fault identification method, applied to a cockpit domain controller including a microcontroller and a system-on-a-chip (SoC). The method includes: collecting key information related to fault identification; determining, based on the communication status with the SoC, the reception of reset commands, the hardware status, and the operating system operation status of the microcontroller, whether the cockpit domain controller is in normal operation, the SoC is in an abnormal state, or the microcontroller is in an abnormal state; based on the determination result, outputting the key information to the SoC, writing it to non-volatile flash memory, or writing it to a reset-hold random access memory (RAM); and after the microcontroller is reset, reading and outputting historical fault information from the storage medium.

[0017] The above solution achieves the following beneficial technical effects:

[0018] This application utilizes the characteristic of microcontroller's internal reset-retaining random access memory (RRAM) that data is not lost after reset. Combined with the operating system's error hook function and watchdog warning mechanism, in critical moments when the microcontroller is about to reset due to an internal operating system error or software infinite loop, it can store the program counter (PC) address, task call stack, and critical hardware voltage to RRAM. This overcomes the shortcomings of traditional solutions that result in the loss of final state data due to slow non-volatile flash memory write speed or file system driver failure, ensuring that occasional and difficult-to-reproduce crash and restart failures can be recorded.

[0019] This application utilizes a microcontroller as the power management core of the cockpit domain controller. Through SPI communication and IO level monitoring, it monitors the entire process of the system-on-a-chip (SoC) QNX and Android system startup status, heartbeat signals, and power timing. When the SoC is unable to log itself due to startup timeouts, black screens, or system crashes, the microcontroller can record the fault triggering cause (such as heartbeat loss or voltage abnormality) and store it in non-volatile flash memory. This establishes a complete fault tracing link in the dual-chip heterogeneous architecture, enabling rapid differentiation between the fault source on the MCU power supply side and the SoC software side.

[0020] This application constructs a detailed fault scene profile by recording the absolute and relative timestamps of the fault occurrence, combined with multi-dimensional information such as the watchdog decrement count, task ID, and function call stack. By comparing the recorded PC address value with the mapping file generated by the software compilation, developers can accurately pinpoint the fault point to the specific line of code or function entry point in offline analysis without relying on external packet capture equipment or long-term manual on-vehicle testing, thus reducing the troubleshooting cost of complex problems such as occasional screen flickering and restarts of the cockpit domain controller. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the cockpit domain controller fault identification device in an embodiment of the present invention;

[0022] Figure 2 This is a flowchart illustrating the overall process of fault identification and hierarchical storage control method in this embodiment of the invention.

[0023] Figure 3 This is a flowchart illustrating the fault handling process of the second-level identification mechanism in this embodiment of the invention.

[0024] Figure 4 This is a flowchart illustrating the fault handling process of the third-level identification mechanism in this embodiment of the invention.

[0025] Figure 5 This is a flowchart illustrating the reporting process of historical fault information after reset in an embodiment of the present invention.

[0026] Figure 6 This is a flowchart of offline fault analysis and location in an embodiment of the present invention. Detailed Implementation

[0027] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Figure 1 This is a schematic diagram of the cockpit domain controller fault identification device in an embodiment of the present invention.

[0029] like Figure 1 As shown, the present invention provides a cockpit domain controller fault identification device, which can be integrated into the cockpit domain controller, which includes a microcontroller (MCU) and a system-on-a-chip (SoC).

[0030] The microcontroller (MCU) is used to run a real-time operating system and low-level software components, performing system power management, vehicle bus communication, and the fault identification method of this invention. The MCU integrates a non-volatile flash memory (DFLASH) and a reset-hold random-access memory (RRAM).

[0031] The cockpit domain controller also includes an external watchdog timer (WDG), which is connected to the microcontroller (MCU) via the watchdog input WDI signal and the reset signal RESET signal. The software on the MCU needs to periodically drive the WDI signal; otherwise, the external watchdog timer (WDG) will time out and force a reset of the MCU via the RESET signal.

[0032] The System-on-a-Chip (SoC) is used to run the QNX and Android operating systems. Under normal operating conditions, the SoC receives and stores data sent by the microcontroller (MCU) through its internal SaveMcuLog software service.

[0033] In terms of hardware connectivity, the microcontroller (MCU) communicates with the system-on-a-chip (SoC) via the Serial Peripheral Interface (SPI) and the Universal Asynchronous Receiver / Transmitter (UART). The MCU is connected to the Controller Area Network (CAN) for information exchange with other electronic control units in the vehicle. The SoC is connected to Ethernet via an Ethernet switch.

[0034] In terms of power management, the cockpit domain controller receives a constant external power supply KL30 and an ignition signal IGN. The microcontroller (MCU) manages the power state of the entire controller and controls the power supply to the system-on-a-chip (SoC) and other peripheral devices according to the system's operating logic.

[0035] The cockpit domain controller connects to multiple peripheral devices, including cameras, head-up displays (HUDs), instrument clusters, and a central control screen. The microcontroller (MCU) and system-on-a-chip (SoC) interact with these peripheral devices via a low-voltage differential signaling (LVDS) interface or an internal integrated circuit I2C bus.

[0036] The cockpit domain controller also includes a real-time clock (RTC). The RTC provides an absolute time reference for the fault identification device of this invention. Simultaneously, the internal timer of the microcontroller (MCU) provides a relative time reference for the fault identification device of this invention.

[0037] In the software runtime environment, the microcontroller (MCU) deploys the McuLog software component for logging and the FailTrace software component for fault tracing. These components constitute the functional entities of the fault identification device of this invention. The McuLog software component is responsible for collecting and formatting information, while the FailTrace software component is responsible for performing data capture under specific abnormal scenarios.

[0038] The fault identification device of the present invention can be logically divided into multiple functional modules. These functional modules are implemented by software programs running on a microcontroller (MCU) and work together to complete the functions of fault identification and data capture.

[0039] The fault identification device includes an information acquisition module. This module's function is to collect key information related to fault identification from the microcontroller's (MCU) software components, hardware interfaces, and operating system kernel. The types of information collected include: system status information, hardware status information, and software runtime context information.

[0040] The fault identification device also includes a hierarchical storage control module. This module is connected to the information acquisition module and its function is to determine the real-time operating status of the cockpit domain controller based on preset judgment conditions. The operating status includes: normal system operation status, system-on-a-chip (SoC) abnormal status, and microcontroller (MCU) abnormal status.

[0041] Based on the determined operating status, the hierarchical storage control module directs the information collected by the information acquisition module to specific storage media. Under normal system operation, information is output to the file system of the system-on-a-chip (SoC); under SoC malfunction, information is written to the non-volatile flash memory (DFLASH) inside the microcontroller (MCU); and under MCU malfunction, information is written to the reset-hold random access memory (RRAM) inside the MCU.

[0042] The fault identification device also includes an information output and reporting module. This module checks for historical fault information in the non-volatile flash memory (DFLASH) and reset-hold random-access memory (RRAM) after the microcontroller (MCU) has undergone a reset and restart. If found, the module reads the historical fault information, organizes it according to a predetermined data format, and outputs it via the serial peripheral interface (SPI) or universal asynchronous transceiver (UART).

[0043] Figure 2 This is a flowchart illustrating the overall process of fault identification and hierarchical storage control method in this embodiment of the invention.

[0044] like Figure 2As shown, in the first-level identification mechanism, the information acquisition module is responsible for collecting and defining system operation data as the first type of key information.

[0045] The first type of key information includes the software version information currently running on the microcontroller (MCU). This software version information is stored in a predefined data structure in the MCU's program memory, and the information acquisition module obtains the version number by directly accessing the memory address of this data structure.

[0046] The first category of key information also includes the wake-up source type of the cockpit domain controller. This wake-up source type is indicated by one or more status registers of the power management unit within the microcontroller (MCU). The information acquisition module determines whether the wake-up event is triggered by the ignition signal IGN, a controller area network (CAN) message, or other specified signal by reading the values ​​of these status registers.

[0047] The first category of critical information also includes hardware configuration information written during the End of Line (EOL) stage. This configuration information is stored in a dedicated data area of ​​the non-volatile flash memory (DFLASH). The information acquisition module reads the contents of this data area by calling the API of the non-volatile memory driver to determine whether functions such as the Driver Monitoring System (DMS) and fuel system type are configured, and the specific configuration parameters.

[0048] The first category of key information also includes the software partition information of the microcontroller (MCU). During the system startup phase, the bootloader determines which software partition (e.g., partition A or partition B) to load and run on based on preset logic. After application initialization, the information acquisition module obtains the identifier of the currently running software partition by querying specific flag bits or memory areas set by the bootloader.

[0049] The first category of key information also includes the network management status of the Controller Area Network (CAN). The information acquisition module obtains the current status of the entire vehicle network or a specific sub-network (such as the Backbone CAN) by calling the application programming interface (API) provided by the CAN Network Management (CanNM) software component, such as whether it has entered the normal network communication mode.

[0050] The first category of critical information also includes the boot status of the System-on-a-Chip (SoC). After the microcontroller (MCU) powers on the SoC, the information acquisition module starts an internal monitoring timer. If a boot success flag is received from the SoC via the Serial Peripheral Interface (SPI) before the timer expires, it is recorded as a successful boot. If the timer expires before receiving the flag, it is recorded as a boot timeout failure event. This mechanism also applies to monitoring the boot processes of the QNX and Android operating systems running on the SoC.

[0051] The first category of key information also includes the status related to the control of external devices (such as instruments and central control screens). The information acquisition module monitors the level status of the general-purpose input / output (GPIO) ports connected to the wake-up pins of external devices and records the time points when these port statuses change, thereby capturing the timing of control signals directly related to behaviors such as screen lighting up and turning off.

[0052] After the information acquisition module obtains the first type of key information, the McuLog software component is responsible for formatting the information and generating a log entry with a uniform structure.

[0053] Each log entry is constructed as a text string containing an absolute timestamp, a relative timestamp, a message level identifier, and the message body.

[0054] The absolute timestamp is derived from the Real-Time Clock (RTC). When a log entry is generated, the McuLog software component reads the current count value from the RTC and converts it to the format "year-month-day hour:minute:second.millisecond". This absolute timestamp provides a unified time reference for fault analysis spanning multiple device power-on cycles.

[0055] The relative timestamp is derived from the TickCounter, a clock counter in the microcontroller's (MCU) real-time operating system kernel. This counter starts at zero each time the MCU powers on or resets and monotonically increments at fixed time intervals (e.g., 1 millisecond). The MCULog software component retrieves the current value of this tick counter as the relative timestamp. This relative timestamp provides a high-resolution time metric for accurately analyzing the timing relationships of consecutive events occurring within a single runtime cycle with extremely short intervals.

[0056] Information level identifiers are used to distinguish the importance of different information. For example, the character I represents general information (Info), the character E represents error information (Error), and the character H represents high-priority information (High).

[0057] The information body is the raw key information (such as status value or version number) obtained by the information acquisition module, which is converted into a readable ASCII string.

[0058] Finally, the McuLog software component concatenates the above four parts in a preset order to form a complete log entry string for subsequent transmission and storage.

[0059] After the McuLog software component generates a complete log entry string, the log entry string is submitted to the hierarchical storage control module.

[0060] The hierarchical storage control module performs a status check to determine whether the execution conditions of the first-level identification mechanism are met. This status check includes checking whether the serial peripheral interface (SPI) communication link between the microcontroller (MCU) and the system-on-a-chip (SoC) has been initialized and is active. When the communication link is active, the hierarchical storage control module determines that the system is currently in normal operating condition.

[0061] After confirming that the system is in normal operating condition, the hierarchical storage control module sends the log entry string to the system-on-a-chip (SoC) via the serial peripheral interface (SPI). During this transmission, the microcontroller (MCU), acting as the master device on the SPI bus, sends a data packet containing the log entry string.

[0062] The System-on-a-Chip (SoC) receives this data packet from the device interface via its SPI. The SaveMcuLog software service running on the SoC retrieves the log entry string from the data packet and appends this string as a new line to the designated log file located within the SoC's file system, thus completing one information recording.

[0063] Figure 3 This is a flowchart illustrating the fault handling process of the second-level identification mechanism in this embodiment of the invention.

[0064] like Figure 3 As shown, the triggering conditions for the second-level identification mechanism are determined by the hierarchical storage control module. One of the triggering conditions is a communication interruption of the system-on-a-chip (SoC). The microcontroller (MCU) software has a periodic heartbeat timer, which is repeatedly reset upon receiving a periodic heartbeat signal from the SoC during normal operation. If the heartbeat timer times out without being reset, the hierarchical storage control module determines that the SoC communication is interrupted and triggers the second-level identification mechanism.

[0065] Another triggering condition is receiving a clear instruction that will cause the SoC to reset. These instructions include: an active reset request sent to the microcontroller (MCU) via the Serial Peripheral Interface (SPI) after the SoC software detects a serious internal error; a diagnostic reset instruction sent by an external diagnostic device connected to the Controller Area Network (CAN) or Ethernet; or a system reset requested by the software upgrade management module to enter a specific upgrade mode (such as FASTBOOT mode). Once the hierarchical storage control module receives and verifies any of these instructions, it will trigger the second-level identification mechanism.

[0066] Another trigger condition is when critical hardware conditions exceed preset thresholds. The microcontroller (MCU) continuously monitors the power rail voltage supplied to the SoC via its internal analog-to-digital converter (ADC). If the monitored voltage value is higher than a preset overvoltage protection threshold or lower than a preset undervoltage protection threshold, the hierarchical storage control module determines it as a power supply abnormality. Similarly, if the operating temperature of the SoC is detected by a temperature sensor to exceed a preset overtemperature protection threshold, it is determined as a temperature abnormality. The occurrence of any of the above abnormalities will trigger the second-level identification mechanism.

[0067] Another trigger condition is a failed state transition of the System-on-a-Chip (SoC). For example, during the execution of the Suspend-to-RAM (STR) process, after the microcontroller (MCU) sends a command to the SoC to enter the suspend state, it starts a state transition monitoring timer. If no confirmation signal indicating that the SoC has successfully entered the suspend state is received before the timer expires, or if the system power consumption is not detected to drop to the expected low power level, the hierarchical storage control module determines that the state transition has failed and triggers the second-level identification mechanism.

[0068] After the hierarchical storage control module determines that the system-on-a-chip (SoC) is in an abnormal state based on the trigger conditions, the hierarchical storage control module will immediately identify and encode the specific cause of the abnormal state.

[0069] In this embodiment, a reset reason code table is predefined. This reset reason code table establishes a one-to-one mapping relationship from specific fault events to unique numerical codes. The software logic of the hierarchical storage control module includes the implementation of this code table.

[0070] When the tiered storage control module identifies a specific trigger event, it searches the reset reason code table to determine the unique code corresponding to that event. This code is defined as a fixed-length data type, such as an 8-bit unsigned integer.

[0071] For example, if the event is determined to be a system-on-a-chip (SoC) communication heartbeat interruption, the hierarchical storage control module assigns it a preset code, such as the hexadecimal value 0xA1. If the event is determined to be a diagnostic reset command received from an external diagnostic device, another preset code is assigned, such as 0xB2. If the event is determined to be that the SoC operating temperature exceeds the over-temperature protection threshold, the code 0xC3 is assigned.

[0072] In this way, every foreseeable SoC anomaly event captured in the second-level identification mechanism is converted into an independent, unique, and minimally sized digital code. This digital code is then passed to the next step for persistent storage.

[0073] After the hierarchical storage control module obtains the digital code representing the reason for the reset, and before performing any actual operation that causes the system-on-a-chip (SoC) to reset (e.g., cutting off its power or sending a reset signal), the hierarchical storage control module initiates the persistent storage process of the data.

[0074] The hierarchical storage control module calls the application programming interface (API) provided by the non-volatile memory driver running on the microcontroller MCU.

[0075] Through the application programming interface, digital codes are written into pre-allocated data blocks within the non-volatile flash memory DFLASH, which are dedicated to storing historical fault causes.

[0076] Non-volatile flash memory (DFLASH) was chosen as the storage medium because of its physical characteristic that data is not lost after the controller is powered off. This ensures that the reset reason code can still be retained and read even after the cockpit domain controller has undergone a complete power cycle.

[0077] After the cockpit domain controller experiences an abnormal event recorded by the second-level identification mechanism and restarts, the information output and reporting module is activated in the microcontroller MCU initialization program.

[0078] The information output and reporting module first calls the application programming interface of the non-volatile memory driver to read the previously stored historical fault cause codes from the predefined data blocks of the non-volatile flash memory (DFLASH).

[0079] The information output and reporting module performs validity checks on the read code. In one embodiment, the verification method is to check whether the code value is a non-preset default value (e.g., not 0xFF). If the verification passes, it is confirmed that a valid historical fault record exists.

[0080] After confirming the existence of a valid record, the information output and reporting module converts the numerical code into a log message body containing a predefined text description. For example, the code 0xA1 is converted into the string "Historical Reset:SoCHeartbeat Lost". Subsequently, this message body is combined with the current absolute timestamp and relative timestamp to form a complete log entry conforming to the format of the first-level identification mechanism.

[0081] The formatted log entry is submitted to the hierarchical storage control module. Once the system startup process continues and the communication link between the microcontroller (MCU) and the system-on-a-chip (SoC) is established, the log entry will be sent to the SoC via the serial peripheral interface (SPI) through the standard first-level identification mechanism and ultimately recorded in its log file. Alternatively, the log entry can also be output via the universal asynchronous transceiver (UART) interface.

[0082] After the historical fault cause code is successfully read and processed, the information output and reporting module will call the non-volatile memory driver to erase or overwrite the contents of the data block in the non-volatile flash memory (DFLASH) with a preset default value. This operation ensures that the historical fault event will not be reported repeatedly during subsequent system startups.

[0083] The following describes a fault identification method for internal errors occurring in a real-time operating system (OS) running on a microcontroller (MCU). The real-time operating system conforms to the AUTOSAR specification, which defines the ErrorHook function. When the operating system kernel detects a service rule violation or a fatal error, such as a protection error or illegal memory access, the operating system's execution flow is forcibly transferred to this ErrorHook function.

[0084] The embodiments of the present invention extend the specific implementation of the ErrorHook function. Within the execution body of this function, the address value of the program counter (PC) at the time of the error is first extracted from the exception context that triggered the error. This address value points to the machine instruction that caused the operating system error.

[0085] Subsequently, the extracted program counter address value is stored in a pre-defined physical address area in the reset hold random access memory (RRAM) inside the microcontroller MCU through one or more direct memory write operations.

[0086] Within the same ErrorHook function, the identifier of the current task is obtained by reading specific data structures related to the current task in the operating system kernel, and the execution context of the current task is parsed to obtain multiple return addresses in the function call stack. Furthermore, the power supply voltage sampling values ​​of preset key hardware modules are read by directly accessing the data registers of the analog-to-digital converter (ADC).

[0087] Finally, the task identifier, function call stack address sequence, and voltage sample value, along with the program counter address value, are stored in other corresponding preset areas of the Reset Hold Random Access Memory (RRAM) via a direct memory write operation.

[0088] Direct memory write operations do not invoke any operating system services, nor do they rely on any peripheral driver application programming interfaces. The operation is compiled into low-level store instructions that directly assign values ​​to the target memory address.

[0089] The use of Reset-Retaining Random Access Memory (RRAM) as the storage medium leverages its physical characteristic that the data stored within the microcontroller (MCU) remains unchanged after a reset. Furthermore, the timing of write operations to RRAM is identical to that of write operations to ordinary Static Random Access Memory (SRAM), ensuring data storage can be completed within the extremely short time window before the system completely fails. This method allows the MCU to recover the instruction address that caused the error from RRAM during subsequent startup even if it is reset due to a fatal operating system error.

[0090] Figure 4 This is a flowchart illustrating the fault handling process of the third-level identification mechanism in this embodiment of the invention.

[0091] like Figure 4 As shown, the third-level identification mechanism is further used to handle fault scenarios where the microcontroller MCU experiences software execution flow deadlock (e.g., getting stuck in an infinite loop or deadlock).

[0092] This method utilizes an external watchdog timer (WDG) to detect software freezes. During normal operation, software tasks on the microcontroller (MCU) must periodically drive the WDI signal connected to the external watchdog timer (WDG) at intervals shorter than the WDG's preset timeout period. If the MCU's software execution flow freezes, this periodic driving operation will cease.

[0093] The timeout signal output of the external watchdog timer (WDG) is connected to the non-maskable interrupt (NMI) input pin of the microcontroller (MCU). When the external watchdog timer times out due to not receiving a periodic WDI signal, it will first generate a level transition at this output pin, thereby triggering the non-maskable interrupt of the microcontroller (MCU).

[0094] The FailTrace software component in this embodiment includes an interrupt service routine (NMI ISR) specifically for handling the non-maskable interrupt. When an NMI is triggered, the microcontroller's (MCU) processor hardware automatically pushes the currently interrupted execution context (including the program counter (PC) value of the code location that caused the software freeze) onto the stack of the current task and forces a jump to execute the NMI interrupt service routine.

[0095] Within this NMI interrupt service routine, the FailTrace component executes a predefined, minimal sequence of instructions. This sequence begins by reading the program counter (PC) value, which is automatically saved by the processor hardware, from the memory location indicated by the current stack pointer.

[0096] Subsequently, the FailTrace component stores the acquired program counter (PC) value into a specific address region pre-allocated within the Reset Hold Random Access Memory (RRAM) for recording NMI events via a single direct memory write operation. This operation is independent of any operating system service.

[0097] Simultaneously, within the NMI interrupt service routine, the FailTrace component parses and retrieves the current task identifier and function call stack information from the interrupted execution context. Furthermore, this component reads the real-time voltage values ​​of critical power rails by directly accessing the relevant data registers of the analog-to-digital converter (ADC). In addition, the FailTrace component also reads the internally maintained counter values ​​used to monitor the watchdog status of each processor core.

[0098] Finally, the acquired task identifiers, function call stack information, voltage values, and dog feed status count values, along with the program counter (PC) value, are stored in the corresponding preset addresses of the reset hold random access memory (RRAM) via direct memory write operations.

[0099] The external watchdog timer (WDG) is designed so that, after triggering a non-maskable interrupt signal, its other output drives the RESET signal connected to the microcontroller (MCU) after a very short delay, thus performing a hardware reset on the entire MCU. This design ensures that the MCU will be reset after the program counter (PC) value is successfully written to the RRAM, thereby recovering the system from a completely frozen state.

[0100] Figure 5 This is a flowchart illustrating the reporting process of historical fault information after reset in an embodiment of the present invention.

[0101] like Figure 5 As shown, after capturing and storing fault-related data through the above multi-level identification mechanism, the present invention also includes a method for integrating and analyzing these data to achieve accurate fault location.

[0102] After the microcontroller (MCU) undergoes a reset and restart triggered by an operating system error or an external watchdog timeout, the information output and reporting module in its initialization program is executed. This information output and reporting module first accesses a preset address area in the reset hold random access memory (RRAM) and reads the address value of the program counter (PC) at the time of the fault, which is stored by the third-level identification mechanism.

[0103] The information output and reporting module performs a validity check on the address value, such as checking whether it is an invalid value that is not preset (e.g., all 0s or all Fs). After confirming that a valid program counter address has been obtained, the information output and reporting module formats the address value into a log message body with a specific format, such as "MCU Reset from NMI, Last PC:0x..." or "MCU Reset from OS Error, Last PC:0x...".

[0104] Furthermore, the information output and reporting module also reads additional fault context information stored together by the third-level identification mechanism from other preset address areas of the reset hold random access memory (RRAM), such as the task identifier, function call stack address sequence, critical power rail voltage value, and dog feed status count value.

[0105] The information output and reporting module organizes and concatenates these additional fault context information, along with the program counter address, into one or more detailed and readable log message bodies.

[0106] The log message body is then combined with the current absolute and relative timestamps to form a complete log entry. This log entry is submitted to the hierarchical storage control module and, ultimately, after the system-on-chip (SoC) communication link is established, is stored in the SoC's log file through the first-level identification mechanism. Simultaneously, the information output and reporting module clears the contents of this address area in RRAM to prevent duplicate reporting.

[0107] Using the methods described above, all fault-related information captured by the first, second, and third-level identification mechanisms is uniformly integrated into a single log file on the System-on-Chips (SoC). This log file, arranged chronologically, comprehensively records key state changes during normal system operation, the historical causes of SoC anomalies, and the points where fatal MCU errors occurred.

[0108] During fault analysis, analysts export this unified log file from the cockpit domain controller. When they find an entry in this log file that records the program counter (PC) address, they compare that address value with the linker mapping file (.map file) generated when compiling the corresponding software version. The linker mapping file records in detail the specific address range of each software function and variable in the program's memory.

[0109] By locating the program counter address in the mapping file, analysts can directly pinpoint the specific function or even the line of source code that caused the MCU reset, thereby improving the efficiency and accuracy of fault diagnosis.

[0110] Figure 6 This is a flowchart of offline fault analysis and location in an embodiment of the present invention.

[0111] like Figure 6 As shown, the above method enables unified recording of fault-related data, which is then used to locate the root cause of the fault.

[0112] When performing offline fault analysis, analysts need two key inputs: one is a unified log file exported from the System-on-a-Chip (SoC) that contains information recorded by all levels of identification mechanisms; the other is a linker mapping file (.map file) that corresponds exactly to the software version running on the microcontroller (MCU) at the time of the fault. This mapping file is a standard output of the software compilation and linking process.

[0113] Analysts first searched the unified log file for log entries containing the phrase "LastPC" recorded by the information output and reporting module. From these log entries, the analysts extracted the hexadecimal address value of the program counter (PC) that caused the microcontroller (MCU) to reset.

[0114] The analysts then searched the linker mapping file. The linker mapping file, in text format, details the names of all functions, global variables, and other symbols in the software version, along with their exact starting addresses and the number of bytes they occupy in program memory.

[0115] By comparing the data, analysts searched for a function in the linker mapping file such that the program counter address value extracted from the log fell within the memory address range of that function. The goal of this search process was to find a function... Make it satisfy the following conditions:

[0116] ;

[0117] in, This represents the address value of the program counter extracted from the log; This represents functions in the linker mapping file; This represents the starting address of function F in the memory address space; This indicates the amount of memory occupied by the code of function F.

[0118] To achieve more precise location, analysts can load the program counter address into a disassembler or debugger corresponding to the software version. This tool can then directly map the address to a specific machine instruction and further associate it with its specific line number in the high-level language source code.

[0119] This method allows a transient software error that occurs during runtime and causes serious system failure to be precisely traced back to its root cause at the source code level, thereby shortening the debugging cycle of difficult problems and providing a direct and reliable basis for software repair and quality improvement.

[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cockpit domain controller fault identification device, wherein the cockpit domain controller includes a microcontroller and a system-on-a-chip, the microcontroller integrating non-volatile flash memory and reset-hold random access memory, characterized in that, The fault identification device includes: The information acquisition module is used to collect key information related to fault identification; A hierarchical storage control module is used to determine the real-time operating status of the cockpit domain controller based on preset judgment conditions, including: The normal operating status of the cockpit domain controller is determined by whether the communication link with the system-on-a-chip is active. The abnormal state of the system-on-a-chip is determined based on the communication interruption, received reset command, or hardware status abnormality of the system-on-a-chip. The abnormal state of the microcontroller is determined based on an internal error occurring in the real-time operating system or a software execution flow freeze. The hierarchical storage control module is also used for: During normal operation of the cockpit domain controller, the key information is output to the system-on-a-chip. In the abnormal state of the system-on-a-chip, the critical information is written into the non-volatile flash memory; In the abnormal state of the microcontroller, the key information is written into the reset hold random access memory; The information output and reporting module is used to check and read the historical fault information stored in the non-volatile flash memory and the reset hold random access memory after the microcontroller is reset, and output the historical fault information.

2. The cockpit domain controller fault identification device according to claim 1, characterized in that, When the system-on-a-chip is determined to be in an abnormal state, the hierarchical storage control module is used to: According to a predefined reset reason code table, the specific reasons that cause the abnormal state of the system-on-a-chip are identified and encoded into digital codes; Before performing a reset operation on the system-on-a-chip, the digital code is written as the key information into the non-volatile flash memory.

3. The cockpit domain controller fault identification device according to claim 1, characterized in that, When an internal error occurs in the real-time operating system and is determined to be an abnormal state of the microcontroller, the hierarchical storage control module extracts the address value of the program counter at the time of the error through the ErrorHook hook function of the real-time operating system, and writes the address value of the program counter at the time of the error as the key information into the reset hold random access memory.

4. The cockpit domain controller fault identification device according to claim 3, characterized in that, The hierarchical storage control module stores the address value of the program counter when an error occurs to the reset hold random access memory via a direct memory write operation.

5. A cockpit domain controller fault identification device according to claim 3, characterized in that, When the software execution flow is determined to be stuck as an abnormal state of the microcontroller, an unmasked interrupt is triggered by an external watchdog timer. The hierarchical storage control module reads the address value of the interrupted program counter from the stack within the interrupt service routine of the unmasked interrupt, and writes the address value of the interrupted program counter as the key information into the reset hold random access memory.

6. The cockpit domain controller fault identification device according to claim 1, characterized in that, The information output and reporting module is also used for: The read historical fault information is formatted into log entries containing timestamps; After the microcontroller establishes communication with the system-on-a-chip, the log entries are sent to the system-on-a-chip for unified recording.

7. A cockpit domain controller fault identification device according to claim 1, characterized in that, The key information collected by the information collection module is formatted into log entries, which include: Absolute timestamp derived from a real-time clock; The relative timestamp originates from the internal timer of the microcontroller; And the main body of the message.

8. A cockpit domain controller fault identification device according to claim 1, characterized in that, The hierarchical storage control module, under normal operating conditions of the cockpit domain controller, is used to send the critical information to the system-on-a-chip via a serial peripheral interface. The software service running on the system-on-a-chip receives the critical information and writes it to the file system.

9. A cockpit domain controller fault identification device according to claim 5, characterized in that, The information output and the program counter address value when the error occurred or the interrupted program counter address value output by the reporting module are compared with the linker mapping file corresponding to the software version of the microcontroller to determine the function that caused the microcontroller to malfunction.

10. A cockpit domain controller fault identification method, applied to a cockpit domain controller including a microcontroller and a system-on-a-chip, wherein the microcontroller integrates non-volatile flash memory and reset-hold random access memory, characterized in that, Includes the following steps: S1. Collect key information related to fault identification; S2. Determine the normal operating status of the cockpit domain controller based on whether the communication link with the system-on-a-chip is active; determine the abnormal status of the system-on-a-chip based on the communication interruption, received reset command, or abnormal hardware status of the system-on-a-chip; and determine the abnormal status of the microcontroller based on the internal error of the real-time operating system or the software execution flow being stuck. S3. When it is determined that the cockpit domain controller is in normal operating condition, the key information is output to the system-on-a-chip; when it is determined that the system-on-a-chip is in an abnormal state, the key information is written to the non-volatile flash memory. When the microcontroller is determined to be in an abnormal state, the key information is written into the reset hold random access memory. S4. After the microcontroller is reset, check and read the historical fault information stored in the non-volatile flash memory and the reset hold random access memory, and output the historical fault information.

Images