Bootloader and APP upgrading method based on flash memory partition

Abstract

The invention discloses a Bootloader and an APP (Application) upgrading method based on a flash memory partition. According to the method, a flash memory in an MCU is logically partitioned into a Bootloader region, an APP A region, an APP B region and a corresponding flag bit A region / B, and an A / B redundant backup mechanism is constructed. When the system is initialized, the Bootloader judges the activation and validity states of the A / B area of the APP through the zone bit area and determines a starting path. In the upgrading process, upgrading data are received by means of communication modes such as CAN, a new program is temporarily stored in an inactive area, and data integrity and legality are ensured through multiple layers of verification such as Hash verification, CRC verification and digital signature verification; and switching the active area after the verification is passed, and automatically rolling back to the original active area when the upgrading fails, thereby ensuring that the system is continuously available. The method is suitable for upgrading various automobile electronic control units.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control, specifically a bootloader and APP upgrade method based on flash memory partitioning. Background Technology

[0002] The software system of the automotive electronic control unit (ECU) is the core of intelligent vehicle control, and mainly consists of the bootloader, application layer software (APP), etc.

[0003] (1) The bootloader is responsible for loading and updating the firmware when the ECU starts up, which is the basis for system initialization and software upgrade.

[0004] (2) The APP achieves complex control logic such as driving condition management and functional scenario optimization through the collaboration of multiple software components.

[0005] With the rapid development of automotive electronics technology, software functions are becoming increasingly complex. To meet the needs of performance optimization, defect repair, and security vulnerability patching, the frequency of ECU software upgrades has significantly increased. However, existing technologies for upgrading the bootloader or app of ECUs such as motor controllers have the following problems:

[0006] (1) Once a design flaw or security vulnerability is discovered, it is usually necessary to disassemble the motor controller and rewrite the MCU's Flash memory using an external programmer. This method is not only cumbersome and inefficient, but it also leads to a longer vehicle maintenance cycle, seriously affecting the vehicle's availability and making it difficult to meet the modern automobile's demand for efficient and convenient software updates.

[0007] (2) At the same time, traditional upgrade methods are highly dependent on hardware equipment and manual operation, which increases maintenance costs and operational risks. The drawbacks are even more prominent in the scenario of software updates for a large number of vehicles.

[0008] Therefore, a technical solution is needed that allows for efficient and secure upgrades of the Bootloader and App through software without disassembling the device or using an external programmer. Summary of the Invention

[0009] To address the aforementioned shortcomings of existing technologies, this invention employs a single AB partitioning of flash memory to upgrade the Bootloader and App, proposing a method for upgrading the Bootloader and App based on flash memory partitioning, comprising the following steps:

[0010] S1: Divide the internal flash memory of the MCU into logical partitions, including a Bootloader area, an APP A area, and an APP B area; the APP A area and the APP B area are divided into an active APP area and an inactive APP area according to their activation status.

[0011] S2: After system startup, hardware initialization is performed, partition status is read, and boot path is determined;

[0012] S3: Upgrade the bootloader using the logical partition; step S3 includes:

[0013] S31: Receives Bootloader upgrade instructions sent by the vehicle terminal via the bus;

[0014] S32: Select the currently inactive APP area as the temporary storage area for the new Bootloader;

[0015] S33: The vehicle terminal transmits the new Bootloader program in segments, and the receiving end receives the segments after verification.

[0016] S34: After all fragments have been received, the first integrity check is performed on the new Bootloader program in the temporary storage area;

[0017] S35: The activation states of APP A area and APP B area are swapped, triggering MCU reset;

[0018] S36: Write the new Bootloader from the temporary storage area to the Bootloader area;

[0019] S37: Perform a second integrity check on the new Bootloader in the Bootloader area, swap the activation states again, and restore the temporary storage area to the inactive APP area;

[0020] S38: Triggers the MCU to reset again, start from the Bootloader area, and complete the Bootloader upgrade.

[0021] Preferably, it also includes an APP upgrade process, which includes:

[0022] S41: Receive APP upgrade request sent by the vehicle terminal;

[0023] S42: The currently inactive APP area is used as the target storage area;

[0024] S43: Download and verify the new app, and save it to the target storage area;

[0025] S44: The activation states of APP A and APP B are swapped, triggering an MCU reset;

[0026] S45: The bootloader detects that the new APP is "valid and activated", jumps to the starting address of the new activated APP area, and the new APP starts.

[0027] Preferably, the logical partition further includes a flag area, which includes flag A and flag B; flag A includes an activation flag, validity flag, upgrade progress, error code, and reserved bytes indicating APP A area; flag B includes an activation flag, validity flag, upgrade progress, error code, and reserved bytes indicating APP B area; the activation status swapping can be performed using the following method:

[0028] (1) Write the original activation flag of flag A into the activation flag of flag B, and write the original activation flag of flag B into the original activation flag of flag A.

[0029] (2) Alternatively, increment the count value of the activation flag corresponding to the original activated APP area by one and write it into the activation flag corresponding to the original non-activated APP area. The activation flag with a larger count value indicates "activated", and the activation flag with a smaller count value indicates "non-activated".

[0030] Preferably, the hardware initialization includes:

[0031] (1) Communication interface initialization; the communication interface includes CAN controller, LIN controller, and UDS communication protocol stack;

[0032] (2) Initialize the storage controller, configure the erase / write timing, enable flash memory error detection, and lock the flag bit area;

[0033] (3) Basic module initialization; the basic module includes clock and power supply.

[0034] Preferably, the reading of the partition status includes:

[0035] (1) If the activation flag in flag A is “activated” and the validity flag is “valid”, and the activation flag in flag B is “inactive” or the validity flag is “invalid”: determine that APP A is an activated APP area and APP B is an inactive APP area;

[0036] (2) If the activation flag in flag area B is “activated” and the validity flag is “valid”, and the activation flag in flag area A is “inactive” or the validity flag is “invalid”: determine that APP area B is the activated APP area and APP area A is the inactive APP area;

[0037] (3) If the activation flags of flag A and flag B are both "activated" and the validity flags are both "valid", the APP A area will be set as the activated APP area by default, and the activation flag of flag B will be forcibly changed to "inactive".

[0038] (4) If the activation flag in flag A is “inactive” or the validity flag is “invalid”, and the activation flag in flag B is “inactive” or the validity flag is “invalid”, then there is no available APP and the system remains in the Bootloader stage.

[0039] Preferably, the fragment verification includes receiving fragment data, verifying the CRC, and sending a "retransmission request" message if the CRC is incorrect; the integrity verification includes calling the encryption algorithm hardware acceleration module to perform a hash verification on the new Bootloader program in the temporary storage area, and setting the validity flag to "invalid" if the verification fails.

[0040] Preferably, S43 includes:

[0041] (1) Receive new APP in segments, calculate the CRC check value of the segment, request retransmission if there is an error, and write to the target storage area after the check passes;

[0042] (2) After receiving all data, calculate the CRC value of all received data in the target storage area to verify data integrity;

[0043] (3) Verify the digital signature. Use the preset public key to decrypt the signature, compare the decryption result with the hash value calculated based on the new APP, and verify the legality of the program.

[0044] Preferably, the system also includes an exception handling mechanism, which includes: communication interruption exception handling, verification failure exception handling, and power supply exception handling.

[0045] Preferably, the communication interruption exception handling includes:

[0046] (1) Interruption detection: Real-time monitoring of communication status. If no new fragment is received after the timer expires, it is determined as "communication interruption";

[0047] (2) Progress saving: Write the largest received fragment sequence number into the flag area, and set the "Upgrade Progress" field to "Upgrade Pause" at the same time;

[0048] (3) Interruption recovery: When the vehicle terminal resends the "continue upgrade" command, the Bootloader reads the progress information in the flag area and requests the vehicle terminal to send the "fragment after the interruption point", or passively waits for the vehicle terminal to retransmit the fragment that failed to upgrade.

[0049] Preferably, the power supply anomaly handling includes:

[0050] (1) Anomaly detection: If the power supply voltage is detected to be lower than the minimum operating voltage of the MCU during the upgrade process, the "Power Abnormality" interrupt is triggered, and the Bootloader enters the interrupt service function;

[0051] (2) Emergency handling: In the interrupt service function, the current "upgrade progress" is saved to the flag area first, and then all flash memory operations are turned off;

[0052] (3) Restart and recovery: After the power is restored, the MCU restarts, the Bootloader reads the "upgrade progress" flag in the flag area, triggers the breakpoint resume transmission or waits for the vehicle terminal to restart the upgrade process.

[0053] The present invention has the following beneficial effects:

[0054] (1) Simplify the upgrade process and reduce hardware dependence. The upgrade can be completed through the MCU’s internal flash memory and communication methods such as CAN and LIN without disassembling the motor controller or using an external programmer. This achieves the upgrade function at the pure software level and reduces the dependence on dedicated hardware equipment and manual operation.

[0055] (2) The partition design improves the flexibility and efficiency of upgrades. After partitioning the flash memory once, it can support independent upgrades of the bootloader and the APP, avoiding repeated partitioning operations and improving upgrade efficiency.

