Memory monitoring method for microcontroller unit in vehicle, electronic device and vehicle

Abstract

This application provides a memory monitoring method, electronic device, and vehicle for a microcontroller unit in a vehicle. The method includes: storing static memory information of the microcontroller unit to a target address in the microcontroller unit's memory in response to the microcontroller unit being in a configuration state; acquiring dynamic memory information of the microcontroller unit and acquiring static memory information from the target address in response to the microcontroller unit switching from a configuration state to a running state; and determining memory occupancy information of the microcontroller unit based on the dynamic and static memory information, wherein the memory occupancy information represents the trend of memory occupancy over time while the microcontroller unit is in the running state. This application solves the technical problem of low memory monitoring efficiency for microcontroller units in vehicles.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a method for monitoring the memory of a microcontroller unit in a vehicle, an electronic device, and a vehicle. Background Technology

[0002] Currently, comprehensive monitoring of the static and dynamic memory of microcontroller units in vehicles requires obtaining dynamic memory information through hardware-level debugging tools. However, this necessitates external hardware for on-site monitoring, resulting in limited flexibility in microcontroller unit monitoring. Additionally, obtaining static memory information through static analysis and compilation methods requires manual collection and analysis.

[0003] When using both methods to comprehensively monitor the memory status of the microcontroller unit in a vehicle, both static and dynamic memory monitoring require additional external hardware or manual intervention, resulting in low memory monitoring efficiency for the microcontroller unit. Therefore, the technical problem of low memory monitoring efficiency for the microcontroller unit in a vehicle persists.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] This application provides a method for monitoring the memory of a microcontroller unit in a vehicle, an electronic device, and a vehicle, to at least solve the technical problem of low memory monitoring efficiency of a microcontroller unit in a vehicle.

[0006] According to one aspect of the embodiments of this application, a memory monitoring method for a microcontroller unit in a vehicle is provided. The method may include: in response to the microcontroller unit being in a configuration state, storing static memory information of the microcontroller unit to a target address in the memory of the microcontroller unit, wherein the static memory information represents the memory occupancy status of static data of the vehicle, and the static data is state data that remains fixed during vehicle operation; in response to the microcontroller unit switching from a configuration state to a running state, acquiring dynamic memory information of the microcontroller unit and acquiring static memory information from the target address, wherein the dynamic memory information represents the memory occupancy status of dynamic data of the vehicle, and the dynamic data is state data that changes during vehicle operation; and determining memory occupancy information of the microcontroller unit based on the dynamic memory information and the static memory information, wherein the memory occupancy information represents the trend of memory occupancy status changing over time while the microcontroller unit is in a running state.

[0007] Furthermore, in response to the microcontroller unit being in a configuration state, storing the static memory information of the microcontroller unit to the target address of the microcontroller unit's memory includes: in response to the microcontroller unit being in a configuration state, performing a compilation operation on the microcontroller unit to obtain a compilation result, wherein the compilation result is used to represent the allocation state of the static memory of the microcontroller unit; and using the compilation result to store the static memory information to the target address.

[0008] Furthermore, the compilation results include an object program file and a memory-mapped file. The object program file is used to represent the data layout state of the microcontroller unit, and the memory-mapped file is used to represent the memory occupancy distribution state. In response to the microcontroller unit being in a configuration state, a compilation operation is performed on the microcontroller unit to obtain the compilation results, including: in response to the microcontroller unit being in a configuration state, a compilation operation is performed on the microcontroller unit to obtain an object program file and a memory-mapped file.

[0009] Furthermore, using the compilation results, the static memory information is stored at the target address, including: extracting the static memory information from the memory-mapped file; writing the extracted static memory information to the target address corresponding to the target program file; and / or, the method further includes: writing the target program file written to the target address to the microcontroller unit.

[0010] Furthermore, based on dynamic memory information and static memory information, the memory usage information of the microcontroller unit is determined, including: generating log information of the microcontroller unit based on dynamic memory information and static memory information; and determining memory usage information based on the log information.

[0011] Furthermore, memory includes a heap and a stack. Dynamic memory information includes heap memory information and stack memory information. Heap memory information is used to indicate the occupancy status of dynamic data in the heap, and stack memory information is used to indicate the occupancy status of dynamic data in the stack. In response to the microcontroller unit being in a running state, the dynamic memory information of the microcontroller unit is obtained, including: in response to the microcontroller unit being in a running state, performing data verification from the end address of the heap to the start address of the heap, obtaining the verification result, and determining the heap memory information based on the verification result, wherein the verification result is used to indicate whether the dynamic data occupies the area between the end address and the start address; in response to the microcontroller unit being in a running state, the stack occupancy rate is obtained, and the stack memory information is determined based on the utilization rate, wherein the utilization rate is used to indicate the degree of space occupancy of the stack.

[0012] Furthermore, in response to the microcontroller unit being in a running state, data verification is performed from the end address of the heap to the beginning address of the heap to obtain a verification result, including: in response to the microcontroller unit being in a running state and the data in the region being preset data, determining the verification result as a dynamically occupied data region; in response to the microcontroller unit being in a running state and the data in the region being non-preset data, determining the verification result as a dynamically unoccupied data region; and / or, based on the verification result, determining heap memory information, including: in response to the verification result being a dynamically occupied data region, determining the minimum offset of the memory based on non-preset data; and determining the heap memory information based on the minimum offset.

[0013] Furthermore, in response to the microcontroller unit being in a running state, the stack utilization rate is obtained, including: in response to the microcontroller unit being in a running state, calling the stack monitoring function to monitor the stack and obtain the utilization rate; and / or, based on the utilization rate, determining stack memory information, including: transmitting the utilization rate determined by the stack monitoring function to the log printing task function through the idle task hook function; and processing the utilization rate using the log printing task function to obtain the stack memory information.

[0014] According to another aspect of the embodiments of this application, a memory monitoring device for a microcontroller unit in a vehicle is also provided. This device may include: a storage unit, configured to store static memory information of the microcontroller unit to a target address in the memory of the microcontroller unit in response to the microcontroller unit being in a configuration state, wherein the static memory information represents the memory occupancy status of static data of the vehicle, and the static data is state data that remains fixed during vehicle operation; an acquisition unit, configured to acquire dynamic memory information of the microcontroller unit and acquire static memory information from the target address in response to the microcontroller unit switching from a configuration state to a running state, wherein the dynamic memory information represents the memory occupancy status of dynamic data of the vehicle, and the dynamic data is state data that changes during vehicle operation; and a determination unit, configured to determine memory occupancy information of the microcontroller unit based on the dynamic memory information and the static memory information, wherein the memory occupancy information represents the trend of memory occupancy status changing over time while the microcontroller unit is in a running state.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0016] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0020] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0021] In this embodiment, in response to the microcontroller unit being in a configuration state, the static memory information of the microcontroller unit is stored in the target address of the microcontroller unit's memory; in response to the microcontroller unit switching from the configuration state to the running state, the dynamic memory information of the microcontroller unit is obtained, and the static memory information is obtained from the target address; based on the dynamic memory information and the static memory information, the memory usage information of the microcontroller unit is determined. That is, in this embodiment, by synchronously obtaining static and dynamic memory information when the microcontroller unit is in the running phase; based on the synchronously obtained static and dynamic memory information, the memory usage information of the microcontroller unit can be further determined. Therefore, this overcomes the obstacle in related technologies where static and dynamic memory information can only be obtained in isolation, and obtaining static and dynamic memory information requires additional external hardware or manual intervention, resulting in low memory monitoring efficiency of the microcontroller unit. This achieves the technical effect of improving the memory monitoring efficiency of the microcontroller unit and solves the technical problem of low memory monitoring efficiency of the microcontroller unit. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a flowchart of a memory monitoring method for a microcontroller unit in a vehicle according to an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of a historical dynamic memory change curve according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of a historical static memory change curve according to an embodiment of this application;

