Firmware flashing method and system for vehicle single-core microcontroller and vehicle-mounted controller

Abstract

The application relates to the technical field of vehicles and provides a firmware flashing method and system of a vehicle single-core microcontroller and a vehicle-mounted controller. The method comprises the following steps: in response to an upgrade starting instruction sent by an upper computer, performing a background pre-erasing operation on a temporary buffer area, so that all storage units of the temporary buffer area are set to a logic high level state; receiving new firmware data blocks sent by the upper computer in the same sub-sector granularity, and directly writing the data blocks into corresponding positions of the temporary buffer area; after all the data blocks are written, performing a full-amount check on the complete new firmware in the temporary buffer area, and if the check is passed, instructing the MCU to load the new firmware in the temporary buffer area at the next restart; after the new firmware is successfully started and runs, erasing the old firmware in the original firmware running area in the background, and converting the original firmware running area into a new temporary buffer area for next upgrade. The method, system and vehicle-mounted controller provided by the application greatly shorten the user-perceived flashing waiting time.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a firmware flashing method, system, and vehicle controller for a single-core microcontroller for vehicles. Background Technology

[0002] With the rapid development of vehicle electronics technology, the Electronic Control Unit (ECU) has evolved into the core control component of a vehicle. Firmware upgrades for the integrated single-core microcontroller unit (MCU) have become a key technical means to achieve functional optimization, performance improvement, and fault repair. However, current mainstream vehicle single-core MCU firmware flashing technology faces a long-standing and significant technical bottleneck: the firmware update process must strictly follow a serial operation sequence of "erase first, then write."

[0003] Before data can be written to a Flash memory cell, its state must be reset to all 1s (i.e., binary "1") through an erase operation. If new data is attempted to be written directly over an unerased area, the Flash memory can only change bits from "1" to "0" and cannot reverse the process to change "0" to "1". This will lead to data writing errors, logical confusion, and in severe cases, directly cause the MCU to malfunction or become bricked, resulting in irreversible hardware damage.

[0004] Therefore, the traditional firmware flashing process involves first performing a time-consuming full-sector or sub-sector erase operation after receiving an upgrade command. Only after the erase operation is completely complete can new firmware data be written. This erasure process is significantly time-consuming, typically lasting several seconds or even tens of seconds, forcing users to endure a waiting period without any data transmission during firmware upgrades. This rigid process, caused by underlying physical limitations, severely restricts the improvement of flashing efficiency and prolongs vehicle maintenance or upgrade time. Summary of the Invention

[0005] This invention provides a firmware flashing method, system, and vehicle controller for a single-core microcontroller in a vehicle, which solves the problem of low flashing efficiency caused by the requirement to wait for erasure to be completed before writing can begin in the prior art.

[0006] This invention provides a firmware flashing method for a vehicle single-core microcontroller. The non-volatile memory built into the microcontroller MCU includes three physically isolated storage areas: a firmware running area, a temporary buffer, and an upgrade status area. The method includes: In response to the upgrade start command sent by the host computer, a background pre-erasure operation is performed on the temporary buffer, setting all its storage units to a logic high level. The pre-erasure is performed on a sub-sector basis. Receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and write the data blocks directly into the pre-erased positions in the temporary buffer corresponding to the block number; After all data blocks have been written, a full verification is performed on the complete new firmware in the temporary buffer. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next reboot. After the new firmware is successfully started and running, the old firmware in the original firmware running area is erased in the background, and the original firmware running area is converted into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware running area.

[0007] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the step of performing a background pre-erase operation on the temporary buffer in response to the upgrade start command sent by the host computer includes: After receiving the upgrade start command sent by the host computer, read the data in the upgrade status area; If the data indicates an incomplete upgrade, then resume the download from where it left off according to the stored upgrade progress; if it is a completely new upgrade, then trigger a pre-erase operation on the temporary buffer.

[0008] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the upgrade status area adopts a power-off retention type storage medium and redundantly stores upgrade process status data, the status data including: the data block number that has been transmitted and written, the firmware full verification value, and the start switching flag. The firmware runtime area is used to store and execute the currently active firmware program and only supports read operations.

