Firmware burning method and system, vehicle control system

By working in concert with the MCU and MPU in the vehicle control system, the effectiveness and reliability of the firmware are achieved, the problem of firmware burning in the vehicle control system is solved, and the normal operation of the system is ensured.

CN114527994BActive Publication Date: 2026-02-03BEIQI FOTON MOTOR CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202011324770.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-11-23
Publication Date
2026-02-03
Estimated Expiration
2040-11-23

AI Technical Summary

Technical Problem

The effectiveness and reliability of firmware burning in vehicle control systems are low, causing the system to malfunction.

Method used

The MCU receives the programming message from the host computer and sends a reboot command. The MPU performs a reboot and loads the Linux minimal system. It receives and verifies the file package to be programmed via Ethernet to ensure that it is complete and matches before writing it to the MPU and executing the bootloader to run the target firmware.

Benefits of technology

This improves the effectiveness and reliability of firmware flashing, ensuring the normal operation of the vehicle control system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114527994B_ABST
    Figure CN114527994B_ABST
Patent Text Reader

Abstract

The present disclosure relates to a firmware burning method and system and vehicle control system, and relates to the field of vehicle control. The method is applied to a vehicle control system and comprises the following steps: an MCU receives a burning message sent by an upper computer through a bus, and sends a first restart instruction to an MPU according to the burning message; the MPU executes a restart in response to the first restart instruction, and loads a Linux minimum system stored in the MPU as a root file system; the MPU sends a burning request to the upper computer through Ethernet, so that the upper computer sends a to-be-burned file package to the MPU through Ethernet in response to the burning request; the MPU checks the to-be-burned file package, and writes target firmware included in the to-be-burned file package into the MPU when the checking result indicates that the to-be-burned file package is complete and matches the vehicle control system; the MPU executes a restart, and loads a bootloader stored in the MPU as the root file system to execute the target firmware.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control, specifically to a firmware burning method, system, and vehicle control system. Background Technology

[0002] With the rapid development of the automotive industry, more and more vehicles are equipped with various types of vehicle control systems, such as AEB (Autonomous Emergency Braking), ECU (Electronic Control Unit), and ESP (Electronic Stability Program). Therefore, the effectiveness and reliability of firmware flashing in vehicle control systems are becoming increasingly important. Typically, firmware in vehicle control systems is flashed via Ethernet. The vehicle control system obtains the firmware to be flashed from a designated server. Various anomalies may occur during the flashing process, causing the vehicle control system to malfunction, resulting in relatively low effectiveness and reliability of firmware flashing. Summary of the Invention

[0003] The purpose of this disclosure is to provide a firmware burning method, system, and vehicle control system to solve the problem of low effectiveness and reliability of firmware burning in vehicle control systems.

[0004] According to a first aspect of the present disclosure, a firmware burning method is provided, applied to a vehicle control system, the vehicle control system including: a microcontroller unit (MCU) and a microprocessor unit (MPU), the method including:

[0005] The MCU receives the programming message sent by the host computer via the bus, and sends a first restart command to the MPU according to the programming message;

[0006] In response to the first reboot command, the MPU performs a reboot and loads the minimal Linux system stored in the MPU as the root file system;

[0007] The MPU sends a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU via Ethernet.

[0008] The MPU verifies the file package to be burned, and if the verification result indicates that the file package to be burned is complete and matches the vehicle control system, the target firmware included in the file package to be burned is written into the MPU.

[0009] The MPU performs a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware.

[0010] Optionally, the file package to be burned may also include startup parameters;

[0011] The step of writing the target firmware included in the file package to be burned into the MPU includes:

[0012] Determine the target region specified in the startup parameters;

[0013] According to the startup parameters, the target firmware is written into the target area within the MPU;

[0014] The step of loading the bootloader stored in the MPU as a root file system to execute the target firmware includes:

[0015] The bootloader is loaded as a root file system so that the bootloader copies the target firmware from the target region to the memory of the MPU;

[0016] Execute the target firmware.

[0017] Optionally, after determining the target region specified in the boot parameters, writing the target firmware included in the file package to be burned into the MPU further includes:

[0018] Determine the state of the target area;

[0019] If the state of the target area is abnormal, a first abnormality message is sent to the MCU, so that the MCU sends the first abnormality message to the host computer via the bus;

[0020] The step of writing the target firmware into the target region within the MPU according to the boot parameters includes:

[0021] If the target area is in a normal state, the target firmware is written to the target area according to the startup parameters.

[0022] Optionally, after determining the state of the target region, writing the target firmware included in the file package to be programmed into the MPU further includes:

[0023] If the state of the target region is abnormal, update the startup parameters and determine the replacement region specified in the updated startup parameters, wherein the replacement region is different from the target region;

[0024] The step of writing the target firmware into the target region within the MPU according to the boot parameters includes:

[0025] The target firmware is written to the replacement area according to the updated boot parameters.

[0026] Optionally, after writing the target firmware included in the file package to be programmed into the MPU, the method further includes:

[0027] The MPU sends a first prompt message to the MCU, so that the MCU sends the first prompt message to the host computer via the bus;

[0028] The MCU sends a second restart command to the MPU;

[0029] The MPU performs a reboot and loads the bootloader stored within the MPU as the root file system to execute the target firmware, including:

[0030] In response to the second reboot command, the MPU performs a reboot and loads the bootloader as the root file system to execute the target firmware.