[0026] Figure 4 This is a flowchart of an MCU memory monitoring process according to an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of a heap memory acquisition module according to an embodiment of this application;

[0028] Figure 6 This is a flowchart of a stack memory acquisition method according to an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of a memory monitoring device for a microcontroller unit in a vehicle according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] According to an embodiment of this application, a memory monitoring method for a microcontroller unit in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] This application provides a method for monitoring the memory of a microcontroller unit in a vehicle. Figure 1 This is a flowchart of a memory monitoring method for a microcontroller unit in a vehicle according to an embodiment of this application, as shown below. Figure 1 As shown, the method may include the following steps.

[0034] In step S102, in response to the microcontroller unit being in the configuration state, the static memory information of the microcontroller unit is stored in the target address of the microcontroller unit's memory.

[0035] In the technical solution provided by step S102 of this application embodiment, the configuration state can be used to represent the incomplete programming state of the microcontroller unit, such as the waiting programming state that the microcontroller unit enters during the operation of a continuous integration / continuous delivery (CI / CD) pipeline. The static memory information can be used to represent the memory occupancy status of the vehicle's static data, such as the amount of static data occupied in memory. The static data can be state data that remains fixed during vehicle operation, such as static variables, global variables, and constants during vehicle operation. The static variables can include, but are not limited to, tire pressure calibration values ​​and brake response curve coefficients; the global variables can include, but are not limited to, global state machine variables and historical pose cache structures; and the constants can include, but are not limited to, maximum vehicle speed limits and battery overvoltage protection thresholds. The memory can be a non-volatile storage area of ​​the microcontroller unit. The target address can be used to represent a predefined dedicated storage area in the memory for storing static memory information.

[0036] Optionally, if the microcontroller unit is in a configured state, the static memory information of the microcontroller unit can be stored in the target address of the microcontroller unit's memory.

[0037] Optionally, if the microcontroller unit is in a configured state, information generated by a firmware building system outside the microcontroller unit can be used to extract the static memory information. This static memory information can then be written into a dedicated data area in the microcontroller unit's memory for storing static memory information. The firmware building system outside the microcontroller unit can be a firmware building pipeline, including but not limited to a continuous integration / continuous delivery (CI / CD) pipeline. The information generated by the firmware building system can be a memory-mapped file.

[0038] It should be noted that the above-mentioned method of generating memory-mapped files through a firmware building system outside the microcontroller unit and extracting the above-mentioned static memory information based on the above information is only an example, and no specific restrictions are placed on the method of obtaining static memory information.

[0039] In this embodiment of the application, through the above step S102, the static memory information of the microcontroller unit can be stored in the memory of the microcontroller unit, so that the microcontroller unit can directly read the static memory information during operation, thereby improving the efficiency and accuracy of memory analysis.

[0040] Step S104: In response to the microcontroller unit switching from the configuration state to the running state, obtain the dynamic memory information of the microcontroller unit and obtain the static memory information from the target address.

[0041] In the technical solution provided by step S104 of this application embodiment, the aforementioned operating state can be used to indicate that the microcontroller unit has completed program burning and started running. The aforementioned dynamic memory information can be used to indicate the memory occupancy status of the vehicle's dynamic data. The aforementioned dynamic memory information may include, but is not limited to, the amount of heap memory occupied and the amount of stack memory occupied. The aforementioned dynamic memory information can be simply referred to as dynamic memory. The aforementioned heap memory and the aforementioned stack memory are the two main types of dynamic memory areas occupied by the microcontroller unit's memory. The aforementioned dynamic data can be state data that changes during vehicle operation, and may include, but is not limited to, temporary variables during vehicle operation.

[0042] Optionally, after storing the static memory information of the microcontroller unit to the target address of the microcontroller unit's memory, if the microcontroller unit switches from the configuration state to the running state, the dynamic memory information of the microcontroller unit can be obtained, as well as the static memory information can be obtained from the target address.

[0043] Optionally, if the microcontroller unit switches from the configuration state to the running state, the usage of heap memory and stack memory in the memory of the microcontroller unit can be collected through the built-in functions of the microcontroller unit to generate dynamic memory information; at the same time, the static memory information stored in the target address can be read.

[0044] In this embodiment of the application, through the above step S104, dynamic memory usage and static memory usage can be obtained simultaneously during the operation of the microcontroller unit, thereby obtaining complete details of the memory usage status.

[0045] Step S106: Determine the memory usage information of the microcontroller unit based on dynamic memory information and static memory information.

[0046] In the technical solution provided by step S106 in the embodiments of this application, the memory usage information can be used to represent the trend of memory usage status changing over time during the operation of the microcontroller unit. The memory usage curve information may include, but is not limited to, the memory usage curve.

[0047] Optionally, after obtaining the dynamic memory information of the microcontroller unit and the static memory information from the target address, the memory usage information of the microcontroller unit can be determined based on the dynamic memory information and the static memory information.

[0048] Optionally, based on dynamic memory information and static memory information, the memory occupancy status of dynamic data in the dynamic memory information can be superimposed with the memory occupancy status of static data in the static memory information. For example, the heap memory occupancy and stack memory occupancy in the dynamic memory information can be added to the static memory occupancy in the static memory information to obtain the memory occupancy value. The time corresponding to the memory occupancy value can be recorded to form a coordinate system with the time as the horizontal axis and the memory occupancy value as the vertical axis. A memory occupancy curve can be constructed under this coordinate system, and the memory occupancy curve can be used as the memory occupancy information of the microcontroller unit.

[0049] In this embodiment, through steps S102 to S106, in response to the microcontroller unit being in a configuration state, the static memory information of the microcontroller unit is stored in the target address of the microcontroller unit's memory; in response to the microcontroller unit switching from the configuration state to the running state, the dynamic memory information of the microcontroller unit is obtained, and the static memory information is obtained from the target address; based on the dynamic memory information and the static memory information, the memory usage information of the microcontroller unit is determined. In other words, in this embodiment, by synchronously obtaining static and dynamic memory information when the microcontroller unit is in the running stage; based on the synchronously obtained static and dynamic memory information, the memory usage information of the microcontroller unit can be further determined. Therefore, this overcomes the obstacle in related technologies where static and dynamic memory information can only be obtained in isolation, and obtaining static and dynamic memory information requires additional external hardware or manual intervention, resulting in low memory monitoring efficiency of the microcontroller unit. This achieves the technical effect of improving the memory monitoring efficiency of the microcontroller unit and solves the technical problem of low memory monitoring efficiency of the microcontroller unit.

[0050] The embodiments of this application will be described in detail below with reference to the steps described above.

[0051] As an optional implementation, step S102, in response to the microcontroller unit being in a configuration state, stores the static memory information of the microcontroller unit to the target address of the microcontroller unit's memory, including: in response to the microcontroller unit being in a configuration state, performing a compilation operation on the program of the microcontroller unit to obtain a compilation result, wherein the compilation result is used to represent the allocation state of the static memory of the microcontroller unit; and using the compilation result to store the static memory information to the target address.