[0009] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the step of performing a full verification of the complete new firmware in the temporary buffer includes: The new firmware's checksum is calculated based on the complete data in the temporary buffer and compared with the full checksum stored in the upgrade status area. If the comparison is consistent, a start-up switching flag is set in the upgrade status area. The start-up switching flag is used to instruct the MCU to skip loading the new firmware in the temporary buffer in the firmware runtime area during the next reboot. If the comparison is inconsistent, the status data in the upgrade status area will be cleared and the upgrade will be marked as failed, while the original firmware in the firmware running area will be retained.

[0010] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the method further includes a rollback mechanism: if the new firmware fails to pass the preset operation verification conditions, the startup switching flag is cleared, and the original firmware in the firmware running area is restored and loaded during the next restart.

[0011] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the preset operation verification conditions include: the new firmware runs continuously and normally for more than a preset time, or the vehicle power-on self-test is completed and all key diagnostic items are passed.

[0012] According to the firmware flashing method for a vehicle single-core microcontroller provided by the present invention, the step of directly writing the data block to the pre-erased position corresponding to the block number in the temporary buffer includes: Receive the block checksum value of the new firmware data block sent by the host computer; The block check value is compared with the locally calculated check value. If they match, the data block is directly written into the pre-erased position in the temporary buffer corresponding to the block number.

[0013] This invention also provides a firmware flashing system for a vehicle single-core microcontroller. The non-volatile memory built into the microcontroller MCU includes three physically isolated storage areas: a firmware running area, a temporary buffer, and an upgrade status area. The system includes: The pre-erase unit is used to respond to the upgrade start command sent by the host computer and perform a background pre-erase operation on the temporary buffer, setting all its storage units to a logic high level. The pre-erase is performed on a sub-sector basis. The writing unit is used to receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and to directly write the data blocks into the pre-erased positions in the temporary buffer corresponding to the block number. The verification unit is used to perform a full verification of the complete new firmware in the temporary buffer after all data blocks have been written. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next reboot. The conversion unit is used to erase the old firmware in the original firmware running area in the background after the new firmware is successfully started and running, and convert the original firmware running area into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware running area.

[0014] The present invention also provides an in-vehicle controller, including a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that the processor executes the computer program to implement a firmware flashing method for the vehicle's single-core microcontroller.

[0015] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the firmware flashing method for a vehicle single-core microcontroller as described above.

[0016] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the firmware flashing method for a single-core microcontroller of a vehicle as described above.

[0017] The firmware flashing method, system, and vehicle controller for a single-core microcontroller provided by this invention, through background pre-erasure and precise matching of sub-sector granularity, completes the overall erasure of the temporary buffer during the upgrade startup phase, so that subsequent data block writing does not need to wait for any real-time erasure operation. The host computer can directly transmit and write data blocks, transforming the traditional serial erase-write process into parallel processing, significantly reducing the user-perceived flashing wait time, and achieving a highly efficient experience similar to direct overwrite. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the firmware flashing method for a single-core microcontroller for vehicles provided by the present invention.

[0020] Figure 2 This is a schematic diagram of the firmware flashing system for a single-core microcontroller in a vehicle provided by the present invention.

[0021] Figure 3 This is a schematic diagram of the vehicle controller provided by the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] To address the problem of low flashing efficiency caused by waiting for erasure to complete before writing in existing technologies, this invention provides a firmware flashing method for a vehicle single-core microcontroller. In this method, in response to an upgrade start command sent by a host computer, a background pre-erasure operation is performed on a temporary buffer, setting all its storage units to a logic high level. The pre-erasure is performed on a sub-sector basis. New firmware data blocks sent by the host computer in blocks with the same sub-sector granularity are received and directly written into the pre-erased position in the temporary buffer corresponding to the block number. After all data blocks are written, a full verification is performed on the complete new firmware in the temporary buffer. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next restart. After the new firmware successfully starts and runs, the old firmware in the original firmware running area is erased in the background, and the original firmware running area is converted into a new temporary buffer for the next upgrade.

