Dual-partition boot program, application program synchronization upgrade and abnormal rollback method, chip and storage medium

Abstract

The application discloses a dual-partition boot program and application program synchronous upgrading and abnormal rollback method, a chip and a storage medium. The method is applied to a target chip, the target chip comprises a flash memory, the flash memory comprises a first partition, a second partition and a state area independent of the first partition and the second partition; the method comprises the following steps: when a target upgrade package is received, an integral partition image is acquired, the integral partition image contains a boot program, application program header information and application program code; the integral partition image is written into a non-running partition, and a current running partition remains available; the integral partition image written into the non-running partition is subjected to validity verification, and only when the validity verification passes, a switching permission flag is written into the state area; after the switching permission flag is written, the partition switching is performed according to the switching permission flag, and the non-running partition is switched into the running partition. The application realizes synchronous upgrading of the boot program and the application program, controlled switching after verification and automatic rollback of startup abnormality.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, and in particular to a method for synchronous upgrading and rollback of dual-partition bootloaders and applications, as well as a chip and storage medium. Background Technology

[0002] In automotive electronics, body control, digital keys, NFC controllers, and other embedded products, a separate architecture for the bootloader and application program is commonly used. The bootloader is responsible for power-on initialization, upgrade reception, partition selection, integrity verification, and jump execution, while the application program is responsible for business logic, diagnostic communication, and upgrade triggering. Traditional upgrade schemes typically only upgrade the application program area, while the bootloader area remains unchanged after mass production. However, when the bootloader also needs to be updated due to changes in upgrade protocols, flash memory partition adjustments, boot verification strategy optimization, or improved anomaly recovery logic, if a single-partition overwrite upgrade or separate upgrade method is used, a power outage, reset, or image mismatch during the upgrade process may lead to damage to the bootloader or application program, preventing the device from booting normally.

[0003] The existing technology lacks a mechanism for writing a whole partition image containing bootloader, application header information and application code to a non-running partition, and for controlled switching after verification and automatic rollback in case of startup failure.

[0004] Therefore, how to write the bootloader and application as a whole partition image to a non-running partition, switch it in a controlled manner after the validity verification is passed, and roll back to the valid partition in the event of a startup error is a problem that urgently needs to be solved in this field.

[0005] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0006] This invention provides a method, chip, and storage medium for synchronous upgrading and rollback of dual-partition bootloader and application, aiming to solve the technical problems of low reliability and difficulty in recovery after anomalies in the synchronous upgrading of bootloader and application in the prior art.

[0007] A first aspect of the present invention provides a method for synchronous upgrading and rollback of a dual-partition bootloader and application, applied to a target chip, the target chip including flash memory, the flash memory including a first partition, a second partition, and a state area independent of the first and second partitions; both the first partition and the second partition include a bootloader area, an application header area, and an application code area; the state area is used to store partition status and switching control information; Upon receiving a target upgrade package, a full partition image is obtained, the full partition image containing a bootloader, application header information, and application code; the method includes: Write the entire partition image to a non-running partition, which is the currently non-running partition among the first partition and the second partition. The currently running partition remains available, which is the currently running partition among the first partition and the second partition. The validity of the whole partition image written to the non-running partition is verified, and the switching permission flag is written to the status area only if the validity verification passes. After the switch enable flag is written, when the target chip is reset, before the bootloader of the target chip jumps to the application, a partition switch is performed according to the switch enable flag to switch the non-running partition to a running partition.

[0008] A second aspect of the present invention provides a dual-partition bootloader and application synchronous upgrade and exception rollback chip, comprising flash memory and a processor; The flash memory includes a first partition, a second partition, and a status area independent of the first and second partitions; both the first and second partitions include a bootloader area, an application header area, and an application code area; the status area is used to store partition status and switching control information. The processor includes: The image acquisition module is used to acquire the entire partition image when the target upgrade package is received. The entire partition image contains the bootloader, application header information and application code. The image writing module is used to write the entire partition image to a non-running partition, which is the partition that is not currently running in the first partition and the second partition. The currently running partition remains available, and the currently running partition is the partition that is currently running in the first partition and the second partition. The verification module is used to verify the validity of the whole partition image written to the non-running partition. Only when the validity verification passes will the switch permission flag be written to the status area. The partition switching module is used to perform partition switching according to the switching enable flag after the switching enable flag is written, when the chip is reset, before the chip's boot program jumps to the application program, and switch the non-running partition to a running partition.

[0009] In a third aspect, embodiments of the present invention also provide a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the steps of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method described in any of the preceding claims.