[0031] Optionally, before the MCU receives the programming message sent by the host computer via the bus and sends a first restart command to the MPU according to the programming message, the method further includes:

[0032] The MCU receives the authentication request sent by the host computer via the bus, and authenticates the host computer according to the authentication request;

[0033] When the authentication result indicates that the host computer has passed the authentication, the MCU sends authentication information to the host computer via the bus, so that the host computer responds to the authentication information and sends the programming message to the MCU via the bus.

[0034] Optionally, the file package to be programmed further includes a first verification code and first version information; the MPU verifies the file package to be programmed, including:

[0035] A second verification code is generated based on the file package to be burned;

[0036] If the first verification code matches the second verification code, and the first version information matches the second version information of the vehicle control system, the verification result indicates that the file package to be burned is complete and matches the vehicle control system.

[0037] According to a second aspect of the present disclosure, a vehicle control system is provided, the vehicle control system comprising: an MCU and an MPU;

[0038] The MCU is used to receive the programming message sent by the host computer through the bus, and send a first restart command to the MPU according to the programming message;

[0039] The MPU is used to respond to the first reboot command, perform a reboot, and load the Linux minimal system stored in the MPU as the root file system;

[0040] The MPU is also used to send a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU via Ethernet;

[0041] The MPU is also used to verify the file package to be burned, and write the file package to be burned into the MPU if the verification result indicates that the file package to be burned is complete and matches the vehicle control system.

[0042] The MPU is also used to perform a reboot and load the bootloader stored in the MPU as a root file system to execute the target firmware included in the file package to be burned.

[0043] Optionally, the file package to be programmed also includes startup parameters; the MPU is further used for:

[0044] Determine the target region specified in the startup parameters;

[0045] According to the startup parameters, the target firmware is written into the target area within the MPU;

[0046] The bootloader is loaded as a root file system so that the bootloader copies the target firmware from the target region to the memory of the MPU;

[0047] Execute the target firmware.

[0048] Optionally, after determining the target region specified in the startup parameters, the MPU is further configured to:

[0049] Determine the state of the target area;

[0050] If the state of the target area is abnormal, a first abnormality message is sent to the MCU, so that the MCU sends the first abnormality message to the host computer via the bus;

[0051] If the target area is in a normal state, the target firmware is written to the target area according to the startup parameters.

[0052] Optionally, after determining the state of the target area, the MPU is further configured to:

[0053] If the state of the target region is abnormal, update the startup parameters and determine the replacement region specified in the updated startup parameters, wherein the replacement region is different from the target region;

[0054] The target firmware is written to the replacement area according to the updated boot parameters.

[0055] Optionally, after writing the target firmware included in the file package to be burned into the MPU, the MPU is further configured to send a first prompt message to the MCU, so that the MCU sends the first prompt message to the host computer via the bus;

[0056] The MCU is also used to send a second restart command to the MPU;

[0057] The MPU is also configured to respond to the second reboot command, perform a reboot, and load the bootloader as the root file system to execute the target firmware.

[0058] Optionally, before the MCU receives the programming message sent by the host computer via the bus and sends a first restart command to the MPU according to the programming message, the MCU is further configured to:

[0059] Receive the authentication request sent by the host computer via the bus, and authenticate the host computer according to the authentication request;

[0060] If the authentication result indicates that the host computer has passed the authentication, the authentication information is sent to the host computer via the bus, so that the host computer responds to the authentication information and sends the programming message to the MCU via the bus.

[0061] Optionally, the file package to be burned further includes a first verification code and first version information; the MPU is also used for:

[0062] A second verification code is generated based on the file package to be burned;

[0063] If the first verification code matches the second verification code, and the first version information matches the second version information of the vehicle control system, the verification result indicates that the file package to be burned is complete and matches the vehicle control system.

[0064] According to a third aspect of the present disclosure, a firmware burning system is provided, the firmware burning system comprising: a vehicle control system and a host computer, the vehicle control system comprising an MCU and an MPU;

[0065] The vehicle control system is used to perform the method described in any one of the first aspects of the embodiments of this disclosure.

[0066] Through the above technical solution, in this disclosure, the host computer sends a programming message to the MCU in the vehicle control system via the bus. The MCU sends a first restart command to the MPU according to the received programming message. After receiving the first restart command, the MPU performs a restart and loads the Linux minimal system stored in the MPU as the root file system. Then, it sends a programming request to the host computer via Ethernet. After receiving the programming request, the host computer sends the file package to be programmed to the MPU via Ethernet. The MPU verifies the file package to be programmed. If the verification result indicates that the file package to be programmed is complete and matches the vehicle control system, the target firmware included in the file package to be programmed is written to the MPU. Finally, the MPU performs a restart and loads the bootloader stored in the MPU as the root file system to execute the target firmware. In the vehicle control system disclosed herein, the MCU communicates with the host computer via a bus, thereby enabling the MCU to control the MPU to load the Linux minimal system as the root file system. Then, the MPU communicates with the host computer via Ethernet, receives the file package to be burned from the host computer, and the MPU first verifies the file package to be burned before writing the target firmware in the file package to the MPU, thereby improving the effectiveness and reliability of firmware burning.

[0067] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0068] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings:

[0069] Figure 1 This is a flowchart illustrating a firmware flashing method according to an exemplary embodiment;

[0070] Figure 2 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0071] Figure 3 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0072] Figure 4 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0073] Figure 5 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0074] Figure 6 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0075] Figure 7 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment;

[0076] Figure 8 This is a block diagram illustrating a vehicle control system according to an exemplary embodiment;