[0056] (3) Ensure upgrade security and system reliability. A multi-layered verification mechanism is employed during the upgrade process, including SHA-256 hash verification, CRC verification, and digital signature verification, to ensure program integrity and legitimacy and prevent system anomalies caused by malicious attacks or erroneous data. The redundant partition design allows for automatic rollback to the original active area in the event of an upgrade failure, ensuring the continued availability of the vehicle's ECU.

[0057] (4) By combining with TBOX (vehicle terminal) to realize wireless upgrade function, software updates can be completed without the vehicle coming to the store, which greatly shortens the maintenance cycle, improves user experience, and meets the needs of modern cars for efficient and convenient OTA upgrades. The solution is applicable to a variety of MCUs and can be flexibly adapted to different types of automotive electronic control units (ECUs).

[0058] The present invention provides a bootloader and APP upgrade method based on flash memory partitioning, which is characterized by simple operation, convenient use, and high reliability. Attached Figure Description

[0059] Figure 1 This is a diagram showing the flash storage space partitioning according to an embodiment of the present invention;

[0060] Figure 2This is a flowchart illustrating the bootloader upgrade process according to an embodiment of the present invention;

[0061] Figure 3 This is a diagram illustrating the bootloader upgrade message interaction in an embodiment of the present invention.

[0062] Figure 4 This is a flowchart illustrating the APP upgrade process according to an embodiment of the present invention.

[0063] Figure 5 This is the process for determining the active area in an embodiment of the present invention. Detailed Implementation

[0064] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0065] This embodiment targets MCUs (Microcontroller Units) in the C2000 series, such as the F280039. Through flash memory partitioning, A / B redundancy backup mechanisms, and multi-layer verification strategies, it achieves secure and efficient online upgrades of the bootloader program and the application. This MCU has a maximum Flash capacity of 384KB and supports an AES encryption algorithm hardware acceleration module. This embodiment supports automotive-grade communication protocols such as CAN2.0B and LIN 2.0, eliminating the need to disassemble the motor controller or rely on an external programmer. It can be directly adapted to ECU scenarios such as new energy vehicle motor controllers and body controllers. Figure 1 The specific steps and detailed instructions are as follows:

[0066] S1: Flash Storage Partition Design. To achieve independent upgrades, redundant backups, and status management for the Bootloader and APP, the internal Flash memory of the MCU needs to be logically partitioned. The physical Flash address range is 0x00080000-0x000AFFFF, totaling 384KB, which is divided into multiple functional areas, such as... Figure 1 As shown, the function, characteristics, and configuration details of each partition are as follows:

[0067] (1) Bootloader area, address range: 0x00080000-0x00087FFF, capacity 64KB. Stores the currently running Bootloader program, responsible for receiving upgrade requests, verifying data, booting, and controlling the upgrade process. The address is fixed at the Flash running start address to ensure that the program is loaded from this area first after the MCU powers on. The capacity can be set according to the complexity of the Bootloader function, and must be able to meet the basic communication, verification, and boot logic, etc.

[0068] (2) APP A area, address range: 0x00088000-0x0009BF6F, capacity 159.7KB. Stores APP programs, supports switching between "active area" (currently running APP) and "inactive area" (APP to be upgraded / temporary storage Bootloader). The capacity matches the typical size of motor control APP, and can accommodate drive algorithms, operating condition management modules, etc.

[0069] (3) APP B area, address range: 0x0009C000-0x000AFF6F, capacity 159.7KB. Functionally identical to APP A area, serving as a redundant backup area to ensure the system can roll back to the original active area in case of upgrade failure. Capacity and address length are consistent with APP A area, forming A / B redundancy. The erase / write timing is uniformly configured with APP A area, and the Flash wait cycle is 5 CPU cycles.

[0070] (4) Flag area A, address range: 0x0009BF70-0x0009BFFF, capacity 288B. Independently stores the status information of APP area A to prevent accidental modification during program area erasure and rewriting. Contains several types of information: activation flag, validity flag (e.g., 0x01 = valid, 0x00 = invalid), upgrade progress (records received fragment sequence numbers), error code (records verification failure types), magic number, unused byte reservation, etc.

[0071] The activation flag can use 0x01 to represent "activated" and 0x00 to represent "inactive". Alternatively, it can use an incrementing method, adding one to the count of the activation flag in the original active area and writing it into the activation flag in the original inactive area. In this case, the flag with the larger count value represents the active area, and the other represents the inactive area. The activation flag can use a 32-bit counter to meet the incrementing requirements throughout its lifecycle without overflow. This design allows for switching of the active area through numerical comparison without modifying any of the original active area's flash memory data, making it more secure and reliable.

