Brush writing method and device, equipment, storage medium and program product

Abstract

The invention relates to a flashing method and device, equipment, a storage medium and a program product. The method comprises the steps that a flashing initial address indicated in a to-be-processed flashing request is acquired; if the flashing starting address is located outside the memory range corresponding to the first controller, a preset interface corresponding to a second controller is called according to the flashing starting address, flashing operation is conducted on the second controller, and the second controller is mounted under the first controller. The controller needing to be flashed is dynamically recognized through the memory address range, the requirement for computing resources of the first controller is lowered, the standard first controller can efficiently complete the flashing task of the second controller hung below, and the flashing flexibility and efficiency of the controller are improved.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a brushing method, apparatus, device, storage medium, and program product. Background Technology

[0002] In embedded controller software upgrade applications, standard controllers (such as electronic control units that conform to standard protocols) often need to have their connected non-standard controllers (controllers that do not conform to standard protocols, such as onboard chips or other auxiliary controllers) flashed.

[0003] However, due to the limited hardware and software resources of standard controllers (e.g., lack of file system support), they cannot directly identify the non-standard controllers that need to be flashed based on the downloaded file content, thus limiting the flashing process for non-standard controllers. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a flashing method, apparatus, device, storage medium, and program product, which realizes dynamic identification of the controller to be flashed through the memory address range, reduces the computing resource requirements of the first controller, and enables the standard first controller to efficiently complete the flashing task of the connected second controller, thereby improving the flexibility and efficiency of controller flashing.

[0005] In a first aspect, embodiments of this disclosure provide a flashing method, comprising: obtaining a flashing start address indicated in a flashing request to be processed; if the flashing start address is outside the memory range corresponding to a first controller, calling a preset interface corresponding to a second controller according to the flashing start address to perform a flashing operation on the second controller, wherein the second controller is mounted under the first controller.

[0006] Secondly, embodiments of this disclosure provide a controller writing device, comprising:

[0007] The acquisition module is used to obtain the start address of the flashing request indicated in the pending flashing request;

[0008] The flashing module is used to call the preset interface corresponding to the second controller according to the flashing start address if the flashing start address is outside the memory range corresponding to the first controller, and to perform a flashing operation on the second controller, which is mounted under the first controller.

[0009] Thirdly, embodiments of this disclosure provide a vehicle, including:

[0010] At least one processor; and

[0011] A memory that is communicatively connected to the at least one processor;

[0012] The memory stores instructions executable by the at least one processor, which is configured to execute the instructions to implement the method described in any of the above aspects.

[0013] Fourthly, embodiments of this disclosure provide an electronic device, including:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to the at least one processor;

[0016] The memory stores instructions executable by the at least one processor, which is configured to execute the instructions to implement the method described in any of the above aspects.

[0017] Fifthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in any of the above aspects.

[0018] Sixthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above aspects.

[0019] In a seventh aspect, embodiments of this disclosure provide a controller flashing system, including a server and a terminal, wherein the terminal and the server interact via data to implement the method described in any of the above aspects.

[0020] The flashing method, apparatus, device, storage medium, and program product provided in this disclosure obtain the flashing start address in the flashing request and use this flashing start address as the basis for identifying the controller. If the flashing start address is not within the memory range of the first controller, it indicates that the flashing target of the flashing request is not the first controller, but a second controller attached to the first controller needs to be flashed. In this case, the flashing process for the second controller is automatically triggered, that is, the preset interface of the second controller corresponding to the flashing start address is called to perform a precise flashing operation on the second controller. In this way, the flashing process does not rely on the file system, transforming the complex controller identification problem into a simple hardware-level identification of the memory address range. This solves the problem in traditional technology where the standard first controller cannot directly identify the object to be flashed due to limited hardware and software resources, reduces the demand on the computing resources of the first controller, and enables the standard first controller to efficiently complete the flashing task of the attached second controller, improving the flexibility and efficiency of controller flashing. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It will be apparent that the drawings described below are some embodiments of this disclosure, and that those skilled in the art can derive other drawings from these drawings without any inventive effort.

[0022] Figure 1 A flowchart illustrating a flashing method provided in an embodiment of this disclosure;

[0023] Figure 2 This is a schematic diagram of memory address partitioning provided in an embodiment of the present disclosure;

[0024] Figure 3 A schematic diagram of a controller node based on a device tree provided in this disclosure embodiment;

[0025] Figure 4 This is a schematic diagram illustrating an application scenario of the writing method provided in this disclosure;

[0026] Figure 5 This is a schematic diagram of the structure of a controller writing device provided in an embodiment of the present disclosure;

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure;

[0028] Figure 7 This is a schematic diagram illustrating an application scenario of a controller flashing system provided in an embodiment of this disclosure;

[0029] Figure 8 This is a schematic diagram of the structure of a vehicle provided in an embodiment of the present disclosure.

[0030] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0032] In this article, the term "and / or" is used to describe the relationship between related objects. Specifically, it means that there can be three kinds of relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, or B exists alone.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0034] In order to clearly describe the technical solutions of the embodiments of this disclosure, the terms involved in this disclosure are first defined as follows:

[0035] ECU: Electronic Control Unit.

[0036] ISO: International Organization for Standardization.

[0037] UDS: Unified Diagnostic Services. This protocol is a diagnostic communication framework for automotive electronic systems defined in the ISO 14229 standard, which supports core diagnostic functions such as reading fault codes from ECUs, controlling actuators, and executing routines.

[0038] DTC: Diagnostic Trouble Code.

[0039] 0x31 Service: Routine Control.

[0040] MBF: Memory Block Format.

[0041] ZCU: Zone Control Unit.

[0042] Flash: Non-volatile memory.

[0043] BLDC: Brushless Direct Current Motor.

[0044] The controller flashing method of this disclosure can be applied to any field that requires flashing the controller memory.

[0045] Taking the software upgrade scenario of an embedded controller in a vehicle (such as an ECU) as an example, in practical applications, flashing embedded controllers typically relies on standard protocols for memory erasure and data writing operations. Standard controllers (such as ECUs conforming to ISO standards) usually require flashing of their underlying non-standard controllers (such as onboard chips or other auxiliary controllers).

[0046] However, in related technologies, due to the limited hardware resources of standard controllers (e.g., lack of file system support), it is impossible to directly identify the non-standard controller that needs to be flashed based on the downloaded file content. Furthermore, some industry standards (such as enterprise standards or ISO standards) impose strict restrictions on the format of the flashing process, making it impossible to explicitly identify the target non-standard component through diagnostic commands within the flashing sequence of a standard controller. This limitation makes it difficult to efficiently and flexibly support the unified flashing requirements of multiple non-standard controllers, especially in scenarios requiring dynamic expansion of downstream controllers, resulting in significant technical deficiencies.

[0047] To address at least one of the aforementioned problems, this disclosure provides a flashing scheme. By obtaining the flashing start address from the flashing request and using this address as the basis for controller identification, if the flashing start address is not within the memory range of the first controller, it indicates that the flashing target of the request is not the first controller, but rather a second controller mounted under the first controller. In this case, the flashing process for the second controller is automatically triggered, i.e., calling the preset interface of the second controller corresponding to the flashing start address to perform a precise flashing operation on the second controller. Thus, the flashing process does not rely on the file system, transforming the complex controller identification problem into a simple hardware-level identification of the memory address range. This solves the problem in traditional technologies where the standard first controller cannot directly identify the object to be flashed due to limited hardware and software resources, reducing the computational resource requirements of the first controller. This allows the standard first controller to efficiently complete the flashing task of the mounted second controller, improving the flexibility and efficiency of controller flashing.

[0048] The following detailed description of some embodiments of this disclosure is provided in conjunction with the accompanying drawings. Where there is no conflict between the embodiments, the following embodiments and features can be combined with each other. Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0049] Please refer to Figure 1 This is a flashing method according to an embodiment of the present disclosure, which can be performed by... Figure 6 The electronic device 6 shown is used to perform this function and can be applied to... Figure 7In the controller flashing application scenario shown, the controller that needs to be flashed is dynamically identified by memory address range, reducing the computational resource requirements of the first controller. This allows the standard first controller to efficiently complete the flashing task of the connected second controller, improving the flexibility and efficiency of controller flashing. This embodiment uses a standard vehicle controller as the execution end as an example, and the method includes the following steps:

[0050] Step 101: Obtain the start address for flashing as indicated in the pending flash request.

[0051] In this step, the flashing request can be obtained according to actual needs. For example, it can be triggered by diagnostic software running on a computer to send a flashing request to the vehicle controller. The flashing request must include at least the flashing start address for this flashing task, and includes, but is not limited to, memory erase requests and data write requests. The flashing start address can be obtained by parsing the MBF file corresponding to this flashing using a diagnostic tool, and then sent to the first controller via the flashing request. Specifically, taking memory erase in a vehicle ECU flashing scenario as an example, the erase request can be implemented through the 0x31 diagnostic service message.

[0052] In the field of automotive electronics, the ECU is the core control module of a vehicle, responsible for managing specific systems through sensor inputs and actuator outputs. Its functions include real-time data processing, fault diagnosis, and control strategy execution, making it a key component of the vehicle's electronic architecture. The 0x31 service in the UDS protocol is a core service used to execute specific diagnostic routines on the ECU. The 0x31 service implements in-depth diagnostic and maintenance operations through predefined routine sequences, including memory erasure, such as erasing the target area before firmware upgrades. Figure 1 shows a vehicle ECU flashing flowchart provided in an embodiment of this disclosure:

[0053] Table 1. ECU flashing process

[0054]

[0055] The memory erase routine message for service 0x31 can include the following six parts:

[0056] 31 01 FF00 44 0103E000 00002000

[0057] The meanings of each field are as follows:

[0058] "31" indicates diagnostic routine control service.

[0059] "01" indicates the start of the routine.

[0060] “FF00” indicates the memory erase routine.

[0061] "44" indicates that the erase start address is represented by 4 bytes and the erase length is represented by 4 bytes.

[0062] “0103E000” indicates the starting address for erasure.

[0063] "00002000" indicates the erase length.