[0077] Figure 9 This is a block diagram illustrating a firmware burning system according to an exemplary embodiment. Detailed Implementation

[0078] 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.

[0079] Figure 1 This is a flowchart illustrating a firmware flashing method according to an exemplary embodiment, such as... Figure 1 As shown, this method is applied to a vehicle control system, which includes an MCU (Micro Controller Unit) and an MPU (Micro Processor Unit). The method may include the following steps:

[0080] Step 101: The MCU receives the programming message sent by the host computer via the bus and sends the first restart command to the MPU according to the programming message.

[0081] In step 102, the MPU responds to the first reboot command, performs a reboot, and loads the minimal Linux system stored in the MPU as the root file system.

[0082] For example, a vehicle control system includes an MCU and an MPU. The MCU can interact with a host computer via a bus, and the MPU can interact with the host computer via Ethernet. Furthermore, the MCU and MPU can interact via hardwired connections. Simultaneously, the MCU can also interact with the power management chip controlling the MPU via a bus, thereby controlling the MPU's power-on and power-off operations. The bus between the MCU and the host computer, and the bus between the MCU and the power management chip, can be the same or different.

[0083] The vehicle control system can be AEB, ECU, ESP, etc., and this disclosure does not specifically limit it. The MPU can include multiple different types of memory, such as NOR Flash, eMMC (Embedded MultiMedia Card), DDR3, etc. NOR Flash can be used to store the Linux minimal system and bootloader, while eMMC can be used to store system programs (such as firmware) and user data (such as configuration files). The host computer can be a terminal device or a server. The terminal device can be a fixed terminal such as a PC (Personal Computer), or a mobile terminal including but not limited to mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Tablet PCs), PMPs (Portable Multimedia Players), and in-vehicle terminals (such as in-vehicle navigation terminals). Specifically, the host computer can include a CANoe (CAN open environment) module and a TCP / IP (Transmission Control Protocol / Internet Protocol) module. The CANoe module in the host computer can interact with the MCU of the vehicle control system via the CAN bus, while the TCP / IP module can interact with the MPU of the vehicle control system via Ethernet. The bus can be, for example, a CAN (Controller Area Network) bus, an I2C (Inter-Integrated Circuit) bus, an SMBus (System Management Bus), or an SPI (Serial Peripheral Interface) bus. The bus between the MCU and the host computer can be, for example, a CAN bus, and the bus between the MCU and the power management chip can be, for example, an I2C bus.

[0084] In scenarios involving installing or upgrading firmware within a vehicle control system, the host computer sends a programming message to the MCU (Microcontroller Unit) of the vehicle control system via a bus. Upon receiving the programming message, the MCU can send a first reboot command to the MPU (Multi-Processing Unit) via a hardwired connection, thereby controlling the MPU to reboot and enter Ethernet programming mode. This first reboot command can be a high-level signal. After receiving the first reboot command from the MCU, the MPU can restart its internal program and load the internally stored minimal Linux system as the root file system.

[0085] Specifically, let's take a system with an AEB (Autonomous Emergency Braking) vehicle control system, a PC containing a CANoe module as the host computer, and a CAN bus as the bus as an example. The PC is connected to the AEB via PCAN. One end of the PCAN module is plugged into the PC's USB (Universal Serial Bus) port, and the other end is plugged into the CAN bus interface in the exposed wiring harness of the AEB. First, the CANoe module sends a programming message to the AEB's MCU (Microcontroller Unit) via the CAN bus. After receiving the programming message, the MCU can send a first reboot command to the MPU (Multi-Processing Unit) via a hardwired connection. Upon receiving the first reboot command, the MPU reboots and enters Ethernet programming mode, loading a minimal Linux system as the root file system.

[0086] Step 103: The MPU sends a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU via Ethernet.

[0087] For example, after successfully loading the Linux minimal system as the root file system, the MPU enters Ethernet programming mode. The Linux minimal system can control the MPU to send a notification message to the MCU, informing the MCU that the root file system has been successfully loaded. After receiving the notification message, the MCU can send a programming preparation message to the host computer via the bus, so that the host computer is ready to receive the programming request sent by the MPU. Furthermore, the MPU can send a Socket long connection establishment request to the host computer via Ethernet, so that the host computer can establish a Socket long connection with the MPU according to the Socket long connection establishment request. The MPU can send a programming request to the host computer via the Socket long connection. After receiving the programming request sent by the MPU, the host computer can send the file package to be programmed to the MPU via the Socket long connection according to the TFTP (Trivial File Transfer Protocol) protocol. The file package to be burned may include the target firmware and boot parameters. The target firmware can be understood as the system program to be burned into the vehicle control system. The boot parameters can be understood as parameters used to indicate the attributes of the target firmware. For example, it may include the name and address of the area to be written to the target firmware (i.e., the target area mentioned later), as well as the check value and version information of the target firmware.

[0088] Step 104: The MPU verifies the file package to be burned, and if the verification result indicates that the file package to be burned is complete and matches the vehicle control system, the target firmware included in the file package to be burned is written into the MPU.

[0089] Step 105: The MPU performs a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware.

[0090] For example, after receiving the file package to be programmed, the MPU first verifies the integrity and reliability of the file package. After the verification is completed, the MPU sends the verification result back to the MCU. After receiving the verification result, the MCU sends the verification result to the host computer through the bus.

