Abnormal information acquisition method and embedded device

Abstract

The embodiment of the invention provides an abnormal information acquisition method and embedded equipment, the embedded equipment is applied to a vehicle, the embedded equipment comprises a controller, the controller comprises a first core, a second core and a first memory, and the method comprises the following steps: when the first core determines that an abnormality occurs in the operation process, acquiring corresponding abnormal information, writing the abnormal information into a first memory; and when determining that the abnormal information exists in the first memory, the second core reads the abnormal information, performs corresponding processing on the abnormal information to obtain target abnormal information, and generates an abnormal storage file according to the target abnormal information, so that a developer performs abnormal analysis processing according to the abnormal storage file. Therefore, when the controller of the embedded device of the vehicle is abnormal, the abnormal information can be obtained at the first time, so that a developer can perform abnormal analysis according to the abnormal information at the abnormal occurrence moment, and the accuracy of abnormal analysis is improved.

Description

Technical Field

[0001] This application relates to the field of exception handling technology, and in particular to an exception information acquisition method and an embedded device. Background Technology

[0002] For embedded devices in vehicles, whether in the testing phase or the actual use phase, it is usually necessary to obtain the exception information when an exception occurs so that developers can handle the exception based on the exception information. Exception handling includes exception location, exception problem investigation, exception cause determination and other exception analysis and handling, as well as exception repair.

[0003] Taking microcontrollers (MCUs) in embedded devices as an example, when anomalies occur in the controller's operating system or other components, developers often need to connect a debugger for anomaly analysis. However, this process typically involves developers accessing the debugger some time after the anomaly has occurred, only then obtaining anomaly information such as controller logs and performing anomaly analysis. This approach, where anomaly information is obtained and analyzed after the anomaly has several drawbacks. First, in scenarios like road tests in test vehicles, developers cannot immediately connect to the debugger for anomaly handling, often resulting in the loss of useful information about the on-site environment. Second, connecting the debugger after the anomaly has occurred may lead to the loss of anomaly information at the time of the anomaly, making it impossible to observe environmental variables at that moment. This makes it difficult to pinpoint the exact cause of the anomaly, resulting in challenging anomaly troubleshooting and inaccurate anomaly analysis. Therefore, improving the accuracy of anomaly analysis by obtaining anomaly information when the controller malfunctions is a key direction for current anomaly analysis and processing. Summary of the Invention

[0004] This application provides an abnormal information acquisition method and an embedded device, which can directly acquire the abnormal information at the time of controller abnormality, making it convenient to handle controller abnormalities based on the abnormal information at the time of abnormality.

[0005] To address the aforementioned technical problems, in a first aspect, embodiments of this application provide an anomaly information acquisition method. This method is applied to an embedded device in a vehicle. The embedded device includes a controller, which includes a first core, a second core, and a first memory. The method includes: when the first core determines that an anomaly has occurred during operation, acquiring corresponding anomaly information and writing the anomaly information into the first memory; when the second core determines that an anomaly information exists in the first memory, reading the anomaly information, processing the anomaly information accordingly to obtain target anomaly information, and generating an anomaly storage file based on the target anomaly information for developers to perform anomaly analysis and processing based on the anomaly storage file.

[0006] Using the above technical solution, when the first core of the controller determines that an anomaly has occurred during the operation of the controller, it obtains the corresponding anomaly information and writes the anomaly information into the first memory. When the second core determines that there is an anomaly information in the first memory, it reads the anomaly information, processes the anomaly information accordingly, obtains the target anomaly information, and generates an anomaly storage file based on the target anomaly information. This allows developers to directly obtain the anomaly storage file generated by the real-time anomaly information during the operation of the controller at the moment an anomaly occurs, and to perform anomaly analysis based on the anomaly storage file. In this way, complete and real-time anomaly information can be obtained as soon as an anomaly occurs in the controller, improving the accuracy of anomaly analysis.

[0007] In one possible implementation of the first aspect above, the controller's operating system includes an error logging module and a development error tracker module. The exception information includes first exception information, which includes first sub-exception information and second sub-exception information. When the first core determines that an exception has occurred during operation, it obtains the corresponding exception information, including: when the first core determines that an operating system exception has occurred during operation, it determines the exception type of the operating system exception, and obtains the first sub-exception information corresponding to the exception type from the error logging module based on the exception type and a first hook function; when the first core determines that a development error tracker exception has occurred during operation, it obtains the second sub-exception information from the development error tracker module based on a second hook function.