[0024] The method provided in this invention, through background pre-erasure and precise matching of sub-sector granularity, completes the overall erasure of the temporary buffer during the upgrade startup phase, so that subsequent data block writing does not need to wait for any real-time erasure operation. The host computer can directly transmit and write data blocks, transforming the traditional serial erase-write process into parallel processing, significantly shortening the user-perceived flushing and writing waiting time, and achieving a highly efficient experience similar to direct overwrite.

[0025] Furthermore, this method employs a dynamic role-swapping storage area management strategy (switching between firmware runtime area and temporary buffer function), abandoning the A / B partition scheme that requires double the storage space. Without increasing hardware capacity, it achieves a uniform distribution of erase and write cycles, effectively extending the lifespan of small-capacity automotive-grade Flash memory and significantly reducing ECU material costs and design complexity.

[0026] Furthermore, this solution is based on existing diagnostic protocols and standard sub-sector erasable Flash hardware, requiring no modification to the host computer's writing logic, only MCU-side embedded software adaptation; all operations such as pre-erasure, block writing, and status management are completed autonomously by the MCU, without relying on external coprocessors or additional storage devices, and possesses strong portability and short-cycle mass production capabilities.

[0027] In this embodiment, the non-volatile memory built into the microcontroller (MCU) includes three physically isolated storage areas: a firmware runtime area, a temporary buffer, and an upgrade state area. This non-volatile memory can be Flash memory.

[0028] The firmware runtime area is used to store and execute the currently active firmware program and only supports read operations. Temporary buffer: Used to store new firmware block data after pre-erasure. It is the same size as the firmware running area and supports sub-sector erasure. For example, the erasure granularity is 256B-512B, ensuring that data can be directly overwritten without real-time erasure when writing. Upgrade status area: Employs power-off retention EEPROM media, ensuring data integrity even in the event of power failure. Two identical copies of the data are redundantly stored, containing upgrade progress (numbers of transmitted and written data blocks), firmware full checksum, and start-up switching flags to prevent upgrade status errors caused by power outages or interference.

[0029] Figure 1 This is a flowchart illustrating the firmware flashing method for a single-core microcontroller in a vehicle provided by the present invention, as shown below. Figure 1 As shown, the method includes steps 110-140.

[0030] Step 110: In response to the upgrade start command sent by the host computer, perform a background pre-erase operation on the temporary buffer, setting all its storage units to a logic high level. The pre-erase is performed on a sub-sector basis.

[0031] Specifically, the host computer can be a diagnostic tool or an FOTA Master. The host computer sends an upgrade start command to the vehicle's single-core MCU. After receiving the upgrade command, the MCU starts a low-priority background task, calls the Flash driver library function, and erases the entire temporary buffer in a loop, sector by sector, and verifies whether all its memory units are in a logic high state.

[0032] Background pre-erase operation refers to the system performing erasure as a low-priority task when the system is idle, without the user's awareness. The core idea is to complete the time-consuming erasure operation in advance, rather than performing it in real-time during data writing. The erase operation resets the memory cell to "1" (high level), and the write operation can only change "1" to "0". Keeping the temporary buffer in "all 1s" creates the prerequisite for subsequent direct overwrite writing. A sub-sector is one of the smallest units of Flash memory that can be erased (e.g., 256B / 512B), much smaller than the entire sector. Small-granularity erasure is fast and suitable for frequent operations.

[0033] The purpose of this step is to remove the erase wait time on the data write path. By processing the target area, i.e., the temporary buffer, into a writable state before data transmission, the foundation for subsequent direct overwriting is laid, avoiding the serial wait of "transfer-erase-write" in the traditional process, thereby greatly improving the user experience.

[0034] In some embodiments, step 110 specifically includes: After receiving the upgrade start command sent by the host computer, read the data in the upgrade status area; If the data indicates that there is an incomplete upgrade, the interrupted download will be resumed according to the stored upgrade progress; if it is a brand new upgrade, a pre-erase operation of the temporary buffer will be triggered.