[0052] In the embodiments of this application, the above compilation results can be used to represent the allocation state of the static memory of the microcontroller unit. The above compilation results include, but are not limited to, memory allocation configuration files and programming files.

[0053] Optionally, in response to the microcontroller unit being in a configured state, the program of the microcontroller unit can be compiled using a firmware building system other than the microcontroller unit itself, generating a file containing the compilation results and a burning file. For example, the compilation results can be obtained by calling the compilation toolchain through a CI / CD pipeline.

[0054] Optionally, based on the compilation results determined above, the static memory information in the compilation results can be stored at the target address.

[0055] In this embodiment of the application, the above method can realize automated monitoring of the static memory usage of the microcontroller unit, and overcome the obstacle of low efficiency in determining the static memory usage caused by the need for manual analysis of memory allocation configuration files in related technologies.

[0056] As an optional implementation, the compilation result includes an object program file and a memory-mapped file. The object program file is used to represent the data layout state of the microcontroller unit, and the memory-mapped file is used to represent the memory occupancy distribution state. In response to the microcontroller unit being in a configuration state, a compilation operation is performed on the program of the microcontroller unit to obtain the compilation result, including: in response to the microcontroller unit being in a configuration state, a compilation operation is performed on the program to obtain an object program file and a memory-mapped file.

[0057] In this embodiment, the aforementioned object program file can be used to represent the data layout state of the microcontroller unit. The aforementioned memory mapping file can be used to represent the memory occupancy distribution state.

[0058] Optionally, in response to the microcontroller unit being in a configured state, the program of the microcontroller unit can be compiled through a firmware building system other than the microcontroller unit, and a compilation result can be generated. The compilation result may include target program files (e.g., mcu0.hex file) and memory mapping files (e.g., map file).

[0059] For example, the program for the microcontroller unit can be compiled using a CI / CD pipeline that invokes the compilation toolchain. The linker in the toolchain can then generate a memory-mapped file (e.g., a map file) containing the symbol table and the memory usage of static data, as well as an object program file (e.g., mcu0.hex file). The symbol table can be a mapping table, including but not limited to mappings of the names, starting addresses, and lengths of global variables, static variables, and constants in the target address space. The object program file can contain program code and data segments and can be loaded into the microcontroller unit's non-volatile memory. This method allows for the compilation of the microcontroller unit's program, yielding the object program file and the memory-mapped file.

[0060] In the embodiments of this application, the above method can automatically embed the static memory information of the microcontroller unit into the memory mapping file without human intervention, and obtain the target program file containing the target address of the static memory information storage, thereby improving the efficiency and automation level of the program compilation operation of the microcontroller unit.

[0061] As an optional implementation, the static memory information is stored to the target address using the compilation result, including: extracting the static memory information from the memory-mapped file; writing the extracted static memory information to the target address corresponding to the target program file; and / or, the method further includes: writing the target program file written to the target address to the microcontroller unit.

[0062] In this embodiment of the application, during the process of storing static memory information to the target address using the compilation results, the extracted static memory information can be written to the target address corresponding to the target program file. After writing the static memory information to the target address corresponding to the target program file, the target program file written to the target address can be written to the microcontroller unit.

[0063] Optionally, the memory-mapped file described above is parsed to obtain a parsed memory-mapped file. The static memory usage in the parsed memory-mapped file can be extracted as static memory information, which can then be stored at a target address in the target program file. For example, a Python script can be used to parse the memory-mapped file, extracting the starting memory address and length of the global variables, the starting memory address and length of the static variables, and the starting memory address and length of the constants. The sum of the lengths of the global variables, static variables, and constants is taken as the static memory usage, which is then written to a target address pre-set in the target program file.

[0064] It should be noted that the method described above for parsing the memory-mapped files using Python scripts is merely an example and does not impose any specific limitations on parsing the memory-mapped files described above.

[0065] Optionally, after writing the static memory information to the target address, the target program file containing the static memory information can be flashed into the microcontroller unit's memory using a programming tool or an online debugging interface. For example, using a debugging probe or a protocol built into the microcontroller unit, the target program file containing the static memory information can be written into the microcontroller unit's non-volatile memory in a standard binary programming format, and the static memory information can be fixed as a read-only constant at the target address, allowing direct reading of the static memory information after the microcontroller unit is powered on and reset.

[0066] In this embodiment of the application, the static memory usage of the microcontroller unit can be permanently stored in the target program file in a readable and traceable manner through the above method, so that the microcontroller unit can obtain the static memory usage by reading the pre-specified target address during operation without relying on manual intervention.

[0067] As an optional implementation, step S106, determining the memory usage information of the microcontroller unit based on dynamic memory information and static memory information, includes: generating log information of the microcontroller unit based on dynamic memory information and static memory information; and determining the memory usage information based on the log information.

[0068] In this embodiment, the log information can be a structured operational data record, such as a microcontroller unit log (MCU Log).

[0069] Optionally, when the microcontroller unit is running, it can periodically collect dynamic memory usage and read static memory usage from the aforementioned target address. The dynamic and static memory usage can then be merged into log information. For example, during the microcontroller unit's operating cycle, a preset function can periodically collect dynamic memory usage and read the static memory usage already written to the target program file from the aforementioned target address, merging the dynamic and static memory usage into log information. This log information can be output to the vehicle's System Operating Controller (SOC) via the vehicle's Controller Area Network (CAN) bus.

[0070] Optionally, by parsing the above log information, parsed log information is obtained. From this parsed log information, static memory usage, dynamic memory usage, and total memory usage can be extracted, along with the timestamps corresponding to the static memory usage, dynamic memory usage, and total memory usage, thus determining memory usage information. For example, by parsing the above log information through the vehicle system controller, parsed log information is obtained. From this parsed log information, static memory usage, dynamic memory usage, and total memory usage can be extracted, along with the timestamps corresponding to the static memory usage, dynamic memory usage, and total memory usage, and a structured dataset can be constructed. Based on this structured dataset, the vehicle system controller can call a preset algorithm to generate a memory usage curve, where the horizontal axis of the memory usage curve can be a timestamp, and the vertical axis can be a percentage of memory usage. This memory usage curve can then be used to determine memory usage information.

[0071] In this embodiment of the application, the above method can generate log information and extract static memory usage, dynamic memory usage, total memory usage and their corresponding timestamps, and generate a memory usage curve graph including static memory usage curve, dynamic memory usage curve and total memory usage curve, thereby achieving the purpose of real-time integrated monitoring of static memory and dynamic memory.

[0072] As an optional implementation, the memory includes a heap and a stack. The dynamic memory information includes heap memory information and stack memory information. The heap memory information is used to indicate the occupancy status of dynamic data in the heap, and the stack memory information is used to indicate the occupancy status of dynamic data in the stack. In response to the microcontroller unit being in a running state, the dynamic memory information of the microcontroller unit is obtained, including: in response to the microcontroller unit being in a running state, performing data verification from the end address of the heap to the start address of the heap, obtaining the verification result, and determining the heap memory information based on the verification result, wherein the verification result is used to indicate whether the dynamic data occupies the area between the end address and the start address; in response to the microcontroller unit being in a running state, the stack occupancy rate is obtained, and the stack memory information is determined based on the occupancy rate, wherein the occupancy rate is used to indicate the degree of space occupancy of the stack.

[0073] In this embodiment, the heap memory information can be used to represent the occupancy status of dynamic data in the heap. The stack memory information can be used to represent the occupancy status of dynamic data in the stack. The end address of the heap can be used to represent the highest physical address allocated to the heap area. The start address of the heap can be used to represent the lowest physical address allocated to the heap area. The verification result can be used to indicate whether dynamic data occupies the area between the end address and the start address. The occupancy rate can be used to represent the degree of stack space occupancy.