[0064] During the controller flashing process, the data on the Flash (a non-volatile memory) is first erased using the memory erase routine, and then the data is written. The starting address and erase length of the erased Flash memory can be reflected in the message. Therefore, different starting addresses can be assigned to different controllers in the message and sent as a flashing request to the first controller.

[0065] In one embodiment, prior to step 101, the method further includes: determining a first memory space occupied by the first controller; configuring a second memory space occupied by the second controller based on the first memory space, wherein the starting address of the second memory space is greater than the ending address of the first memory space.

[0066] In this embodiment, the first controller can be a standard controller conforming to a standard protocol, such as an ECU conforming to the ISO standard. The second controller can be a controller that does not conform to a standard protocol, such as an onboard chip or other auxiliary controller attached to a standard ECU. The memory space occupied by the controller can be used to store the data blocks required by the controller. Before flashing, memory space is pre-allocated for the second controller. First, the first memory space occupied by the first controller is determined, and the memory space of the second controller is dynamically configured based on the first memory space to ensure that the starting address of the second memory space is strictly greater than the ending address of the first memory space. For example, in the MBF file, the starting address of the data block of the non-standard controller (i.e., the second controller) to be flashed is set to be greater than the ending address of the standard controller (i.e., the first controller). Assuming that the upper limit of the address range specified in the memory layout of the first controller is 0xBXXX XXXX, then the address range of the second controller 1 attached to it can be set to 0xB000 0000-0xBXXX XXXX. In the MBF file, an address offset of 0xC000 0000 can be added to the memory corresponding to the software data of the second controller 1.

[0067] By employing a memory address isolation mechanism, it is ensured that the memory spaces of the two controllers do not overlap, fundamentally preventing data overwriting or access anomalies caused by address contention. Dynamically allocating space for the second controller based on the actual memory requirements of the first controller reduces memory fragmentation, makes resource allocation more precise, and provides a standardized configuration interface for subsequent additions of controllers or functional modules, supporting collaborative work between controllers with different memory capacities.

[0068] In one embodiment, configuring a second memory space occupied by the second controller based on a first memory space includes: determining the memory requirements of the software data of the second controller; and configuring the capacity of the second memory space based on the first memory space and the memory requirements, wherein the capacity of the second memory space is greater than or equal to the memory requirements.

[0069] In this embodiment, the software data of the second controller relies on memory space to operate. If the memory requirements of the first memory space and the software data are not considered when configuring the second memory space directly, it may lead to insufficient memory allocation or memory redundancy. In this embodiment, the memory requirements of the second controller's software data are estimated and determined in advance before the controller is written. For example, when configuring the MBF file, the size of the software data segment of the second controller is multiplied by a safety factor greater than 1 to obtain the reserved memory size of the second controller. Then, combined with the capacity of the first memory space of the first controller, the capacity of the second memory space is configured to ensure that the capacity of the second memory space is greater than or equal to the memory requirement, ensuring that the capacity of the second memory space covers the memory requirements of the second controller's software data, ensuring that the software data can be stored completely, and avoiding operational failures due to insufficient memory. Furthermore, the configuration fully considers the correlation between the first memory space and the requirement, avoiding memory waste caused by blind allocation and improving the utilization rate of system memory resources.

[0070] Optionally, the safety factor can be dynamically adjusted based on the historical write failure rate of the second controller. For example, the safety factor can be increased when the failure rate is high and decreased when the failure rate is low. Dynamically adjusting the safety factor solves the static redundancy problem in memory planning. Specifically, the historical failure rate of the second controller can be recorded during the write process; for example, the probability of a write failure due to address conflict for a certain second controller can be recorded as 5%. If the failure rate exceeds a threshold (e.g., 3%), the safety factor is automatically increased (e.g., from 1.5 to 2.0) to reserve more memory to avoid conflicts. If the failure rate is below the threshold, the safety factor is decreased (e.g., adjusted to 1.2) to release redundant memory. Memory allocation is optimized through a real-time feedback mechanism, avoiding resource waste or insufficiency caused by a static safety factor.

[0071] In one embodiment, configuring the capacity of the second memory space based on the first memory space and memory requirements includes: determining the capacity of the second memory space occupied by each second controller based on the memory requirements of the software data of each second controller; and configuring the memory start address of each second controller based on the end address of the first memory space and the capacity of the second memory space. Specifically, the memory start address of the first second controller following the first controller is greater than the memory end address of the first controller, and the memory start addresses of subsequent second controllers are sequentially offset based on the capacity of the second memory space occupied by the preceding second controller.

[0072] In this embodiment, for scenarios where multiple second controllers are mounted under a first controller, such as a scenario where multiple auxiliary controllers are mounted under an ECU conforming to the ISO standard, in order to avoid problems such as data overwriting, flashing failure, and resource waste caused by memory address conflicts, the memory start address of the corresponding second controller can be configured based on the first memory space termination address corresponding to the first controller and the memory requirement capacity of the second controller. By configuring the memory start address of the first second controller after the first controller to be greater than the memory termination address of the first controller, and the memory start addresses of the subsequent multiple second controllers are sequentially offset according to the memory requirement capacity of the previous second controller, the memory ranges of the first controller and the second controllers, as well as the various second controllers, do not interfere with each other, avoiding flashing failures caused by address conflicts, ensuring the continuity and independence of memory addresses, satisfying the memory requirements of the software data of each controller, and maximizing the use of the remaining memory after the first memory space through address offset, thus reducing memory waste.