[0010] Beneficial Effects: Compared with existing technologies, this invention provides a method, chip, and storage medium for synchronous upgrading and rollback of dual-partition bootloaders and applications. The method for synchronous upgrading and rollback of dual-partition bootloaders and applications provided by this invention is applied to a target chip, which includes flash memory. The flash memory includes a first partition, a second partition, and a state area independent of the first and second partitions. Both the first and second partitions include a bootloader area, an application header area, and an application code area. The state area is used to store partition status and switching control information. In the method, when a target upgrade package is received, a full partition image is obtained. The full partition image contains a bootloader, application header information, and application code. Then, the full partition image is written to a non-running partition, which is the currently non-running partition among the first and second partitions. The currently running partition remains available and is the currently running partition among the first and second partitions. After that, the validity of the full partition image written to the non-running partition is verified. Only when the validity verification passes is a switch permission flag written to the status area. After writing the switch permission flag, when the target chip is reset, before the bootloader of the target chip jumps to the application, a partition switch is performed according to the switch permission flag, switching the non-running partition to a running partition. This invention provides users with a method for synchronously upgrading and rolling back of dual-partition bootloaders and applications. By writing a full partition image containing the bootloader, application header information, and application code to a non-running partition, and writing a switch permission flag after the validity verification is passed, the bootloader performs partition switching after a reset. This solves the problem of the device failing to start normally due to power failure, reset, or image mismatch during the synchronous upgrade of the bootloader and application. It achieves the beneficial effects of improving upgrade reliability, realizing controlled switching and automatic rollback in case of anomalies, and ensuring device recoverability. Attached Figure Description

[0011] Figure 1 A flowchart illustrating an embodiment of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided by the present invention; Figure 2 This is an overall system architecture diagram of an embodiment of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided by the present invention; Figure 3 This is an overall chip distribution diagram of an embodiment of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided by the present invention; Figure 4 This is an upgrade startup flowchart of an embodiment of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided by the present invention; Figure 5This is a block diagram illustrating the overall principle of the chip in an embodiment of the dual-partition bootloader and application synchronous upgrade and abnormal rollback chip provided by the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0013] Example 1 The dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided in this embodiment can be executed by multiple terminals. The terminals can be, but are not limited to, smart computers, smart mobile devices, or cloud servers / edge gateways. In this embodiment, the method is executed by the target chip.

[0014] In the existing embedded product field, automotive electronics, body control, digital keys, NFC (Near Field Communication) controllers, and other embedded products often employ a dual-project architecture that separates the BOOT (Bootloader) and APP (Application). The BOOT project is responsible for power-on initialization, upgrade reception, partition selection, integrity verification, and jump execution, while the APP project is responsible for business logic, diagnostic communication, and upgrade triggering.

[0015] Traditional OTA (Over-the-Air) upgrade solutions typically only upgrade the app area, while the boot area remains unchanged after mass production. However, in real-world projects, the boot area may need to be updated synchronously due to changes in upgrade protocols, flash memory partition adjustments, optimized boot verification strategies, or improved anomaly recovery logic. If a single-partition overwrite upgrade or manual image merging method is still used, a power outage, reset, or image mismatch during the upgrade process could damage either the boot area or the app area, preventing the device from booting normally.

[0016] It can be seen that common solutions and shortcomings in existing technologies include: upgrading only the APP area while keeping the BOOT area unchanged, with the OTA package only containing the APP Header (Application Header) and APP Code (Application Code). This method is simple to implement, but it cannot simultaneously repair the upgrade protocol, partition management, startup verification, and exception recovery logic in the BOOT, limiting future maintenance; directly overwriting the running partition, erasing and writing the Flash area that is currently starting or about to start during the upgrade, this method is very sensitive to power failure, reset, and transmission anomalies, and an interruption in the upgrade may result in incomplete startup vectors, BOOT code, or APP images, posing a risk of bricking the device; upgrading BOOT and APP independently, upgrading BOOT first and then APP, or having the production end burn the data twice, this method has a long process and many states, and is prone to version mismatch, incorrect switching timing, or unrecoverable problems after a failure in a certain step; ordinary AB partition upgrade, which saves two sets of APP images through A / B dual partitions, but usually only focuses on APP rollback, without repairing the BOOT area, APP Header, and APP... Code, as a mirror of the entire Bank (the storage unit), is used for consistency upgrades, but it lacks verification and switching constraints for synchronous updates between BOOT and APP.

[0017] Therefore, a method for BOOT and APP synchronous upgrades and anomaly rollback based on AB partitions is needed. This method would allow the entire Bank image to be written to a non-running partition, verified, and then switched to running mode. Furthermore, it would automatically roll back to a usable partition if the new partition fails. Providing a method that can perform BOOT and APP synchronous writing, full package verification, controlled switching, and anomaly rollback on a non-running partition, ensuring device recoverability in the event of upgrade anomalies, verification failures, or startup failures, is a pressing problem in this field.

[0018] Based on this, in this embodiment, a dual-partition architecture, namely a dual-Bank Flash architecture, is adopted for the target chip. Specifically, each Bank contains a BOOT area, an APP Header area, and an APP Code area, and the currently running partition, upgrade result, and switching flag are recorded through a partition status area. In this embodiment, the target chip can be a chip with the model number MSPMOG3519.

[0019] Specifically, the dual-partition bootloader and application synchronous upgrade and abnormal rollback method provided in this embodiment is applied to a target chip, which includes flash memory.

[0020] like Figure 1As shown, the dual-partition bootloader and application synchronous upgrade and anomaly rollback method provided in this embodiment is applied to a target chip. The target chip includes flash memory, which includes a first partition, a second partition, and a state area independent of the first and second partitions. Both the first and second partitions include a bootloader area, an application header area, and an application code area. The state area is used to store partition status and switching control information. The method includes: S100. When the target upgrade package is received, the whole partition image is obtained. The whole partition image contains the bootloader, application header information and application code.

