Method of recording power down and reset paths for an embedded controller, embedded controller, and vehicle
By recording the power-down or reset path identifier in the non-volatile storage area of the embedded controller and overwriting the diagnostic identifier after power-on, the problem of inaccurate path recording in the prior art is solved, enabling accurate traceability and anomaly judgment of the controller status, and improving the reliability and maintainability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ELECTRIC VEHICLE
- Filing Date
- 2026-03-11
- Publication Date
- 2026-06-02
AI Technical Summary
Existing technologies cannot accurately record the power-down or reset path of embedded controllers, making it difficult to distinguish between normal processes and abnormal power outages. This results in isolated diagnostic information, affecting system reliability and maintainability.
The power-down or reset path identifier is recorded in the non-volatile memory area of the embedded controller. After power-on, the diagnostic identifier is read and overwritten. The previous state is determined by the path identifier, and the fault identifier is output through the communication bus.
It enables accurate recording of power-down or reset paths and reliable judgment of abnormal power failures, improving system reliability and maintainability, supporting remote diagnostics and big data analysis, and reducing R&D and after-sales maintenance costs.
Smart Images
Figure CN122131677A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of vehicle control technology, and more specifically, relates to a method for recording the power-down and reset paths of an embedded controller, the embedded controller, and a vehicle. Background Technology
[0002] Embedded controllers, especially those in the automotive field, are the core control units of a vehicle's electronic and electrical systems. Their reliability and stability directly impact the vehicle's functional safety and user experience. In modern automobiles, a controller often needs to operate under various conditions, such as normal driving, power-off upon engine shutdown, emergency fault handling, and low-power sleep / wake-up. Correspondingly, when exiting an operational state, the controller may also follow different power-down or reset procedures. For example, during normal engine shutdown, the controller needs to systematically save data, shut down peripheral devices, and then enter a low-power state; while in the event of a serious fault, an emergency reset or a hardware watchdog-triggered reset may be required, in which case the process is more direct.
[0003] Currently, the industry typically relies on built-in status registers, watchdog reset flags, or simple log entries to trace the causes of controller power-down or reset. These methods can answer questions like "Did the controller reset?" or "What was the reset source?" to some extent, but they have significant limitations: 1. Inability to distinguish specific paths: Existing technologies struggle to accurately record which preset software process path is executed within the same type of reset (e.g., watchdog reset) or power-down (e.g., hibernation). Different paths may correspond to different data retention strategies, peripheral shutdown sequences, and delays. Errors in path execution can lead to potential problems such as corruption of non-volatile data, abnormal peripheral states, or power management failures.
[0004] 2. Difficulty in diagnosing abnormal power outages: When the controller powers down unexpectedly due to an external power failure (such as a power outage) instead of following the expected procedure, existing status flags are often unable to effectively distinguish between this "unexpected power outage" and a "normal power outage." This makes it difficult to determine whether a data anomaly is caused by a process error or purely by external power interference during R&D testing or after-sales diagnostics.
[0005] 3. Isolated diagnostic information: Traditional reset flags or logs are usually stored locally on the controller, lacking a standardized mechanism that can be easily acquired and analyzed in real time by upper-level diagnostic systems (such as vehicle fault diagnostic tools or remote monitoring platforms), which is not conducive to the systematic tracking and prevention of power management problems throughout the vehicle's entire life cycle.
[0006] Therefore, there is an urgent need for a method that can accurately record the specific power-down and reset paths of the embedded controller, reliably distinguish between normal processes and abnormal power outages, and support diagnostic information reporting, in order to improve system reliability, accelerate problem troubleshooting, and enhance vehicle maintainability. This invention addresses this technical problem. Summary of the Invention
[0007] The purpose of this invention is to propose a method, an embedded controller, and a vehicle for recording the power-down and reset paths of an embedded controller. This invention addresses the shortcomings of existing technologies, such as the inability to accurately record the specific power-down or reset paths of embedded controllers and the difficulty in reliably distinguishing between normal process execution and abnormal power failure, which makes it difficult to trace and diagnose problems. The invention achieves accurate recording of each power-down / reset path and reliable judgment of abnormal power failures, significantly improving system reliability and maintainability, and providing support for remote diagnostics and big data analysis, all without incurring additional hardware costs.
[0008] To achieve the above objectives, in a first aspect, the present invention proposes a method for recording the power-down and reset paths of an embedded controller, comprising: When the embedded controller executes any preset power-down or reset procedure, before the procedure ends, the path identifier representing the procedure is written into the non-volatile memory area of the embedded controller. After the embedded controller is powered on, the stored path identifier is read from the non-volatile memory area and assigned to a path flag. Immediately write the preset diagnostic identifier to the non-volatile storage area to overwrite the path identifier; Based on the value of the path flag, determine the state of the previous power-down or reset, and set the corresponding fault flag; Output the path flag and the fault flag.
[0009] Optionally, determining the previous power-down or reset state based on the value of the path flag includes: If the value of the path flag is the path identifier corresponding to the power-down or reset procedure, then the previous power-down or reset procedure is determined to be normal.
[0010] Optionally, determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path flag is the diagnostic identifier, then the previous power-down or reset process is determined to be an abnormal power-down or reset.
[0011] Optionally, determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path flag is the initial default value of the non-volatile memory area, then the embedded controller is determined to be powered on for the first time.
[0012] Optionally, determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path identifier cannot be identified, it is determined that the non-volatile storage area is damaged or that the program reading the path identifier stored in the non-volatile storage area is abnormal.
[0013] Optionally, the predetermined power-down or reset procedure includes at least two different power-down paths and at least one reset path, each path corresponding to a unique path identifier.
[0014] Optionally, the non-volatile storage area is the Flash memory or EEPROM inside the embedded controller.
[0015] Optionally, the path flag and the fault flag can be output via the vehicle communication bus.
[0016] In a second aspect, the present invention provides an embedded controller, including a processor and a non-volatile memory, wherein the processor is configured to perform a method for recording the power-down and reset paths of the embedded controller as described in any one of the first aspects.
[0017] Thirdly, the present invention provides a vehicle including an embedded controller as described in the second aspect.
[0018] The beneficial effects of this invention are as follows: By writing the corresponding path identifier into the non-volatile memory area before the embedded controller's preset power-down or reset process ends, reading the identifier after power-on and immediately overwriting it with a diagnostic identifier, and then judging the previous power-down or reset state based on the identifier and outputting relevant flags, the specific path of each power-down or reset and whether it was executed normally can be accurately traced, effectively solving the problem that traditional methods are difficult to troubleshoot power-down or reset anomalies. This design can quickly locate process design defects during the R&D stage and efficiently lock the root cause of the fault in the after-sales stage, avoiding serious problems such as non-volatile data writing errors, hardware damage, and data loss, reducing the risk of vehicle recalls, lowering R&D and after-sales maintenance costs, and significantly improving the traceability and maintainability of the power-down / reset process. At the same time, the identifier writing and overwriting mechanism of the non-volatile memory area ensures the accuracy and uniqueness of the state judgment, providing a reliable basis for monitoring the controller's operating status, improving the operational stability and product reliability of the vehicle-mounted embedded controller, and enhancing the product's competitiveness in the market. In addition, by outputting status information through the bus, remote diagnostics and big data analysis are supported without increasing additional hardware costs, making it easy to integrate and implement in existing embedded systems.
[0019] The system of the present invention has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description
[0020] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.
[0021] Figure 1 A flowchart illustrating the steps of a method for recording the power-down and reset paths of an embedded controller according to the present invention is shown.
[0022] Figure 2 A schematic flowchart of the power-down section according to Embodiment 1 of the present invention is shown.
[0023] Figure 3 A schematic flowchart of the power-on section according to Embodiment 1 of the present invention is shown. Detailed Implementation
[0024] The invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
[0025] like Figure 1 As shown, a method for recording the power-down and reset paths of an embedded controller according to the present invention includes: When the embedded controller executes any preset power-down or reset procedure, before the procedure ends, the path identifier representing the procedure is written to the non-volatile memory area of the embedded controller. After the embedded controller is powered on, the stored path identifier is read from the non-volatile memory area and assigned to a path flag. Immediately write the preset diagnostic identifier to the non-volatile storage area to overwrite the path identifier; Based on the value of the path flag, determine the state of the last power-down or reset, and set the corresponding fault flag; Output path flags and fault flags.
[0026] Specifically, the implementation process of this method is divided into a recording stage when power is off or reset, and a diagnosis and reporting stage after power is turned on again, which together constitute a complete state tracking closed loop.
[0027] During the power-down or reset recording phase, when the embedded controller needs to execute any predefined power-down procedure (such as normal sleep power-down or emergency power-down) or reset procedure (such as watchdog reset or software instruction reset), it will write a unique path identifier corresponding to that procedure (for example, a specific value S1_N represents the normal power-down path, and R1_N represents the watchdog reset path) to a non-volatile memory area (such as Flash or EEPROM) inside the controller at the instant after all the necessary operations of that specific procedure are completed and before the final power is cut off or the reset operation is triggered. This is to permanently save the critical information of "how to power off or reset", so that the information will not be lost even if the embedded controller is completely powered off.
[0028] Upon entering the power-on diagnostic phase, after the embedded controller powers on again, it first reads the previously saved path identifier from the non-volatile memory area and loads it into a temporary variable (called path flag F1) for processing. Immediately after reading, a preset diagnostic flag (E1_N) is written to the same non-volatile memory area, overwriting the original path identifier. This overwrite operation is crucial; it essentially timestamps the power-on event as "processed."
[0029] Subsequently, the value stored in the path flag F1 is analyzed and judged: if the value is a predictable power-down or reset path identifier (such as S1_N), it indicates that the embedded controller was normally shut down or reset according to the predetermined procedure last time; if the value is the diagnostic flag E1_N itself, it indicates that the embedded controller experienced an unexpected abnormal power-down last time (because in the normal procedure, this diagnostic flag would be overwritten by the path identifier); if it is the initial default value of the non-volatile memory area, it indicates that the embedded controller is being powered on for the first time; if it is another unrecognizable value, it indicates that there may be a fault in the non-volatile memory area or the logic for reading the non-volatile memory area. Based on this judgment result, a corresponding fault flag ER is set to record the diagnosis conclusion in coded form. For example, if the previous power-down or reset was normal, the fault flag ER=SU_1 is set; if the previous power-down or reset was abnormal, the fault flag ER=ER_1 is set; if the embedded controller is being used for the first time, the fault flag ER=SU_2 is set; if it is another unrecognizable value, the fault flag ER=ER_2 is set.
[0030] Finally, the path flag F1, containing specific path information, and the fault flag ER, representing the diagnostic conclusion, are sent out via the communication bus (such as the CAN bus) on the embedded controller. This allows external diagnostic equipment or upper-level monitoring systems to obtain the cause and nature of the embedded controller's previous operating state termination in real time and accurately, providing a solid data foundation for accurate fault diagnosis, performance analysis, and preventive maintenance.
[0031] In one example, determining the previous power-down or reset state based on the path flag value includes: If the value of the path flag is the path identifier corresponding to the power-down or reset procedure, then the previous power-down or reset procedure is considered to be normal.
[0032] Specifically, if the value of the path flag matches the path identifier corresponding to a specific preset power-down or reset procedure (e.g., S1_N for normal sleep power-down, S2_N for emergency power-down, or R1_N for watchdog reset), then the previous power-down or reset procedure of the embedded controller is determined to have been executed normally. The core logic of this judgment is to verify whether the controller strictly follows the predetermined software path to complete its state exit process. Each preset path identifier is a unique "identity code" assigned to a specific procedure during the design phase. When the embedded controller executes along the expected path, it writes this code to the non-volatile memory area at the end of the procedure. Therefore, when the path flag read after power-on is exactly equal to a certain expected "identity code", a conclusive chain of evidence is formed: proving that at the end of the previous working cycle, the controller successfully identified the specific working condition, completely executed the predetermined procedure that matched it and included all necessary operations (such as data saving, orderly shutdown of peripherals, etc.), and finally completed the power-down or reset under controlled conditions. This determination provides a reliable basis for subsequent advanced diagnostics and analysis, confirming the compliance and integrity of the process execution.
[0033] In one example, determining the previous power-down or reset state based on the path flag value also includes: If the path flag value is a diagnostic flag, then the previous power-down or reset process is determined to be an abnormal power-down or reset.
[0034] Specifically, if the path flag value is a preset diagnostic identifier, it clearly indicates that the embedded controller experienced an unexpected abnormal power-down or reset in the previous operation. The core basis for this judgment lies in the preset logical sequence and data overwrite relationship within the entire recording and diagnostic mechanism: the diagnostic identifier is designed to be written to and overwrites the original data in the non-volatile memory area immediately after reading the contents during the power-on initialization phase, effectively timestamping the "power-on event." Therefore, in a normal power-down or reset process, the embedded controller will overwrite the contents of the non-volatile memory area with the corresponding path flag (such as S1_N, R1_N) at the end of the process. If, upon the next power-on, the non-volatile memory area still reads the diagnostic identifier, the only reasonable explanation is that the embedded controller, after the end of the previous working cycle, did not execute any preset normal power-down or reset process that included writing the path flag. Instead, due to an unexpected interruption of external power, a serious hardware failure, or a software crash leading to a forced reset, it directly lost its operating voltage or experienced an uncontrolled reset. In this scenario, the embedded controller, due to a sudden power outage or loss of control, is unable to execute any pre-defined process steps. The contents of the non-volatile memory area, which have remained unchanged since the diagnostic flag was written during the last power-on, preserve evidence of this "abnormal state." This determination clearly reveals an unplanned power event and is a crucial basis for diagnosing unexpected restarts, troubleshooting hardware power problems, or fatal software errors.
[0035] In one example, determining the previous power-down or reset state based on the path flag value also includes: If the path flag value is the initial default value of the non-volatile memory area, then the embedded controller is determined to be powered on for the first time.
[0036] Specifically, if the path flag value is the initial default value of the non-volatile memory area (e.g., a specific value D1_N in the factory default state), then the embedded controller is determined to be in the first power-on phase of its lifecycle. This determination is based on the data lifecycle characteristics of the non-volatile memory area: before the embedded controller is manufactured and before any user program writes to it, its contents are in a known, preset initial state (i.e., the initial default value). In this method, whether the path flag is written during normal power-down / reset or during power-on diagnostics, any non-first normal operation will overwrite this initial value. Therefore, when the path flag read after power-on still remains at the initial default value, a clear logical inference is formed: since the embedded controller was manufactured, its non-volatile memory area has never been written with any valid flag by the recording mechanism of this method. This uniquely means that the current power-on event is the first power-on startup of the embedded controller after applying this method, and no power-down or reset procedures requiring recording have been executed previously. This determination is crucial for initial operating condition identification, activating the first-run configuration or calibration process, and distinguishing between the status of "new controller" and "used controller," ensuring proper initialization during the initial lifecycle phase and the establishment of subsequent diagnostic benchmarks.
[0037] In one example, determining the previous power-down or reset state based on the path flag value also includes: If the value of the path identifier cannot be recognized, it is determined that the non-volatile memory area is damaged or that the program reading the path identifier stored in the non-volatile memory area is abnormal.
[0038] Specifically, if the value of the path flag does not belong to any preset known valid value (i.e., it is not the path flag corresponding to any power-down or reset process, not the diagnostic flag, nor the initial default value of the non-volatile memory area), then it is determined that there is a low-level hardware or basic software fault, which specifically points to two possibilities: physical damage to the non-volatile memory area, or an abnormality in the program module responsible for reading data from the non-volatile memory area.
[0039] This judgment serves as the ultimate safety guarantee and fault isolation mechanism in the diagnostic logic. Its technical basis lies in the fact that, in a correctly designed and normally functioning system, the data contained in non-volatile memory after any operating cycle should be strictly limited to a predefined, finite set of values. These values are explicitly specified by the designer and correspond to all expected states such as "normal path completion," "abnormal power failure," and "initial power-on." Therefore, when a value is read that is "unrecognizable" or "outside the expected set," it directly violates the core data contract of the design. This typically means: Physical failure of storage media: Non-volatile storage cells (such as Flash or EEPROM) may experience bit flips, data retention failure, or complete damage due to lifespan, voltage surges, environmental stress, etc., causing the stored values to change spontaneously without being written correctly, or errors to occur during reading.
[0040] Data bus or read / write logic error: During the reading process, the address or data bus is interfered with, or there are defects in the read / write control timing or driver, resulting in the transmitted or parsed data not matching the actual stored content.
[0041] Illegal write or software crash: At an unexpected moment, an illegal write operation to the memory area is performed by an incorrect program pointer or a disturbed CPU, which corrupts the original valid data.
[0042] Once this determination is made, a corresponding critical fault flag will be set. This indicates that the system has detected an unreliable underlying state, and its recorded path information is no longer trustworthy. This determination is crucial for triggering the highest level of failsafe policies. For example, it can prevent the system from relying on potentially corrupted storage data for critical decisions, activate backup storage areas, or report explicit hardware fault codes through diagnostic interfaces, thereby guiding maintenance personnel to directly inspect the storage hardware or refresh the underlying software, effectively preventing systemic misjudgments or functional failures caused by underlying, hidden faults.
[0043] In one example, the predetermined power-down or reset procedure includes at least two different power-down paths and at least one reset path, each path corresponding to a unique path identifier.
[0044] Specifically, in the complex embedded systems addressed by this solution, especially in automotive controllers, power management and system state management are not singular. The system pre-designs and defines diverse state exit procedures based on different triggering conditions, operating conditions, or safety requirements. Specifically, the predetermined procedures must include at least two different power-down paths and at least one reset path.
[0045] The diversity of power-down paths stems from different operational scenarios. For example, the first power-down path might correspond to "normal hibernation power-down," which involves saving all user settings, writing critical data to non-volatile memory, orderly shutting down sensors and communication peripherals, and finally switching to low-power mode. The second power-down path might correspond to "emergency power-down" or "rapid hibernation," typically triggered when an emergency event is detected or when a very short time is needed to enter hibernation. This path might omit saving some non-critical data to shut down the power domain more quickly. These two paths differ fundamentally in their operational timing, the completeness of the tasks performed, and power consumption targets.
[0046] The reset path is also necessary. For example, a typical reset path may be triggered by a "watchdog timer overflow". This path will perform hardware initialization, critical state recovery and other operations, but the process is completely different from the power-down path.
[0047] The key is that each such predetermined path is assigned a globally unique path identifier (such as S1_N, S2_N, R1_N). This unique identifier is the fundamental basis for the system to logically distinguish different processes. During runtime, the controller selects the corresponding predetermined path to execute by judging the specific trigger source and context, and writes the unique identifier bound to it to the non-volatile storage area at the final stage of that path. This design enables the system to not only record "a power-down or reset occurred," but also to accurately record "which specific, preset rule was followed," providing a more granular and valuable data foundation for subsequent advanced diagnostics, performance analysis, and functional safety audits. It is the core design for achieving accurate state management and fault tracing.
[0048] In one example, the non-volatile memory is the Flash memory or EEPROM inside the embedded controller.
[0049] Specifically, the non-volatile storage area is implemented as a non-volatile semiconductor memory inside the embedded controller, typically and preferably Flash memory or EEPROM (Electrically Erasable Programmable Read-Only Memory). These two types of memory are core components of embedded systems, and are called "non-volatile" because they can retain data for a long time without loss after a complete power outage. In this invention, this storage area is dedicated to persistently saving critical status indicators at the critical moment when the controller is powered down or reset.
[0050] Flash memory is renowned for its high density, low cost, and large capacity, and is widely used for storing program code. In some implementations of this invention, a small portion of its sectors can be allocated as a data storage area. Write operations are typically performed in units of "pages," requiring erasure before writing. Although its write speed is relatively slow and its erase / write cycles are limited (typically in the range of hundreds of thousands to millions), its lifespan and performance are perfectly adequate for recording low-frequency, high-importance events such as power / reset paths.
[0051] EEPROM supports byte-level reading and writing, eliminating the need for large-block erase operations like Flash memory. Therefore, it is more flexible and efficient in scenarios involving frequent modifications of small amounts of data. Its write endurance is typically comparable to or slightly higher than that of Flash memory. For systems requiring more precise and rapid write path identification, EEPROM is an ideal choice.
[0052] The choice between these two depends on the specific embedded controller's hardware resources, storage architecture, write speed requirements, and cost considerations. Regardless of the choice, the core function remains the same: to provide a reliable, persistent, and controller-built-in memory unit that ensures the recorded path identifiers can still be accurately read after a complete power outage, thus providing a trustworthy data source for subsequent power-on diagnostics. This design avoids reliance on external storage devices, enhancing system integration and reliability.
[0053] In one example, path flags and fault flags are output via the vehicle communication bus.
[0054] Specifically, the final step of this invention is to output and report the generated path markers and fault markers via the vehicle communication bus. This step is crucial for achieving a closed-loop diagnostic information system and improving system observability and maintainability.
[0055] After assigning values to the path flag and fault flag, the embedded controller encapsulates these two data points into a specific diagnostic message or data frame according to the communication protocol agreed upon by the vehicle network (such as CAN, LIN, FlexRay, or automotive Ethernet protocol). Subsequently, the controller uses its integrated bus transceiver to drive the message to the corresponding physical bus for broadcasting.
[0056] This output mechanism brings the following core value: 1. Enables remote and centralized diagnostics: Other controllers on the bus (such as gateways and smart cockpit domain controllers) or dedicated diagnostic tools can receive and parse these flags in real time. This allows engineers or cloud platforms to remotely and non-intrusively obtain detailed power-on history and health status of the controller during vehicle R&D testing, production line final inspection, after-sales service, and even daily user use, without needing to directly connect to the controller.
[0057] 2. Supports system-level analysis and traceability: Once the status flags of multiple controllers are collected in a unified manner, they can be analyzed and correlated. For example, by comparing the fault flags and timestamps reported by different controllers, it can help determine whether a vehicle-level fault originates from an independent anomaly of a certain controller or is caused by systemic reasons such as the power network.
[0058] 3. Empowering predictive maintenance and big data applications: The massive amounts of controller power-on status data collected continuously can be used to analyze the correlation between power-off / reset modes and hardware reliability and software quality, providing data support for product quality improvement, the formulation of predictive maintenance strategies, and the design of next-generation products.
[0059] Therefore, by outputting the flag through the vehicle communication bus, not only is the complete logical chain of "record-diagnosis-report" of this method completed, but the internal status information of a single controller is also transformed into a digital asset that can be shared and analyzed within the vehicle network, greatly enhancing the transparency and manageability of the entire electronic and electrical system.
[0060] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the invention. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present invention can be combined with each other.
[0061] Example 1
[0062] This embodiment provides a method for recording the power-down and reset paths of an embedded controller, including: This method has two parts: a power-down section and a power-on section. The power-down section is used to record the power-down and reset paths, while the power-on section is used to check whether the previous power-down path was normal.
[0063] like Figure 2 As shown, in the power-down section, there are two power-down paths and one reset path, S1, S2, and R1, respectively. There is also a non-volatile data storage area, N1, used to store the identifiers of the power-down paths. The term "non-volatile data storage area" means that data written to this area will not be lost after the controller is powered down, and the written data can still be read after power-up. If the non-volatile data storage area N1 has not been used, the default value of the data in N1 is D1_N. When powering down via power-down path S1, the corresponding path identifier S1_N is written to the non-volatile data storage area N1 before power-down; similarly, when powering down via power-down path S2, the corresponding path identifier S2_N is written to the non-volatile data storage area N1 before power-down; and when resetting via reset path R1, the corresponding path identifier R1_N is written to the non-volatile data storage area N1 before reset. After the data is written to the non-volatile data storage area N1, a power-down or reset operation can be performed.
[0064] like Figure 3As shown, in the power-on section, after the embedded controller powers on, it sets a path flag F1 and a fault flag ER. Then, it reads the content written in the non-volatile data storage area N1 during the last power-off, copies it to the path flag F1, and immediately writes the diagnostic flag E1_N to the non-volatile data storage area N1. The value of this diagnostic flag E1_N is used to determine whether the controller has powered on or reset normally. If it has powered on or reset normally, the value in the non-volatile data storage area N1 will be overwritten with the path flag S1_N, path flag S2_N, or path flag R1_N before power-off or reset. If it has not powered on or reset normally, the value in the non-volatile data storage area N1 will still be the diagnostic flag E1_N after the next power-on. If the value in path flag F1 is path identifier S1_N, path identifier S2_N, or path identifier R1_N, it indicates that the previous power-down or reset was normal, and the fault flag ER=SU_1 is set. If the value in path flag F1 is diagnostic identifier E1_N, it indicates that the previous power-down or reset was abnormal, and the fault flag ER=ER_1 is set. If the value in path flag F1 is the initial default value D1_N, it indicates that the controller is being used for the first time, and the fault flag ER=SU_2 is set. If the value in path flag F1 is an unrecognizable value, that is, it is not any of the following values: path identifier S1_N, path identifier S2_N, path identifier R1_N, diagnostic identifier E1_N, or initial default value D1_N, then it indicates that the non-volatile data storage area N1 is damaged or that the program reading the non-volatile data storage area N1 has a bug, and the fault flag ER=ER_2 is set. After power-on, the values of path flag F1 and fault flag ER are sent out through the communication bus. Based on the received values of path flag F1 and fault flag ER, it can be determined whether the controller's previous power-down or reset was normal. If it was normal, it can also be determined which power-down or reset path it was and whether it is consistent with the expected path.
[0065] Example 2
[0066] This embodiment provides an embedded controller, including a processor and a non-volatile memory, wherein the processor is configured to perform a method for recording the power-down and reset paths of the embedded controller as described in Embodiment 1.
[0067] Example 3
[0068] This embodiment provides a vehicle including an embedded controller as described in Embodiment 2.
[0069] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.
Claims
1. A method for recording the power-down and reset paths of an embedded controller, characterized in that, include: When the embedded controller executes any preset power-down or reset procedure, before the procedure ends, the path identifier representing the procedure is written into the non-volatile memory area of the embedded controller. After the embedded controller is powered on, the stored path identifier is read from the non-volatile memory area and assigned to a path flag. Immediately write the preset diagnostic identifier to the non-volatile storage area to overwrite the path identifier; Based on the value of the path flag, determine the state of the previous power-down or reset, and set the corresponding fault flag; Output the path flag and the fault flag.
2. The method for recording the power-down and reset paths of an embedded controller according to claim 1, characterized in that, The step of determining the previous power-down or reset state based on the value of the path flag includes: If the value of the path flag is the path identifier corresponding to the power-down or reset procedure, then the previous power-down or reset procedure is determined to be normal.
3. The method for recording the power-down and reset paths of an embedded controller according to claim 2, characterized in that, The step of determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path flag is the diagnostic identifier, then the previous power-down or reset process is determined to be an abnormal power-down or reset.
4. The method for recording the power-down and reset paths of an embedded controller according to claim 3, characterized in that, The step of determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path flag is the initial default value of the non-volatile memory area, then the embedded controller is determined to be powered on for the first time.
5. The method for recording the power-down and reset paths of an embedded controller according to claim 1, characterized in that, The step of determining the previous power-down or reset state based on the value of the path flag further includes: If the value of the path identifier cannot be identified, it is determined that the non-volatile storage area is damaged or that the program reading the path identifier stored in the non-volatile storage area is abnormal.
6. The method for recording the power-down and reset paths of an embedded controller according to claim 1, characterized in that, The predetermined power-down or reset procedure includes at least two different power-down paths and at least one reset path, with each path corresponding to a unique path identifier.
7. The method for recording the power-down and reset paths of an embedded controller according to claim 1, characterized in that, The non-volatile storage area is the Flash memory or EEPROM inside the embedded controller.
8. The method for recording the power-down and reset paths of an embedded controller according to claim 1, characterized in that, The path marker and the fault marker are output via the vehicle communication bus.
9. An embedded controller, characterized in that, It includes a processor and non-volatile memory, the processor being configured to perform a method for recording the power-down and reset paths of an embedded controller as described in any one of claims 1 to 8.
10. A vehicle, characterized in that, Including the embedded controller as described in claim 9.