[0035] Specifically, the MCU's communication driver layer parses the messages from the bus and identifies the upgrade start command. The MCU calls the storage driver to read the data from the upgrade status area of ​​the EEPROM at a fixed address, which is the status data of the upgrade process. This status data typically includes: upgrade flag bits (such as 0x55AA indicating in progress), the number of data blocks that have been transmitted and written, the firmware full checksum, and the start switching flag, etc.

[0036] The MCU checks if the upgrade flag is in progress and verifies the validity of information such as the data block number. If it determines that an incomplete upgrade needs to be resumed, the MCU increments the last successfully written data block number in the status area by one to calculate the next block number to be received. When the host computer reconnects, the MCU can inform the host computer to start sending from that block number, thus achieving resume transmission.

[0037] If the upgrade flag is "idle" or the status data verification fails, it is determined to be a brand new upgrade, triggering a pre-erase operation on the temporary buffer. The pre-erase operation is performed in the background and does not affect the MCU from performing other non-critical tasks.

[0038] This invention effectively addresses unexpected interruptions during the upgrade process through a breakpoint resume mechanism, avoiding the need to start the entire upgrade from scratch due to a brief malfunction, thus greatly improving user experience and system reliability. By automatically reading historical states and intelligently selecting execution paths, the system possesses memory and sustainability capabilities, reducing manual intervention and making the entire upgrade process more automated and intelligent.

[0039] Step 120: Receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and write the data blocks directly into the pre-erased position in the temporary buffer corresponding to the block number.

[0040] Specifically, the host computer divides the new firmware into several data blocks (e.g., 256 bytes / block) according to the sub-sector granularity of the temporary buffer, and sends the data block, along with its corresponding block number and block checksum, to the MCU block by block. The same sub-sector granularity means that the size of the data block is consistent with the smallest unit (sub-sector) of Flash erasure. Direct writing means that the target location has been pre-erased to all 1s; writing new data is simply a "write 0" operation, without prior erasure, i.e., direct overwrite. Data blocks can be written immediately upon arrival, and the writing speed reaches the limit of the Flash hardware.

[0041] To further improve reliability, the host computer sends a CRC checksum along with each data block. The MCU receives the block checksum of the new firmware data block sent by the host computer; it compares the block checksum with the locally calculated checksum; if the comparison matches, the checksum passes, and the MCU directly calls the Flash write function to write the data to the corresponding sub-sector address in the temporary buffer.

[0042] After the write is complete, the MCU updates the "transmitted block number" in the upgrade status area and returns a block write success response to the host computer.

[0043] Step 130: After all data blocks have been written, perform a full verification of the complete new firmware in the temporary buffer. If the verification passes, instruct the MCU to load the new firmware in the temporary buffer during the next reboot.

[0044] Specifically, full verification refers to calculating the checksum (such as SHA-256) of the entire new firmware after all data blocks have been written, comparing it with the standard value provided by the host computer, and verifying that the new firmware written to the temporary buffer is completely consistent with the source file, ensuring that the firmware is complete and error-free. If the verification passes, the MCU can be instructed to load the new firmware in the temporary buffer on the next reboot via a startup flag.

[0045] In some embodiments, step 130 specifically includes: Step 131: Calculate the check value of the new firmware based on the complete data in the temporary buffer, and compare it with the full check value stored in the upgrade status area; Step 132: If the comparison is consistent, a start-up switching flag is set in the upgrade status area. The start-up switching flag is used to instruct the MCU to skip loading the new firmware in the temporary buffer in the firmware running area during the next reboot. Step 133: If the comparison is inconsistent, clear the status data in the upgrade status area and mark the upgrade as failed, while retaining the original firmware in the firmware running area.

[0046] Specifically, the complete data in the temporary buffer refers to the complete, unexecuted new firmware binary image that has been fully written into the temporary buffer. A checksum is calculated for the complete new firmware data in the temporary buffer using a specific algorithm (such as CRC32 or SHA256).