[0091] If the verification result is normal, meaning the MPU determines that the file package to be burned is complete and matches the vehicle control system, then the MPU will write the target firmware from the file package to the MPU. After receiving the normal verification result, the host computer can continue to execute the preset steps. Specifically, matching the file package to be burned with the vehicle control system can be understood as the version information of the file package to be burned matching the version information of the vehicle control system.

[0092] If the verification result is abnormal, meaning the file package to be programmed is incomplete and / or incompatible with the vehicle control system, the MPU exits Ethernet programming mode and waits for the MCU to resend the first restart command. After receiving the abnormal verification result, the host computer can modify the file package to be programmed or display the verification result to the operator, for example, by popping up a dialog box on the screen displaying "Verification result abnormal".

[0093] Furthermore, after the target firmware included in the file package to be burned is written to the MPU, it can perform a reboot and load the bootloader stored within the MPU as the root file system. The bootloader can then execute the target firmware, thereby enabling the vehicle control system to operate normally. The bootloader, for example, could be a BootLoader.

[0094] In summary, in this disclosure, the host computer sends a programming message to the MCU in the vehicle control system via a bus. The MCU sends a first reboot command to the MPU based on the received programming message. After receiving the first reboot command, the MPU executes a reboot and loads the Linux minimal system stored in the MPU as the root file system. Then, it sends a programming request to the host computer via Ethernet. After receiving the programming request, the host computer sends the file package to be programmed to the MPU via Ethernet. The MPU verifies the file package to be programmed. If the verification result indicates that the file package to be programmed is complete and matches the vehicle control system, the target firmware included in the file package is written to the MPU. Finally, the MPU executes a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware. In the vehicle control system disclosed herein, the MCU communicates with the host computer via a bus, thereby enabling the MCU to control the MPU to load the Linux minimal system as the root file system. Then, the MPU communicates with the host computer via Ethernet, receives the file package to be burned from the host computer, and the MPU first verifies the file package to be burned before writing the target firmware in the file package to the MPU, thereby improving the effectiveness and reliability of firmware burning.

[0095] Figure 2 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 2 As shown, the file package to be burned also includes startup parameters. Step 104 can be achieved through the following steps:

[0096] Step 1041: Determine the target region specified in the startup parameters.

[0097] Step 1042: Write the target firmware into the target area within the MPU according to the startup parameters.

[0098] Step 105 can be achieved through the following steps:

[0099] Step 1051: Load the bootloader as the root file system so that the bootloader can copy the target firmware from the target area to the MPU's memory.

[0100] Step 1052: Execute the target firmware.

[0101] For example, when the MPU verifies the file package to be burned and the verification result indicates that the file package to be burned is complete and matches the vehicle control system, it can read the startup parameters included in the file package to be burned. The startup parameters may include the name and address of the target region. Based on the name and address of the target region, the target region is determined. Then, the MPU writes the target firmware in the file package to be burned into the target region within the MPU.

[0102] Furthermore, the MPU can update the values ​​of the boot parameters stored internally to the values ​​of the boot parameters included in the file package to be burned, and load the bootloader as the root file system. In this way, the bootloader can copy the target firmware from the target area to the MPU's memory based on the name and address of the target area contained in the updated boot parameters stored internally by the MPU, so as to execute the target firmware.

[0103] Specifically, taking the NOR Flash and eMMC components in the MPU as an example, the NOR Flash can be used to store the Linux minimal system and the bootloader. The eMMC can include partitions A and B to store the target firmware. If the Linux minimal system reads that the target region name specified in the boot parameters of the file to be flashed is A, then it can write the target firmware from the file to be flashed into partition A of the eMMC according to the address of partition A in the boot parameters. Furthermore, the MPU can update the name of the target region in the boot parameters stored internally to A, update the address of the target region to the address of partition A, and then load the bootloader as the root file system. The bootloader can then copy the target firmware from partition A to the MPU's memory according to the address of partition A to execute the target firmware.

[0104] Figure 3 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 3 As shown, after step 1041, step 104 may further include the following steps:

[0105] Step 1043: Determine the status of the target area.

[0106] Step 1044: If the state of the target area is abnormal, send the first abnormal information to the MCU so that the MCU sends the first abnormal information to the host computer through the bus.

[0107] Accordingly, step 1042 can be implemented as follows:

[0108] If the target region is in a normal state, the target firmware will be written to the target region according to the startup parameters.

[0109] For example, after determining the target area, the MPU can first determine the status of the target area. If the target area is in an abnormal state, the MPU can send a first abnormality message to the MCU. After receiving the first abnormality message, the MCU can send it to the host computer via the bus. If the target area is in a normal state, the MPU can write the target firmware from the file package to be programmed into the target area within the MPU, based on the target area's name and address.

[0110] Specifically, taking the eMMC included in the MPU as an example, the eMMC can include partition A and partition B, used to store the target firmware. For example, if the Linux minimal system reads that the target region name in the boot parameters of the file package to be burned is A, it can first determine the status of partition A. If the status of partition A is abnormal, the MPU can send the first abnormal information to the MCU. After receiving the first abnormal information, the MCU can send the first abnormal information to the host computer through the bus.

[0111] Figure 4 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 4 As shown, after step 1043, step 104 may further include the following steps:

[0112] Step 1047: If the target region is in an abnormal state, update the startup parameters and determine the replacement region specified in the updated startup parameters. The replacement region is different from the target region.

[0113] Correspondingly, another implementation of step 1042 can be:

[0114] Write the target firmware to the replacement area according to the updated boot parameters.

