Safety anti-brick upgrading method, system and controller of vehicle-mounted single-zone MCU

Abstract

The application relates to the technical field of vehicles and provides a safe anti-brick upgrading method, system and controller of a vehicle-mounted single-partition MCU, the method comprising the following steps: in response to an upgrading instruction, a main program area sub-block receives new firmware data and writes the new firmware data into a temporary upgrading area, while the main program area keeps a read-only lock state; after the new firmware data is completely written into the temporary upgrading area, full-amount verification is carried out, if the verification is passed, the upgrading state in a double-backup configuration area is updated to be under verification; a system reset is triggered, and a boot program in a solidification boot area guides the execution of new firmware in the temporary upgrading area according to the under-verification state in the double-backup configuration area; if an identification signal indicating that the new firmware is successfully initialized is not received within a preset time length, the upgrading state in the double-backup configuration area is updated to be rolled back, and the original firmware in the main program area is guided to be executed, so that automatic rollback is completed. The method, system and controller provided by the application avoid device brick, and guarantee driving safety.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a secure anti-bricking upgrade method, system, and controller for an in-vehicle single-zone MCU. Background Technology

[0002] With the rapid development of automotive electronics technology, automotive microcontrollers (MCUs) have become core execution components for critical electronic control functions such as body control modules (BCMs), lighting systems, and tire pressure monitoring systems (TPMS). Among them, automotive MCUs based on single-partition Flash memory architecture dominate the electronic systems of mid-to-low-end vehicles due to their low cost and stable operation. However, these MCUs face significant challenges in adapting to automotive scenarios during firmware upgrades, including: Upgrading while the vehicle is in motion can easily brick the equipment. Voltage fluctuations caused by the start-stop system and other functions during vehicle operation often interrupt the upgrade process. Because traditional solutions directly overwrite the old program with the new one, there is a lack of effective backup after an upgrade failure, causing critical control modules such as the BCM to malfunction. This necessitates on-site assistance from a 4S dealership, severely impacting user experience and increasing maintenance costs.

[0003] Furthermore, functional safety does not meet automotive-grade requirements. Existing dual-bank storage solutions suitable for mid-to-high-end MCUs are difficult to implement on single-partition MCUs, resulting in simplified upgrade solutions lacking necessary data integrity verification and fault monitoring mechanisms, and failing to meet the safety requirements of ISO 26262 standard ASIL-B level. Summary of the Invention

[0004] This invention provides a secure anti-bricking upgrade method, system, and controller for a vehicle-mounted single-partition MCU, which solves the defects of existing technologies such as easy bricking and non-compliance with functional safety standards during vehicle upgrades. It achieves high reliability by meeting the ISO 26262 ASIL-B functional safety level requirements under a low-cost single-partition hardware architecture and ensuring uninterrupted upgrade of critical functions during vehicle operation.

[0005] This invention provides a secure anti-brick upgrade method for a vehicle-mounted single-partition MCU. The MCU's unique physical Flash memory is divided into four functional areas by software logic: a firmware boot area, a main program area, a temporary upgrade area, and a dual backup configuration area. The method includes: In response to the upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state. After all the new firmware data is written to the temporary upgrade area, a full verification is performed. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification. The system is triggered to reset, and the boot program in the solidified boot area guides the execution of the new firmware in the temporary upgrade area according to the unverified status in the dual backup configuration area. If no identifier signal indicating successful initialization of the new firmware is received within the preset time period, the upgrade status in the dual backup configuration area is updated to rollback, and the original firmware in the main program area is executed to complete the automatic rollback.

[0006] According to the secure anti-brick upgrade method for a vehicle-mounted single-partition MCU provided by the present invention, the solidified boot area is used to store unmodifiable boot code; The main program area is used to store and execute the currently active in-vehicle application, and is locked in a read-only state during the upgrade process and protected by error check code ECC. The temporary upgrade area is used to temporarily store new firmware data to be verified. It is only allowed to be written to during the upgrade phase, and a full sector erase is performed before writing. The dual backup configuration area adopts a power-off retention non-volatile storage structure, redundantly storing two copies of configuration data. Each copy of configuration data includes the program entry address, the full verification value of the new firmware, the upgrade status, the vehicle power status, and the parity check code.

[0007] According to the secure anti-brick upgrade method for a vehicle-mounted single-partition MCU provided by the present invention, the boot program in the solidified boot area guides the execution of new firmware in the temporary upgrade area based on the unverified state in the dual backup configuration area, including: The boot program in the solidified boot area first reads the primary backup data from the dual backup configuration area. If the primary backup verification fails, it reads the secondary backup. If both backups fail verification, it jumps to the hard-coded fallback execution address of the main program area. After confirming the valid configuration, the system will jump to the temporary upgrade area based on the upgrade status to load and execute the new firmware.

[0008] The security anti-brick upgrade method for an in-vehicle single-zone MCU provided by the present invention further includes: The solidified guide area monitors the vehicle power supply voltage and MCU core temperature before startup verification; When the power supply voltage exceeds the preset voltage threshold or the core temperature exceeds the preset temperature threshold, the startup process is delayed until the environmental parameters return to normal.

[0009] According to the secure anti-brick upgrade method for a vehicle-mounted single-partition MCU provided by the present invention, the step of performing a full verification after all the new firmware data is written to the temporary upgrade area includes: After all the new firmware data is written to the temporary upgrade area, the full check value of the complete new firmware in the temporary upgrade area is calculated and compared with the check value pre-stored in the dual backup configuration area, and the functional safety identifier of the new firmware is verified at the same time. After the comparison is consistent and the security mark verification is passed, the verification is confirmed to be successful.