[0047] The full checksum stored in the upgrade status area is calculated by the host computer and sent along with the upgrade command; it represents the checksum of the standard firmware. The MCU stores it in the upgrade status area as a benchmark for comparison.

[0048] The purpose of the comparison is to confirm that the new firmware data transmitted from the host computer and written to the temporary buffer is 100% complete and error-free, thereby preventing system startup failure caused by incorrect or corrupted firmware. This fundamentally eliminates firmware data corruption caused by transmission errors, write interference, or storage media failure. It ensures that only firmware that passes the verification is allowed to be loaded and executed.

[0049] If the comparison matches, confirming the new firmware is intact, a boot switch flag is set in the upgrade status area. The boot switch flag is one or a set of specific flags stored in the upgrade status area. It indicates where the MCU's bootloader should load the program on the next boot. When the boot switch flag is set, the bootloader ignores the normal boot process (loading from the firmware runtime area) and jumps to the beginning address of the temporary buffer, loading and executing the new firmware from the temporary buffer. Setting the flag does not affect the currently running old firmware; the system remains stable until the next planned reboot.

[0050] If the comparison fails (i.e., verification fails), a secure failure handling procedure is executed. Its core objective is to erase all traces of this upgrade and ensure the system has an absolutely reliable fallback path. Clearing the status data in the upgrade status area means resetting the upgrade progress recorded there, such as transmitted block numbers and start-up switch flags, to their initial state. A separate failure flag is then set in the upgrade status area to report the status to the host computer and may record error logs.

[0051] In practice, the MCU program clears the field recording the upgrade progress in the upgrade status area, writes the address of the start switching flag to 0x0000 (or other invalid value), and writes a verification failure error code to the error log area. After completion, it sends an upgrade failure response to the host computer.

[0052] At the same time, the original firmware in the firmware runtime area is retained, ensuring that even if this upgrade fails, the system can still revert to a known and stable old version on the next boot, thus 100% avoiding bricking.

[0053] Step 140: After the new firmware successfully starts and runs, erase the old firmware in the original firmware runtime area in the background, and convert the original firmware runtime area into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware runtime area.

[0054] Specifically, after the new firmware successfully boots and runs, the system triggers a low-priority task to gradually erase the original firmware's runtime area. The purpose is to clean up the outdated firmware and free up storage space. Background erasure refers to the cleanup operation performed when the system is idle and does not affect the current system performance.

[0055] In this upgrade, the "firmware runtime area" (storing the old firmware) is logically marked as a "temporary buffer" for the next upgrade after the old firmware is erased. By switching roles, the number of erase / write cycles for the two main storage areas (firmware runtime area and temporary buffer) is balanced, extending the Flash lifespan. At the same time, a clean temporary buffer is prepared for the next upgrade cycle.

[0056] In some embodiments, the firmware flashing method further includes a rollback mechanism: if the new firmware fails to pass the preset running verification conditions, the boot switching flag is cleared, and the original firmware in the firmware running area is restored and loaded during the next reboot.

[0057] Specifically, the rollback mechanism refers to the system's ability to automatically and safely revert to the previous upgrade operation and restore to the known, stable old firmware version when the new firmware fails to pass verification.

[0058] The preset operational verification conditions here are a series of objective standards used by the system to determine whether the new firmware is healthy and usable after startup. The preset operational verification conditions may include: the new firmware running continuously and normally for more than a preset time, or completing the vehicle power-on self-test and passing all critical diagnostic items.

[0059] The phrase "new firmware runs continuously for more than a preset time" refers to whether the new firmware can run stably without crashing within a preset time, such as 30 seconds, after it has successfully started.

[0060] Completing the vehicle power-on self-test and passing all critical diagnostic items means that the new firmware can complete the critical vehicle startup self-test process, such as sensor communication checks and actuator drive tests, and return a "pass" signal.

[0061] Preset operational verification conditions may also include heartbeat signals, such as whether the new firmware can periodically send a liveness signal to a specific monitoring unit of the system, such as a watchdog or bootloader, within a specified time.