[0008] By adopting the above technical solution, the exception type of the operating system exception is determined. Based on the exception type, the first sub-exception information corresponding to the exception type is obtained from the error recording module based on the first hook function, and the second sub-exception information is obtained from the development error tracker module based on the second hook function. By directly obtaining the exception information, the exception information of different modules can be obtained more efficiently.

[0009] In one possible implementation of the first aspect above, if the exception type is an application layer error, the first sub-exception information includes detailed information and related parameter information; if the exception type is a protection class error or a kernel error, the first sub-exception information includes the controller's register information.

[0010] By adopting the above technical solution, different anomaly information can be obtained according to different anomaly types, which can meet different anomaly information acquisition needs.

[0011] In one possible implementation of the first aspect above, the controller further includes a second memory, the operating system further includes a watchdog recording module, the exception information further includes second exception information, and when the first core determines that an exception has occurred during operation, it obtains the corresponding exception information and writes the exception information into the first memory, including: when the first core determines that an exception has occurred during operation and there is a situation where the watchdog reset function is enabled, it obtains the second exception information corresponding to the watchdog recording module, stores the second exception information in the second memory, and obtains the second exception information from the second memory after the controller is powered on again.

[0012] Using the above technical solution, when a watchdog reset occurs, the abnormal information is stored in the second memory, and after the controller is powered on again, the second abnormal information is retrieved from the second memory and written into the first memory, ensuring that the abnormal information is not cleared due to the watchdog reset.

[0013] In one possible implementation of the first aspect above, the first core determines that the watchdog reset function is enabled in the following way: when the first core detects that a watchdog reset program exists in the watchdog recording module, it determines that the watchdog reset function is enabled.

[0014] In one possible implementation of the first aspect above, if the first core and the second core are heterogeneous cores, then the first core and the second core adopt a one-way flag mechanism to realize the processing of the first core writing exception information to the first memory and the second core reading exception information from the first memory; if the first core and the second core are homogeneous cores, then the first core and the second core use at least one core index array included in the first memory to realize the processing of the first core writing exception information to the core index array corresponding to the first core in the first memory and the second core reading exception information from the core index array corresponding to the first core included in the first memory.

[0015] Using the above technical solution, if the first core and the second core are heterogeneous cores, a one-way flag mechanism is adopted to enable the first core to write exception information to the first memory and the second core to read exception information from the first memory, so that the functions between the two cores do not interfere with each other. If the first core and the second core are homogeneous cores, the first core and the second core use at least one core index array included in the first memory to enable the first core to write exception information to the core index array corresponding to the first core in the first memory and the second core to read exception information from the core index array corresponding to the first core included in the first memory, so that the two cores can achieve information isolation based on the core index array.

[0016] In one possible implementation of the first aspect above, the abnormal information is processed accordingly to obtain the target abnormal information, including: characterizing the variable information included in the abnormal information to obtain the target abnormal information.

[0017] By adopting the above technical solution, only the variable information is processed into characters, which reduces the amount of data processing and speeds up the processing efficiency.

[0018] In one possible implementation of the first aspect above, after the first core writes the exception information into the first memory, the method further includes: the first core modifies the read / write flag of the first memory to a written flag; when the second core determines that there is exception information in the first memory, it reads the exception information, including: the second core determines that there is exception information in the first memory based on the reading thread detecting that the read / write flag of the first memory is a written flag, and reads the exception information.

[0019] By adopting the above technical solution, based on the periodic detection of the read / write flag bit of the first memory by the read thread, when the read / write flag bit is a written flag, it is determined that there is abnormal information in the first memory, and the abnormal information is read, so that the abnormal information can be obtained in the first time.

[0020] In one possible implementation of the first aspect above, the controller is a microcontroller unit, the first core is a real-time core, the second core is an application core, the first memory is volatile memory, the second memory is non-volatile memory, and the operating system is a system based on an automotive open architecture.

[0021] By adopting the above technical solution, when an anomaly occurs in the microcontroller system based on the automotive open architecture, the anomaly information can be read in real time by the kernel, the anomaly information is stored in volatile memory, and the anomaly information is stored in non-volatile memory before the watchdog reset occurs, ensuring that the anomaly information is not hard deleted. The application kernel can obtain the anomaly information and generate an anomaly storage file, which facilitates anomaly analysis by developers.

[0022] Secondly, this application also discloses an embedded device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the embedded device implements the exception information acquisition method provided by any of the implementations of the first aspect above.

[0023] Thirdly, this application also discloses a computer-readable storage medium storing a computer program that can be executed by an embedded device to implement the exception information acquisition method provided by any of the implementations of the first aspect.