[0072] (5) Flag area B, address range: 0x000AFF70-0x000AFFFF, capacity 288B. It has the same allocation structure as flag area A, and stores the activation flag, validity flag and upgrade-related status information of APP area B. The address of the flag area is independent of the program area, and the erase / write permission is set to "Bootloader only" to prevent APP from accidentally modifying it.

[0073] S2: System Initialization and Status Detection. After the MCU powers on or resets, it first enters the Bootloader program. Since the Bootloader area is located at the starting address of Flash execution, it completes hardware peripheral initialization, partition status detection, and boot path determination, laying the foundation for subsequent upgrades or APP startup. The specific sub-steps are as follows:

[0074] S21: Hardware Initialization. The bootloader first initializes the MCU core peripherals, ensuring stable communication, storage, and power supply, and configuring parameters to meet automotive electronic operating requirements, including:

[0075] (1) Communication Interface. CAN Controller: Configured in CAN 2.0B mode, with a baud rate of 500kbps, which is the common rate for automotive ECUs. Enable the receive FIFO buffer and set the interrupt priority to the highest level to avoid data loss during upgrades. LIN Controller: Baud rate of 19.2kbps, adapted to the low-speed communication requirements of the vehicle body, and only used as a backup upgrade channel when there is no CAN communication. Communication Protocol Stack: Loads the UDS (Unified Diagnostic Services) protocol conforming to the ISO 14229-1 standard, supporting upgrade-related services such as 0x34 (request download), 0x36 (transfer data), and 0x37 (request to end transmission).

[0076] (2) Storage Controller. Initialize the Flash controller and configure the erase / write timing, such as waiting for 5 CPU cycles to match the 120MHz main frequency. Enable Flash error detection, such as ECC verification. Lock the flag area, allowing the Bootloader to write only after unlocking it through specific instructions, such as the Flash_WriteEnable function, to prevent the APP or abnormal programs from tampering with the state.

[0077] (3) Basic Module. The CPU clock can be configured to 120MHz, balancing computing performance and power consumption. The peripheral clocks (CAN, LIN) are obtained by dividing the system clock. The power management module (PMU) is enabled. When the supply voltage is lower than 3.0V (the minimum operating voltage of the MCU), an interrupt is triggered, pausing the upgrade process.

[0078] S22: Partition Status Read. The bootloader reads the status information of partitions A and B, including activation and validity flags, such as... Figure 5 As shown, the current state of APP A / B areas is determined by preset logic to avoid ambiguity.

[0079] (1) If the flag bit of APP A area is "valid (0x01) and activated (0x01)" and APP B area is "invalid (0x00) or inactive (0x00)": APP A area is determined to be the activated area and APP B area is the inactive area.

[0080] (2) If the flag bit of APP B area is "valid (0x01) and activated (0x01)" and APP A area is "invalid (0x00) or inactive (0x00)": APP B area is determined to be the activated area and APP A area is the inactive area.

[0081] (3) If both A and B areas are "valid and active" at the same time, this is an abnormal state, which may be due to the power failure causing the flag bit not to be updated. By default, APP A area is set as the active area, and at the same time, the activation flag of APP B area is forcibly rewritten to 0x00 (inactive), and the error code 0x01 (dual area activation abnormal) is written to the reserved byte of the flag bit in B area. After completion, it is synchronously written to Flash.

[0082] (4) If both A and B are "invalid or inactive", there is no usable APP, such as during the first power-on or when all APPs are damaged. Set the error code of A / B to 0x02 (no valid APP), and the system will remain in Bootloader mode.

[0083] S23: Boot path determination. Based on partition status and upgrade flags, determine the next system operation to ensure a closed-loop process:

[0084] (1) If the “upgrade progress” field of the flag A / B is not 0 (e.g., a specific byte is 0x02, which means “upgrading in progress”): it is determined that there is an incomplete upgrade task. If the upgrade is supported, it will directly enter the upgrade process S3 or S4. If it is not supported, it will enter the subsequent judgment.

[0085] (2) If there is a valid activated APP area (such as area A) and there are no unfinished upgrade tasks: Bootloader points to the starting address of the APP area through a function pointer, jumps to the APP program, and disables its own interrupt to avoid interfering with the operation of the APP.

[0086] (3) If there is no APP area that can be effectively activated: the Bootloader periodically sends a "waiting for upgrade" message through the CAN bus, or passively waits for the APP upgrade instruction.

[0087] S3: Bootloader Upgrade Process. When the bootloader program needs to be updated, such as fixing boot logic vulnerabilities or adding verification algorithms, the system relies on the redundant space in the APP A / B areas to achieve "secure self-update," avoiding system crashes caused by directly erasing or rewriting the bootloader area. Figure 2 , Figure 3 As shown, the steps are as follows:

[0088] S31: Receive upgrade request. The bootloader receives the bootloader upgrade command sent by TBOX (vehicle terminal) via the CAN bus. The command is based on UDS protocol services such as 0x34, 0x36, and 0x37. The data segment includes: new bootloader version number (2B), total size (4B, maximum not exceeding 96KB, matching the APP area capacity), SHA-256 checksum (32B), RSA2048 digital signature (256B), etc.

[0089] First, verify the RSA2048 signature: the public key is stored at a fixed address 0x00087F80-0x00087FFF in the Bootloader area. Decrypt the signature using the preset public key and compare the decryption result with the hash value of "version number + total size + SHA-256 value". If they do not match, a negative response is sent in the UDS dependency check routine. Second, check the version number: if the new Bootloader version number is less than or equal to the current version, the version number check fails, and a negative response is sent in the UDS dependency check routine.

[0090] S32: Determine the temporary storage area. Based on the partition status determination result of S22, select the currently inactive APP area as the temporary storage area for the new Bootloader. Example: If APP A is the active area, then APP B is selected as the temporary storage area.

[0091] Erasure preparation: Read the sector address of the temporary storage area (APP B area), such as the corresponding sector of APP B area is SEC00-SEC20, and disable all peripheral interrupts, including CAN receive interrupt, to prevent interruption during the erase and write process.

[0092] Sector Erasure: The Flash API function "Flash_EraseSector" is called to erase the data in the APP's B sector sector by sector. After erasing each sector, the sector data is read to confirm whether it is the default value of 0xFFFF after erasure. If erasure fails, the sector is marked as a "bad sector," and a reserved sector, such as sector 0x38, is attempted to be used as a replacement. After erasure is complete, the "Upgrade Progress" field in the B sector is set to 0x0000, representing "Data to be Received," and the data is synchronously written to Flash. When bad sector marking and sector reservation mechanisms are not supported, the entire sector needs to be erased.

[0093] S33: Segmented Download and Verification. TBOX transmits the new Bootloader program in "segments," each 2KB. The Bootloader receives and verifies each segment to ensure data integrity.

[0094] Fragmentation format: Each data fragment contains "fragmentation sequence number (or block sequence number), data segment (1020B), CRC16 check value (2B)" to avoid exceeding the APP area capacity.

[0095] Reception and Verification: The bootloader receives fragmented data via CAN, first performing a CRC16 check, comparing the calculated value of the received data with the checksum carried in the fragment. If the vehicle terminal does not receive a response for an extended period, it can determine that a transmission error has occurred and initiates a retransmission. If the maximum number of retransmissions is reached and the transmission still fails, the upgrade process terminates.

[0096] After verification, the fragment data is written to the corresponding address in the temporary storage area. At the same time, the "upgrade progress" field of the flag B area is updated to record the maximum fragment sequence number that has been received. Each received fragment is synchronously written to Flash to prevent the progress from being lost in the event of a power outage.

[0097] S34: Integrity check. After all fragments are received, i.e., the fragment sequence number reaches the calculated value of "total size / 1KB", the new Bootloader program in the temporary storage area (APP B area) is subjected to SHA-256 hash verification.

[0098] The MCU encryption algorithm hardware acceleration module is invoked to calculate the SHA-256 value of the data in the temporary storage area. The calculated result is compared with the total SHA-256 checksum sent by the TBOX. If the checksum passes, the activation area switching step (S35) is initiated. If the checksum fails, the "validity flag" in flag B is set to 0x00 (invalid), and the "error code" is set to 0x03 (SHA-256 checksum failure). An "upgrade failure" message (ID: 0x1805F101, data segment: 0x03) is sent via CAN to terminate the upgrade, while retaining the received data for subsequent troubleshooting. When using the UDS protocol, a response can also be used to address the vehicle terminal's checksum failure.

[0099] S35: Activation Area Switching and Reset. Activation State Switching: Update the "Activation Flag" in flag area B to 0x01 (activated) and the "Validity Flag" to 0x01 (valid). Simultaneously, set the "Activation Flag" of the original activation area (APP A area) to 0x00 (inactive). After the update is complete, write the data synchronously to Flash to ensure that the state is not lost after power failure. Activation state switching can also use the aforementioned numerical increment method.

[0100] Reset Preparation: Restore all peripheral interrupt enable, retain only the CAN interrupt, disable Flash erase / write permissions, and clear temporary data in the CPU registers. Trigger Reset: Trigger a software reset by writing to the MCU reset register (e.g., address 0x000001). During the reset process, the MCU automatically restarts and re-enters the Bootloader area.

[0101] S36: Bootloader area update. After reset, the Bootloader first checks the status of the flag area and finds that "APP B area is active and stores the new Bootloader". Then it runs the "firmware transfer program" pre-installed in APP B area. This program is bound to the new Bootloader and is used to write the new Bootloader into the Bootloader area.