[0115] For example, after determining the target region, the MPU can first determine the status of the target region. If the target region's status is abnormal, the MPU can update the boot parameters. Specifically, it can modify the target region's name, address, and other target region-related parameters contained in the boot parameters. Further, the MPU can determine the replacement region specified in the updated boot parameters, where the replacement region differs from the target region. Then, the MPU can write the target firmware to the replacement region according to the replacement region's name, address, and other replacement region-related parameters contained in the modified boot parameters.

[0116] Specifically, taking the example of an eMMC component within an MPU, the eMMC can include partitions A and B, used to store the target firmware. For instance, if a minimal Linux system reads that the target region name in the boot parameters of the file to be burned is A, it can first determine the status of partition A. If partition A is in an abnormal state, the MPU can modify the target region name A in the boot parameters to B (i.e., the name of the replacement region), and modify the address of the target region to the address of partition B (i.e., the address of the replacement region). The MPU can then determine the name B of the replacement region and the address of partition B. Afterward, the MPU can write the target firmware to partition B based on the address of partition B contained in the modified boot parameters.

[0117] In this way, if the target area is damaged, the MPU can automatically update the target area and write the target firmware to the updated replacement area without restarting the burning program, thus improving the efficiency and reliability of firmware burning.

[0118] Figure 5 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 5 As shown, after step 104, the method may further include the following steps:

[0119] Step 106: The MPU sends the first prompt information to the MCU, so that the MCU sends the first prompt information to the host computer via the bus.

[0120] Step 107: The MCU sends a second restart command to the MPU.

[0121] Accordingly, step 105 can be implemented as follows:

[0122] In response to the second reboot command, the MPU performs a reboot and loads the bootloader as the root file system to execute the target firmware.

[0123] For example, after the MPU writes the target firmware to the target area, it can send a first prompt message to the MCU. Upon receiving the first prompt message, the MCU can send it to the host computer via the bus and then send a second reboot command to the MPU via a hardwired connection. Upon receiving the second reboot command, the MPU can perform a reboot and load the bootloader as the root file system. The bootloader can then copy the target firmware from the target area to the MPU's memory for execution. After receiving the first prompt message, the host computer can display a message to the operator, such as a dialog box on the screen displaying "Write successful".

[0124] Figure 6 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 6 As shown, prior to step 101, the method may further include the following steps:

[0125] Step 108: The MCU receives the authentication request sent by the host computer via the bus and authenticates the host computer according to the authentication request.

[0126] Step 109: When the authentication result indicates that the host computer has passed the authentication, the MCU sends authentication information to the host computer via the bus, so that the host computer responds to the authentication information and sends a programming message to the MCU via the bus.

[0127] For example, before sending the programming message to the MCU, the host computer can first authenticate with the MCU. First, the host computer sends an authentication request to the MCU via the bus. After receiving the authentication request, the MCU can authenticate the host computer according to the request. Authentication methods could include using a Security Access mechanism. If the authentication result indicates that the host computer has passed authentication, the MCU can send authentication information to the host computer via the bus. After receiving the authentication information, the host computer can then send the programming message to the MCU via the bus.

[0128] Specifically, after receiving the authentication request from the host computer, the MCU can generate a random seed based on the authentication request and send the random seed to the host computer via the bus. Upon receiving the random seed, the host computer can generate a first key based on the random seed and send the first key to the MCU via the bus. The MCU can also generate a second key based on the generated random seed and compare the first key with the second key. If the host computer has been authenticated by the MCU, then the algorithm used by the host computer to generate the first key based on the random seed should match the algorithm used by the MCU to generate the second key based on the random seed; therefore, the first key and the second key should also match. Thus, if the first key and the second key match, the MPU can determine that the authentication result indicates the host computer has passed authentication; if the first key and the second key do not match, the MPU can determine that the authentication result indicates the host computer has failed authentication.

[0129] It should be noted that matching the first key and the second key can be interpreted as the first key and the second key being identical. If the host computer and the vehicle MCU contain the same key generation algorithm, then using the same random seed and the same key generation algorithm, the same key can be generated. When the first key and the second key are identical, it can be determined that the host computer has passed authentication.

[0130] Figure 7 This is a flowchart illustrating another firmware flashing method according to an exemplary embodiment, such as... Figure 7 As shown, the file package to be burned also includes a first verification code and first version information. Step 104 can also be achieved through the following steps:

[0131] Step 1045: Generate a second verification code based on the file package to be burned.

[0132] Step 1046: If the first verification code matches the second verification code, and the first version information matches the second version information of the vehicle control system, the verification result indicates that the file package to be burned is complete and matches the vehicle control system.

[0133] For example, after receiving the file packet to be programmed, the MPU can first generate a second checksum based on the file packet. If the first checksum in the file packet matches the second checksum generated by the MCU, and the first version information in the file packet matches the second version information in the vehicle control system, then the verification result indicates that the file packet to be programmed is complete and matches the vehicle control system. The MCU can use a CRC (Cyclic Redundancy Check) 32 verification tool to generate a second checksum based on the data frame corresponding to the file packet to be programmed. If the first checksum in the file packet and the second checksum generated by the MCU are the same, then the first checksum and the second checksum are considered to match.