[0024] Fourthly, this application also discloses a computer program product, including a computer program, which, when executed by an embedded device, implements the exception information acquisition method provided by any of the implementations of the first aspect.

[0025] The relevant beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0026] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0027] Figure 1 A schematic diagram of the structure of an embedded device provided in an embodiment of this application;

[0028] Figure 2 This is another schematic diagram of the structure of the embedded device provided in the embodiments of this application;

[0029] Figure 3 This is another schematic diagram of the structure of the embedded device provided in the embodiments of this application;

[0030] Figure 4 This is a flowchart illustrating an abnormal information acquisition method provided in an embodiment of this application. Detailed Implementation

[0031] For embedded devices in vehicles, whether in the testing phase or the actual use phase, it is usually necessary to obtain the exception information when an exception occurs so that developers can handle the exception based on the exception information. Exception handling includes exception location, exception problem investigation, exception cause determination and other exception analysis and handling, as well as exception repair.

[0032] Taking the testing of controllers such as MCUs in embedded devices as an example, especially during the road test phase of test vehicles, traditional debugging methods such as MCUlog and diagnostic fault codes become ineffective when the MCU experiences an operating system (OS) crash. Furthermore, when a serious MCU anomaly occurs, the operating system undergoes a hard reset (e.g., an external watchdog reset), often resulting in the loss of on-site information. Currently, developers often use debugging tools (such as Lauterbach) for anomaly debugging. However, when developers connect to the debugger for anomaly analysis, they can only obtain controller logs and other anomaly information some time after the anomaly occurs, leading to low troubleshooting efficiency.

[0033] First, in test vehicle road test scenarios, developers cannot immediately connect to the debugger for troubleshooting, often resulting in the loss of useful information about the on-site environment. Second, if the debugger is connected after an anomaly occurs, it is impossible to observe the time of the anomaly or even the environmental variables prior to the anomaly, making it difficult to find the direct cause of the problem. Third, anomalies are often sporadic issues in specific scenarios, making it impossible to reproduce the problems later.

[0034] In summary, existing methods for obtaining anomaly information are lagging behind, failing to capture anomaly information at the moment of occurrence, leading to inaccurate anomaly analysis.

[0035] Based on this, this application provides an anomaly information acquisition method. This method is applied to an embedded device in a vehicle. The embedded device includes a controller, which includes a first core, a second core, and a first memory. The method includes: when the first core determines that an anomaly has occurred during operation, it acquires the corresponding anomaly information and writes the anomaly information into the first memory; when the second core determines that an anomaly information exists in the first memory, it reads the anomaly information, processes the anomaly information accordingly to obtain target anomaly information, and generates an anomaly storage file based on the target anomaly information for developers to perform anomaly analysis and processing. Thus, when an anomaly occurs during the controller's operation, the first core can immediately acquire the anomaly information and write it into the first memory; the second core reads the anomaly information from the first memory, processes the anomaly information accordingly to obtain target anomaly information, and generates an anomaly storage file based on the target anomaly information. This allows developers to obtain the anomaly storage file and perform anomaly analysis and processing, accelerating the efficiency of anomaly information acquisition and ensuring that anomaly information at the moment of occurrence is acquired, thereby improving the efficiency and accuracy of anomaly analysis.

[0036] Next, the embedded device and the method for obtaining abnormal information in this application will be described in detail.

[0037] like Figure 1 As shown, this application provides an embedded device applied to a vehicle. The embedded device includes a controller, which includes a first core, a second core, and a first memory.

[0038] The first core is used to obtain the corresponding exception information when an exception is detected during operation, and write the exception information into the first memory.

[0039] For example, an embedded device includes hardware devices and software systems. In this application, the hardware device is a controller, such as a microcontroller unit, and the software system is such as an automotive open platform architecture system (i.e., the AUTOSAR operating system), wherein the operating system is deployed in a first core.

[0040] In the implementation of this application, there is at least one first core.

[0041] When the first core determines that an abnormality occurs during the operation of the operating system, it obtains the corresponding abnormality information of the operating system and writes the abnormality information into the first memory.

[0042] Among them, such as Figure 2 As shown, the controller's operating system includes an error logging module and a development error tracker module. Exception information includes first exception information and second exception information; the first exception information includes first sub-exception information and second sub-exception information.

[0043] When the first core determines that an operating system exception has occurred during operation, it determines the exception type of the operating system exception, and based on the exception type, it obtains the first sub-exception information corresponding to the exception type from the error recording module based on the first hook function, and writes the first sub-exception information into the first memory.