[0074] Optionally, in response to the microcontroller unit being in a running state, starting from the end address of the heap area, byte-by-byte data verification is performed along the address decreasing direction to the start address to obtain a verification result. If the above verification result is non-zero, it means that dynamic data occupies the area between the end address and the start address. If the above verification result is zero, it means that dynamic data occupies the unused area between the end address and the start address.

[0075] Optionally, in response to the microcontroller unit being in a running state, the stack top pointer address and stack bottom pointer address are obtained, the length of the stack used space is determined based on the stack top pointer address and stack bottom pointer address, and the stack memory information is determined.

[0076] In the embodiments of this application, the above method can achieve lightweight, real-time monitoring of heap memory information and stack memory information, avoiding the performance overhead caused by full traversal in related technologies.

[0077] As an optional implementation, in response to the microcontroller unit being in a running state, data verification is performed from the end address of the heap to the beginning address of the heap to obtain a verification result, including: in response to the microcontroller unit being in a running state and the data in the region being preset data, determining the verification result as a dynamically occupied data region; in response to the microcontroller unit being in a running state and the data in the region being non-preset data, determining the verification result as a dynamically unoccupied data region; and / or, based on the verification result, determining heap memory information, including: in response to the verification result being a dynamically occupied data region, determining the minimum offset of the memory based on non-preset data; and determining the heap memory information based on the minimum offset.

[0078] In this embodiment, the aforementioned preset data can be used to represent a fixed value, such as 0, written during heap initialization or clearing. The aforementioned dynamically occupied data area can be used to represent the memory area actually used in the heap. The aforementioned dynamically unoccupied data area can be used to represent the memory area not actually used in the heap. The aforementioned minimum offset can be used to represent the offset between the memory address corresponding to the first detection of non-preset data and the heap start address during a reverse scan from the end address of the heap to the start address of the heap.

[0079] Optionally, in response to the microcontroller unit being in operation, during the byte-by-byte scanning process from the end address of the heap to the start address of the heap, if the value of the currently scanned byte is not equal to any preset data (e.g., 0), then it is determined that the address of the byte belongs to the dynamic data occupancy area, and the address is recorded as a potential candidate for the smallest effective offset address.

[0080] For example, in an idle task, data verification is performed starting from the end address of the heap: if the data is 0, it is determined that the above area has not been used; if non-zero data is obtained, it is considered that the above area has been used.

[0081] Optionally, the heap is scanned in reverse order starting from the end address of the heap area. When non-preset data is detected for the first time, the address of the non-preset data is recorded as the minimum effective offset address. The difference between the minimum effective offset address and the start address of the heap area is used as the actual number of bytes occupied by the heap. The actual number of bytes occupied by the heap area is divided by the total capacity of the heap area to obtain the heap occupancy rate. The minimum effective offset address, the actual number of bytes occupied by the heap, and the heap occupancy rate can be used as heap memory information.

[0082] In the embodiments of this application, the above method can achieve lightweight identification of the actual heap memory usage boundary of the microcontroller unit. By scanning byte by byte and determining the minimum effective offset address, the upper limit of heap memory usage is located, and the heap memory information is determined.

[0083] As an optional implementation, in response to the microcontroller unit being in a running state, obtaining the stack utilization rate includes: in response to the microcontroller unit being in a running state, calling a stack monitoring function to monitor the stack and obtain the utilization rate; and / or, based on the utilization rate, determining stack memory information includes: transmitting the utilization rate determined by the stack monitoring function to a log printing task function through an idle task hook function; and processing the utilization rate using the log printing task function to obtain the stack memory information.

[0084] In this embodiment, the stack monitoring function can be used to represent low-level functions periodically scheduled by the system during the operation of the microcontroller unit. The stack memory information can be a structured data set representing the stack usage status, including but not limited to the stack top pointer address, stack bottom pointer address, number of used stack bytes, stack occupancy rate, and number of remaining stack bytes. The idle task hook function can be a function periodically called by the microcontroller unit when no other tasks are executing, and the log printing task function can be an independently running function triggered by polling or events.

[0085] Optionally, in response to the microcontroller unit being in a running state, the current stack top pointer address is obtained by reading the stack pointer register through the stack monitoring function. Based on the obtained current stack top pointer address, the stack bottom address configured when the program of the microcontroller unit is compiled by calling the compilation toolchain through the CI / CD pipeline is used to calculate the stack used space length. The stack used space length can be divided by the total stack length to obtain the stack occupancy rate. The stack occupancy rate, stack top pointer address, stack bottom address, and remaining stack length can be determined as stack memory information.

[0086] Optionally, in the idle task hook function, the stack occupancy rate, stack top pointer address, and stack bottom pointer address returned by the aforementioned stack monitoring function are written into a preset structure variable; the log printing task function can read the aforementioned structure variable. Using the above method, the occupancy rate determined by the stack monitoring function can be transmitted to the log printing task function. The aforementioned log printing task function can periodically read the stack occupancy rate data from the aforementioned structure variable; combine it with heap memory information and static memory information to construct a unified log message format; structurally encapsulate the timestamp, microcontroller unit version number, memory type (heap / stack), and memory usage information to obtain the log; the aforementioned log can be uploaded to the SOC via a communication protocol.

[0087] In this embodiment, in response to the microcontroller unit being in a configuration state, the static memory information of the microcontroller unit is stored in the target address of the microcontroller unit's memory; in response to the microcontroller unit switching from the configuration state to the running state, the dynamic memory information of the microcontroller unit is obtained, and the static memory information is obtained from the target address; based on the dynamic memory information and the static memory information, the memory usage information of the microcontroller unit is determined. That is, in this embodiment, by synchronously obtaining static and dynamic memory information when the microcontroller unit is in the running phase; based on the synchronously obtained static and dynamic memory information, the memory usage information of the microcontroller unit can be further determined. Therefore, this overcomes the obstacle in related technologies where static and dynamic memory information can only be obtained in isolation, and obtaining static and dynamic memory information requires additional external hardware or manual intervention, resulting in low memory monitoring efficiency of the microcontroller unit. This achieves the technical effect of improving the memory monitoring efficiency of the microcontroller unit and solves the technical problem of low memory monitoring efficiency of the microcontroller unit.

[0088] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.

[0089] Currently, Microcontroller Units (MCUs) are widely used in automotive electronics, medical devices, the Internet of Things (IoT), and home appliances due to their low cost, low power consumption, high integration, high functional safety, and excellent real-time control capabilities. However, with the increasing complexity of MCU embedded software, memory resource management issues are becoming increasingly prominent. Frequent memory leaks and resource exhaustion have prompted developers to pay close attention to memory monitoring solutions for MCU systems. As highly optimized embedded systems, MCUs lack standardized memory monitoring instruction sets similar to those of System-on-Chips (SoCs). Monitoring solutions in related technologies can be divided into hardware-level monitoring and software-level monitoring. Hardware-level monitoring uses professional tools such as the Lauterbach debugger to directly access memory and obtain dynamic memory through the Advanced High-performance Bus (AHB) / Advanced eXtensible Interface (AXI). Software-level monitoring obtains static memory usage by statically analyzing map files generated by Python parsing and compilation. Dynamic monitoring involves embedding custom monitoring code to track runtime heap and stack memory consumption in real time.