[0021] Specifically, the status area is located in a separate data flash page of the flash memory, and the status area includes currently running partition information, upgrade success flag, switch permission flag, and reset assist flag; The currently running partition information is used to record the partition that should be started now or next. The upgrade success flag is used to indicate that the target image transfer is complete and the verification is passed. The switch allow flag is used to indicate that partition switching is allowed. The reset assist flag is used to constrain the execution order of switch and recovery commands.

[0022] Specifically, in this embodiment, the Flash memory of the target chip is first divided into partition A and partition B, each partition containing a BOOT area, an APP Header area, and an APP Code area; at the same time, an independent data status area is set up to store the currently running partition, upgrade success flag, switch permission flag, and reset auxiliary flag.

[0023] Specifically, the status area is located in a separate data flash page of the flash memory, and the status area includes currently running partition information, an upgrade success flag, a switch permission flag, and a reset assist flag. The currently running partition information is used to record the partition that should be started now or next, the upgrade success flag is used to indicate that the target image transfer is complete and the verification is passed, the switch permission flag is used to indicate that partition switching is allowed, and the reset assist flag is used to constrain the execution order of switch and recovery commands.

[0024] In one embodiment, the status area is located in a separate data flash page with a base address of 0x41D00000. The records in the status area total 8 bytes and are aligned to 8-byte levels. The currently running partition information, the upgrade success flag, the switch enable flag, and the reset assist flag each occupy 1 byte (8 bits) independently, without bit-field compression.

[0025] Specifically, in this embodiment, the currently running partition information is located in Byte[0], with a length of 8 bits. Its values ​​can include: 0xFF indicating uninitialized, 0x00 indicating the initial state, 0x01 indicating the first partition, and 0x02 indicating the second partition. The currently running partition information is used to record the partition that should be started now or next.

[0026] The upgrade success flag is located in Byte[1], which is 8 bits long. Its value can include: 0x00 indicating failure or unverified, and 0x01 indicating successful verification. The upgrade success flag is used to indicate that the target image transmission is complete and the entire packet verification is successful.

[0027] The switching permission flag is located in Byte[2], with a length of 8 bits. Its value can include: 0x00 indicating prohibition and 0x08 indicating permission. The switching permission flag is used to indicate that the partition switching is allowed after the secondary validity check of the non-running partition passes. The non-running partition is the currently non-running partition that was written into the full partition image in this upgrade and is intended to be used as the running partition after the switch.

[0028] The reset auxiliary flag is located in Byte[3], with a length of 8 bits. Its value can include: 0x00 indicating normal operation, and 0x01 indicating entry into the switching or reset sequence. The reset auxiliary flag is used to constrain the execution order of switching and recovery instructions.

[0029] The status area may also include a reserved field located in Byte[4:7], with a length of 32 bits, for extended version, incrementing sequence number, status cyclic redundancy check or inverse code check and other information.

[0030] like Figure 2As shown, in this embodiment, the overall system architecture includes a host computer and image side, a full partition packaging module, and a device bootloader side. The host computer and image side is used to generate the bootloader BOOT image and the application APP image; the full partition packaging module is used to combine the bootloader, application header information, and application code into a full partition image, and generate an application-only upgrade package or a full-bank upgrade package; the device bootloader side includes an upgrade receiving module, a verification and status management module, and a startup switching module. The upgrade receiving module is used to receive the full partition image and write it to the non-running partition; the verification and status management module is used to perform full-packet cyclic redundancy check (CRC), bootloader vector validity check, application header validity check, and application cyclic redundancy check, and manage the switch permission flag SwapInfo (Swap Information) in the status area; the startup switching module is used to perform partition switching (Bank Swap), jump to application, and abnormal rollback after reset.

[0031] Reference Figure 3 The target chip's flash memory AB partition layout includes a first partition, a second partition, a DATA status area, and a rollback path. The first partition is partition A, and the second partition is partition B. Both the first and second partitions include a bootloader area, an application header area, and an application code area.

[0032] Specifically, the first partition can correspond to Bank0 (storage bank 0), with an address range of 0x00000 to 0x3FFFF, and includes BOOT (Bootloader), Header (Application Header), and APP (Application). The second partition can correspond to Bank1 (storage bank 1), with an address range of 0x40000 to 0x7FFFF, and includes BOOT, Header, and APP.

[0033] The DATA status area can be located in a separate data flash page with a base address of 0x41D00000, and is used to store information such as partition status, upgrade success flag, and switch permission flag. The rollback path is used to indicate that when the currently running partition is invalid, it will automatically switch to another valid partition between the first partition and the second partition and resume boot; if both the first partition and the second partition are invalid, it will remain in bootloader mode.

[0034] Wherein, Flash is the storage medium of the target chip, AB represents a dual-partition layout, Bank (storage body) represents a bootable partition unit in the flash memory, BOOT represents the boot program area, Header represents the application header area, APP represents the application code area, and DATA represents the status data storage area.

[0035] The target upgrade package is a full partition upgrade package, which includes a bootloader area, an application header area, and an application code area; the full partition image is composed of bootloader vectors and code, application header information, and valid application code linked in a predetermined low address manner.