[0073] In real-world scenarios, when creating an MBF file, the size of the data segment for each second controller can be planned based on the total number of second controllers in the actual project. The size of the data segment is then multiplied by a safety factor greater than 1 to obtain the reserved memory size for that second controller. The starting addresses of each second controller after the first second controller in the MBF file are all offset relative to the reserved memory segment size of the second controller preceding it.

[0074] like Figure 2The diagram illustrates a memory address partitioning scheme provided in this embodiment of the present disclosure. Taking the transmission of the erase start address of each controller via the 0x31 service as an example, it assumes that the termination address of the first memory space occupied by the first controller conforming to the standard is 0xBXXX XXXX, and n second controllers are connected under the first controller, where n is a positive integer. In the MBF file, the starting address of the second memory space occupied by the second controller 1 can be configured as 0xC000 0000. The memory range 0xBXXX XXXX-0xC000 0000 is reserved for the first controller, ensuring normal write operation even if the data block of the first controller subsequently increases.

[0075] Assume the software data memory requirement of the first second controller 1 is in the address range 0xC000 0000-0xCXXX XXXX. The starting address of the memory for the second controller 2 can be configured as 0xD000 0000, where the memory range 0xCXXXXXXX-0xD000 0000 is reserved for the second controller 1. This ensures normal data writing even if the data blocks of the second controller 1 increase in size. Similarly, subsequent second controllers 2 can also reserve corresponding memory space. For example, the starting address of the memory for the second controller 3 can be set to 0xE000 0000, where the memory range 0xDXXX XXXX-0xE000 0000 is reserved for the second controller 2. This also ensures normal data writing even if the data blocks of the second controller 2 increase in size. And so on, subsequent second controllers can be configured according to this principle.

[0076] Step 102: If the flashing start address is outside the memory range corresponding to the first controller, call the preset interface corresponding to the second controller according to the flashing start address to perform the flashing operation on the second controller. The second controller is mounted under the first controller.

[0077] In this step, the flashing start address is used as the basis for controller identification. If the flashing start address is not within the memory range of the first controller, it means that the flashing target of the request is not the first controller, but a second controller mounted under the first controller needs to be flashed. In this case, the preset interface of the second controller corresponding to the flashing start address is called to perform a precise flashing operation on the second controller. In this way, the flashing process does not rely on the file system, transforming the complex controller identification problem into a simple hardware-level identification of the memory address range. This solves the problem in traditional technology where the standard first controller cannot directly identify the object to be flashed due to limited hardware and software resources, thus improving the flexibility and efficiency of controller flashing.

[0078] For example, if the first controller identifies the erase start address sent by the 0x31 service message as being greater than the memory end address of the first controller, it can further identify which auxiliary controller (i.e., the second controller) the erase start address belongs to, and then call the relevant write interface of the auxiliary controller to perform the erase operation on the auxiliary controller.

[0079] In one embodiment, prior to step 102, the method further includes configuring a preset interface applicable to the flashing process for at least one second controller mounted under the first controller.

[0080] In this embodiment, a preset interface is used to perform specific flashing operations. This preset interface includes, but is not limited to, memory read, write, and erase interfaces. By pre-configuring the interface information required for flashing for each second controller, it is ensured that when the flashing start address is called, the instruction can accurately match the corresponding controller's interface. Pre-configuring the interfaces reduces the interface adaptation time during flashing, allowing the flashing operation to be executed directly based on the preset interface, improving the smoothness of the flashing process and increasing flashing efficiency.

[0081] In one embodiment, configuring a preset interface suitable for the flashing process for at least one second controller mounted under the first controller includes: forming a device tree by using the first controller as the master node and the at least one second controller mounted under the first controller as the slave node, and configuring a preset interface suitable for the flashing process for each slave node.

[0082] In this embodiment, the first controller and the second controller are abstracted as the master node and slave node of the device tree, respectively, clarifying the master-slave relationship and node hierarchy. The hierarchical structure of the device tree provides unified logic for interface configuration, ensuring that the preset interface of each slave node (second controller) matches the calling logic of the master node (first controller), thus avoiding flashing failures due to interface mismatches. This allows the flashing process of multiple second controllers to be executed in an orderly manner based on the topology of the device tree, reducing the interface adaptation time during flashing and enabling efficient execution of flashing operations directly based on the preset interfaces of the device tree, thereby improving the smoothness of the flashing process.

[0083] like Figure 3 The diagram shown is a schematic of a controller node based on a device tree according to an embodiment of this disclosure. Taking ZCU as the first controller as an example, ZCU is abstracted as a master node Zcu_Node (ZCU node). A Switch controller and a BLDC (brushless DC motor) controller are attached to the ZCU. The switch is configured with a corresponding slave node Switch_Node (switch node), and the brushless DC motor is configured with a corresponding slave node BLDC_Node (brushless DC motor node). Wherein:

[0084] The Flash operation interfaces of the Zone Controller (ZCU) are as follows: ZCUFlashWrite is the write interface for the Zone Controller Flash; ZCUFlashRead is the read interface for the Zone Controller Flash; ZCUFlashErase is the erase interface for the Zone Controller Flash; ZCUBlockList is the event counting and status monitoring interface for Zone Controller Flash storage management, mainly used to count and track Flash operation events (such as erase, programming, and read counts); ZCUBlockCount is the block operation counter interface for the Zone Controller Flash; and ZCUFlashSwitch is the electronic protection switch interface for the Zone Controller Flash circuit.

[0085] The switch Flash operation interface list includes: SwitchFlashWrite (write interface for switch Flash), SwitchFlashRead (read interface for switch Flash), SwitchFlashErase (erase interface for switch Flash), SwitchBlockList (event counting and status monitoring interface for switch Flash storage management), SwitchBlockCount (block operation counter interface for switch Flash), and SwitchFlashSwitch (electronic protection switch interface for switch Flash circuit).

[0086] The Flash operation interfaces for a brushless DC motor (BLDC) are as follows: BLDCFlashWrite is the write interface for the brushless DC motor Flash; BLDCFlashRead is the read interface for the brushless DC motor Flash; BLDCFlashErase is the erase interface for the brushless DC motor Flash; BLDCFlockList is the event counting and status monitoring interface for the brushless DC motor Flash memory management; BLDCFlockCount is the block operation counter interface for the brushless DC motor Flash; and BLDCFlashSwitch is the electronic protection switch interface for the brushless DC motor Flash circuit.

[0087] The current ZCU itself and the second controller attached to it are abstracted as device nodes, and the devices are configured for the device tree according to the device software contained in the MBF file. Each node is configured with a set of Flash memory operation methods (i.e., corresponding preset interfaces), and an intermediate adaptation layer is set up to maintain the Flash operation methods of each flashing node. During the flashing process, the flashing module initializes and configures the corresponding Flash operation interface according to the currently identified target node. The abstract node concept can support flashing of various attached controllers, improving scalability.

[0088] In one embodiment, step 102 may specifically include: determining the target second controller corresponding to the flashing start address, and obtaining the preset interface corresponding to the target second controller; determining the operation instruction specified in the flashing request; selecting the target interface corresponding to the operation instruction from the preset interfaces, and calling the target interface to execute the operation instruction on the memory space of the second controller.

[0089] In this embodiment, the target second controller to be flashed is identified based on the flashing start address, and then the corresponding preset interface of the target second controller is loaded. This not only ensures that the called preset interface matches the target controller, but also that the preset interface of the second controller to be flashed is loaded only, avoiding the resource consumption caused by blindly loading the preset interfaces of all second controllers and improving data processing efficiency. Secondly, the operation instructions for the flashing request are clearly defined, providing a basis for interface selection and reducing the risk of interface selection errors caused by ambiguous instructions. The target interface is selected for flashing based on the operation instructions, ensuring the accuracy and stability of the flashing process and improving the reliability and efficiency of the controller flashing operation.

[0090] by Figure 2 In the example shown, after the diagnostic instrument parses the MBF file, it sends the erase start address of each controller to the first controller one by one through the 0x31 service. When the erase start address (0xC0000000) corresponding to the second controller 1 is sent, the first controller recognizes that the erase start address is greater than its own end address value (0xBXXX XXXX), and then calls the erase interface of the second controller 1 to perform an erase operation on the second controller 1.

[0091] Step 103: If the flashing start address is within the memory range corresponding to the first controller, call the flashing interface corresponding to the first controller to perform a flashing operation on the first controller.

[0092] In this step, if the first controller identifies that the flash start address is within the memory range corresponding to the first controller, it means that the object to be flashed is the first controller. In this case, the flashing process for the first controller is automatically triggered, and the corresponding flashing interface is called to perform the flashing operation. For example, the flashing process can be executed according to the flashing procedure specified by the standard protocol conforming to the first controller.

[0093] The aforementioned flashing method, based on a dynamic identification mechanism using the flashing start address, automatically identifies and flashes non-standard controllers by utilizing the flashing start address information carried in standard protocols (such as the 0x31 service). Leveraging the differences in memory address spaces between standard and non-standard controllers, combined with streaming flashing characteristics, unified management of multiple controllers can be achieved without modifying the protocol stack. Furthermore, based on a device abstraction-based intermediate adaptation layer design, standard and non-standard controllers are abstracted into unified nodes using a device tree approach, with each node configured with an independent Flash operation interface. This intermediate layer decouples hardware differences, improving system compatibility and scalability. It enables the use of the same diagnostic and flashing protocol stack to flash multiple non-standard controllers connected to a standard controller, improving flashing efficiency.

[0094] like Figure 4 The diagram illustrates an application scenario of a flashing method provided in this disclosure. The first controller is designated as the master node, and the second controllers connected to the first controller are designated as slave nodes. Assume there are n slave nodes, where n is a positive integer. The flashing process mainly includes the following steps:

[0095] 1. Standard Controller (i.e., First Controller) Self-Brushing Process: The diagnostic tool is host computer software that can run on a desktop or mobile computer. Before brushing, the MBF file to be brushed is imported into the diagnostic tool. After the brushing begins, the diagnostic tool sends a brushing request message to the first controller (master node) according to the process shown in Table 1 above. This message carries the brushing start address. The first controller identifies the controller to be brushed based on the brushing start address. If the first controller determines that the brushing start address is within its own memory range, it executes the self-brushing process. In the data transmission step (36 XX XX) in Table 1, the MBF file is transmitted to the first controller. Subsequently, the first controller calls the master node's preset Flash interface (such as read interface, write interface, erase interface) to complete the brushing process.

[0096] 2. Flashing process for non-standard controllers using standard controllers:

[0097] Before flashing, import the MBF file to be flashed into the diagnostic tool. After flashing begins, the diagnostic tool sends a flashing request message to the first controller (master node) according to the process shown in Table 1 above. This message carries the flashing start address (e.g., ...). Figure 4 If the first controller determines that the write start address is not within its own memory address range (e.g., the write address passed in the erase Flash routine is greater than the master node's memory end address), then the master node will recognize that the passed MBF file contains software data for the downstream nodes and needs to write the downstream nodes. Then, it can then... Figure 2The memory address allocation of each controller shown identifies which downstream node needs to be written. Assuming it's identified as downstream node 2, then... Figure 3 The device tree structure shown initializes the preset interface corresponding to the lower-level node 2. Finally, the preset interface corresponding to the lower-level node 2 is called to perform the flashing according to the flashing character. The preset interface includes, but is not limited to, Flash read interface, Flash write interface, and Flash erase interface.

[0098] For details of each step of the above method, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0099] Please refer to Figure 5 This is a controller writing device 500 according to an embodiment of the present disclosure. This device can be applied to electronic device 6 and can be applied to... Figure 7 In the controller flashing application scenario shown, the controller that needs to be flashed is dynamically identified by memory address range, reducing the computational resource requirements of the first controller. This allows the standard first controller to efficiently complete the flashing task of the connected second controller, improving the flexibility and efficiency of controller flashing. The device includes an acquisition module 501 and a flashing module 502. The functional principles of each module are as follows:

[0100] The acquisition module 501 is configured to acquire the start address of the flash request indicated in the pending flash request.

[0101] The flashing module 502 is configured to call the preset interface corresponding to the second controller according to the flashing start address if the flashing start address is outside the memory range corresponding to the first controller, and perform a flashing operation on the second controller. The second controller is mounted under the first controller.

[0102] In one embodiment, the apparatus further includes: a first configuration module configured to determine a first memory space occupied by the first controller before obtaining the flash start address indicated in the pending flash request. A second memory space occupied by the second controller is configured based on the first memory space, wherein the start address of the second memory space is greater than the end address of the first memory space.

[0103] In one embodiment, the first configuration module is further configured to determine the memory requirements of the software data of the second controller. The capacity of the second memory space is configured based on the first memory space and the memory requirements, wherein the capacity of the second memory space is greater than or equal to the memory requirements.

[0104] In one embodiment, the first controller is equipped with multiple second controllers. The first configuration module is further configured to determine the capacity of the second memory space occupied by each second controller based on the memory requirements of the software data of each second controller. The starting address of the memory for each second controller is configured based on the ending address of the first memory space and the capacity of the second memory space. Specifically, the starting address of the memory for the first second controller following the first controller is greater than the ending address of the first controller, and the starting addresses of subsequent second controllers are sequentially offset based on the capacity of the second memory space occupied by the preceding second controller.

[0105] In one embodiment, the device further includes a second configuration module configured to configure a preset interface applicable to the flashing process for at least one second controller mounted under the first controller before calling a preset interface corresponding to the second controller according to the flashing start address to perform a flashing operation on the memory space of the second controller.

[0106] In one embodiment, the second configuration module is configured to use the first controller as the master node and at least one second controller mounted under the first controller as the slave node to form a device tree, and to configure a preset interface applicable to the flashing process for each slave node.

[0107] In one embodiment, the flashing module 502 is configured to determine the target second controller corresponding to the flashing start address and obtain a preset interface corresponding to the target second controller. It then determines the operation instruction specified in the flashing request. From the preset interfaces, it selects the target interface corresponding to the operation instruction and calls the target interface to execute the operation instruction on the memory space of the second controller.

[0108] In one embodiment, the flashing module 502 is further configured to call the flashing interface corresponding to the first controller to perform a flashing operation on the first controller if the flashing start address is within the memory range corresponding to the first controller.

[0109] For a detailed description of the flashing device 500 of the controller, please refer to the description of the relevant method steps in the above embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0110] like Figure 6 As shown, this embodiment provides an electronic device 6, including: at least one processor 61 and a memory 62. Figure 6Taking a processor as an example, processor 61 and memory 62 are connected via bus 60. Memory 62 stores instructions that can be executed by processor 61. The instructions are executed by processor 61 to enable electronic device 6 to perform all or part of the process of the method in the following embodiments, so as to realize the dynamic identification of the controller that needs to be flashed by memory address range, reduce the demand on the computing resources of the first controller, and enable the standard first controller to efficiently complete the flashing task of the connected second controller, thereby improving the flexibility and efficiency of controller flashing.