[0090] However, hardware-level memory monitoring suffers from poor flexibility, requiring on-site hardware monitoring and incurring additional hardware costs. Software-based memory monitoring technologies, at least, separate static and dynamic memory monitoring. Static memory monitoring can only be analyzed through compiled files, unable to analyze or record the current static memory allocation of the software running on the MCU. Dynamic memory monitoring records problems within the running software, and lacks historical memory data, making it difficult to analyze which function or variable caused a rapid increase in memory. Furthermore, both static and dynamic memory monitoring on the MCU require manual collection and analysis, resulting in low efficiency.

[0091] In the embodiments of this application, the following problems are solved: the MCU running software cannot monitor static memory in the related technology; the MCU lacks historical memory comparison and analysis; and the manual processing of memory data is required.

[0092] This application proposes an MCU memory monitoring method and system. The method includes: acquiring MCU dynamic memory periodically through a monitoring function; acquiring static memory by analyzing a map file using a Python script; writing the statistically generated static memory to the address of the corresponding variable in the compiled MCU0 hex file; generating a final hex file for flashing into the MCU; implementing SOC / MCU communication; sending MCU static and dynamic memory monitoring logs to the SOC for storage; the SOC uploading the MCU logs to the cloud; and automatically generating an MCU memory usage curve based on massive log data to analyze memory changes.

[0093] In this embodiment, the dynamic memory of the MCU is acquired periodically by a monitoring function. Then, the CI / CD pipeline is triggered to compile and generate the mcu0.hex file and a map file. The CI / CD pipeline calls a Python script to obtain the static memory from the map file and writes the statistically generated static memory to the address of a preset variable in the mcu0.hex file. This variable stores the MCU's static memory, thus generating the final hex file for flashing into the MCU. This hex file contains static and dynamic memory printing information. Furthermore, communication between the MCU and the SOC is implemented, sending the MCU's static and dynamic memory monitoring logs to the SOC for storage. The SOC uploads the MCU logs to the cloud and generates an MCU memory usage curve based on historical logs to analyze memory changes.

[0094] The methods of the embodiments of this application will be further illustrated below.

[0095] In this embodiment, printing dynamic memory and static memory in the log includes dynamic memory (e.g., heap and stack usage) and static memory usage. For example, when the program corresponding to the MUC is an autonomous driving related program, printing dynamic memory in the log may include usage core0: 15%, core1: 44%, and core2: 28%, where usage core0 can represent the overall utilization rate of all memory resources allocated to core 0 (core0) in the microcontroller unit (MCU).

[0096] `core1` can represent the first processing core (core1) in the MCU, corresponding to an independent memory space and task scheduling context. `core2` can represent the second processing core (core2) in the MCU. In this embodiment, it is often used to run advanced driver assistance or autonomous driving related software modules. Static memory usage data is used to analyze the memory resource consumption trend of high-complexity algorithm modules (such as perception and planning). Printing static memory in the log can include: SRAM: 97.85%, ASW: 4.92%. SRAM can represent Static Random-Access Memory, which is a high-speed, low-latency volatile storage area inside the MCU, used to store runtime global variables, stack, and key real-time data. ASW can represent the application software layer, referring to the consumption of software components running at the application layer in the architecture.

[0097] Figure 2 This is a schematic diagram of a historical dynamic memory change curve according to an embodiment of this application, such as... Figure 2 As shown, taking the autonomous driving-related program corresponding to the MCU as an example, the horizontal axis of this historical dynamic memory change curve represents the time series or release version number of the MCU software version iteration. Each scale corresponds to a software firmware version built and flashed to the MCU through the CI / CD pipeline, which is used to characterize the evolution of memory usage trends with functional iterations. The vertical axis represents the dynamic memory utilization rate, that is, the percentage of the total allocated memory capacity occupied by the sum of heap memory and stack memory actually occupied by the MCU during runtime. This value is collected and reported in real time in IdleTask by the periodic monitoring function of this invention, reflecting the dynamic memory consumption of the system under real operating load.

[0098] The horizontal axis includes: V0: RamSize / k represents the total available RAM allocated to the MCU in firmware version 0 (V0), in kilobytes (kByte). It serves as a baseline reference for memory usage in all subsequent versions, used to normalize and compare memory pressure across different versions. V1: RamSize / k represents the total available RAM allocated to the MCU in firmware version 1 (V1), in kilobytes (kByte). This value may be adjusted from V0 due to the addition of new functional modules or expansion of data structures, used to assess the impact of version upgrades on memory resource allocation. V2: RamSize / k represents the total available RAM allocated to the MCU in firmware version 2 (V2), in kilobytes (kByte), used to compare the long-term impact of changes in RAM resource allocation strategies between versions V0 and V2 on dynamic memory usage.

[0099] Among them, 5apa can be used to represent the overall dynamic memory usage trend line of the Automatic Parking Assist (APA) system. The value is the sum of the stack memory of all sub-modules (including control, perception, and drive) of the APA module during operation. This curve is used to macroscopically monitor whether the memory growth of the APA functional domain exceeds the expected threshold.

[0100] Figure 2 In the diagram, 8apa_pk_ussSnsDrv can be used to represent the dynamic memory usage trend line of the APA ultrasonic sensor driver module. Its peak fluctuations reflect the dynamic memory allocation of the sensor data cache, filtering algorithm and real-time sampling queue during operation, and are a key monitoring point for detecting memory leaks or buffer overflows.

[0101] Figure 2 In the diagram, 6apa_pk_state_manager can be used to represent the dynamic memory usage trend line of the APA (Parking StateManager). A stable growth trend indicates that there is continuous memory allocation without release in the event queue, context saver, or historical trajectory cache inside the state machine, providing direct evidence for locating the root cause of memory leaks in this invention.

[0102] Figure 2 In this context, 2asw can be used to represent the dynamic memory usage trend line of application software layer modules, covering all functional components outside the BSW layer. The upward trend can be used to identify whether application layer algorithms (such as path planning and behavioral decision-making) have exhausted resources due to improper memory management during runtime.

[0103] Figure 2In the code, 4apa_generic can be used to represent the dynamic memory usage trend line of APA general function modules. It can represent the memory consumption of common components such as cross-platform reusable interface layer, configuration manager, and shared buffer, and is used to evaluate the memory efficiency and redundancy overhead of modular architecture.

[0104] Figure 2 In the diagram, 7apa_pk_control can be used to represent the dynamic memory usage trend line of the APA (Parking Control Module). It can periodically fluctuate to reflect the dynamic allocation behavior of temporary variables, intermediate parameters and state buffers of the PID / MPCC controller during real-time execution. It is a core indicator for analyzing the correlation between system real-time performance and memory jitter.

[0105] Figure 3 This is a schematic diagram of a historical static memory change curve according to an embodiment of this application, such as... Figure 3 As shown, taking the autonomous driving-related program corresponding to the MCU as an example, the horizontal axis of the historical static memory change curve is used to represent the time series or release version number of the MCU software version iteration. Each scale corresponds to a software firmware version built and flashed to the MCU through the CI / CD pipeline, which is used to characterize the evolution of memory usage trends with functional iterations. The vertical axis is used to represent the dynamic memory utilization rate, that is, the percentage of the sum of heap memory and stack memory actually occupied by the MCU during runtime to the total allocated memory capacity. This value is collected and reported in real time in IdleTask by the periodic monitoring function in this embodiment of the application, reflecting the dynamic memory consumption of the system under real operating load.