[0044] If the exception type is an application layer error, the first sub-exception information includes detailed information and related parameter information; if the exception type is a protection class error or a kernel error, the first sub-exception information includes the controller's register information.

[0045] In another implementation, if the exception type is a kernel error, the first sub-exception information includes kernel hardware context information.

[0046] Furthermore, when the first core determines that a development error tracker exception has occurred during operation, it obtains the second sub-exception information from the development error tracker module based on the second hook function and writes the second sub-exception information into the first memory.

[0047] In the implementation method of this application, such as Figure 3 As shown, the controller also includes a second memory, and the operating system also includes a watchdog recording module. When the first core determines that an abnormality has occurred during operation and there is a situation where the watchdog reset function is enabled, it obtains the second abnormality information corresponding to the watchdog recording module, stores the second abnormality information in the second memory, and after the controller is powered on again, it obtains the second abnormality information from the second memory and writes the second abnormality information into the first memory.

[0048] When the first core detects the presence of a watchdog reset program in the watchdog recording module, it determines that the watchdog reset function is enabled.

[0049] Furthermore, when the first core writes the exception information into the first memory, it writes the exception information into the MCU tombstone area of ​​the first memory and modifies the read / write flag of the first memory to the written flag.

[0050] The second core is used to read the abnormal information when it is determined that there is abnormal information in the first memory, process the abnormal information accordingly, obtain the target abnormal information, and generate an abnormal storage file based on the target abnormal information, so that developers can perform abnormal analysis and processing based on the abnormal storage file.

[0051] For example, continue as follows Figure 3 As shown, the second core, based on the reading thread or process (MCUlog.bin), calls the operating system I / O application programming interface (API). When it detects that the read / write flag of the first memory is written, it determines that there is abnormal information in the first memory, reads the abnormal information, performs characterization on the variable information included in the abnormal information to obtain the target abnormal information, and generates an abnormal storage file. The MCU tombstone file module reads the abnormal storage file (i.e., MCUtombstonefile, also known as MCU tombstone file) based on the fopen() function and stores it. Developers can download the abnormal storage file on a host computer (e.g., a PC), open it with Notepad, and see the specific reason for the MCU core hang, thus realizing abnormal analysis.

[0052] In the implementation of this application, when reading exception information based on the operating system I / O API (i.e., OS I / O API), the physical address, length and other information of the exception information are also read (e.g., MemCopy(Physical Addr, Length)). When the reading thread or process reads exception information based on the operating system I / O API, the data pointer and data length are also read (e.g., Read(DataPtr, DataLen)).

[0053] In the implementation of this application, if the first core and the second core are heterogeneous cores, the first core and the second core adopt a one-way flag mechanism to realize the processing of the first core writing exception information to the first memory and the second core reading exception information from the first memory.

[0054] In the implementation of this application, if each first core and the second core are homogeneous cores, then each first core and the second core use at least one core index array included in the first memory to implement the processing of each first core writing exception information to the core index array corresponding to each first core in the first memory, and the second core reading exception information from the core index array corresponding to each first core included in the first memory.

[0055] Furthermore, in this implementation, the first memory is equipped with an MCU tombstone area for storing abnormal information.

[0056] In this implementation, the controller is a microcontroller unit, the first core is a real-time core (i.e., M core), the second core is an application core (i.e., A core), the first memory is volatile memory (e.g., SRAM), and the second memory is non-volatile memory (e.g., Flash).

[0057] Next, taking an embedded device with an S32G series chip as the controller and an operating system based on an automotive open architecture as an example, see [link to relevant documentation]. Figure 4 The method for obtaining exception information provided in this application includes the following steps.

[0058] S100: When the first core determines that an exception has occurred during operation, it obtains the corresponding exception information and writes the exception information into the first memory.

[0059] The abnormal information includes first abnormal information and second abnormal information, and the first abnormal information includes first sub-abnormal information and second sub-abnormal information.

[0060] In the implementation of this application, when the first core determines that an operating system exception has occurred during operation, it determines the exception type of the operating system exception, and based on the exception type, obtains the first sub-exception information corresponding to the exception type from the error recording module based on the first hook function, and writes the first sub-exception information into the first memory.

[0061] For example, when the first core (S32G-M core) determines that an anomaly has occurred in the AUTOSAR operating system during operation, it analyzes the error recording module (Error module) of the AUTOSAR operating system and reads the relevant ErrorType variable information recorded by the OS kernel in the error recording module when the anomaly occurs (as an example of the first sub-anomaly information) through the first hook function ErrorHook.

[0062] If the exception type is an application layer error, the first sub-exception information includes detailed information and related parameter information. If the exception type is a protection class error or a kernel error, the first sub-exception information includes the controller's register information.