[0111] In one embodiment, the electronic device 6 may be an in-vehicle device, such as an in-vehicle controller, or a mobile phone, tablet computer, laptop computer, desktop computer, or a large computing system composed of multiple computers.

[0112] Figure 7 This is a schematic diagram illustrating an application scenario 700 of a controller flashing system provided in an embodiment of this disclosure. For example... Figure 7 As shown, the system includes: a server 710 and a terminal 720, wherein:

[0113] Server 710 can be a data center providing controller flashing services, such as a vehicle service data center. In a real-world scenario, a vehicle service data center may have multiple Server 710s. Figure 7 Taking a single server (710) as an example.

[0114] Terminal 720 can be an electronic device that interacts with the vehicle service data center, such as a vehicle, vehicle controller, computer, mobile phone, tablet, or other device used to access the vehicle service data center. There can also be multiple terminals 720. Figure 7 The following example uses two terminals (720) for illustration.

[0115] Terminal 720 and server 710 can transmit information via the Internet, enabling terminal 720 to access data on server 710. Both terminal 720 and / or server 710 can be implemented by electronic device 6.

[0116] The controller flashing scheme of this embodiment can be deployed on server 710, on terminal 720, or partially on server 710 and partially on terminal 720. The choice can be made based on actual needs in a real-world scenario, and this embodiment does not impose any limitations.

[0117] When the controller's flashing scheme is deployed entirely or partially on server 710, the call interface can be opened to terminal 720 to provide algorithm support to terminal 720.

[0118] The method provided in this embodiment can be implemented by an electronic device 6 executing corresponding software code, and is achieved through data interaction with a server. The electronic device 6 can be a local terminal device. When the method runs on a server, it can be implemented and executed based on a cloud interaction system, which includes a server and client devices.

[0119] In one possible implementation, the method provided in this disclosure provides a graphical user interface through a terminal device, wherein the terminal device may be the aforementioned local terminal device or a client device in the aforementioned cloud interaction system.

[0120] Figure 8 This is a block diagram illustrating a vehicle 800 according to an exemplary embodiment. For example, vehicle 800 may be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicles.

[0121] Reference Figure 8 The vehicle 800 may include various subsystems, such as an infotainment system 810, a perception system 820, a decision control system 830, a drive system 840, and a computing platform 850. The vehicle 800 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and each component of the vehicle 800 can be interconnected via wired or wireless means.

[0122] In some embodiments, the infotainment system 810 may include a communication system, an entertainment system, and a navigation system, etc.

[0123] The perception system 820 may include several sensors for sensing information about the environment surrounding the vehicle 800. For example, the perception system 820 may include a global positioning system (which may be GPS, BeiDou, or other positioning systems), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0124] The decision control system 830 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system.

[0125] The drive system 840 may include components that provide powered motion to the vehicle 800. In one embodiment, the drive system 840 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0126] Some or all of the functions of the vehicle 800 are controlled by a computing platform 850. The computing platform 850 may include at least one processor 851 and a memory 852, the processor 851 being able to execute instructions 853 stored in the memory 852.

[0127] The processor 851 can be any conventional processor, such as a commercially available CPU. The processor may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems on chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0128] The memory 852 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0129] In addition to instruction set 853, memory 852 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 852 can be used by computing platform 850.

[0130] In this embodiment of the disclosure, processor 851 may execute instructions 853 to complete all or part of the steps of the method of any of the above embodiments.

[0131] In some embodiments of this disclosure, a computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of an electronic device to perform the methods of any of the above embodiments. For example, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0132] This disclosure also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0133] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the methods of any of the foregoing embodiments.

[0134] In the several embodiments provided in this disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0135] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this disclosure.

[0136] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor. The memory may include high-speed RAM (Random Access Memory), and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk, or optical disc, etc.

[0137] The aforementioned storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0138] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0139] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A. X applies B. or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0140] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding this specification and the accompanying drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0141] The sequence numbers of the embodiments disclosed above are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0142] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this disclosure.

[0143] The collection, storage, use, processing, transmission, provision, and disclosure of user data and other information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0144] The above are merely exemplary embodiments of this disclosure and do not limit the patent scope of this disclosure. Any equivalent structural or procedural transformations made using the content of this disclosure and its drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this disclosure.

Claims

1. A brushing method, characterized in that, include: Obtain the start address for the flash request as indicated in the pending flash request; If the flashing start address is outside the memory range corresponding to the first controller, the preset interface corresponding to the second controller is called according to the flashing start address to perform a flashing operation on the second controller, and the second controller is mounted under the first controller.

2. The method according to claim 1, characterized in that, Before obtaining the flash start address indicated in the pending flash request, the process also includes: Determine the first memory space occupied by the first controller; The second memory space occupied by the second controller is configured according to the first memory space, and the starting address of the second memory space is greater than the ending address of the first memory space.