[0036] The target upgrade package can be generated and sent by a host computer. The host computer constructs a complete partition image and sends it to the target chip in fixed block sizes. Specifically, the host computer sends a request to enter programming mode. Upon receiving this request, the target chip resets and enters the bootloader upgrade process. After the upgrade data transmission is complete, the host computer sends a data check request, which carries a cyclic redundancy check value for the entire package. After the target chip completes the validity check and writes the switch permission flag, the host computer sends a switch request. The target chip performs a secondary validity check based on the switch request and allows partition switching upon successful verification.

[0037] Specifically, in this embodiment, the application header information is fixed at 128 bytes, and multi-byte fields are stored in little-endian. The application header information includes a firmware identifier field, a packet quantity field, a file size field, an application verification field, a software version field, a reserved field, and a header verification field.

[0038] The firmware identifier field is located in Byte[0:5] of the application header information, with a length of 6 bytes, and is used to represent the firmware type identifier. In one embodiment, the first three bytes are the ASCII code "NFC", and the last three bytes are reserved.

[0039] The number of packets is located in Byte[6:7], with a length of 2 bytes, and is stored in little-endian. It is used to represent the number of packets in the upgrade file so as to verify the number of received packets and the file length.

[0040] The file size field is located in Byte[8:11], with a length of 4 bytes. It is stored in little-endian and is used to represent the total length of the application header information and the valid code of the application, so as to perform range and out-of-bounds checks.

[0041] The application verification field is located in Byte[12:15], with a length of 4 bytes. In one embodiment, it is a cyclic redundancy check, used to represent the valid code verification value of the application.

[0042] The software version field is located in Byte[16:18], with a length of 3 bytes, including low version number, medium version number and high version number, and is used for version identification, dependency checking and anti-downgrade judgment.

[0043] The reserved field is located in Byte[19:123], with a length of 105 bytes. When not in use, it is filled with 0xFF and can be used to extend the hardware version, image type, security version number, digest, or signature index.

[0044] The header verification field is located in Byte[124:127], with a length of 4 bytes. In one embodiment, it is a cyclic redundancy check, used to represent the header self-check value, calculated on Byte[0:123].

[0045] In one embodiment, the entire partition image is composed according to a predetermined low-address linking method, such that the bootloader vector and code, application header information and application valid code are located in the low-address region in sequence, so as to be used as a whole for subsequent writing, verification and switching operations.

[0046] The verification range of the application verification field is Byte

[128] to Byte[fileSize-1], where fileSize is the length represented by the file size field. The header verification field is calculated for Byte[0:123].

[0047] S200. Write the entire partition image to the non-running partition, which is the currently non-running partition among the first partition and the second partition. The currently running partition remains available, and the currently running partition is the currently running partition among the first partition and the second partition.

[0048] Specifically, before writing the entire partition image to the non-running partition, the target chip can receive a request to enter programming mode and reset to enter the bootloader upgrade process. The bootloader determines whether to allow the upgrade based on the currently running partition and the upgrade package type to avoid erasing or writing the non-running partition containing the bootloader area in an insecure state.

[0049] When an upgrade is permitted, the bootloader erases the target area of ​​the non-running partition and receives upgrade data in fixed block sizes. Each 256-byte image block can be split into multiple flexible data rate controller LAN (FRDC) data frames for transmission, and after collection, written to the non-running partition. During the writing process, the currently running partition remains available and is not erased or modified. Since the non-running partition is the currently non-running partition, writing the entire partition image to the non-running partition will not affect the bootloader, application header information, and application code of the currently running partition.

[0050] like Figure 4 As shown, the upgrade phase includes: building a complete bank image, i.e., a complete partition image, which includes BOOT, Header, and APP; entering programming mode and resetting to BOOT; erasing the target partition, i.e., the non-running partition of this upgrade; transmitting and writing to the non-running partition in blocks according to a fixed block size, for example, using 256-byte blocks and transmitting via CAN FD (Controller Area Network with Flexible Data-Rate); performing full packet verification, which includes CRC and Header verification; and writing the switch status, which includes Partition and Swap Flag. The boot and rollback constraints include: the status area records whether the currently running partition is the first partition or the second partition, i.e., the current A / B (first partition / second partition), and the status area base address is 0x41D00000; the target partition is subjected to BOOT Vector (Bootloader Vector) validity check and APP CRC (Application Cyclic Redundancy Check) matching; after reset, BOOT performs Bank Swap (Bank Switching, i.e., partition switching), so that the new bank is mapped to a logical low address and the switching enable flag is cleared; if the currently running partition is invalid, it is rolled back to another valid partition; if both the first and second partitions are invalid, it remains in bootloader mode.

[0051] S300. Perform validity verification on the whole partition image written to the non-running partition. Only when the validity verification passes will the switch permission flag be written to the status area.

[0052] The validity verification of the whole partition image written to the non-running partition includes: Perform full-packet cyclic redundancy check, bootloader vector validity check, application header validity check, and application cyclic redundancy check on the entire partition image; The application header validity verification includes verifying the firmware identifier, file length, number of sub-packets, and header verification information in the application header; The scope of the application's cyclic redundancy check is the valid code of the application.