[0063] Specifically, as shown in Table 1, Table 1 gives the correspondence between the error behaviors corresponding to different error types and the exception information written to the exception storage file.

[0064] Table 1. Correspondence between error behaviors and exception information for different exception types.

[0065]

[0066] As shown in Table 1, application layer errors (APP1 error) are errors at the application task level. They do not involve the core functions of the operating system kernel and will not cause the kernel to hang. They are usually caused by the application passing illegal parameters or violating API usage rules when calling the OS API, such as passing an invalid semaphore ID when sending a semaphore to a task, or the task attempting to access unauthorized resources.

[0067] In this case, for this type of fault, obtaining the error's Details and Parameters allows us to pinpoint the specific application task and API call. There is no need to obtain the **instruction address (InstrAddr)** and interrupt (Irq) information at the time the error occurred. The program can continue to execute without triggering a system halt or reset. The application layer only needs to handle the error itself.

[0068] Protection errors are violations of system resource access permissions or boundaries, involving AUTOSAR OS's memory protection and task permission protection mechanisms. They commonly occur when a task violates the OS's isolation protection rules, such as: a normal task attempting to access kernel space memory; a task accessing a shared resource not allocated to it; or a task's execution time exceeding a preset time window (time protection violation).

[0069] In this case, for this type of fault, the chip register information is obtained, including the exception number (core.dyn.IntSrc), the instruction address when the error occurred (Error.InstrAddr), data access address, and other kernel-level hardware information. It is not necessary to obtain the application layer details and parameters information. After this type of fault is triggered, the program will enter a waiting state and cannot continue to execute normally, requiring external intervention (such as reset).

[0070] Kernel errors are fatal errors inherent to the operating system kernel itself, directly undermining the kernel's operational foundation and representing the most severe type of OS error. They are caused by abnormalities in core kernel functions, such as: logical errors in the kernel task scheduler; failures in the kernel's system clock or timer module; collapse of the kernel's inter-core communication mechanism in multi-core architectures; and corruption of kernel data structures (such as the task control block and ready queue).

[0071] For this type of fault, obtaining complete register information, i.e. kernel hardware context information (registers, instruction addresses, data addresses, etc.), without obtaining application layer error parameters, cannot trace back to the specific application API, which will cause the kernel to hang completely and the program to enter a stagnant state. This usually triggers a watchdog reset and is a critical fault that needs to be investigated in the road test of automotive MCUs.

[0072] Furthermore, in the implementation of this application, the OS error exception information of the error module is directly read based on the first hook function. This method does not require the use of the standard API interface provided by the OS to obtain data, thus avoiding Hook nesting. Otherwise, there will be various condition judgments in the OS I / O API interface, which will lead to hook nesting, that is, Task->Error->Hook->OsApi->Error->Hook nesting will occur, which will cause Os Error to record the reason of the previous hook and overwrite the exception information of the current task.

[0073] Furthermore, in the implementation method of this application, the original exception information is copied directly without adding any logic judgment related to OS error.

[0074] Furthermore, in the implementation of this application, the first sub-abnormal information includes the timestamp information of the time when the abnormality occurred and the original abnormal information.

[0075] At this point, there's no need to characterize the exception information, so acquiring as much data as possible facilitates debugging. Specifically, when one core fails, all core OsCoreDyn data (i.e., the first sub-exception information) is acquired. Other cores may be running normally, and acquiring this data allows for easy reference and analysis of the cause of the failed core. This is because some faults are core-related: for example, a ProtectionError in one core can lead to PanicErrors in all cores. For instance, a memory access violation in core 0 triggers a hardware bus exception (ProtectionError), which in turn causes the OS kernels of other cores (core 1, core 2) to detect a "bus fault" (PanicError). While saving the exception information of all cores may result in multiple data saves, since the root cause of the faults in multiple cores is the same regardless of whether only one or multiple cores fail, the core content of the exception information is completely consistent, and the state of the normal cores remains unchanged, thus preventing data consistency issues. For example, the erroneous instruction address of core 0 and the resource usage status of core 1 are fixed values ​​in multiple acquisitions; repeated writing will not overwrite or tamper with valid information.

[0076] Furthermore, when the first core determines that a development error tracker exception has occurred during operation, it obtains the second sub-exception information from the development error tracker module based on the second hook function and writes the second sub-exception information into the first memory.