3. The method according to claim 2, characterized in that, The step of configuring the second memory space occupied by the second controller according to the first memory space includes: Determine the memory requirements for the software data of the second controller; The capacity of the second memory space is configured according to the first memory space and the memory requirement, wherein the capacity of the second memory space is greater than or equal to the memory requirement.

4. The method according to claim 3, characterized in that, The first controller is equipped with multiple second controllers; configuring the capacity of the second memory space according to the first memory space and the memory requirement includes: The capacity of the second memory space occupied by each second controller is determined based on the memory requirements of the software data of each second controller. Configure the memory start address of each of the second controllers according to the termination address of the first memory space and the capacity of the second memory space; The memory start address of the first second controller located after the first controller is greater than the memory end address of the first controller, and the memory start addresses of each subsequent second controller are offset sequentially based on the capacity of the second memory space occupied by the previous second controller.

5. The method according to claim 1, characterized in that, Before calling the preset interface corresponding to the second controller according to the write start address to perform a write operation on the memory space of the second controller, the method further includes: Configure a preset interface for the flashing process for at least one second controller mounted under the first controller.

6. The method according to claim 5, characterized in that, The step of configuring a preset interface applicable to the flashing process for at least one second controller mounted under the first controller includes: The first controller is used as the master node, and at least one second controller mounted under the first controller is used as a slave node to form a device tree, and a preset interface applicable to the flashing process is configured for each slave node.

7. The method according to any one of claims 1-6, characterized in that, The step of calling the preset interface corresponding to the second controller according to the flashing start address to perform a flashing operation on the second controller includes: Determine the target second controller corresponding to the flashing start address, and obtain the preset interface corresponding to the target second controller; Determine the operation instruction specified in the write request; Select the target interface corresponding to the operation instruction from the preset interface, and call the target interface to execute the operation instruction in the memory space of the second controller.

8. The method according to claim 1, characterized in that, Also includes: If the flashing start address is within the memory range corresponding to the first controller, the flashing interface corresponding to the first controller is called to perform a flashing operation on the first controller.

9. A controller writing device, characterized in that, include: The acquisition module is used to obtain the start address of the flashing request indicated in the pending flashing request; The flashing module is used to call the preset interface corresponding to the second controller according to the flashing start address if the flashing start address is outside the memory range corresponding to the first controller, and to perform a flashing operation on the second controller, which is mounted under the first controller.

10. The apparatus according to claim 9, characterized in that, Also includes: The first configuration module is configured to determine the first memory space occupied by the first controller before obtaining the flash start address indicated in the flash request to be processed; The second memory space occupied by the second controller is configured according to the first memory space, and the starting address of the second memory space is greater than the ending address of the first memory space.

11. The apparatus according to claim 10, characterized in that, The first configuration module is further configured to determine the memory requirements of the software data of the second controller; and to configure the capacity of the second memory space according to the first memory space and the memory requirements, wherein the capacity of the second memory space is greater than or equal to the memory requirements.

12. The apparatus according to claim 11, characterized in that, The first controller is equipped with multiple second controllers; the first configuration module is further configured to determine the capacity of the second memory space occupied by each second controller based on the memory requirements of the software data of each second controller; and to configure the memory start address of each second controller based on the end address of the first memory space and the capacity of the second memory space. The memory start address of the first second controller located after the first controller is greater than the memory end address of the first controller, and the memory start addresses of each subsequent second controller are offset sequentially based on the capacity of the second memory space occupied by the previous second controller.

13. The apparatus according to claim 9, characterized in that, Also includes: The second configuration module is configured to configure a preset interface applicable to the flashing process for at least one second controller mounted under the first controller before the preset interface corresponding to the second controller is called according to the flashing start address to perform a flashing operation on the memory space of the second controller.

14. The apparatus according to claim 13, characterized in that, The second configuration module is configured to use the first controller as the master node, and at least one second controller mounted under the first controller as a slave node to form a device tree, and to configure a preset interface applicable to the flashing process for each slave node.

15. The apparatus according to any one of claims 9-14, characterized in that, The flashing module is configured to determine the target second controller corresponding to the flashing start address, and obtain the preset interface corresponding to the target second controller; and determine the operation instruction specified by the flashing request. Select the target interface corresponding to the operation instruction from the preset interface, and call the target interface to execute the operation instruction in the memory space of the second controller.

16. The apparatus according to claim 9, characterized in that, The flashing module is further configured to call the flashing interface corresponding to the first controller to perform a flashing operation on the first controller if the flashing start address is within the memory range corresponding to the first controller.

17. A vehicle, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, which is configured to execute the instructions to implement the method according to any one of claims 1-8.

18. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, which is configured to execute the instructions to implement the method according to any one of claims 1-8.

19. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a processor of an electronic device, enable the electronic device to perform a flashing method, the method comprising: Get pending flush requests; Parse the flash request to obtain the flash start address; If the flashing start address is outside the memory range corresponding to the first controller, the preset interface corresponding to the second controller is called according to the flashing start address to perform a flashing operation on the second controller, and the second controller is mounted under the first controller.

20. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-8.

Images