[0062] If the runtime verification conditions are not met, the flag stored in the upgrade status area that indicates the new firmware should be loaded on the next boot will be reset or deleted. After the boot flag is cleared, the bootloader will not be able to find the instruction to load the new firmware on the next system reboot, so it will execute the default boot process, that is, load and execute the old version of firmware before the upgrade from the firmware runtime area.

[0063] This invention constructs a final safety line, ensuring that the Electronic Control Unit (ECU) will not become unusable in the event of any upgrade failure, thus protecting the vehicle's basic functions and safety. Even if the new firmware itself has serious defects that prevent booting, this rollback mechanism ensures that the system automatically reverts to a working older version, allowing the ECU to always maintain basic functionality and fundamentally eliminating the risk of paralysis that upgrades may cause. The entire rollback process requires no manual intervention; it is automatically triggered and executed by the system, achieving intelligent fault recovery.

[0064] The firmware flashing system for a single-core microcontroller for a vehicle provided by the present invention will be described below. The firmware flashing system for a single-core microcontroller for a vehicle described below can be referred to in correspondence with the firmware flashing method for a single-core microcontroller for a vehicle described above.

[0065] Based on the above embodiments, Figure 2 This is a schematic diagram of the firmware flashing system for a single-core microcontroller in a vehicle provided by the present invention, as shown below. Figure 2 As shown, the system includes: The pre-erasure unit 210 is used to respond to the upgrade start command sent by the host computer and perform a background pre-erasure operation on the temporary buffer, setting all its storage units to a logic high level. The pre-erasure is performed on a sub-sector basis. The writing unit 220 is used to receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and directly write the data blocks into the pre-erased position in the temporary buffer corresponding to the block number. The verification unit 230 is used to perform a full verification of the complete new firmware in the temporary buffer after all data blocks have been written. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next restart. The conversion unit 240 is used to erase the old firmware in the original firmware running area in the background after the new firmware is successfully started and running, and convert the original firmware running area into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware running area.

[0066] Based on the above embodiments, the pre-erasing unit is specifically used for: After receiving the upgrade start command sent by the host computer, read the data in the upgrade status area; If the data indicates an incomplete upgrade, then resume the download from where it left off according to the stored upgrade progress; if it is a completely new upgrade, then trigger a pre-erase operation on the temporary buffer.

[0067] Based on the above embodiments, the upgrade status area adopts a power-off retention storage medium and redundantly stores upgrade process status data. The status data includes: the data block number that has been transmitted and written, the firmware full verification value, and the start-up switching flag. The firmware runtime area is used to store and execute the currently active firmware program and only supports read operations.

[0068] Based on the above embodiments, the verification unit is specifically used for: The new firmware's checksum is calculated based on the complete data in the temporary buffer and compared with the full checksum stored in the upgrade status area. If the comparison is consistent, a start-up switching flag is set in the upgrade status area. The start-up switching flag is used to instruct the MCU to skip loading the new firmware in the temporary buffer in the firmware runtime area during the next reboot. If the comparison is inconsistent, the status data in the upgrade status area will be cleared and the upgrade will be marked as failed, while the original firmware in the firmware running area will be retained.

[0069] Based on the above embodiments, the system further includes a rollback unit, used for: If the new firmware fails the preset running verification conditions, the startup switching flag is cleared, and the original firmware in the firmware running area is restored and loaded on the next reboot.

[0070] Based on the above embodiments, the preset operation verification conditions include: the new firmware runs continuously and normally for more than a preset time, or the vehicle power-on self-test is completed and all key diagnostic items pass.

[0071] Based on the above embodiments, the writing unit is specifically used for: Receive the block checksum value of the new firmware data block sent by the host computer; The block check value is compared with the locally calculated check value. If they match, the data block is directly written into the pre-erased position in the temporary buffer corresponding to the block number.

[0072] The system provided by this invention has the following beneficial effects: 1. Improved flashing efficiency: The host computer does not need to execute erase commands. It can directly transmit firmware in blocks to complete the writing process. The total flashing time is significantly reduced compared to traditional solutions. The user layer is completely unaware of the erase operation, achieving a "quasi-direct overwrite" flashing experience.