[0106] The horizontal axis includes: V0: RamSize / k represents the total available RAM allocated to the MCU in firmware version 0 (V0), in kilobytes (kByte). It serves as a baseline reference for memory usage in all subsequent versions, used to normalize and compare memory pressure across different versions. V1: RamSize / k represents the total available RAM allocated to the MCU in firmware version 1 (V1), in kilobytes (kByte). This value may be adjusted from V0 due to the addition of new functional modules or expansion of data structures, used to assess the impact of version upgrades on memory resource allocation. V2: RamSize / k represents the total available RAM allocated to the MCU in firmware version 2 (V2), in kilobytes (kByte), used to compare the long-term impact of changes in RAM resource allocation strategies between versions V0 and V2 on dynamic memory usage.

[0107] Among them, 8apa_pk_ussSnsDrv can be used to represent the dynamic memory usage trend of the ultrasonic sensor drive module in the automatic parking assist system. The memory usage mainly comes from the ultrasonic echo data buffer, the intermediate state of the filtering algorithm, the sensor calibration parameter table, and the runtime allocation of the real-time sampling queue. Due to the high-frequency data acquisition and buffer management, the above modules exhibit periodic memory jitter and potential cumulative allocation during system operation, and are the key monitoring objects used in this application embodiment to identify the risk of memory leaks or buffer overflows.

[0108] like Figure 3 As shown, 6apa_pk_state_manager can be used to represent the dynamic memory usage trend of the state manager module in the automatic parking assistance system. Memory consumption originates from state machine context saving, event trigger queues, historical trajectory caching, and temporary object allocation during switching processes. The above module exhibits a continuous memory growth trend during version iterations, indicating the existence of unreleased dynamically allocated resources. This provides direct evidence for locating the root cause of memory leaks in the embodiments of this application and supports the automated memory anomaly detection function.

[0109] Figure 3 In this context, `3localization_dr` can be used to represent the dynamic memory usage trend of the positioning driver module. This module is responsible for fusing GNSS, IMU odometry, and wheel speed sensor data to output high-precision pose estimation. Memory usage includes Kalman filter state vectors, covariance matrices, multi-sensor timestamp alignment buffers, and map matching caches. Due to its high algorithm complexity and large number of state variables, this module is one of the most significant dynamic memory-consuming modules in the MCU. This application embodiment achieves quantitative evaluation and anomaly warning of the positioning function's memory overhead by monitoring trends.

[0110] Figure 3 In this context, 4apa_generic can be used to represent the dynamic memory usage trends of common functional modules in an automated parking assistance system. This includes runtime allocation for cross-platform reused configuration managers, common data structures, interface adaptation layers, and shared resource pools. The memory changes of these modules reflect the memory efficiency of the modular architecture. If they continue to increase, it indicates redundancy or uncleaned state in common components, making it an important indicator for evaluating the maintainability and resource utilization of the software architecture.

[0111] Figure 3 In this context, 1GhsLib can be used to represent the dynamic memory usage trends of the Green Mountain Compiler Runtime Library (GHS Runtime Library). The aforementioned part is not user code, but rather dynamic stack allocation caused by standard library functions (such as exception handling and floating-point operation support) automatically embedded by the GHS compiler during the linking stage.

[0112] Figure 3 In this context, 5apa can be used to represent the overall dynamic memory usage trend of the automatic parking assist system. This curve is the sum of the runtime stack memory of all APA sub-modules (including control, drive, state management, general modules, etc.), used to macroscopically characterize the overall memory load pressure of the APA functional domain during system operation, and is a global monitoring indicator for judging whether the function exceeds the upper limit of MCU memory capacity.

[0113] Figure 3 In this context, 2asw can be used to represent the dynamic memory usage trend of application software layer modules, covering all functional components of the non-basic software layer (BSW) in the automotive open system architecture, such as the runtime memory allocation of advanced algorithms like behavior decision-making, path planning, and scene management. This curve reflects the direct consumption of system resources by the application layer. If it shows an unexpected growth trend, it indicates a memory management defect in the application layer code, providing data support for the "automatic alarm for application layer memory anomalies" in this invention.

[0114] Figure 4 This is a flowchart of an MCU memory monitoring process according to an embodiment of this application, such as... Figure 4 As shown, the MCU memory monitoring flowchart includes the following steps.

[0115] Step S402, dynamic memory monitoring function.

[0116] Optionally, dynamic memory includes heap and stack memory. In the IdleTask, data verification begins from the end address of the heap and proceeds backward; if the data is 0, the region is considered unused; if non-zero data is obtained, the region is considered used. Monitoring data is initialized through a startup hook function (StartupHook), and the stack monitoring process is initiated by calling the IdleTaskHook function, including the Basic Software Stack Memory Monitoring task. The Task (BswStackMTask) is used to obtain the current stack usage. After starting stack memory monitoring, BswStackMTask periodically returns the current stack usage to the IdleTaskHook function. The printing task function then periodically obtains the current data from the IdleTaskHook function by requesting stack data. When the stack data is updated, the IdleTaskHook function returns the updated stack usage to the printing task function. The offset is defined as the distance from the start address to the monitoring address. When non-zero data is detected, the minimum offset is obtained. The usage rate is the minimum offset address divided by the total heap memory area. The offset is reset to the maximum, and the above process is repeated to update the maximum heap usage.

[0117] Optionally, step S402 above can realize the automated and periodic collection of dynamic memory of the MCU runtime heap and stack, breaking through the limitations of traditional methods that rely on debuggers or manually insert monitoring code, forming a lightweight runtime memory monitoring mechanism that can be embedded in mass-produced firmware, providing an accurate, continuous, and reproducible data source for subsequent historical trend analysis.

[0118] In step S404, cicd triggers mutation to generate mcu0.hex and map files.

[0119] Optionally, cicd triggers the compilation of the MCU program, generating mcu0.hex and map files.

[0120] Optionally, step S404 above can automate and standardize the firmware build process, providing accurate and traceable compilation artifacts for static memory analysis, ensuring that static memory data strictly corresponds to runtime code, and avoiding the risk of version mismatch caused by manual intervention.

[0121] In step S406, cicd calls Python to analyze the map file and obtain static memory.

[0122] Optionally, the static memory of the above map file can be extracted using a Python script to generate static memory statistics.

[0123] Optionally, step S406 above can be used to automatically extract and quantify static memory allocation, completely eliminating the inefficiency and error-proneness of manually checking map files and manually calculating memory usage, making static memory data an engineering indicator that can be processed by machines and managed in a versioned manner.

[0124] Step S408: Write the static memory to the preset address of the mcu0.hex file to generate a new hex file.

[0125] Optionally, a variable is defined to pre-store static memory information. This variable is written to a predetermined address in mcu0.hex to generate a new hex file. This hex file is the final programming file burned into the MCU, which contains dynamic memory printing information and static memory printing information.

[0126] Optionally, step S408 above can achieve the integrated solidification of static memory information and dynamic code, embedding static allocation data that originally only existed during compilation into the runtime MCU memory space in the form of readable variables, so that static memory can be read by the program itself, laying the foundation for subsequent real-time synchronization and reporting of dynamic and static memory.

[0127] Step S410: Print dynamic memory and static memory to the MCU.

[0128] Optionally, the MCU's dynamic and static memory can be printed out using MCU printing functions.

[0129] Since the MCU's log is stored in memory and is lost upon power-off, while the SOC's flash storage space is large and is not lost upon power-off, it is necessary to transfer the MCU's log to the SOC.