[0053] In this embodiment, the application header information in the application header area is a fixed 128 bytes, including firmware identifier field, number of sub-packets field, file size field, application verification field, software version field, reserved field and header verification field; The application header validity verification includes verifying firmware identifier, file length, number of packets, and header verification information, while the application cyclic redundancy verification verifies the validity of the application code.

[0054] Specifically, for the whole packet cyclic redundancy check (CRC) test, the boot program in the target chip recalculates the CRC value of the whole partition image that has been written to the non-running partition, and compares the recalculated CRC value with the CRC value sent by the host computer. If they match, the CRC test passes; if they do not match, the CRC test fails.

[0055] For the bootloader vector validity check, the bootloader checks whether the bootloader vector table in the entire partition image is valid. If the bootloader vector table is invalid, the bootloader vector validity check fails.

[0056] For the application header validity verification, the application header information in the application header area is a fixed 128 bytes, including a firmware identifier field, a packet quantity field, a file size field, an application verification field, a software version field, a reserved field, and a header verification field. The application header validity verification includes verifying the firmware identifier, file length, packet quantity, and header verification information. Specifically, it verifies whether the firmware identifier matches the target firmware type, whether the file length is within a valid range, whether the packet quantity matches the number of received packets, and whether the header verification information passes self-verification for some fields in the application header information. If any one of the firmware identifier, file length, packet quantity, or header verification information fails verification, the application header validity verification fails.

[0057] For the application cyclic redundancy check, the cyclic redundancy check verifies the valid code of the application, and the verification scope is the valid code of the application. The bootloader calculates the cyclic redundancy check value for the valid code of the application and compares the calculation result with the application verification field in the application header information. If the comparison matches, the application cyclic redundancy check passes; if the comparison does not match, the application cyclic redundancy check fails.

[0058] The switch permission flag is written to the status area only after the entire package cyclic redundancy check, the bootloader vector validity check, the application header validity check, and the application cyclic redundancy check all pass. If any of the above checks fails, the switch is kept in the disabled state, and the switch permission flag is not written, thus preventing the target chip from booting to the new image.

[0059] Specifically, in this embodiment, before starting the non-running partition, the firmware identifier, file length, number of packets, header verification, and application verification are checked sequentially; if any one of these fails, the switchover permission flag cannot be set. The firmware identifier is used to indicate the firmware type, the file length is used to indicate the total length of the application header information and the valid application code, the number of packets is used to verify the number of received packets against the file length, the header verification is used to perform self-verification on some fields in the application header information, and the application verification is used to perform cyclic redundancy check on the valid application code.

[0060] Specifically, after the host computer sends a switch request, the bootloader performs a secondary validity check on the non-running partition. This secondary validity check includes verifying the bootloader vector table validity, application header validity, application file size range, and application cyclic redundancy check matching. If all checks pass, the bootloader writes the target running partition information and a switch permission flag. If any of the secondary validity checks fails, the switch is prohibited, and the switch permission flag is not written.

[0061] S400. After writing the switching enable flag, when the target chip is reset, before the boot program of the target chip jumps to the application program, a partition switch is performed according to the switching enable flag to switch the non-running partition to a running partition.

[0062] Performing a partition handover based on the handover permission flag includes: If the switching permission flag is in the switching permission state, then a partition switch is performed; If the switching permission flag is set to a disabled switching state, the currently running partition remains unchanged.

[0063] Switching the non-running partition to a running partition includes: The non-running partition is mapped to a logical low address, making the bootloader vector and code and application code in the non-running partition the boot target; After the switch is completed, the switch permission flag in the status area is cleared to prevent repeated switches.

[0064] Specifically, the reset can be a software reset, a watchdog reset, or a power-on reset. After startup and before jumping to the application, the bootloader reads the switching permission flag in the status area and determines whether to perform a partition switch based on the switching permission flag.

[0065] Performing a partition switch based on the switch permission flag includes: if the switch permission flag is in a switch-allowed state, then performing a partition switch; if the switch permission flag is in a switch-disabled state, then keeping the currently running partition unchanged.

[0066] In one embodiment, a switching permission flag of 0x08 indicates that switching is allowed, and a switching permission flag of 0x00 indicates that switching is prohibited. If the switching permission flag is in the switching allowed state, the boot program performs a partition switch, switching the non-running partition to the running partition; if the switching permission flag is in the switching prohibited state, the boot program does not perform a partition switch, and the target chip continues to boot from the current running partition.

[0067] Specifically, after the bootloader performs a partition switch, the non-running partition is mapped to a logical low address. The target chip then obtains the bootloader vector and code, as well as the application code, from the logical low address, thereby using the non-running partition as the new running partition. After the switch is completed, the bootloader clears the switch enable flag in the status area, ensuring that the same partition switch will not be performed again during the next reset, thus avoiding duplicate switching.

[0068] In one embodiment, the currently running partition information in the status area is also updated to the partition identifier corresponding to the non-running partition after partition switching, so as to record the partition that should be started now or next. If the target chip fails to start after partition switching, the bootloader performs subsequent error rollback operations based on the currently running partition information in the status area and the partition validity check result.