[0134] It should be noted that the second version information may include the version information of the MCU and the version information of the MPU. Matching the first version information in the file package to be programmed with the second version information in the vehicle control system can be understood as a match in the years of the first and second version information. This year matching can be, for example, the year in the first version information being the same as the year in the second version information, or the year in the second version information being earlier than the year in the first version information. For example, if the first version information contains the year 2018, and the version information of both the MCU and MPU also contains the year 2018, then the first and second version information can be considered a match. Alternatively, if the first version information contains the year 2020, and the MCU version information and the MPU version information in the second version information both contain the year 2019, then the first and second version information can also be considered a match. Matching the first version information in the file package with the second version information in the vehicle control system can also involve matching the manufacturer information in the first and second version information, etc., but this disclosure does not specifically limit this.

[0135] In summary, in this disclosure, the host computer sends a programming message to the MCU in the vehicle control system via a bus. The MCU sends a first reboot command to the MPU based on the received programming message. After receiving the first reboot command, the MPU executes a reboot and loads the Linux minimal system stored in the MPU as the root file system. Then, it sends a programming request to the host computer via Ethernet. After receiving the programming request, the host computer sends the file package to be programmed to the MPU via Ethernet. The MPU verifies the file package to be programmed. If the verification result indicates that the file package to be programmed is complete and matches the vehicle control system, the target firmware included in the file package is written to the MPU. Finally, the MPU executes a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware. In the vehicle control system disclosed herein, the MCU communicates with the host computer via a bus, thereby enabling the MCU to control the MPU to load the Linux minimal system as the root file system. Then, the MPU communicates with the host computer via Ethernet, receives the file package to be burned from the host computer, and the MPU first verifies the file package to be burned before writing the target firmware in the file package to the MPU, thereby improving the effectiveness and reliability of firmware burning.

[0136] It should be noted that the steps performed by the host computer in the above embodiments can be as follows:

[0137] Step 1) Send a programming message to the MCU of the vehicle control system via the bus, so that the MCU sends the first restart command to the MPU of the vehicle control system according to the programming message. The MPU is used to perform the restart and load the Linux minimal system stored in the MPU as the root file system.

[0138] For example, in scenarios involving installing or upgrading firmware within a vehicle control system, the host computer sends a programming message to the MCU (Microcontroller Unit) of the vehicle control system via a bus. After receiving the programming message, the MCU can send a first reboot command to the MPU (Multi-Processing Unit) via a hardwired connection. This first reboot command can be a high-level signal. Upon receiving the first reboot command from the MCU, the MPU can perform a reboot and enter Ethernet programming mode, which loads the Linux minimal system as the root file system.

[0139] Step 2) Receive the writing request sent by the MPU via Ethernet. In response to the writing request, send the file package to be written to the MPU via Ethernet so that the MPU can verify the file package to be written. If the verification result indicates that the file package to be written is complete and matches the vehicle control system, write the target firmware included in the file package to the MPU.

[0140] For example, the MPU can send a Socket long-connection establishment request to the host computer via Ethernet. After receiving the Socket long-connection establishment request, the host computer establishes a Socket long-connection with the MPU. The MPU can send a programming request to the host computer via the Socket long-connection. After receiving the programming request from the MPU, the host computer can send the file package to be programmed to the MPU via the Socket long-connection according to the TFTP protocol. The file package to be programmed may include the target firmware and boot parameters. The target firmware can be understood as the system program to be programmed into the vehicle control system, and the boot parameters can be understood as parameters used to indicate the attributes of the target firmware, such as the name and address of the area to be written to the target firmware (i.e., the target area mentioned later), and may also include the checksum and version information of the target firmware.

[0141] After receiving the file package to be programmed, the MPU first verifies the integrity and reliability of the file package. After the verification is completed, the MPU sends the verification result back to the MCU. After receiving the verification result, the MCU sends the verification result to the host computer through the bus.

[0142] If the verification result is normal, meaning the MPU determines that the file package to be burned is complete and matches the vehicle control system, then the MPU will write the target firmware from the file package to the MPU. After receiving the normal verification result, the host computer can continue to execute the preset steps. Specifically, matching the file package to be burned with the vehicle control system can be understood as the version information of the file package to be burned matching the version information of the vehicle control system.

[0143] If the verification result is abnormal, meaning the file package to be programmed is incomplete and / or incompatible with the vehicle control system, the MPU exits Ethernet programming mode and waits for the MCU to resend the first restart command. After receiving the abnormal verification result, the host computer can modify the file package to be programmed or display the verification result to the operator, for example, by popping up a dialog box on the screen displaying "Verification result abnormal." After the file package to be programmed is modified, the host computer can send the programming message to the MCU again to re-execute the programming procedure.

[0144] Furthermore, the host computer can also perform the following steps:

[0145] Step 3) Receive the first exception information sent by the MCU via the bus. The first exception information is sent to the MCU when the MPU determines the target area based on the startup parameters and the status of the target area is abnormal. The target area is used to indicate the area where the target firmware is written to the MPU.

[0146] Step 4) Update the startup parameters in the file package to be burned based on the first error information.

[0147] Step 5) Again execute the step of sending a programming message to the MCU of the vehicle control system via the bus, until in response to the programming request, the programming file package is sent to the MPU via Ethernet.

[0148] For example, the MPU verifies the file package to be programmed. If the verification result indicates that the file package is complete and matches the vehicle control system, it can read the startup parameters included in the file package. These startup parameters may contain the name and address of the target region, allowing the MPU to determine the status of the target region based on these parameters. If the target region's status is abnormal, the MPU can send a first exception message to the MCU. Upon receiving this message, the MCU can send it to the host computer via the bus. The host computer, upon receiving the first exception message, can modify the target region's name and address contained in the startup parameters of the file package, or display the first exception message to the operator, for example, by popping up a dialog box on the screen displaying "Write partition status abnormal." After modification, the host computer can send a programming message to the MCU again to re-execute the programming procedure. An abnormal target region status could be due to, for example, target region corruption.