[0130] Optionally, through the above step S410, the unified formatted output of dynamic and static memory data can be realized locally on the MCU to form structured log entries, providing a standardized data carrier for cross-device log transmission.

[0131] In step S412, the MCU sends the log to the SOC.

[0132] Optionally, the MCU's log can be transferred to the SOC using UDP communication between the MCU and the SOC.

[0133] Optionally, step S412 above can establish an efficient log upload mechanism between the MCU and SOC that does not require a complex protocol stack or handshake confirmation, ensuring that memory monitoring logs are not lost due to communication blockage in real-time sensitive automotive environments, thus meeting the basic requirements of automotive-grade functional safety for data integrity and timeliness.

[0134] Step S414: The SOC uploads the data to the MCU, logs it to the cloud, and generates a memory usage curve.

[0135] Optionally, the SOC uploads the MCU log to the cloud via Ethernet communication. The cloud analyzes the MCU's historical memory data and calls Python functions to plot the memory data into a graph for developers to analyze.

[0136] Optionally, step S414 above can be used to construct a three-level memory monitoring closed loop from MCU to SOC to the cloud, enabling intelligent analysis of massive amounts of data from single-point collection. This allows developers to intuitively identify, through visual curves, which software version introduces memory leaks; which functional module has abnormal memory growth; and whether static memory allocation has become uncontrollable as functions evolve. This allows for memory optimization before mass production, significantly reducing the risk of system crashes due to memory exhaustion and improving the reliability of the vehicle software.

[0137] Figure 5 This is a schematic diagram of a heap memory acquisition module according to an embodiment of this application, as shown below. Figure 5 As shown, the MCU memory monitoring and processing module includes: heap start address 502, offset address 504, heap end address 506, maximum used area 508, minimum offset address 510, non-filled data 512, and unused area 514.

[0138] The heap start address 502 represents the starting physical address of the MCU dynamic heap memory region. This address is statically allocated by the linker script during compilation and identifies the lowest effective address boundary of the heap memory. It is the reference point for calculating the heap usage offset.

[0139] Offset address 504 is used to represent the byte offset of the currently detected memory unit relative to the heap start address 502 during the byte-by-byte scan from the heap start address 502 to the heap end address 506, and is used to quantify the relative position of the current probe location in the heap space.

[0140] The heap end address 506 is used to represent the terminating physical address of the MCU dynamic heap memory region. It is set by the linker configuration or heap size parameters during system initialization, and identifies the highest effective address boundary of the heap memory. Together with the heap start address 502, it defines the total heap memory capacity (total heap size = heap end address - heap start address).

[0141] The maximum usage area 508 represents the memory region covered by the highest heap usage boundary reached in the history during multiple periodic scans. This area extends from the heap start address 502 to the minimum offset address 510 of the most recent record and is used to reflect the peak memory pressure during system operation. It is a key indicator for evaluating memory resource redundancy and safety margin.

[0142] The minimum offset address 510 is used to represent the offset value of the byte address of the non-filled data 512 relative to the heap start address 502 when it is first detected in the current scan from the heap end address 506 to the heap start address 502 (the monitoring direction). This value marks the minimum boundary that is actually used at present and is the core basis for calculating the real-time heap utilization rate (heap utilization rate = minimum offset address 510 / total heap size).

[0143] The non-filled data 512 is used to represent the bytes in the heap memory that have been allocated by the program and written with valid data (non-initialized values ​​0x00 or 0xFF). Its existence indicates that the corresponding memory unit has been dynamically allocated (e.g., through malloc, new, etc.) and used to store variables, structures, or buffer data. It is a key criterion for determining that "memory has been used".

[0144] Unused region 514 represents a contiguous memory region located between the minimum offset address 510 and the end of the heap address 505, where all bytes are filled with preset values ​​(e.g., 0x00 or 0xCC). This indicates that the region has not been occupied by any runtime objects and can be used for subsequent dynamic memory allocation. It is a physical representation of the remaining capacity of the heap memory.

[0145] The monitoring direction indicates the traversal direction of the memory scan. In this embodiment, it is a reverse scan from the end address of the heap (505) to the start address of the heap (502). The minimum offset address can be obtained by subtracting the start address of the heap from the end address.

[0146] Figure 6 This is a flowchart of a stack memory acquisition method according to an embodiment of this application, such as... Figure 6 As shown, this heap memory acquisition method includes a startup hook function, an idle task hook function, a memory monitoring function, and a log printing function.

[0147] Optionally, after the hook function initializes the monitoring data and starts the monitoring process, the idle task hook function can request stack data from the memory monitoring function, and then the memory monitoring function can periodically return stack data to the idle task hook function; the log printing function can request stack data from the idle task hook function, and the idle task hook function can periodically return stack data to the log printing function; after the idle task hook function periodically returns stack data to the log printing function, the memory monitoring function updates the stack data and periodically returns stack data to the idle task hook function; the idle task hook function updates the stack utilization rate and periodically returns stack data to the log printing function, and after the idle task hook function updates the stack utilization rate and periodically returns stack data to the log printing function, the log printing function can update the stack utilization rate; and print the stack data.

[0148] In this embodiment, the method described above, in response to the microcontroller unit being in a configuration state, stores the static memory information of the microcontroller unit at a target address in the microcontroller unit's memory; in response to the microcontroller unit switching from a configuration state to a running state, acquires the dynamic memory information of the microcontroller unit and acquires the static memory information from the target address; based on the dynamic memory information and the static memory information, determines the memory usage information of the microcontroller unit. In other words, in this embodiment, by synchronously acquiring static and dynamic memory information when the microcontroller unit is in the running phase, and based on the synchronously acquired static and dynamic memory information, the memory usage information of the microcontroller unit can be further determined. This overcomes the obstacle in related technologies where static and dynamic memory information can only be acquired in isolation, and acquiring static and dynamic memory information requires additional external hardware or manual intervention, resulting in low memory monitoring efficiency for the microcontroller unit. Thus, it achieves the technical effect of improving the memory monitoring efficiency of the microcontroller unit and solves the technical problem of low memory monitoring efficiency for the microcontroller unit.

[0149] Figure 7 This is a schematic diagram of a memory monitoring device for a microcontroller unit in a vehicle according to an embodiment of this application, as shown below. Figure 7As shown, the memory monitoring device 70 of the microcontroller unit in the vehicle includes: a storage unit 702, an acquisition unit 704, and a determination unit 706.

[0150] Storage unit 702 is used to store the static memory information of the microcontroller unit to the target address of the microcontroller unit's memory in response to the microcontroller unit being in a configuration state. The static memory information is used to represent the occupancy status of the vehicle's static data in memory. The static data is state data that remains fixed during vehicle operation.

[0151] The acquisition unit 704 is used to acquire the dynamic memory information of the microcontroller unit and the static memory information from the target address in response to the microcontroller unit switching from the configuration state to the running state. The dynamic memory information is used to represent the memory occupancy status of the vehicle's dynamic data, and the dynamic data is the number of states that change during the operation of the vehicle.

[0152] The determination unit 706 is used to determine the memory usage information of the microcontroller unit based on dynamic memory information and static memory information. The memory usage information is used to represent the trend of memory usage over time during the operation of the microcontroller unit.

[0153] Furthermore, the storage unit 702 may include a compilation module, configured to perform a compilation operation on the program of the microcontroller unit in response to the microcontroller unit being in the configuration state, and obtain a compilation result, wherein the compilation result is used to represent the allocation state of the static memory of the microcontroller unit; the storage module is configured to use the compilation result to store the static memory information to the target address.