[0069] Furthermore, in this embodiment, the method further includes: If the currently running partition is invalid when the target chip starts up, it will roll back to another valid partition between the first partition and the second partition; if both the first partition and the second partition are invalid, it will remain in bootloader mode.

[0070] Specifically, the bootloader verifies the validity of the currently running partition during startup. The currently running partition is the partition in the first partition and the second partition that is currently mapped to a logical low address and is used as the boot target. If the currently running partition is invalid, the bootloader automatically checks the other partition in the first partition and the second partition. If the other partition is valid, the partition status in the status area is written back, and the bootloader rolls back to run on the other partition. If both the first partition and the second partition are invalid, the bootloader remains in bootloader mode, waiting for a re-upgrade.

[0071] In this embodiment, the invalidity of the currently running partition includes at least one of the following: the bootloader vector table in the currently running partition is invalid, the application header information in the currently running partition is invalid, the cyclic redundancy check of the valid code of the application in the currently running partition fails, or the bootloader or application in the currently running partition fails to start. The bootloader performs a validity check on the currently running partition during startup; if the check fails, the currently running partition is determined to be invalid.

[0072] The step of writing back the partition status in the status area includes: updating the currently running partition information in the status area to the partition identifier corresponding to the other valid partition, so as to record the partition to be started next. The step of rolling back to the other partition includes: the bootloader mapping the other valid partition to a logical low address, making the bootloader vector and code and application code in the other valid partition the boot target, thereby starting from the other valid partition.

[0073] If both the first partition and the second partition are invalid, the bootloader remains in bootloader mode and does not jump to the application, waiting for the host computer to resend the target upgrade package or re-execute the upgrade process.

[0074] In one embodiment, the state update and anomaly recovery sequence of the state area is as follows: When erasing the non-running partition begins, the upgrade success flag is set to failure or unverified, the switch permission flag is set to disabled, and the currently running partition remains available; after the entire package verification passes, only the upgrade success flag is set to verification successful, and switching is still not allowed; after the secondary validity check and switch request pass, the currently running partition information is set to the non-running partition, and the switch permission flag is set to allowed; after the early partition switch is completed by resetting, the non-running partition is mapped to a logical low address, and the switch permission flag is cleared; if the non-running partition is invalid, the other valid partition between the first partition and the second partition is written back and started; if both the first partition and the second partition are invalid, the system remains in bootloader mode waiting for recovery.

[0075] In one embodiment, the state area can employ a method of alternating writing using dual copies, incrementing sequence numbers, and cyclic redundancy check. At startup, a state record with valid verification and a more recent sequence number is selected to improve the reliability of the state area itself.

[0076] Furthermore, in this embodiment, the method further includes: Based on the size of the target upgrade package, distinguish between application-only upgrades and full partition upgrades; When the size of the target upgrade package is greater than the maximum length corresponding to an application-only upgrade, the target upgrade package is determined to be a full partition upgrade package; For full partition upgrades that include the bootloader area, such full partition upgrades are only allowed when the currently running partition is the first partition; when the currently running partition is the second partition, only application upgrades are allowed.

[0077] Specifically, the application-only upgrade refers to an upgrade package that does not include a bootloader area, while the full partition upgrade refers to an upgrade package that includes a bootloader area.

[0078] In this embodiment, for a full partition upgrade including the bootloader area, security constraints are set: the full partition upgrade is only allowed when the currently running partition is the first partition; when the currently running partition is the second partition, only application upgrades are allowed. That is, when the currently running partition is the first partition, the second partition can be erased and a full partition image including the bootloader area can be written; when the currently running partition is the second partition, a full partition upgrade including the bootloader area is not initiated, and only application upgrades without the bootloader area are allowed, thereby reducing the startup risk caused by abnormal resets during bootloader erasure and writing.

[0079] In one implementation, data transmission can employ a flexible data rate controller area network (CAN FD), or a classic controller area network (CAN) with ISO-TP (ISO 15765-2 Transport Protocol), LIN (Local Interconnect Network), UART (Universal Asynchronous Receiver / Transmitter), RS-485 (Recommended Standard 485), USB (Universal Serial Bus), Ethernet / DoIP (Diagnostics over Internet Protocol), Bluetooth, Wi-Fi (Wireless Fidelity), or a cellular network. The block size can be 256 bytes, or it can be 64 bytes, 128 bytes, 512 bytes or other lengths depending on the communication frame, RAM (Random Access Memory) and flash memory programming granularity, and the block sequence number, offset and retransmission mechanism can be configured.

[0080] Furthermore, in another implementation, integrity or authenticity verification can employ CRC16 (Cyclic Redundancy Check 16), CRC32 (Cyclic Redundancy Check 32), CRC64 (Cyclic Redundancy Check 64), Fletcher (Fletcher Checksum), Adler (Adler Checksum), SHA-256 (Secure Hash Algorithm 256), SM3 (ShangMi 3), HMAC (Hash-based Message Authentication Code), or ECDSA (Elliptic Curve Digital Signature Algorithm), RSA (Rivest-Shamir-Adleman), or SM2 (ShangMi 2) digital signatures. Application header information can use a fixed 128-byte structure, or other fixed-length structures, TLV (Type-Length-Value), or versioned Manifest, as long as it can describe the image's identity, length, version, and integrity.