[0077] For example, when the first core determines that the Development Error Tracker (DET) of the upper-layer application of AUTOSAR has an anomaly during operation, it analyzes the Development Error Tracker module (DET module) and reads the relevant fault information recorded by the Development Error Tracker module when the anomaly occurs through the second hook function Det_ErrorHook (as an example of the second sub-anomaly information).

[0078] Specifically, the timestamp information of the time when the exception occurred is first obtained. The DET module and the error module do not interfere with each other and each records its own exception information. Then, the exception log information at the time of the exception is obtained.

[0079] In the case of regular DET, there are only a few function parameters, so there is no data consistency problem. However, when the callout records the log, there is a data consistency problem. If there are multiple exception messages from the first core, the problem between the multiple cores is solved by multi-core data isolation. The exceptions will not occur simultaneously between multiple tasks on the same core, so there is no data inconsistency problem.

[0080] Furthermore, in the prior art, if a watchdog hard reset problem occurs, the abnormal information in the first memory will be flushed away.

[0081] For example, CN10286130A proposes a method for recording reset types, which can distinguish between resets caused by software, internal watchdog, reset pin, or hardware power loss. However, it does not record further reasons for a certain type of reset and lacks key information for analyzing reset types. For example, when the operating system sends an exception, an external watchdog reset often occurs, and all information will be cleared. Recording the operating system's exception information before the reset is the key to performing exception analysis.

[0082] Based on this, in the implementation of this application, before a watchdog reset occurs, the exception information is acquired and hard-stored to avoid the hard reset erasing the stored exception information. That is, in the implementation of this application, when the first core determines that an exception has occurred during operation, it acquires the corresponding exception information and writes the exception information into the first memory. This includes: when the first core determines that an exception has occurred during operation and there is a situation where the watchdog reset function is enabled, it acquires the second exception information corresponding to the watchdog recording module, stores the second exception information in the second memory, and after the controller is powered on again, it retrieves the second exception information from the second memory and writes the second exception information into the first memory.

[0083] The first core determines whether the watchdog reset function is enabled by detecting that a watchdog reset program exists in the watchdog recording module.

[0084] For example, when the AUTOSAR Wdg watchdog recording module detects a program flow abnormality and determines that there is a functional safety requirement to start the watchdog, it reads the relevant fault information of the watchdog recording module so that the abnormal information is written to the internal Flash (as an example of a second memory) before the watchdog needs to reset the entire board when the MCU is abnormal. After the MCU is powered on again, it is read from the internal Flash and written to the shared memory (SRAM).

[0085] In the implementation of this application, the watchdog timer generally needs to be enabled in the later stages of the project. At this time, a new strategy is used for storing the MCU tombstone (i.e., exception information): when the MCU is abnormal, the exception information needs to be written to the internal Flash before the watchdog timer resets the entire board. After the next power-on, it is read from the internal Flash and then passed to the A core.

[0086] Due to the hardware characteristics and functional safety design requirements of NorFlash, the MCU tombstone information can only be written during the execution of the MCU abnormal program, and only once. Even if the watchdog is reset, the information in NorFlash will not be deleted. During each subsequent power-on and normal operation, the second core of the MCU will read this same information and pass it to the microcontroller unit (MPU).

[0087] Furthermore, after detecting a program flow anomaly, the watchdog module first calls the watchdog log module's interface to store the information specified by the watchdog AUTOSAR, and then proceeds with the normal process to re-establish a system reset. Commonly used AUTOSAR watchdog anomaly information includes the number of failed alive supervision cycles, the supervision cycle counter for deadline violations, and the supervision cycle counter for program flow violations.

[0088] Furthermore, after the first core writes the exception information into the first memory, the first core modifies the read / write flag of the first memory to the written flag.

[0089] Furthermore, the first core writes the exception information into a fixed shared memory segment of SRAM, and then enters a while(1) waiting state. At this time, the MCU no longer exhibits any characteristics (Os Error case) or only exhibits limited characteristics (Det case).

[0090] S200, when the second core determines that there is abnormal information in the first memory, it reads the abnormal information.

[0091] S300, the second core processes the abnormal information accordingly to obtain the target abnormal information, and generates an abnormal storage file based on the target abnormal information, so that developers can perform abnormal analysis and processing based on the abnormal storage file.

[0092] In the implementation of this application, when the second core determines that there is abnormal information in the first memory, it reads the abnormal information, including: the second core determines that there is abnormal information in the first memory based on the reading thread detecting that the read / write flag bit of the first memory is a written flag, and reads the abnormal information.