[0154] Furthermore, the compilation module may include a first compilation submodule, which, in response to the microcontroller unit being in the configuration state, performs the compilation operation on the program to obtain the target program file and the memory-mapped file.

[0155] Furthermore, the storage module may include an extraction submodule for extracting the static memory information from the memory-mapped file; a writing submodule for writing the extracted static memory information to the target address corresponding to the target program file; and a flashing submodule for flashing the target program file written to the target address to the microcontroller unit.

[0156] Furthermore, the acquisition unit 704 may include a generation module for generating log information of the microcontroller unit based on the dynamic memory information and the static memory information; and a determination module for determining the memory usage information based on the log information.

[0157] Furthermore, the device also includes a verification module, configured to, in response to the microcontroller unit being in the running state, perform data verification from the end address of the heap to the start address of the heap, obtain a verification result, and determine the heap memory information based on the verification result, wherein the verification result is used to indicate whether the dynamic data occupies the area between the end address and the start address; and a determination module, configured to, in response to the microcontroller unit being in the running state, obtain the stack occupancy rate, and determine the stack memory information based on the occupancy rate, wherein the occupancy rate is used to indicate the degree of space occupancy of the stack.

[0158] Furthermore, the verification module may include a first determining submodule, configured to determine the verification result as dynamic data occupying the area in response to the microcontroller unit being in the running state and the data in the area being preset data; a second determining submodule, configured to determine the verification result as dynamic data not occupying the area in response to the microcontroller unit being in the running state and the data in the area being non-preset data; a third determining module, configured to determine the minimum offset of the memory based on the non-preset data in response to the verification result as dynamic data occupying the area; and a fourth determining submodule to determine the heap memory information based on the minimum offset.

[0159] Furthermore, the determining module may include a calling submodule, used to call a stack monitoring function to monitor the stack and obtain the utilization rate in response to the microcontroller unit being in the running state; a transmission submodule, used to transmit the utilization rate determined by the stack monitoring function to a log printing task function through an idle task hook function; and a processing submodule, used to process the utilization rate using the log printing task function to obtain the stack memory information.

[0160] In the embodiments of this application, the storage unit 702, in response to the microcontroller unit being in a configuration state, stores the static memory information of the microcontroller unit to a target address in the microcontroller unit's memory. The static memory information represents the memory occupancy status of the vehicle's static data, which is state data that remains fixed during vehicle operation. The acquisition unit 704, in response to the microcontroller unit switching from a configuration state to a running state, acquires the dynamic memory information of the microcontroller unit and obtains the static memory information from the target address. The dynamic memory information represents the memory occupancy status of the vehicle's dynamic data, which is the number of states that change during vehicle operation. The determination unit 706, based on the dynamic and static memory information, determines the memory occupancy information of the microcontroller unit. The memory occupancy information represents the trend of memory occupancy status changing over time while the microcontroller unit is in a running state, thereby achieving the technical effect of improving the memory monitoring efficiency of the microcontroller unit and solving the technical problem of low memory monitoring efficiency of the microcontroller unit.

[0161] Embodiments of this application also provide an electronic device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application during runtime.

[0162] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0163] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0164] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0165] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0166] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0167] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0168] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0172] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for monitoring the memory of a microcontroller unit in a vehicle, characterized in that, include: In response to the microcontroller unit being in a configuration state, the static memory information of the microcontroller unit is stored in the target address of the microcontroller unit's memory, wherein the static memory information is used to represent the occupancy status of the vehicle's static data in the memory, and the static data is state data that remains fixed during the operation of the vehicle; In response to the microcontroller unit switching from the configuration state to the running state, the dynamic memory information of the microcontroller unit is obtained, and the static memory information is obtained from the target address, wherein the dynamic memory information is used to represent the occupancy status of the vehicle's dynamic data in the memory, and the dynamic data is the state data that changes during the operation of the vehicle; Based on the dynamic memory information and the static memory information, the memory usage information of the microcontroller unit is determined, wherein the memory usage information is used to represent the trend of the memory usage status changing over time when the microcontroller unit is in the running state.

2. The method according to claim 1, characterized in that, In response to the microcontroller unit being in a configuration state, storing the static memory information of the microcontroller unit to a target address in the memory of the microcontroller unit includes: In response to the microcontroller unit being in the configuration state, a compilation operation is performed on the program of the microcontroller unit to obtain a compilation result, wherein the compilation result is used to represent the allocation state of the static memory of the microcontroller unit; Using the compilation results, the static memory information is stored at the target address.

3. The method according to claim 2, characterized in that, The compilation result includes an object program file and a memory-mapped file. The object program file represents the data layout state of the microcontroller unit, and the memory-mapped file represents the memory usage distribution state. In response to the microcontroller unit being in a configured state, a compilation operation is performed on the program of the microcontroller unit to obtain the compilation result, including: In response to the microcontroller unit being in the configured state, the compilation operation is performed on the program to obtain the target program file and the memory-mapped file.

4. The method according to claim 3, characterized in that, Using the compilation result, storing the static memory information to the target address includes: Extract the static memory information from the memory-mapped file; The extracted static memory information is written to the target address corresponding to the target program file; And / or, The method further includes: flashing the target program file written to the target address into the microcontroller unit.

5. The method according to claim 1, characterized in that, Based on the dynamic memory information and the static memory information, the memory usage information of the microcontroller unit is determined, including: Based on the dynamic memory information and the static memory information, the log information of the microcontroller unit is generated; Based on the log information, the memory usage information is determined.

6. The method according to any one of claims 1 to 5, characterized in that, The memory includes a heap and a stack, and the dynamic memory information includes heap memory information and stack memory information. The heap memory information is used to indicate the occupancy status of the dynamic data in the heap, and the stack memory information is used to indicate the occupancy status of the dynamic data in the stack. In response to the microcontroller unit being in a running state, the dynamic memory information of the microcontroller unit is obtained, including: In response to the microcontroller unit being in the running state, data verification is performed from the end address of the heap to the start address of the heap to obtain a verification result, and the heap memory information is determined based on the verification result, wherein the verification result is used to indicate whether the dynamic data occupies the area between the end address and the start address; In response to the microcontroller unit being in the running state, the stack occupancy rate is obtained, and based on the occupancy rate, the stack memory information is determined, wherein the occupancy rate is used to represent the degree of space occupancy of the stack.

7. The method according to claim 6, characterized in that, In response to the microcontroller unit being in the running state, data verification is performed from the end address of the heap to the beginning address of the heap to obtain the verification result, including: In response to the microcontroller unit being in the running state and the data in the area being preset data, the verification result is determined to be that the dynamic data occupies the area; In response to the microcontroller unit being in the running state and the data in the area being non-preset data, the verification result is determined to be that the dynamic data does not occupy the area; And / or, Based on the verification result, the heap memory information is determined, including: In response to the verification result indicating that the dynamic data occupies the area, the minimum offset of the memory is determined based on the non-preset data; The heap memory information is determined based on the minimum offset.

8. The method according to claim 6, characterized in that, In response to the microcontroller unit being in the running state, the stack occupancy rate is obtained, including: In response to the microcontroller unit being in the running state, a stack monitoring function is called to monitor the stack and obtain the occupancy rate; And / or, Based on the occupancy rate, the stack memory information is determined, including: The occupancy rate determined by the stack monitoring function is transmitted to the log printing task function via the idle task hook function; The occupancy rate is processed using the log printing task function to obtain the stack memory information.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8.

Images