[0073] 2. Maximize hardware resource utilization: No A / B partition design is required, and the Flash space usage is only 50% of the traditional dual-partition solution. It is compatible with small-capacity single-core MCUs and does not require replacement with large-capacity Flash, significantly reducing the hardware cost of vehicle ECUs.

[0074] 3. Reliability Guarantee: Combining read-only protection of the operating area, breakpoint resume, and startup rollback mechanisms, the system comprehensively avoids ECU "bricking" caused by flashing interruptions, from hardware isolation to software fault tolerance.

[0075] 4. Low implementation cost: No need to modify the existing flashing process of the diagnostic instrument, FOTA client and other host computers. Only software adaptation is required inside the MCU. It is compatible with the existing UDS protocol and automotive-grade Flash (supports sub-sector erasure). No additional hardware modifications are required. The engineering implementation cycle is short and the difficulty is low.

[0076] Figure 3 An example is a schematic diagram of the physical structure of an on-board controller, such as... Figure 3 As shown, the vehicle controller may include a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 can call logic instructions in the memory 330 to execute a firmware flashing method for a vehicle single-core microcontroller. This method includes: responding to an upgrade start command sent by a host computer; performing a background pre-erasure operation on the temporary buffer, setting all its storage units to a logic high level; the pre-erasure is performed on a sub-sector basis; receiving new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity; directly writing the data blocks into the pre-erased positions in the temporary buffer corresponding to the block number; after all data blocks have been written, performing a full verification of the complete new firmware in the temporary buffer; if the verification passes, instructing the MCU to load the new firmware in the temporary buffer during the next restart; after the new firmware successfully starts and runs, erasing the old firmware in the original firmware running area in the background, and converting the original firmware running area into a new temporary buffer for the next upgrade, the storage capacity of which is equal to that of the firmware running area.

[0077] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0078] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the firmware flashing method for a vehicle single-core microcontroller provided by the above methods. The method includes: responding to an upgrade start command sent by a host computer, performing a background pre-erasure operation on the temporary buffer, setting all its storage units to a logic high level, wherein the pre-erasure is performed on a sub-sector basis; receiving new firmware data blocks sent by the host computer in blocks of the same sub-sector granularity, and directly writing the data blocks into the pre-erased positions in the temporary buffer corresponding to the block number; after all data blocks have been written, performing a full verification of the complete new firmware in the temporary buffer, and if the verification passes, instructing the MCU to load the new firmware in the temporary buffer during the next restart; after the new firmware has successfully started and is running, erasing the old firmware in the original firmware running area in the background, and converting the original firmware running area into a new temporary buffer for the next upgrade, wherein the storage capacity of the temporary buffer is equal to that of the firmware running area.

[0079] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a firmware flashing method for a vehicle single-core microcontroller provided by the above methods. The method includes: responding to an upgrade start command sent by a host computer, performing a background pre-erasure operation on the temporary buffer, setting all its storage units to a logic high level, wherein the pre-erasure is performed on a sub-sector basis; receiving new firmware data blocks sent by the host computer in blocks of the same sub-sector granularity, and directly writing the data blocks into the pre-erased positions in the temporary buffer corresponding to the block number; after all data blocks have been written, performing a full verification on the complete new firmware in the temporary buffer, and if the verification passes, instructing the MCU to load the new firmware in the temporary buffer during the next restart; after the new firmware has successfully started and is running, erasing the old firmware in the original firmware running area in the background, and converting the original firmware running area into a new temporary buffer for the next upgrade, wherein the storage capacity of the temporary buffer is equal to that of the firmware running area.