[0093] For example, the second core (S32G-A core) provides an MCUlog thread or process (as an example of a read thread), which executes once at a fixed period (e.g., every 1 second). When it detects that there is data update in the shared memory area, it calls the underlying interface (e.g., the operating system I / O API) to read the exception information in the shared memory area and save it to the exception storage file. The A core will only create and write the exception storage file when it writes to the file for the first time during this power-on and there is exception information in the shared memory. After that, it will no longer need to query the shared memory.

[0094] The rules for the MCUlog thread writing exception storage files are as follows: the maximum number of files is the latest 5. File names are numbered from 0000 to 9999, then reset to 0000. The file title is incremented with the UTC time. For example: mcu_tombstone_0000_2023-11-21 02:54:45.log.

[0095] In the implementation of this application, the abnormal information is processed accordingly to obtain the target abnormal information, including: characterizing the variable information included in the abnormal information to obtain the target abnormal information.

[0096] For example, an inline function can be used to characterize the variable portion of the exception message. The description portion, since its content remains unchanged, can be characterized during system startup initialization. Calling external file functions (including library functions) is prohibited because the address region of the external function is unreliable during this system exception. Furthermore, inline functions are used for characterization because execution is currently in a hook-type thread, not a task-type thread, to avoid excessive stack pushing operations caused by function calls.

[0097] Furthermore, on-site personnel can restart the entire system to continue using it, and download the abnormal storage file and send it to the developers for analysis.

[0098] It should be noted that the first memory is a shared memory area provided by the second core for storing MCU tombstones. The size can be 32Kbytes, with the first 4 bytes being UpdateFlag and the remaining area containing exception information.

[0099] In the implementation of this application, if each first core and second core is a heterogeneous core, then each first core and second core adopts a one-way flag mechanism to realize the processing of each first core writing exception information to the first memory and the second core reading exception information from the first memory.

[0100] For example, heterogeneous cores avoid simultaneous operations through flag management. Operations on the flag avoid multiple assembly instructions, i.e., the M core only writes and the A core only reads. Each assembly instruction must be an atomic instruction, i.e., the data is uint32.

[0101] If the first cores and second cores are homogeneous, then each first core and second core, through at least one core index array included in the first memory, enables the first core to write exception information to the core index array corresponding to its own first core in the first memory, and the second core to read exception information from the core index array corresponding to its own first core in the first memory. For example, homogeneous cores communicate through a multi-core index array, where the information of each core is only stored in the array containing its current core index (i.e., the core index array), ensuring information isolation between the multiple cores. The second core reads exception information from the core index arrays corresponding to all first cores or from the core index data corresponding to the first core.

[0102] Furthermore, for multiple tasks within a single core, interrupts are disabled via hooking, preventing task preemption. In other words, when multiple tasks exist on a single core, preemption is disabled, and exception information for each task is stored according to time.

[0103] This application implements an MCU tombstone function. When a serious MCU exception occurs (OS panic, DET error), it can record and save key information about the MCU exception before a hard reset (external watchdog reset, etc.) occurs, and characterize the variable information for developers and testers to investigate the cause of the exception later. Compared to existing methods that require connecting a debugger after an MCU exception occurs for reproduction and debugging, this method does not rely on host computer debugging tools. It can be batch-embedded and deployed in specific products for real-time monitoring. Once a system exception occurs, it can record and save key situational information before the reset action, characterize the exception information, and send it to the host computer for developers and testers to investigate later.

[0104] Furthermore, this application also discloses a vehicle, which includes an embedded device that executes an exception information acquisition method to acquire exception information.

[0105] This application also provides a chip for executing instructions, which is used to execute the abnormal information acquisition method in the above embodiments.

[0106] This application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on the processor of an embedded device, the processor of the embedded device executes the technical solution of the exception information acquisition method described in the above embodiments.

[0107] In some possible implementations, various aspects of the methods provided in this application can also be implemented as a program product, which includes program code. When the program product is run on the processor of an embedded device, the program code is used to cause the processor of the embedded device to perform the steps of the methods in the various exemplary implementations of this application described above. For example, the embedded device can perform the exception information acquisition method described in the embodiments of this application.

[0108] The program product may take the form of any combination of one or more readable media. A readable medium may be a readable data medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CDROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0109] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the abnormal information acquisition method in the above embodiments.