[0081] Furthermore, in many implementations, partition switching can employ hardware partition switching, address remapping, vector table relocation, boot partition table, boot address pointer, or selection of the target image by a primary bootloader. The status area can be located in on-chip flash memory, or in EEPROM (Electrically Erasable Programmable Read-Only Memory), Emulated EEPROM, external flash memory, or ferroelectric memory; the status area can use dual copies, log recording, sequence number plus cyclic redundancy check, or primary / backup status pages. Anomaly detection can employ watchdog reset counting, application startup confirmation, runtime self-test, health handshake, timeout confirmation, or consecutive failure thresholds. The entire partition image can be transmitted as a complete partition image, or transmitted in compressed, encrypted, or differential form; switching is only allowed after the target partition's complete image has been reconstructed and the overall verification has passed.

[0082] The technical features in the above embodiments can be combined with each other and all fall within the protection scope of this embodiment.

[0083] As can be seen, in this embodiment, the bootloader and application are upgraded consistently. The bootloader area, application header area, and application code area are upgraded as a whole partition image, avoiding inconsistencies in the bootloader and application protocols, versions, or partition definitions. The upgrade reliability is high. Upgrade data is written to the non-running partition, and the currently running partition remains available. Switching is only allowed after the cyclic redundancy check, header information check, and partition validity check all pass. The abnormal rollback capability is strong. At startup, the current running partition and another partition are automatically checked. If the current running partition is invalid, it can roll back to the valid partition, reducing the risk of unrecoverable equipment due to upgrade failure, power failure, or reset. The switching process is controllable. The upgrade result and switching timing are managed through the current running partition information, upgrade success flag, switch permission flag, and reset auxiliary flag, which facilitates diagnosis, tracking, and production line debugging. It is compatible with multiple upgrade modes. The same framework can support application-only upgrades and full partition upgrades simultaneously, and security restrictions can be set according to the current running partition. It is suitable for automotive-grade embedded scenarios and can be extended to vehicle controllers, digital keys, near-field communication nodes, and other microcontroller products that adopt a dual-engineering architecture for bootloader and application and flash partition switching.

[0084] In summary, this embodiment provides a method for synchronous upgrade and rollback of dual-partition bootloader and application, applied to a target chip. The target chip includes flash memory, which includes a first partition, a second partition, and a state area independent of the first and second partitions. Both the first and second partitions include a bootloader area, an application header area, and an application code area. The state area is used to store partition status and switching control information. In the method, when a target upgrade package is received, a complete partition image is obtained. The complete partition image contains the bootloader, application header information, and application code. Then, the complete partition image is written to a non-running partition, which is the currently non-running partition among the first and second partitions. The currently running partition remains available and is the currently running partition among the first and second partitions. Afterward, the validity of the complete partition image written to the non-running partition is verified. Only when the validity verification passes is a switching permission flag written to the state area. After writing the switching permission flag, when the target chip is reset, before the bootloader of the target chip jumps to the application, a partition switch is performed according to the switching permission flag, switching the non-running partition to a running partition. This embodiment provides users with a method for synchronously upgrading and rolling back of dual-partition bootloaders and applications. By writing a full partition image containing the bootloader, application header information, and application code to a non-running partition, and writing a switch permission flag after the validity verification is passed, the bootloader performs partition switching after a reset. This solves the problem of the device failing to start normally due to power failure, reset, or image mismatch during the synchronous upgrade of the bootloader and application. It achieves the beneficial effects of improving upgrade reliability, realizing controlled switching and automatic rollback in case of anomalies, and ensuring device recoverability.

[0085] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of the steps in this invention, and these steps can be executed in other orders. Moreover, at least a portion of the steps in this invention may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program using signal-related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0087] Example 2 Based on the above embodiments, the present invention also provides a chip for synchronous upgrade of dual-partition bootloader and application programs, as well as for abnormal rollback, such as... Figure 5 As shown, the dual-partition bootloader and application synchronous upgrade and abnormal rollback chip includes flash memory and a processor; The flash memory includes a first partition, a second partition, and a status area independent of the first and second partitions; both the first and second partitions include a bootloader area, an application header area, and an application code area; the status area is used to store partition status and switching control information, as described in Embodiment 1. The processor includes: The image acquisition module is used to acquire the entire partition image when the target upgrade package is received. The entire partition image contains the bootloader, application header information and application code, as described in Embodiment 1. The image writing module is used to write the entire partition image to a non-running partition, which is the partition that is not currently running in the first partition and the second partition. The currently running partition remains available, and the currently running partition is the partition that is currently running in the first partition and the second partition, as described in Embodiment 1. The verification module is used to verify the validity of the whole partition image written to the non-running partition. Only when the validity verification passes will the switch permission flag be written to the status area, as described in Embodiment 1. The partition switching module is used to perform partition switching according to the switching enable flag after the chip is written, when the chip is reset and before the chip's boot program jumps to the application, to switch the non-running partition to a running partition, as described in Embodiment 1.

[0088] Example 3 The present invention also provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the steps of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method described above.