[0149] Specifically, taking the example of an eMMC included in an MPU, the eMMC can include partition A and partition B, used to store the target firmware. For example, if a Linux minimal system reads that the target region name in the boot parameters of the file package to be written is A, it can first determine the status of partition A. If the status of partition A is abnormal, the MPU can send a first abnormality message to the MCU. After receiving the first abnormality message, the MCU can send it to the host computer via the bus. After receiving the first abnormality message, the host computer can modify the name of the target region in the boot parameters of the file package to be written to B, modify the address of the target region to the address of partition B, or display the first abnormality message to the operator, for example, by popping up a dialog box on the screen displaying "Write partition status abnormal". After the modification is completed, the host computer can send a writing message to the MCU again to re-execute the above writing procedure, so that the MPU writes the target firmware to partition B according to the modified boot parameters.

[0150] Figure 8 This is a block diagram illustrating a vehicle control system according to an exemplary embodiment, such as... Figure 8 As shown, a vehicle control system 300 is provided, which includes an MCU 301 and an MPU 302.

[0151] MCU301 is used to receive the programming message sent by the host computer through the bus, and send the first restart command to MPU302 according to the programming message.

[0152] MPU302 is used to respond to the first reboot command, perform a reboot, and load the minimal Linux system stored in MPU302 as the root file system.

[0153] The MPU302 is also used to send a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU302 via Ethernet.

[0154] MPU302 is also used to verify the file package to be burned, and write the file package to be burned into MPU302 when the verification result indicates that the file package to be burned is complete and matches the vehicle control system 300.

[0155] The MPU302 is also used to perform a reboot and load the bootloader stored in the MPU302 as the root file system to execute the target firmware included in the file package to be burned.

[0156] The file package to be programmed also includes boot parameters. In one application scenario, the MPU302 is also used for:

[0157] Determine the target region specified in the startup parameters.

[0158] According to the startup parameters, the target firmware is written to the target area within the MPU302.

[0159] The bootloader is loaded as the root file system so that the bootloader can copy the target firmware from the target area to the memory of the MPU302.

[0160] Execute the target firmware.

[0161] In another application scenario, after determining the target region specified in the startup parameters, the MPU302 is also used for:

[0162] Determine the status of the target area.

[0163] If the state of the target area is abnormal, send the first abnormal information to the MCU301 so that the MCU301 can send the first abnormal information to the host computer via the bus.

[0164] If the target region is in a normal state, the target firmware will be written to the target region according to the startup parameters.

[0165] In another application scenario, after determining the state of the target area, the MPU302 is also used for:

[0166] If the target region is in an abnormal state, update the startup parameters and determine the replacement region specified in the updated startup parameters. The replacement region is different from the target region.

[0167] Write the target firmware to the replacement area according to the updated boot parameters.

[0168] In another application scenario, after the target firmware included in the file package to be burned is written into the MPU302, the MPU302 is also used to send a first prompt message to the MCU301, so that the MCU301 sends the first prompt message to the host computer via the bus.

[0169] MCU301 is also used to send a second restart command to MPU302.

[0170] The MPU302 is also used to respond to a second reboot command, perform a reboot, and load the bootloader as the root file system to execute the target firmware.

[0171] In another application scenario, before the MCU301 receives the programming message sent by the host computer via the bus and sends the first reset command to the MPU302 based on the programming message, the MCU301 is also used for:

[0172] Receive authentication requests sent by the host computer via the bus, and authenticate the host computer according to the authentication requests.

[0173] If the authentication result indicates that the host computer has passed the authentication, the authentication information is sent to the host computer via the bus, so that the host computer responds to the authentication information and sends a programming message to the MCU301 via the bus.

[0174] In another application scenario, the file package to be burned also includes a first verification code and first version information; the MPU302 is also used for:

[0175] A second verification code is generated based on the file package to be burned.

[0176] If the first verification code matches the second verification code, and the first version information matches the second version information of the vehicle control system 300, the verification result indicates that the file package to be burned is complete and matches the vehicle control system 300.

[0177] Figure 9 This is a block diagram illustrating a firmware flashing system according to an exemplary embodiment, such as... Figure 9 As shown, the firmware burning system includes a vehicle control system 300 and a host computer 400. The vehicle control system 300 includes an MCU 301 and an MPU 302.

[0178] The vehicle control system 300 can be used to perform the steps of the method described above applied to the vehicle control system 300.

[0179] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0180] In summary, in this disclosure, the host computer sends a programming message to the MCU in the vehicle control system via a bus. The MCU sends a first reboot command to the MPU based on the received programming message. After receiving the first reboot command, the MPU executes a reboot and loads the Linux minimal system stored in the MPU as the root file system. Then, it sends a programming request to the host computer via Ethernet. After receiving the programming request, the host computer sends the file package to be programmed to the MPU via Ethernet. The MPU verifies the file package to be programmed. If the verification result indicates that the file package to be programmed is complete and matches the vehicle control system, the target firmware included in the file package is written to the MPU. Finally, the MPU executes a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware. In the vehicle control system disclosed herein, the MCU communicates with the host computer via a bus, thereby enabling the MCU to control the MPU to load the Linux minimal system as the root file system. Then, the MPU communicates with the host computer via Ethernet, receives the file package to be burned from the host computer, and the MPU first verifies the file package to be burned before writing the target firmware in the file package to the MPU, thereby improving the effectiveness and reliability of firmware burning.