[0102] Old firmware erasure: Call the "Flash_EraseSector" function to erase the entire Bootloader area. After erasure, confirm that all bytes are 0xFFFF. New firmware transfer: Batch copy the new Bootloader program from APP B area to the Bootloader area (0x00080000-0x00087FFF).

[0103] S37: Secondary verification and status recovery. Secondary verification: Perform SHA-256 verification again on the new program in the Bootloader area and compare it with the total verification value in S34 to ensure that there are no data errors during the transfer process.

[0104] When the verification is successful: Set the "Activation Flag" in area B of the APP to 0x00 (restore inactive status) and the "Upgrade Progress" to 0xFFFF (representing "Upgrade Complete"), maintaining the symmetrical state of areas A and B.

[0105] When verification fails: Keep the "activation flag" in area B of the APP at 0x01, set the "error code" in area B to 0x04 (firmware transfer failure), wait for the next reset and retry, with a retry interval of 100ms, and a maximum of 3 retries. If it still fails, send a "hardware abnormality" message (ID: 0x1805F102, data segment: 0x04) via CAN, indicating that manual intervention is required.

[0106] S38: Upgrade complete. Triggering the MCU to reset again, the Bootloader starts a new program from the Bootloader area after reset. After initialization, it checks the status of each partition to confirm no abnormalities. A "Upgrade successful" message (ID: 0x1805F103, data segment: new Bootloader version number) is sent via CAN. The TBOX receives this and replies with a "Confirmation successful" message (ID: 0x1805F200). The Bootloader upgrade process ends. Following the logic in S23, the system starts the application from the activated APP area (APP A area).

[0107] S4: App Upgrade Process. App upgrades leverage A / B area redundancy to directly replace the old app with the new one, without occupying Bootloader area space. Figure 4 As shown, the steps are as follows:

[0108] S41: Receive upgrade request. The APP program in the active area (example: APP A area) receives the APP upgrade request sent by TBOX via the CAN bus, such as UDS 0x34 service. The request includes the new APP version number (2B), total size (4B, maximum 96KB), CRC32 check value (4B), ECC digital signature (64B), etc.

[0109] APP Response: After the APP passes the reprogramming check and meets the conditions, it jumps to the Bootloader area by resetting the MCU. Bootloader Verification: Repeat the validity verification logic of S31 (signature, version number). After the verification is successful, a "Allow Upgrade" message (ID: 0x1805F107) is sent.

[0110] S42: Determine the target storage area. Based on the partition status in S22, select the currently inactive APP area as the target storage area. Example: If APP B is an inactive area, then the target area is APP B. Status check: Read the "activation flag" and "validity flag" of flag B again to confirm that they are "inactive (0x00) and invalid (0x00)" to avoid conflicts with other processes. Erase operation: Call the "Flash_EraseSector" function to erase APP B and the corresponding flag B sector by sector. After erasure, confirm that the data is 0xFFFF.

[0111] S43: Download and verify the new app. TBOX transmits the new app in "fragments," each 2KB, matching the 2KB sector size of the Flash memory. The bootloader receives and performs two layers of verification:

[0112] (1) Fragment reception and CRC32 verification. Each data fragment contains "fragment sequence number (2B), data segment (2044B), and CRC32 checksum (4B)". After receiving the data, the Bootloader first calculates the CRC32 value and compares it with the checksum carried in the fragment. If there is an error, it requests retransmission (up to 3 times). After the verification is successful, the fragment is written to the corresponding address in the target area (APP B area), and the "upgrade progress" field of the flag bit in B area is updated at the same time.

[0113] (2) Full verification after reception. First layer: Calculate the CRC32 value of all data in the target area and compare it with the total CRC32 value sent by TBOX to verify data integrity. Second layer: Verify ECC digital signature: Decrypt the signature using the preset public key and compare the decryption result with the hash value of "new APP version number + total size + CRC32 value" to verify the legality of the program. If both layers of verification pass, proceed to S44. If either verification fails, mark the target area as "invalid" and send a "verification failure" message (ID: 0x1805F104, data segment: 0x01 = CRC error / 0x02 = signature error).

[0114] S44: Update Flags and Reset. Flag Update: Set the "Activation Flag" of the target area (APP B area) to 0x01 (activated) and the "Validity Flag" to 0x01 (valid) in flag B area. Set the "Activation Flag" of the original activated area (APP A area) to 0x00 (inactive). The update is then synchronously written to Flash. Trigger MCU reset, the steps are the same as in S35, and the system restarts.

[0115] S45: Run the new app. After reset, the bootloader executes the logic of S22-S23, detects that app B area is "valid and active", and jumps to the starting address of app B area (0x020000). New app startup process:

[0116] (1) Initialize peripherals, including motor drive module, sensor interface, CAN communication, etc., read the running context in the reserved bytes of the flag bit area, and restore the control state before the upgrade, such as the current torque of the motor.

[0117] (2) Perform APP self-test, such as checking whether the sensor signal is normal, whether the drive circuit is short-circuited, etc., to confirm that there is no hardware abnormality.

[0118] (3) Send a “Running Normal” message via CAN (ID: 0x1805F200, data segment: new APP version number + running status code 0x00). The new APP runs normally, and the upgrade process ends.

[0119] S5: Exception Handling Mechanism. To address unexpected failures during the upgrade process, such as communication interruptions, verification failures, and power outages, and to ensure the system does not crash, the following targeted handling logic is designed:

[0120] S51: Communication interrupted. The procedure is as follows:

[0121] (1) Interruption detection: The Bootloader monitors the CAN communication status in real time. If no new fragment is received for 10 consecutive seconds, the timeout period can be configured through TBOX. At this time, it is determined as "communication interruption".

[0122] (2) Progress saving: Write the largest received fragment sequence number (read from the flag area) into the reserved bytes of the flag area (such as the 4th to 7th bytes of the flag area B), and set the "upgrade progress" field to 0x02 (representing "upgrade paused").

[0123] (3) Interruption recovery: When the TBOX resends the "Continue Upgrade" command (UDS 0x36 service), the Bootloader reads the progress information in the flag area and requests the TBOX to send the "fragment after the interruption point". If the sequence number 0x0010 has been received, the request is made to start the transmission from 0x0011 without having to re-receive the verified fragment.

[0124] S52: Verification failed. The following steps should be taken:

[0125] (1) Fragment verification failure: retain all states (activation flag, program data) of the original active area (such as APP A area), only mark the currently received fragment as "invalid", send a "fragment retransmission" request through CAN, and do not trigger rollback.

[0126] (2) Full verification failed: Set the "validity flag" of the target area (such as APP B area) to 0x00 (invalid), keep the "activation flag" at 0x00 (inactive), and automatically roll back to the activated area before the upgrade (APP A area).

[0127] (3) Rollback notification: After the rollback is completed, send an "upgrade rollback" message (ID: 0x1805F105, data segment: 0x00, representing "rollback to the original version") via CAN to inform TBOX of the current status, so that the upgrade can be re-initiated later.

[0128] S53: Power failure. Follow these steps:

[0129] (1) Anomaly detection: If the PMU module detects that the power supply voltage is lower than 3.0V during the upgrade process, it will immediately trigger the "power abnormality" interrupt and the Bootloader will enter the interrupt service function.

[0130] (2) Emergency handling: In the interrupt service function, use the Flash temporary write mode to save the "current upgrade progress" (segment number, erased and written sectors, etc.) to the flag area first, and then shut down all Flash operations to prevent sector damage caused by partial erase and write.

[0131] (3) Reboot and recovery: After power is restored, the MCU restarts and the Bootloader reads the "upgrade pause" flag (0x02) in the flag area and automatically triggers breakpoint resume (the steps are the same as S51). For "half-written data" caused by power failure (such as some bytes of a sector being 0xFFFF and some being valid data), the sector is erased and the corresponding fragment is received again after the "invalid" flag (0x00) in the target area and the sector data verification (after reading to confirm whether it is 0xFFFF) is used to identify the data.

[0132] This embodiment achieves secure and efficient online upgrades of the C2000 series MCU's bootloader and APP through layered design, redundant backup, and multiple verifications, balancing upgrade efficiency and system reliability. It is suitable for embedded scenarios with high security requirements, such as automotive electronics.

[0133] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A bootloader and APP upgrade method based on flash memory partitioning, characterized in that, Includes the following steps: S1: Divide the internal flash memory of the MCU into logical partitions, including a Bootloader area, an APP A area, and an APP B area; the APP A area and the APP B area are divided into an active APP area and an inactive APP area according to their activation status. S2: After system startup, hardware initialization is performed, partition status is read, and boot path is determined; S3: Upgrade the Bootloader using the logical partition; Step S3 includes: S31: Receives Bootloader upgrade instructions sent by the vehicle terminal via the bus; S32: Select the currently inactive APP area as the temporary storage area for the new Bootloader; S33: The vehicle terminal transmits the new Bootloader program in segments, and the receiving end receives the segments after verification. S34: After all fragments have been received, the first integrity check is performed on the new Bootloader program in the temporary storage area; S35: The activation states of APP A area and APP B area are swapped, triggering MCU reset; S36: Write the new Bootloader from the temporary storage area to the Bootloader area; S37: Perform a second integrity check on the new Bootloader in the Bootloader area, swap the activation states again, and restore the temporary storage area to the inactive APP area; S38: Triggers the MCU to reset again, start from the Bootloader area, and complete the Bootloader upgrade.

2. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 1, characterized in that, It also includes the APP upgrade process, which includes: S41: Receive APP upgrade request sent by the vehicle terminal; S42: The currently inactive APP area is used as the target storage area; S43: Download and verify the new app, and save it to the target storage area; S44: The activation states of APP A and APP B are swapped, triggering MCU reset; S45: The bootloader detects that the new APP is "valid and activated", jumps to the starting address of the new activated APP area, and the new APP starts.

3. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 2, characterized in that, The logical partition further includes a flag area, which comprises flag A and flag B. Flag A includes an activation flag, validity flag, upgrade progress, error code, and reserved bytes indicating APP A area. Flag B includes an activation flag, validity flag, upgrade progress, error code, and reserved bytes indicating APP B area. The activation status can be swapped using the following method: Write the original activation flag of flag A to the activation flag of flag B, and write the original activation flag of flag B to the original activation flag of flag A. Alternatively, increment the count value of the activation flag corresponding to the original activated APP area by one, and write it into the activation flag corresponding to the original inactive APP area. The activation flag with a larger count value indicates "activated", and the activation flag with a smaller count value indicates "inactive".

4. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 3, characterized in that, The hardware initialization includes: Communication interface initialization; the communication interface includes the CAN controller, LIN controller, and UDS communication protocol stack; The storage controller is initialized, the erase / write timing is configured, flash memory error detection is enabled, and the flag bit area is locked. Basic module initialization; the basic module includes a clock and a power supply.

5. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 3, characterized in that, The read partition status includes: If the activation flag in area A is "activated" and the validity flag is "valid", and the activation flag in area B is "inactive" or the validity flag is "invalid": then area A of the app is determined to be the activated app area, and area B of the app is the inactive app area; If the activation flag in flag B is "activated" and the validity flag is "valid", and the activation flag in flag A is "inactive" or the validity flag is "invalid": determine that APP B is the activated APP area and APP A is the inactive APP area; If both the activation flags in flag A and flag B are "activated" and the validity flags are both "valid", the default setting is to activate APP area A, while the activation flag in flag B is forcibly changed to "inactive". If the activation flag in flag A is "inactive" or the validity flag is "invalid", and the activation flag in flag B is "inactive" or the validity flag is "invalid", then there is no usable app and the system remains in the Bootloader stage.

6. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 3, characterized in that, The fragment verification includes receiving fragmented data, verifying the CRC, and sending a "retransmission request" message if the CRC is incorrect; the integrity verification includes calling the encryption algorithm hardware acceleration module to perform hash verification on the new Bootloader program in the temporary storage area, and setting the validity flag to "invalid" if the verification fails.

7. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 3, characterized in that, S43 includes: The system receives new applications in segments, calculates the CRC check value of each segment, requests retransmission if an error occurs, and writes the data to the target storage area after successful verification. After receiving all data, calculate the CRC value of all received data in the target storage area to verify data integrity. Verify the digital signature by decrypting it using a preset public key, comparing the decryption result with the hash value calculated based on the new app, and verifying the legitimacy of the program.

8. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 3, characterized in that, It also includes an exception handling mechanism, which includes: communication interruption exception handling, verification failure exception handling, and power supply exception handling.

9. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 8, characterized in that, The communication interruption exception handling includes: Interruption detection: Real-time monitoring of communication status; if no new fragment is received after the timer expires, it is determined as "communication interruption"; Progress saving: Write the largest received fragment sequence number to the flag area, and set the "Upgrade Progress" field to "Upgrade Paused"; Interruption recovery: When the vehicle terminal resends the "continue upgrade" command, the bootloader reads the progress information in the flag area and requests the vehicle terminal to send the "fragment after the interruption point", or passively waits for the vehicle terminal to retransmit the fragment of the upgrade failure.

10. The bootloader and APP upgrade method based on flash memory partitioning as described in claim 8, characterized in that, The power supply anomaly handling includes: Anomaly detection: If the power supply voltage is detected to be lower than the MCU's minimum operating voltage during the upgrade process, a "power failure" interrupt is triggered, and the Bootloader enters the interrupt service function; Emergency handling: In the interrupt service function, first save the current "upgrade progress" to the flag area, and then disable all flash memory operations; Reboot and Restore: After power is restored, the MCU restarts, the Bootloader reads the "upgrade progress" flag in the flag area, triggers breakpoint resume or waits for the vehicle terminal to restart the upgrade process.

Images