[0089] 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 method for synchronously upgrading and rolling back anomalies of a dual-partition bootloader and application, applied to a target chip, the target chip including flash memory, characterized in that... The method is executed by the target chip, and the flash memory includes a first partition, a second partition, and a state area independent of the first and second partitions; both the first and second partitions include a bootloader area, an application header area, and an application code area. The status area is used to store partition status and switching control information; the method includes: When the target upgrade package is received, the entire partition image is obtained, which contains the bootloader, application header information and application code; Write the entire partition image to a non-running partition, which is the currently non-running partition among the first partition and the second partition. The currently running partition remains available, which is the currently running partition among the first partition and the second partition. The validity of the whole partition image written to the non-running partition is verified, and the switching permission flag is written to the status area only if the validity verification passes. After the switch enable flag is written, when the target chip is reset, before the boot program of the target chip jumps to the application, a partition switch is performed according to the switch enable flag to switch the non-running partition to a running partition. The status area is located in a separate data flash page of the flash memory, and the status area includes the currently running partition information, upgrade success flag, switch permission flag and reset assist flag; The currently running partition information is used to record the partition that should be started now or next. The upgrade success flag is used to indicate that the target image transfer is complete and the verification is passed. The switch permission flag is used to indicate that partition switching is allowed. The reset assist flag is used to constrain the execution order of switch and recovery commands. The target upgrade package is a full partition upgrade package, which includes a bootloader area, an application header area, and an application code area; the full partition image is composed of bootloader vector and code, application header information, and valid application code linked in a predetermined low address manner; the application header information includes firmware identifier field, number of sub-packages field, file size field, application verification field, software version field, reserved field, and header verification field.

2. The method for synchronous upgrading and rollback of dual-partition bootloader and application programs according to claim 1, characterized in that, The validity verification of the whole partition image written to the non-running partition includes: Perform full-packet cyclic redundancy check, bootloader vector validity check, application header validity check, and application cyclic redundancy check on the entire partition image; The application header validity verification includes verifying the firmware identifier, file length, number of sub-packets, and header verification information in the application header; The scope of the application's cyclic redundancy check is the valid code of the application.

3. The method for synchronous upgrading and rollback of dual-partition bootloader and application programs according to claim 1, characterized in that, Performing a partition handover based on the handover permission flag includes: If the switching permission flag is in the switching permission state, then a partition switch is performed; If the switching permission flag is set to a disabled switching state, the currently running partition remains unchanged.

4. The method for synchronous upgrading and rollback of dual-partition bootloader and application programs according to claim 1, characterized in that, Switching the non-running partition to a running partition includes: The non-running partition is mapped to a logical low address, making the bootloader vector and code and application code in the non-running partition the boot target; After the switch is completed, the switch permission flag in the status area is cleared to prevent repeated switches.

5. The method for synchronous upgrading and rollback of dual-partition bootloader and application programs according to claim 1, characterized in that, The method further includes: If the currently running partition is invalid when the target chip starts up, it will roll back to another valid partition between the first partition and the second partition; If both the first partition and the second partition are invalid, the system remains in bootloader mode.

6. The method for synchronous upgrading and abnormal rollback of dual-partition bootloader and application according to claim 1, characterized in that, The method further includes: Based on the size of the target upgrade package, distinguish between application-only upgrades and full partition upgrades; When the size of the target upgrade package is greater than the maximum length corresponding to an application-only upgrade, the target upgrade package is determined to be a full partition upgrade package; For full partition upgrades that include the bootloader area, such full partition upgrades are only allowed when the currently running partition is the first partition; when the currently running partition is the second partition, only application upgrades are allowed.

7. A chip, characterized in that, The chip includes flash memory and a processor; The flash memory includes a first partition, a second partition, and a status area independent of the first and second partitions; both the first and second partitions include a bootloader area, an application header area, and an application code area. The status area is used to store partition status and switching control information; The processor includes: The image acquisition module is used to acquire the entire partition image when the target upgrade package is received. The entire partition image contains the bootloader, application header information and application code. The image writing module is used to write the entire partition image to a non-running partition, which is the partition that is not currently running in the first partition and the second partition. The currently running partition remains available, and the currently running partition is the partition that is currently running in the first partition and the second partition. The verification module is used to verify the validity of the whole partition image written to the non-running partition. Only when the validity verification passes will the switch permission flag be written to the status area. The partition switching module is used to perform partition switching according to the switching enable flag after the switching enable flag is written, when the chip is reset, before the chip's boot program jumps to the application program, and switch the non-running partition to a running partition. The status area is located in a separate data flash page of the flash memory, and the status area includes the currently running partition information, upgrade success flag, switch permission flag and reset assist flag; The currently running partition information is used to record the partition that should be started now or next. The upgrade success flag is used to indicate that the target image transfer is complete and the verification is passed. The switch permission flag is used to indicate that partition switching is allowed. The reset assist flag is used to constrain the execution order of switch and recovery commands. The target upgrade package is a full partition upgrade package, which includes a bootloader area, an application header area, and an application code area; the full partition image is composed of bootloader vector and code, application header information, and valid application code linked in a predetermined low address manner; the application header information includes firmware identifier field, number of sub-packages field, file size field, application verification field, software version field, reserved field, and header verification field.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the dual-partition bootloader and application synchronous upgrade and abnormal rollback method as described in any one of claims 1-6.

Images