[0181] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0182] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0183] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A firmware flashing method, characterized in that, Applied to a vehicle control system, the vehicle control system including a microcontroller unit (MCU) and a microprocessor unit (MPU), the method includes: The MCU receives the programming message sent by the host computer via the bus, and sends a first restart command to the MPU according to the programming message; In response to the first reboot command, the MPU performs a reboot and loads the minimal Linux system stored in the MPU as the root file system; The MPU sends a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU via Ethernet. The MPU verifies the file package to be burned, and if the verification result indicates that the file package to be burned is complete and matches the vehicle control system, the target firmware included in the file package to be burned is written into the MPU. The MPU performs a reboot and loads the bootloader stored in the MPU as the root file system to execute the target firmware; Before the MCU receives the programming message sent by the host computer via the bus and sends a first reboot command to the MPU according to the programming message, the method further includes: The MCU receives the authentication request sent by the host computer via the bus, and authenticates the host computer according to the authentication request; When the authentication result indicates that the host computer has passed the authentication, the MCU sends authentication information to the host computer via the bus, so that the host computer responds to the authentication information and sends the programming message to the MCU via the bus.

2. The method according to claim 1, characterized in that, The file package to be burned also includes startup parameters; The step of writing the target firmware included in the file package to be burned into the MPU includes: Determine the target region specified in the startup parameters; According to the startup parameters, the target firmware is written into the target area within the MPU; The step of loading the bootloader stored in the MPU as a root file system to execute the target firmware includes: The bootloader is loaded as a root file system so that the bootloader copies the target firmware from the target region to the memory of the MPU; Execute the target firmware.

3. The method according to claim 2, characterized in that, After determining the target region specified in the boot parameters, the step of writing the target firmware included in the file package to be burned into the MPU further includes: Determine the state of the target area; If the state of the target area is abnormal, a first abnormality message is sent to the MCU, so that the MCU sends the first abnormality message to the host computer via the bus; The step of writing the target firmware into the target region within the MPU according to the boot parameters includes: If the target area is in a normal state, the target firmware is written to the target area according to the startup parameters.

4. The method according to claim 3, characterized in that, After determining the state of the target region, the step of writing the target firmware included in the file package to be programmed into the MPU further includes: If the state of the target region is abnormal, update the startup parameters and determine the replacement region specified in the updated startup parameters, wherein the replacement region is different from the target region; The step of writing the target firmware into the target region within the MPU according to the boot parameters includes: The target firmware is written to the replacement area according to the updated boot parameters.

5. The method according to claim 1, characterized in that, After writing the target firmware included in the file package to be programmed into the MPU, the method further includes: The MPU sends a first prompt message to the MCU, so that the MCU sends the first prompt message to the host computer via the bus; The MCU sends a second restart command to the MPU; The MPU performs a reboot and loads the bootloader stored within the MPU as the root file system to execute the target firmware, including: In response to the second reboot command, the MPU performs a reboot and loads the bootloader as the root file system to execute the target firmware.

6. The method according to any one of claims 1-5, characterized in that, The file package to be programmed also includes a first checksum and first version information; the MPU verifies the file package to be programmed, including: A second verification code is generated based on the file package to be burned; If the first verification code matches the second verification code, and the first version information matches the second version information of the vehicle control system, the verification result indicates that the file package to be burned is complete and matches the vehicle control system.

7. A vehicle control system, characterized in that, The vehicle control system includes: MCU and MPU; The MCU is used to receive the programming message sent by the host computer through the bus, and send a first restart command to the MPU according to the programming message; The MPU is used to respond to the first reboot command, perform a reboot, and load the Linux minimal system stored in the MPU as the root file system; The MPU is also used to send a programming request to the host computer via Ethernet, so that the host computer responds to the programming request and sends the file package to be programmed to the MPU via Ethernet; The MPU is also used to verify the file package to be burned, and write the file package to be burned into the MPU if the verification result indicates that the file package to be burned is complete and matches the vehicle control system. The MPU is also used to perform a reboot and load the bootloader stored in the MPU as a root file system to execute the target firmware included in the file package to be burned; Before the MCU receives the programming message sent by the host computer via the bus and sends a first reboot command to the MPU according to the programming message, the MCU is also used to: Receive the authentication request sent by the host computer via the bus, and authenticate the host computer according to the authentication request; If the authentication result indicates that the host computer has passed the authentication, the authentication information is sent to the host computer via the bus, so that the host computer responds to the authentication information and sends the programming message to the MCU via the bus.

8. The vehicle control system according to claim 7, characterized in that, The file package to be burned also includes startup parameters; the MPU is also used for: Determine the target region specified in the startup parameters; According to the startup parameters, the target firmware is written into the target area within the MPU; The bootloader is loaded as a root file system so that the bootloader copies the target firmware from the target region to the memory of the MPU; Execute the target firmware.

9. A firmware burning system, characterized in that, The firmware burning system includes a vehicle control system and a host computer, wherein the vehicle control system includes an MCU and an MPU. The vehicle control system is used to perform the method according to any one of claims 1-6.

Citation Information

Patent Citations

  • multiprocessor firmware online mutual updating method under a VPX architecture

    CN109656605A