[0010] According to the secure anti-brick upgrade method for a vehicle-mounted single-zone MCU provided by the present invention, the step of updating the upgrade status in the dual backup configuration area to pending verification if the verification passes includes: If the verification passes, update the upgrade status in the dual backup configuration area to pending verification in the atomic order of first erasing the secondary backup, writing to the secondary backup and verifying, then erasing the primary backup, writing to the primary backup and verifying.

[0011] According to the secure anti-brick upgrade method for an in-vehicle single-partition MCU provided by the present invention, before the main program partition receives new firmware data in blocks and writes it to the temporary upgrade area, the method further includes: Detect the current vehicle status; If the module to be upgraded is a safety-related module, the upgrade will be triggered when the vehicle is in the park position; if it is a non-safety-related module, the upgrade can be triggered while the vehicle is in motion.

[0012] According to the secure anti-brick upgrade method for a vehicle-mounted single-partition MCU provided by the present invention, the main program partition receives new firmware data in blocks and writes it to the temporary upgrade area, including: The host computer sends new firmware data in blocks via CAN bus or LIN bus; After receiving each data block, the main program area verifies its local CRC32 and bus communication check code. If the verification passes, the data block is written to the temporary upgrade area; if the verification fails, the host computer is requested to retransmit the data block.

[0013] This invention also provides a secure anti-brick upgrade system for an in-vehicle single-partition MCU. The MCU's unique physical Flash memory is divided into four functional areas by software logic: a firmware boot area, a main program area, a temporary upgrade area, and a dual backup configuration area. The system includes: The data writing unit is used to receive new firmware data in blocks and write it to the temporary upgrade area in response to the upgrade command, while keeping itself in a read-only locked state during the upgrade process. The verification and update unit is used to perform a full verification of the complete new firmware in the temporary upgrade area after all the new firmware data has been written. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification. The verification boot unit is used to read the upgrade status in the dual backup configuration area after the system is reset. If the status is pending verification, it will guide the execution of the new firmware in the temporary upgrade area. The rollback unit is used to update the upgrade status in the dual backup configuration area to rollback if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, and to guide the execution of the original firmware in the main program area to complete the automatic rollback.

[0014] The present invention also provides an in-vehicle controller, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the secure anti-brick upgrade method for in-vehicle single-partition MCUs as described above.