[0080] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, 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 can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A firmware flashing method for a vehicle single-core microcontroller, characterized in that, The microcontroller's built-in non-volatile memory includes three physically isolated storage areas: a firmware runtime area, a temporary buffer, and an upgrade state area. The method includes: In response to the upgrade start command sent by the host computer, a background pre-erasure operation is performed on the temporary buffer, setting all its storage units to a logic high level. The pre-erasure is performed on a sub-sector basis. Receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and write the data blocks directly into the pre-erased positions in the temporary buffer corresponding to the block number; After all data blocks have been written, a full verification is performed on the complete new firmware in the temporary buffer. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next reboot. After the new firmware is successfully started and running, the old firmware in the original firmware running area is erased in the background, and the original firmware running area is converted into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware running area.

2. The firmware flashing method for a vehicle single-core microcontroller according to claim 1, characterized in that, The response to the upgrade start command sent by the host computer includes performing a background pre-erasure operation on the temporary buffer, including: After receiving the upgrade start command sent by the host computer, read the data in the upgrade status area; If the data indicates an incomplete upgrade, then resume the download from where it left off according to the stored upgrade progress; if it is a completely new upgrade, then trigger a pre-erase operation on the temporary buffer.

3. The firmware flashing method for a vehicle single-core microcontroller according to claim 2, characterized in that, The upgrade status area uses a power-off retention storage medium and redundantly stores upgrade process status data. The status data includes: the data block number that has been transmitted and written, the firmware full verification value, and the start-up switching flag. The firmware runtime area is used to store and execute the currently active firmware program and only supports read operations.

4. The firmware flashing method for a vehicle single-core microcontroller according to claim 3, characterized in that, The full verification of the complete new firmware in the temporary buffer includes: The new firmware's checksum is calculated based on the complete data in the temporary buffer and compared with the full checksum stored in the upgrade status area. If the comparison is consistent, a start-up switching flag is set in the upgrade status area. The start-up switching flag is used to instruct the MCU to skip loading the new firmware in the temporary buffer in the firmware runtime area during the next reboot. If the comparison is inconsistent, the status data in the upgrade status area will be cleared and the upgrade will be marked as failed, while the original firmware in the firmware running area will be retained.

5. The firmware flashing method for a vehicle single-core microcontroller according to claim 1, characterized in that, The method also includes a rollback mechanism: if the new firmware fails to pass the preset running verification conditions, the startup switching flag is cleared, and the original firmware in the firmware running area is restored and loaded during the next restart.

6. The firmware flashing method for a vehicle single-core microcontroller according to claim 5, characterized in that, The preset operation verification conditions include: the new firmware runs continuously and normally for more than a preset time, or the vehicle completes the power-on self-test and all key diagnostic items pass.

7. The firmware flashing method for a vehicle single-core microcontroller according to any one of claims 1 to 6, characterized in that, The step of directly writing the data block into the pre-erased location corresponding to the block number in the temporary buffer includes: Receive the block checksum value of the new firmware data block sent by the host computer; The block check value is compared with the locally calculated check value. If they match, the data block is directly written into the pre-erased position in the temporary buffer corresponding to the block number.

8. A firmware flashing system for a vehicle single-core microcontroller, characterized in that, The microcontroller (MCU) has a built-in non-volatile memory comprising three physically isolated storage areas: a firmware runtime area, a temporary buffer, and an upgrade state area. The system includes: The pre-erase unit is used to respond to the upgrade start command sent by the host computer and perform a background pre-erase operation on the temporary buffer, setting all its storage units to a logic high level. The pre-erase is performed on a sub-sector basis. The writing unit is used to receive new firmware data blocks sent by the host computer in blocks with the same sub-sector granularity, and to directly write the data blocks into the pre-erased positions in the temporary buffer corresponding to the block number. The verification unit is used to perform a full verification of the complete new firmware in the temporary buffer after all data blocks have been written. If the verification passes, the MCU is instructed to load the new firmware in the temporary buffer during the next reboot. The conversion unit is used to erase the old firmware in the original firmware running area in the background after the new firmware is successfully started and running, and convert the original firmware running area into a new temporary buffer for the next upgrade. The storage capacity of the temporary buffer is equal to that of the firmware running area.

9. An on-board controller, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the firmware flashing method for a vehicle single-core microcontroller as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the firmware flashing method for a vehicle single-core microcontroller as described in any one of claims 1 to 7.

Images