[0110] It should be noted that, in addition to the specific embodiments described above, those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Although the description of this application is presented in conjunction with preferred embodiments, this does not mean that the features of this application are limited to this implementation. On the contrary, the purpose of describing the application in conjunction with the implementation is to cover other options or modifications that may be derived from this application. To provide a thorough understanding of this application, many specific details are included in the above description, and this application may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of this application, some specific details will be omitted in the description. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0111] It should be noted that in this specification, similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0112] It should be noted that the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0113] It should be noted that some structural or methodological features may be shown in the accompanying drawings in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, including structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0114] Although this application has been illustrated and described with reference to certain preferred embodiments, those skilled in the art should understand that the above description is a further detailed explanation of the application in conjunction with specific implementations, and should not be construed as limiting the specific implementation of the application to these descriptions. Those skilled in the art can make various changes in form and detail, including some simple deductions or substitutions, without departing from the spirit and scope of this application.

Claims

1. A method for obtaining abnormal information, characterized in that, An embedded device used in a vehicle, the embedded device including a controller, the controller including a first core, a second core, and a first memory, the method including: When the first core determines that an abnormality has occurred during operation, it obtains the corresponding abnormality information and writes the abnormality information into the first memory. When the second core determines that there is abnormal information in the first memory, it reads the abnormal information, processes the abnormal information accordingly to obtain target abnormal information, and generates an abnormal storage file based on the target abnormal information, so that developers can perform abnormal analysis and processing based on the abnormal storage file.

2. The method for obtaining abnormal information according to claim 1, characterized in that, The controller's operating system includes an error logging module and a development error tracker module. The exception information includes first exception information, which includes first sub-exception information and second sub-exception information. When the first core determines that an exception has occurred during operation, it acquires the corresponding exception information, including: When the first core determines that an operating system exception has occurred during operation, it determines the exception type of the operating system exception, and based on the exception type, it obtains the first sub-exception information corresponding to the exception type from the error recording module based on the first hook function; When the first core determines that a development error tracker exception has occurred during operation, it obtains the second sub-exception information from the development error tracker module based on the second hook function.

3. The method for obtaining abnormal information according to claim 2, characterized in that, If the exception type is an application layer error, the first sub-exception information includes detailed information and related parameter information; If the exception type is a protection class error or a kernel error, then the first sub-exception information includes the register information of the controller.

4. The method for obtaining abnormal information according to claim 3, characterized in that, The controller further includes a second memory, the operating system further includes a watchdog recording module, and the exception information further includes second exception information. When the first core determines that an exception has occurred during operation, it acquires the corresponding exception information, including: When the first core determines that an abnormality has occurred during operation and there is a situation where the watchdog reset function is enabled, it obtains the second abnormality information corresponding to the watchdog recording module, stores the second abnormality information in the second memory, and retrieves the second abnormality information from the second memory after the controller is powered on again.

5. The method for obtaining abnormal information according to claim 4, characterized in that, The first core determines whether the watchdog reset function is enabled by means of the following method: When the first core detects that a watchdog reset program exists in the watchdog recording module, it determines that the watchdog reset function is enabled.

6. The method for obtaining abnormal information according to claim 5, characterized in that, If the first core and the second core are heterogeneous cores, then the first core and the second core adopt a one-way flag mechanism to realize the processing of the first core writing the exception information to the first memory and the second core reading the exception information from the first memory; If the first core and the second core are isomorphic cores, then the first core and the second core use at least one core index array included in the first memory to implement the process of the first core writing the exception information to the core index array corresponding to the first core in the first memory, and the second core reading the exception information from the core index array corresponding to the first core included in the first memory.

7. The method for obtaining abnormal information according to claim 6, characterized in that, The abnormal information is processed accordingly to obtain the target abnormal information, including: The variable information included in the abnormal information is converted into characters to obtain the target abnormal information.

8. The method for obtaining abnormal information according to claim 7, characterized in that, After the first core writes the exception information into the first memory, the method further includes: The first core modifies the read / write flag of the first memory to the written flag; When the second core determines that there is abnormal information in the first memory, it reads the abnormal information, including: The second core determines that there is abnormal information in the first memory when the read thread detects that the read / write flag of the first memory is written, and then reads the abnormal information.

9. The method for obtaining abnormal information according to claim 8, characterized in that, The controller is a microcontroller unit, the first core is a real-time core, the second core is an application core, the first memory is volatile memory, the second memory is non-volatile memory, and the operating system is a system based on an automotive open architecture.

10. An embedded device for use in vehicles, characterized in that, The embedded device includes a controller, which includes a first core, a second core, and a first memory, wherein... The first core is used to obtain the corresponding exception information when an exception is detected during operation, and write the exception information into the first memory; The second core is used to read the abnormal information when it is determined that there is abnormal information in the first memory, process the abnormal information accordingly to obtain target abnormal information, and generate an abnormal storage file based on the target abnormal information, so that developers can perform abnormal analysis and processing based on the abnormal storage file.

Images