[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 secure anti-brick upgrade method for an in-vehicle single-partition MCU 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 security anti-bricking upgrade method for an in-vehicle single-partition MCU as described above.

[0017] This invention provides a secure, brick-proof upgrade method, system, and controller for a vehicle-mounted single-partition MCU. A single physical Flash memory is divided into a firmware boot area, a main program area, a temporary upgrade area, and a dual-backup configuration area via software logic. During an upgrade, the new firmware is written to the independent temporary upgrade area, while the main program area running the current system remains in a read-only locked state. This ensures that the upgrade process does not damage or overwrite the currently running valid firmware. Even if the upgrade process is interrupted due to vehicle power fluctuations, critical control modules such as the BCM can still operate normally based on the original firmware, fundamentally preventing device bricking, ensuring driving safety, and eliminating high on-site rescue costs. 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 secure anti-bricking upgrade method for a vehicle-mounted single-zone MCU provided by the present invention.

[0020] Figure 2This is a schematic diagram of the structure of the vehicle-mounted single-zone MCU security anti-brick upgrade system 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 issues of bricking and non-compliance with functional safety standards during vehicle upgrades in existing technologies, this invention proposes a secure anti-bricking upgrade method for a vehicle-mounted single-partition MCU. In this method, the MCU's unique physical Flash memory is logically divided into four functional areas: a firmware boot area, a main program area, a temporary upgrade area, and a dual-backup configuration area. The upgrade process includes: responding to an upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains read-only locked; after all the new firmware data is written to the temporary upgrade area, a full verification is performed. If the verification passes, the upgrade status in the dual-backup configuration area is updated to "pending verification"; a system reset is triggered, and the bootloader in the firmware boot area, based on the "pending verification" status in the dual-backup configuration area, guides the execution of the new firmware in the temporary upgrade area; if no indicator signal indicating successful initialization of the new firmware is received within a preset time period, the upgrade status in the dual-backup configuration area is updated to "rollback," and the original firmware in the main program area is executed, completing the automatic rollback.

[0024] The upgrade method provided in this invention divides a single physical Flash memory into a firmware boot area, a main program area, a temporary upgrade area, and a dual backup configuration area through software logic. During the upgrade, the new firmware is written to the independent temporary upgrade area, while the main program area running the current system remains in a read-only locked state. This ensures that the upgrade process will not damage or overwrite the currently running valid firmware. Even if the upgrade process is interrupted due to vehicle power fluctuations, critical control modules such as the BCM can still operate normally based on the original firmware, fundamentally preventing the device from becoming unusable, ensuring driving safety, and eliminating high on-site rescue costs.

[0025] This method performs a full verification before launching the new firmware via the bootloader and monitors whether the new firmware has been successfully initialized by setting a confirmation window of a preset duration (e.g., 5 seconds). If no success signal is received, the rollback process is automatically triggered. This achieves status monitoring, error diagnosis, and security isolation throughout the upgrade process, ensuring that the system can automatically and reliably roll back to a known stable older version within 10 seconds in the event of any upgrade failure, thus meeting functional safety standards.

[0026] Furthermore, the method provided in this invention does not rely on expensive dual-bank hardware or additional Flash chips, but implements all the functions required for security upgrades on a low-cost single-partition MCU solely through software. This enables a large number of deployed low-to-mid-range automotive ECUs to be upgraded with a high level of security without increasing hardware costs, greatly improving the compatibility and cost-effectiveness of the solution.

[0027] The execution entity for this method can be an onboard single-partition MCU microcontroller. The MCU's single physical Flash memory is divided into four functional areas via software logic: a boot sector, a main program sector, a temporary upgrade sector, and a dual-backup configuration sector. The sectors in each area do not overlap and are subject to access control isolation. Specifically: The hardened boot sector is used to store unmodifiable boot code; The main program area is used to store and execute currently active in-vehicle applications. During the upgrade process, it is locked in a read-only state and protected by error check codes (ECC). The temporary upgrade area is used to temporarily store new firmware data that is yet to be verified. It is only allowed to be written to during the upgrade phase, and a full sector erase is performed before writing. The dual-backup configuration area adopts a power-loss-retaining non-volatile storage structure, redundantly storing two copies of the configuration data. Each copy of the configuration data includes the program entry address, the full checksum of the new firmware, the upgrade status, the vehicle power status, and the parity check code.

[0028] Specifically, the hardened boot sector stores a minimal startup code that is burned at the factory and cannot be modified subsequently. It is the first piece of code that runs after the MCU powers on. As the system's root of trust, the hardened boot sector ensures the security of the boot chain's starting point and is responsible for executing safe switching and rollback decisions after upgrades. This area is implemented through hardware write protection, with extremely concise code, mainly integrating vehicle environment monitoring (such as voltage and temperature) and core boot logic. The hardened boot sector provides hardware-level security against tampering and implements automatic rollback after upgrade failure through an intelligent fault-tolerance mechanism, becoming the core guarantee against bricking.

[0029] The main program area is used to store and execute currently active in-vehicle applications (such as BCM body control logic). During the upgrade process, the main program area is locked in a read-only state to ensure the continuous and stable operation of critical vehicle functions and to act as a safety backup during the upgrade process. Read-only permissions are set through the MCU's memory protection unit, and ECC error checking and correction functions are enabled to ensure the absolute correctness of the runtime code. This allows for upgrades while driving without interrupting critical functions and fundamentally solves the risk of system bricking, as a complete and intact system is always available as a fallback option in any situation.

[0030] The temporary upgrade area is a "sandbox" specifically designed to temporarily store the data for the new firmware to be upgraded. Its purpose is to ensure that the writing, verification, and trial operation of the new firmware are completed in an independent, isolated space, thereby limiting the potential risks of the new firmware to this area.

[0031] The dual-backup configuration area uses non-volatile storage media to store two identical copies of critical system configuration data in a redundant manner. By securely storing the upgrade status, it ensures that at least one valid configuration copy is available in the event of unexpected power outages or other scenarios. The dual-backup configuration area is typically implemented using power-loss-retaining non-volatile storage media or specific Flash sectors, including functions such as parity checking, ensuring that configuration information is never lost and providing a reliable basis for status management and security decisions throughout the upgrade process.

[0032] Figure 1 This is a flowchart illustrating the secure anti-bricking upgrade method for a vehicle-mounted single-zone MCU provided by the present invention, as shown below. Figure 1 As shown, the method includes steps 110-140.

[0033] Step 110: In response to the upgrade command, the main program area receives the new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state.

[0034] Specifically, the host computer (such as an OTA server) sends upgrade commands via the CAN / LIN bus. The upgrade command may include the new program size, CRC32, and ASIL level identification information. To adapt to the characteristics of the vehicle bus and avoid timeouts or errors caused by excessively large single data transmissions, the host computer cuts the complete new firmware file into multiple smaller data blocks, which are then sent sequentially to the vehicle MCU via the CAN / LIN bus.

[0035] The main program area writes the received data blocks into a dedicated, separate storage area in Flash memory for this upgrade—the temporary upgrade area—rather than directly overwriting the currently running program. Through the MCU's memory protection unit, the area storing and running the currently active vehicle application is set to read-only, prohibiting writing or erasure. This ensures that the new firmware writing process will not disrupt the currently stable vehicle control system.

[0036] In some embodiments, before the main program receives new firmware data in a partition block and writes it to the temporary upgrade area, the method further includes: Detect the current vehicle status; if the module to be upgraded is a safety-related module, the upgrade will be triggered when the vehicle is in the park position; if it is a non-safety-related module, the upgrade can be triggered while the vehicle is in motion.

[0037] Specifically, in order to fundamentally ensure driving safety and improve the reliability of upgrades, and to prevent serious accidents caused by system function interruption or loss of control due to the upgrade of key safety modules during vehicle operation, this embodiment binds the upgrade trigger conditions to the vehicle status (whether the vehicle is parked) and the module safety level, ensuring that any upgrade operation will not affect the vehicle's active safety functions.

[0038] The microcontroller acquires real-time vehicle operating parameters via an in-vehicle network (such as a CAN bus) to determine whether the electronic control unit module to be upgraded is a safety-related module and whether the vehicle's gear lever is in P (Park). Safety-related modules refer to control units whose malfunction could directly lead to vehicle safety risks, such as the body control module, whose functions, such as lights and door locks, are crucial. Conversely, non-safety-related modules refer to units whose malfunction will not immediately cause safety problems, such as the infotainment system. Triggering an upgrade while the vehicle is in Park is a mandatory safety condition, requiring the vehicle to be stationary and power off before a high-risk upgrade can be performed.

[0039] The specific implementation relies on network communication and status monitoring between the MCU and other vehicle systems. During the system design phase, a lookup table defining the security levels of each module can be pre-stored in the MCU's firmware or configuration area. For example, the BCM ID can be marked as "safety-related," and the infotainment system ID as "non-safety-related." When the MCU's upgrade management program receives an upgrade command, it first parses the command, identifies the target module, and queries the pre-stored list to determine its security level. If the target module is a safety-related module, the program enters a waiting loop, continuously listening for gear status messages from the transmission controller on the CAN bus until it parses a signal indicating the current gear is "P" (Park). Only then will it continue with the subsequent upgrade process. If the target module is a non-safety-related module, the upgrade management program will continue immediately without waiting. By forcing the safety module to upgrade in a stationary, stable P-gear state, upgrade failures caused by dynamic operational interference such as vehicle vibration and voltage fluctuations are effectively avoided.

[0040] In other embodiments, step 110, in which the main program divides the block to receive new firmware data and writes it to the temporary upgrade area, includes: Step 111: The host computer sends the new firmware data in blocks via CAN bus or LIN bus; Step 112: After receiving each data block, the main program area verifies its local CRC32 and bus communication check code. Step 113: If the verification passes, the data block is written to the temporary upgrade area; if the verification fails, the host computer is requested to retransmit the data block.

[0041] Specifically, in order to solve the problem of reliable and efficient transmission and writing of large-scale firmware data in complex vehicle network environments, this embodiment effectively combats the inherent communication delays, data packet loss and electromagnetic interference of the vehicle bus through a mechanism of block transmission, block-by-block verification and abnormal retransmission, ensuring that every data block sent from the host computer to the vehicle MCU is accurate and error-free, thereby laying a solid foundation for the subsequent construction of a complete and usable new firmware image.

[0042] In this process, sending new firmware data in chunks involves dividing the complete new firmware binary file into multiple smaller data packets according to a preset size (e.g., 512 bytes). The host computer then sends these data packets sequentially to the vehicle's MCU via the CAN or LIN bus. By breaking down a large-scale data transmission task into multiple smaller transmissions, this approach adapts to the limited bandwidth of the vehicle's bus and avoids timeouts for single transmissions.

[0043] Local CRC32 is a cyclic redundancy check code calculated for the content of a single data block, used to verify whether bit errors have occurred during the transmission of that data block. Bus communication checksums are check sequences automatically generated by the CAN or LIN bus protocol layer for each data frame, used to ensure the integrity of the data frame during physical transmission. Dual checksums ensure comprehensive verification of the correctness of the content received from the data frame.

[0044] Requesting a retransmission of a data block is an error control mechanism. When the MCU detects an error in the currently received data block through verification, it immediately sends a retransmission request to the host computer via the bus. The request carries the sequence number of the erroneous block, and the host computer retransmits the data block upon receiving the request.

[0045] The implementation of this process relies on the coordinated operation of the MCU's communication driver and firmware upgrade logic. First, the host computer and the MCU need to pre-agree on the data block size and communication protocol. Once the upgrade process starts, the host computer begins sending data in sequential blocks. Each data packet contains a block number, a data payload, and a CRC32 value calculated based on that payload. After receiving a complete data frame, the MCU's communication interrupt service routine first verifies the bus communication checksum using hardware or the underlying driver. If successful, the data payload is stored in a temporary buffer. Subsequently, the application-level upgrade logic retrieves the data from the buffer and calculates its CRC32 value, comparing it with the CRC32 value embedded in the data packet. If both verifications (bus checksum and CRC32) pass, the upgrade logic calls the Flash driver function to write this data block to the physical address corresponding to its sequence number in the temporary upgrade area. If either verification fails, the MCU constructs a retransmission request frame containing the erroneous block number and sends it to the host computer via the bus, triggering the retransmission of that data block. This process repeats until all data blocks have been transmitted and written.

[0046] The method provided by this invention greatly improves the reliability of data transmission for upgrades in unreliable vehicle network environments. The dual verification and retransmission mechanism ensures that the data finally written to Flash is completely consistent with the source file, thus eliminating upgrade failures caused by data transmission errors from the source.

[0047] Step 120: After all the new firmware data is written to the temporary upgrade area, a full verification is performed. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification.

[0048] Specifically, full verification refers to calculating the checksum (such as SHA-256) of the new firmware image in the entire temporary upgrade area after all data blocks have been written, and comparing it with the standard value provided by the host computer. Full verification confirms that the entire new firmware data written to the temporary upgrade area is complete and error-free.

[0049] If the verification passes, the upgrade process proceeds to the boot verification stage. The dual-backup configuration area uses non-volatile media such as EEPROM to store two identical copies of configuration data (primary and backup). This area is used to store critical information such as upgrade status and program checksums. An upgrade status of "pending verification" is a status flag set in the dual-backup configuration area, indicating that the new firmware has been written and verified, awaiting the next step of boot verification. This step ensures that only 100% correct new firmware will enter the boot phase, avoiding the risk of system boot failure due to data errors.

[0050] In some embodiments, step 120, which involves performing a full verification after all the new firmware data has been written to the temporary upgrade area, specifically includes: After all the new firmware data is written to the temporary upgrade area, the full checksum of the complete new firmware in the temporary upgrade area is calculated and compared with the checksum pre-stored in the dual backup configuration area. At the same time, the functional safety identifier of the new firmware is verified. If the comparison is consistent and the safety identifier is verified, the verification is confirmed to be successful.

[0051] Specifically, this embodiment performs a final quality and security audit after the new firmware is written by setting dual verification conditions. The entire new firmware image transmitted from the host computer and written to the temporary upgrade area is not only data-complete and error-free, but also functionally safe, compliant, and suitable for the current automotive environment.

[0052] A firmware functional safety identifier is a type of metadata or specific tag embedded in the new firmware code that declares the functional safety level (such as ISO 26262 ASIL-B) that the firmware conforms to. Verifying this identifier is a crucial step in ensuring that the new firmware meets vehicle safety requirements.

[0053] After all data blocks are written to the temporary upgrade area, the upgrade management program in the main program area initiates a verification task. This task first traverses the entire address space of the temporary upgrade area, reads all data, and inputs it into the verification algorithm, such as calling a software library to calculate the SHA-256 hash value to obtain the calculated full verification value. Subsequently, the program reads the pre-stored verification value from the primary backup in the dual-backup configuration area and performs a numerical comparison. Simultaneously, the program also parses the functional safety identifier from the fixed header or specific metadata segments of the new firmware image and checks whether it conforms to system requirements. For example, whether the identifier value is the expected ASIL-B code. Only after both the verification value comparison and identifier verification are successful will the system update the status of the dual-backup configuration area to "pending verification."

[0054] This invention incorporates functional safety requirements into the upgrade process, confirming the security compliance of the firmware before startup, thus eliminating the risk of unsafe code execution from the source.

[0055] In some embodiments, if the verification passes in step 120, the upgrade status in the dual backup configuration area is updated to pending verification, specifically including: If the verification passes, update the upgrade status in the dual backup configuration area to pending verification in the atomic order of first erasing the secondary backup, writing to the secondary backup and verifying, then erasing the primary backup, writing to the primary backup and verifying.

[0056] Specifically, the purpose of this embodiment is to provide the highest level of data integrity and reliability when updating critical system configurations to cope with extreme situations such as sudden power outages in a vehicle environment. It ensures that during the update of the dual backup configuration areas, even in the event of an unexpected power outage, the system retains at least one valid and complete copy of the configuration data, thereby preventing the system from failing to start correctly due to corrupted or lost configuration information.

[0057] In this context, atomic order refers to treating the update process of "secondary backup first, then primary backup" as a single transaction. The "update primary backup" operation only begins after the "write to and verify secondary backup" is successfully completed. If a power outage occurs during this process, such as when updating the primary backup, the system can still read the correct pending verification status from the successfully updated and verified secondary backup after restarting, thus continuing the process.

[0058] Once the main program area confirms that the new firmware has passed full verification, the upgrade logic initiates a configuration update task. This task first erases the secondary backup sector in the dual backup configuration area, and then writes the complete configuration data packet containing the new state to that secondary backup sector. After writing is complete, the data just written is immediately read for verification to confirm that the write is error-free. Only after the secondary backup is updated and verified successfully will the system update the primary backup sector using the exact same steps: erase-write-verify. This process ensures that a valid backup is available in the event of any single point of failure.

[0059] The method provided in this invention achieves the highest level of fault tolerance for configuration data updates. Through atomic operation sequence and strict verification, it ensures that even in the most unfavorable sudden power outage, the system configuration information will not be lost or in a contradictory state, thereby fundamentally preventing the risk of system bricking due to configuration data corruption.

[0060] Step 130: Trigger system reset, and the bootloader in the solidified boot sector will execute the new firmware in the temporary upgrade sector based on the pending verification status in the dual backup configuration sector.

[0061] Specifically, after the upgrade status in the dual-backup configuration area is "Pending Verification," a system reset is triggered. A system reset means triggering an MCU restart, transferring program execution control from the main program area to the firmware boot area. The bootloader in the firmware boot area is a piece of low-level startup code stored in a protected area and cannot be tampered with. It is the first piece of code that runs after the MCU powers on and is responsible for the initial system boot. Booting the new firmware in the temporary upgrade area means that the bootloader, according to the instructions in the dual-backup configuration area, skips the regular boot process and directly jumps to the starting address of the temporary upgrade area to run the new firmware. The purpose of this step is to attempt to boot the new firmware in a controlled environment, verifying whether the new firmware can initialize and run normally, thereby achieving a safe switch between the old and new systems.

[0062] In some embodiments, step 130 specifically includes: The bootloader in the solidified boot sector first reads the primary backup data from the dual backup configuration area. If the primary backup verification fails, it reads the secondary backup. If both backups fail verification, it jumps to the hard-coded fallback execution address of the main program area. After confirming the valid configuration, the system will jump to the temporary upgrade area based on the upgrade status to load and execute the new firmware.

[0063] Specifically, the purpose of this embodiment is to construct a highly reliable system boot chain with multi-layered fault tolerance. This ensures that the onboard MCU can find a definite and valid program to execute under any abnormal circumstances (such as corrupted configuration data or upgrade failure), thereby fundamentally eliminating the risk of system bricking and providing a controlled execution environment for safe attempts to boot new firmware.

[0064] The primary and secondary backups in the dual-backup configuration area are two identical copies of configuration data redundantly stored in non-volatile memory. The primary backup is the default data source, and the secondary backup is the backup data source used when the primary backup fails.

[0065] Verification failure means that after the bootloader reads the configuration data, it detects errors or corruption in the data using algorithms such as parity check or cyclic redundancy check, making the data unreliable. When all backup configurations fail, the bootloader no longer relies on any external configuration data but directly executes a pre-written (hard-coded) instruction—jumping to a preset starting address in the main program area. This ensures that even if the entire configuration system crashes, a known and usable basic program can be started to maintain essential functionality.

[0066] After the system powers on or resets, the bootloader first initializes the basic hardware, then attempts to read configuration data from the primary backup address in the dual-backup configuration area. Upon completion of the read, it immediately calculates the checksum of the data and compares it with the stored checksum. If they match, the primary backup is deemed valid, and the program continues execution. If the primary backup verification fails, the bootloader automatically switches to the secondary backup address and repeats the same read and verification process. Only when both backups fail verification will the system trigger the final hard-coded fallback mechanism: ignoring all configuration data, it directly executes a jump instruction, jumping to the predefined entry address of the main program area.

[0067] If any backup verification is successful, the bootloader will parse the upgrade status field. If the status is pending verification, it will jump to the starting address of the temporary upgrade area to attempt to start the new firmware; if the status is other (normal / rollback), it will jump to the starting address of the main program area to ensure that the system rolls back to a stable version.

[0068] This invention establishes a multi-level redundant boot fault-tolerance system. Through a three-layer progressive fault-tolerance mechanism of primary backup, secondary backup, and hard-coded fallback, it ensures that the system can find a safe boot path in the event of any single or even double point of failure, achieving true "never bricking". Secondly, the boot decision-making power is entrusted to a highly reliable bootloader, which is immune to software failures due to its immutable nature, providing the final secure arbitration for the entire upgrade process.

[0069] Based on the above embodiments, the method further includes: The solidified guide area monitors the vehicle power supply voltage and MCU core temperature before startup verification; When the power supply voltage exceeds the preset voltage threshold or the core temperature exceeds the preset temperature threshold, the startup process is delayed until the environmental parameters return to normal.

[0070] Specifically, this embodiment actively monitors two key environmental parameters: vehicle power supply voltage and MCU chip junction temperature. When these parameters exceed safe ranges, the startup process is automatically delayed. This prevents system startup failure, program malfunction, or even hardware damage caused by harsh external environments such as voltage drops or chip overheating. It ensures that the upgraded firmware or the rolled-back firmware can be initialized and run stably under ideal conditions.

[0071] The vehicle power supply voltage refers to the voltage of the vehicle's power network that supplies power to the MCU. It is usually labeled as 12V, but it will fluctuate during actual vehicle operation due to start-stop, sudden load changes, etc. The preset voltage threshold can be a lower limit of 9V and an upper limit of 16V, which correspond to the safety boundaries to avoid the inability to drive normally due to low voltage and to avoid damage to the device due to high voltage, respectively.

[0072] MCU core temperature refers to the temperature of the silicon wafer inside the MCU chip. The preset temperature threshold can be, for example, a lower limit of -40℃ and an upper limit of 125℃, which defines the automotive-grade industrial temperature range that ensures the normal operation of the MCU.

[0073] Delaying the startup process is a proactive safety waiting strategy. When environmental parameters are abnormal, the bootloader will not immediately perform risky startup operations, but will pause in the current monitoring loop and continue to sample environmental parameters until the voltage and temperature return to within a preset safety window before continuing to execute subsequent startup steps.

[0074] In practice, after the system powers on and resets, the bootloader first initializes the MCU's internal analog-to-digital converter and temperature sensor. It then enters a loop: sampling the power supply pin voltage via the ADC and reading the core temperature using the built-in sensor. The bootloader compares the real-time voltage and temperature values ​​with preset safety thresholds, such as voltage: 9V-16V; temperature: -40℃~125℃. If either parameter (e.g., voltage below 9V or temperature above 125℃) exceeds the threshold, the bootloader will not execute subsequent critical startup logic such as configuration reading and verification procedures. Instead, it will perform a short delay (e.g., 10 milliseconds) before sampling and comparing again, i.e., delayed startup. This loop continues until both voltage and temperature are detected to be within safe ranges. Only then will the bootloader exit the loop and continue with subsequent processes, ensuring the system only starts under safe conditions.

[0075] The method provided in this invention significantly improves the startup success rate and reliability of the system in harsh vehicle environments. By employing a proactive defense strategy of detecting the environment before starting, it effectively avoids unpredictable failures caused by forced startup under adverse conditions such as unstable voltage or chip overheating, thus ensuring that the system can start successfully on the first attempt after upgrades or rollbacks. Furthermore, it protects the hardware, preventing the MCU from operating at excessive voltage or temperature, thereby extending the lifespan and long-term reliability of the electronic control unit and providing a deeper level of safety for the entire vehicle.

[0076] Step 140: If no indicator signal indicating successful initialization of the new firmware is received within the preset time period, the upgrade status in the dual backup configuration area is updated to rollback, and the original firmware in the main program area is executed to complete the automatic rollback.

[0077] Here, the preset duration is a set time window, such as 5 seconds or 8 seconds. This preset duration is the maximum time the program waits for the new firmware to prove its health. The identifier signal indicating successful initialization of the new firmware refers to a pre-defined value (such as 0x5A5A) that must be written to a specific address in RAM immediately after successful initialization, as a heartbeat signal to report to the bootloader.

[0078] In practice, after jumping to the new firmware, the bootloader starts a hardware timer (e.g., every 5 seconds). It periodically checks if the value at a specific address in RAM equals 0x5A5A. If a signal is read before the timer expires, the bootloader considers the new firmware to have booted successfully, updates the dual-backup configuration area status to "normal," and the upgrade is complete. If no signal is read before the timer expires, the bootloader determines the new firmware boot failed, immediately updates the dual-backup configuration area status to "rollback," and then triggers a second system reset. After the second reset, the bootloader restarts, reads the dual-backup configuration area status as "rollback," and jumps back to the original firmware in the main program area to complete the rollback.

[0079] In this step, when the new firmware fails to boot normally, the system can automatically and quickly revert to a known stable version. This achieves fully automated fault recovery, completely eliminating the risk of the system becoming "bricked" due to defects in the new firmware, without any manual intervention.

[0080] The handling of failure scenarios during the upgrade process can include the following situations: 1. The failure phase is currently in the temporary upgrade area writing stage. Possible causes of vehicle-side failures include: voltage fluctuations during driving (start-stop system operation) and CAN bus interference. The handling mechanisms include: locking the main program area and ensuring it remains unchanged; after restarting, the bootloader in the boot sector is solidified to guide the main program area to normal operation; and the reason for the upgrade interruption is communicated to the OTA Master via the CAN bus.

[0081] 2. During the failure phase, the system is updating the dual backup configuration area. Possible causes of vehicle-side failures include: sudden power outages, such as a depleted battery. The handling mechanism includes: dual backups + parity checking to ensure at least one backup is valid; the bootloader reads the valid backup bootloader area to ensure basic functions such as vehicle control.

[0082] 3. The failure phase occurs during the new program startup phase. Possible causes include: failure to initialize onboard peripherals (e.g., sensor communication anomalies) or program incompatibility. The handling mechanism includes: if no confirmation flag is detected, automatic rollback within 10 seconds; after the main program area starts, the fault code is uploaded via the CAN bus, requiring no manual intervention.

[0083] 4. The failure stage is due to damage to the dual backup configuration area. Possible causes include: Flash sector aging caused by the high temperature environment of the vehicle. The handling mechanism includes: the bootloader hard-coding a jump to the main program area's starting address to ensure basic functions such as vehicle body control, while simultaneously triggering a CAN bus fault alarm.

[0084] The following describes the security anti-brick upgrade system for a vehicle-mounted single-zone MCU provided by the present invention. The security anti-brick upgrade system for a vehicle-mounted single-zone MCU described below can be referred to in correspondence with the security anti-brick upgrade method for a vehicle-mounted single-zone MCU described above.

[0085] Based on the above embodiments, Figure 2 This is a schematic diagram of the structure of the vehicle-mounted single-zone MCU security anti-brick upgrade system provided by the present invention, as shown below. Figure 2 As shown, the system includes: The data writing unit 210 is used to receive new firmware data in blocks and write it to the temporary upgrade area in response to the upgrade command, while keeping itself in a read-only locked state during the upgrade process. The verification and update unit 220 is used to perform a full verification of the complete new firmware in the temporary upgrade area after all the new firmware data has been written. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification. The verification boot unit 230 is used to read the upgrade status in the dual backup configuration area after the system is reset, and if the status is pending verification, it will guide the execution of the new firmware in the temporary upgrade area. The rollback unit 240 is used to update the upgrade status in the dual backup configuration area to rollback if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, and to guide the execution of the original firmware in the main program area to complete the automatic rollback.

[0086] Figure 3 An example is a schematic diagram of the physical structure of an on-board controller, such as... Figure 3 As shown, the controller may include a processor 310, a communications interface 320, a memory 330, and a communications bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other through the communications bus 340. The processor 310 can call logic instructions in the memory 330 to execute a secure anti-brick upgrade method for an on-board single-zone MCU. This method includes: in response to an upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state; after all the new firmware data is written to the temporary upgrade area, a full verification is performed; if the verification passes, the upgrade status in the dual-backup configuration area is updated to pending verification; a system reset is triggered, and the bootloader in the solidified boot area guides the execution of the new firmware in the temporary upgrade area according to the pending verification status in the dual-backup configuration area; if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, the upgrade status in the dual-backup configuration area is updated to rollback, and the original firmware in the main program area is guided to execute, completing the automatic rollback.

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

[0088] 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 secure anti-brick upgrade method for a vehicle-mounted single-zone MCU provided by the above methods. The method includes: in response to an upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state; after all the new firmware data is written to the temporary upgrade area, a full verification is performed. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification; a system reset is triggered, and the boot program in the solidified boot area guides the execution of the new firmware in the temporary upgrade area according to the pending verification status in the dual backup configuration area; if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, the upgrade status in the dual backup configuration area is updated to rollback, and the original firmware in the main program area is guided to execute, completing the automatic rollback.

[0089] 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 secure anti-bricking upgrade method for an in-vehicle single-zone MCU provided by the above methods. The method includes: in response to an upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state; after all the new firmware data is written to the temporary upgrade area, a full verification is performed; if the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification; a system reset is triggered, and the boot program in the solidified boot area guides the execution of the new firmware in the temporary upgrade area according to the pending verification status in the dual backup configuration area; if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, the upgrade status in the dual backup configuration area is updated to rollback, and the original firmware in the main program area is guided to execute, completing the automatic rollback.

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

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

[0092] 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 secure anti-brick upgrade method for a vehicle-mounted single-zone MCU, characterized in that, The MCU's unique physical Flash memory is divided into four functional areas via software logic: a boot sector, a main program sector, a temporary upgrade sector, and a dual backup configuration sector. The method includes: In response to the upgrade command, the main program area receives new firmware data in blocks and writes it to the temporary upgrade area, while the main program area remains in a read-only locked state. After all the new firmware data is written to the temporary upgrade area, a full verification is performed. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification. The system is triggered to reset, and the boot program in the solidified boot area guides the execution of the new firmware in the temporary upgrade area according to the unverified status in the dual backup configuration area. If no identifier signal indicating successful initialization of the new firmware is received within the preset time period, the upgrade status in the dual backup configuration area is updated to rollback, and the original firmware in the main program area is executed to complete the automatic rollback.

2. The method for secure anti-brick upgrade of an on-board single-zone MCU according to claim 1, characterized in that, The solidified boot sector is used to store unmodifiable boot code; The main program area is used to store and execute the currently active in-vehicle application, and is locked in a read-only state during the upgrade process and protected by error check code ECC. The temporary upgrade area is used to temporarily store new firmware data to be verified. It is only allowed to be written to during the upgrade phase, and a full sector erase is performed before writing. The dual backup configuration area adopts a power-off retention non-volatile storage structure, redundantly storing two copies of configuration data. Each copy of configuration data includes the program entry address, the full verification value of the new firmware, the upgrade status, the vehicle power status, and the parity check code.

3. The method for secure anti-brick upgrade of an on-board single-zone MCU according to claim 2, characterized in that, The bootloader in the solidified boot area, based on the unverified status in the dual backup configuration area, guides the execution of the new firmware in the temporary upgrade area, including: The boot program in the solidified boot area first reads the primary backup data from the dual backup configuration area. If the primary backup verification fails, it reads the secondary backup. If both backups fail verification, it jumps to the hard-coded fallback execution address of the main program area. After confirming the valid configuration, the system will jump to the temporary upgrade area based on the upgrade status to load and execute the new firmware.

4. The method for secure anti-brick upgrade of an on-board single-zone MCU according to claim 3, characterized in that, The method further includes: The solidified guide area monitors the vehicle power supply voltage and MCU core temperature before startup verification; When the power supply voltage exceeds the preset voltage threshold or the core temperature exceeds the preset temperature threshold, the startup process is delayed until the environmental parameters return to normal.

5. The method for preventing bricking and upgrading an on-board single-zone MCU according to claim 1, characterized in that, The full verification performed after all the new firmware data is written to the temporary upgrade area includes: After all the new firmware data is written to the temporary upgrade area, the full check value of the complete new firmware in the temporary upgrade area is calculated and compared with the check value pre-stored in the dual backup configuration area, and the functional safety identifier of the new firmware is verified at the same time. After the comparison is consistent and the security mark verification is passed, the verification is confirmed to be successful.

6. The method for secure anti-brick upgrade of an on-board single-zone MCU according to claim 5, characterized in that, If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification, including: If the verification passes, update the upgrade status in the dual backup configuration area to pending verification in the atomic order of first erasing the secondary backup, writing to the secondary backup and verifying, then erasing the primary backup, writing to the primary backup and verifying.

7. The method for secure anti-brick upgrade of an on-board single-zone MCU according to any one of claims 1 to 6, characterized in that, Before the main program divides the block to receive new firmware data and writes it to the temporary upgrade area, the method further includes: Detect the current vehicle status; If the module to be upgraded is a safety-related module, the upgrade will be triggered when the vehicle is in the park position; if it is a non-safety-related module, the upgrade can be triggered while the vehicle is in motion.

8. The method for secure anti-brick upgrade of an on-board single-zone MCU according to any one of claims 1 to 6, characterized in that, The main program divides into blocks to receive new firmware data and write it to the temporary upgrade area, including: The host computer sends new firmware data in blocks via CAN bus or LIN bus; After receiving each data block, the main program area verifies its local CRC32 and bus communication check code. If the verification passes, the data block is written to the temporary upgrade area; if the verification fails, the host computer is requested to retransmit the data block.

9. A security anti-brick upgrade system for a vehicle-mounted single-zone MCU, characterized in that, The MCU's unique physical Flash memory is divided into four functional areas via software logic: a boot sector, a main program sector, a temporary upgrade sector, and a dual backup configuration sector; the system includes: The data writing unit is used to receive new firmware data in blocks and write it to the temporary upgrade area in response to the upgrade command, while keeping itself in a read-only locked state during the upgrade process. The verification and update unit is used to perform a full verification of the complete new firmware in the temporary upgrade area after all the new firmware data has been written. If the verification passes, the upgrade status in the dual backup configuration area is updated to pending verification. The verification boot unit is used to read the upgrade status in the dual backup configuration area after the system is reset. If the status is pending verification, it will guide the execution of the new firmware in the temporary upgrade area. The rollback unit is used to update the upgrade status in the dual backup configuration area to rollback if no identifier signal indicating successful initialization of the new firmware is received within a preset time period, and to guide the execution of the original firmware in the main program area to complete the automatic rollback.

10. 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 secure anti-brick upgrade method for an in-vehicle single-zone MCU as described in any one of claims 1 to 8.

Images