Firmware updating method and digital signal processor

Abstract

The embodiment of the invention provides a firmware updating method and a digital signal processor. The firmware updating method comprises the steps that when the upgrading type of an upgrading instruction is differential upgrading, according to the upgrading instruction, a to-be-updated storage block and a to-be-copied storage block in a first firmware storage partition are determined; and writing the obtained update firmware data into the to-be-updated storage block, and writing block data corresponding to the second firmware storage partition into the to-be-copied storage block, so that the first firmware storage partition is subjected to firmware update. According to the embodiment of the invention, during differential upgrading, only the differential data is written into the first partition, and the unchanged data is copied from the second partition, so that the problems of poor reliability of traditional single-partition upgrading and high resource overhead of differential upgrading of complete firmware are solved, and the effects of managing the A / B partition by using a secondary Bootloader, ensuring the upgrading reliability and improving the upgrading efficiency are achieved. The data transmission quantity is obviously reduced; and the OTA upgrading speed is accelerated.

Description

Technical Field

[0001] This invention relates to the technical field of firmware upgrades and updates, specifically to a firmware update method and a digital signal processor. Background Technology

[0002] In the field of digital signal processor (DSP) firmware upgrades, the ROM space of a DSP is typically limited, making it difficult to accommodate the primary bootloader code that supports AB partitioning. Alternatively, the primary bootloader may not have considered AB partitioning in its initial design. This necessitates erasing the old firmware from the Flash memory before writing the new firmware during system upgrades. This upgrade method carries significant risks, especially in over-the-air (OTA) upgrade scenarios. If a system power outage occurs or communication interfaces such as Unasynchronous Receiver / Transmitter (UART) or Serial Peripheral Interface (SPI) become unstable, it is highly likely that the old firmware will be erased but the new firmware will not be fully written. In this case, no valid firmware will be available for operation, directly affecting the normal execution of the DSP's core functions and rendering the product unusable.

[0003] In related technologies, solutions such as AB partitioning for overall upgrades or differential upgrades can be adopted, but each has significant shortcomings. While AB partitioning for overall upgrades improves reliability by retaining two firmware copies, the complete firmware download process is time-consuming when the firmware size is large, affecting upgrade efficiency. Differential upgrade technology only transmits the differences between the old and new versions, reducing data transmission volume, but it requires integrating complex compression / decompression algorithms and encryption / decryption modules into the secondary bootloader. It also requires restoring the complete firmware image in random access memory (RAM), which not only increases the complexity of software development but also places higher demands on the DSP's RAM resources, indirectly increasing hardware costs. Summary of the Invention

[0004] This invention provides a firmware update method and a digital signal processor. By acquiring an upgrade command and determining the first partition to be updated and the second partition to retain data, different strategies are executed according to whether the upgrade type is a partition upgrade or a differential upgrade. In a partition upgrade, the complete update data is written to the first partition. In a differential upgrade, only the difference data is written to the first partition, combined with copying the unchanged data from the second partition. This solves the problems of poor reliability in traditional single-partition upgrades and high resource overhead in complete firmware differential upgrades. It achieves the effect of using a two-level bootloader to manage A / B partitions, thereby significantly reducing data transmission volume and accelerating OTA upgrade speed while ensuring upgrade reliability.

[0005] The firmware update method provided in this application is applied to a digital signal processor (DSP). The DSP has at least two firmware storage partitions in its flash memory. The method includes: obtaining an upgrade instruction and determining a first firmware storage partition that needs data updating and a second firmware storage partition that needs data retention; when the upgrade type of the upgrade instruction is a partition upgrade, determining the storage block to be updated in the first firmware storage partition according to the upgrade instruction; writing the obtained update firmware data into the storage block to be updated to enable firmware updating in the first firmware storage partition; when the upgrade type of the upgrade instruction is a differential upgrade, determining the storage block to be updated and the storage block to be copied in the first firmware storage partition according to the upgrade instruction; writing the obtained update firmware data into the storage block to be updated, and writing the block data corresponding to the second firmware storage partition into the storage block to be copied to enable firmware updating in the first firmware storage partition.

[0006] In some implementations, determining the first firmware storage partition that needs data updating and the second firmware storage partition that needs data retention includes: obtaining header information corresponding to each firmware storage partition, wherein the header information includes at least a version identifier; determining the version identifier corresponding to each firmware storage partition by comparing the header information of each partition; and determining the first firmware storage partition that needs data updating and the second firmware storage partition that needs data retention based on the version identifier corresponding to each firmware storage partition.

[0007] In some implementations, when the upgrade type of the upgrade instruction is a partition upgrade, determining the storage block to be updated in the first firmware storage partition according to the upgrade instruction includes: determining the storage block to be updated in the first firmware storage partition according to the size information of the firmware to be updated in the upgrade instruction; writing the acquired update firmware data into the storage block to be updated to enable the first firmware storage partition to perform firmware update includes: erasing the storage block to be updated in the first firmware storage partition; receiving the data of the firmware to be updated frame by frame and writing it sequentially into the storage block to be updated in the first firmware storage partition to determine the updated first firmware storage partition.

[0008] In some implementations, when the upgrade type of the upgrade instruction is a differential upgrade, determining the storage blocks to be updated and the storage blocks to be copied in the first firmware storage partition according to the upgrade instruction includes: parsing the upgrade instruction to determine the number and size information of the storage blocks that need to be differentially upgraded; determining the storage blocks to be updated in the first firmware storage partition according to the number and size information of the storage blocks to be differentially upgraded and the upgrade packet header information in the second firmware storage partition; and determining the storage blocks in the first firmware storage partition other than the storage blocks to be updated as the storage blocks to be copied.

[0009] In some implementations, determining the storage blocks to be updated in the first firmware storage partition based on the number and size information of the storage blocks to be differentially upgraded as needed, and the upgrade packet header information in the second firmware storage partition, includes: checking whether the upgrade packet header information includes upgraded marked storage blocks; if so, comparing the first check value corresponding to the marked storage block with the first preset check value issued by the host computer; if the comparison results are consistent, excluding the marked storage block from the storage blocks to be updated.

[0010] In some implementations, writing the acquired updated firmware data into the storage block to be updated and writing the block data corresponding to the second firmware storage partition into the storage block to be copied, so that the first firmware storage partition can be updated, includes: erasing the storage block to be updated in the first firmware storage partition; receiving the data of the firmware to be updated frame by frame and writing it sequentially into the storage block to be updated in the first firmware storage partition, wherein, for the portion of the storage block to be copied that is less than the minimum erase unit of flash memory, a predefined padding value is used to supplement the minimum erase unit before writing; enabling the direct memory access channel in the digital signal processor and writing the block data corresponding to the second firmware storage partition into the storage block to be copied.

[0011] In some implementations, enabling the direct memory access channel in the digital signal processor to write the block data corresponding to the second firmware storage partition into the storage block to be copied includes: starting a first direct memory access channel to read block data from a specified address in the second firmware storage partition; and starting a second direct memory access channel to write the read data into the address corresponding to the storage block to be copied in the first firmware storage partition.

[0012] In some implementations, after obtaining the updated firmware in the first firmware storage partition, the firmware update method further includes: calculating a second verification value of the updated firmware in the first firmware storage partition; comparing the second verification value with a second preset verification value issued by the host computer; if the comparison results are consistent, then determining the firmware information in the updated first firmware storage partition as valid version information.

[0013] In some implementations, after obtaining the updated firmware in the first firmware storage partition, the firmware update method further includes: reading the header information of all firmware storage partitions in the flash memory to determine the storage address and length of the firmware in each partition; identifying the partition with the largest version count identifier as the new version firmware partition to be verified based on the version count identifier in the header information; calculating the third checksum of the firmware in the new version firmware partition and comparing it with the third preset checksum carried in the upgrade instruction; if the comparison result is consistent, moving the firmware in the new version firmware partition into memory for execution; if the comparison result is inconsistent, executing an error handling process and then verifying the validity of the firmware in the partition with the next largest version count identifier.

[0014] The digital signal processor provided in this application includes a memory and a processor. The memory stores a computer program, and the processor is configured to execute the above-described firmware update method through the computer program.

[0015] This invention, through obtaining upgrade instructions and determining the first partition to be updated and the second partition to retain data, executes different strategies depending on whether the upgrade type is a partition upgrade or a differential upgrade. In a partition upgrade, the complete update data is written to the first partition; in a differential upgrade, only the difference data is written to the first partition, combined with copying the unchanged data from the second partition. This solves the problems of poor reliability in traditional single-partition upgrades and high resource overhead in complete firmware differential upgrades. It achieves the effect of using a two-level bootloader to manage A / B partitions, thereby significantly reducing data transmission volume and accelerating OTA upgrade speed while ensuring upgrade reliability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating the working steps of the firmware update method provided in an embodiment of the present invention.

[0018] Figure 2This is a schematic diagram of the structure of the firmware storage partition provided in the embodiments of this application.

[0019] Figure 3 This is a flowchart illustrating the interaction between the microcontroller system and the host computer provided in an embodiment of this application. Detailed Implementation

[0020] In the field of digital signal processor (DSP) system firmware upgrades, the ROM space of a DSP is typically limited, making it difficult to accommodate the primary bootloader code that supports AB partitioning. Alternatively, the primary bootloader may not have considered AB partitioning in its initial design. This necessitates erasing the old firmware from the Flash memory before writing the new firmware during system upgrades. This upgrade method carries significant risks, especially in over-the-air (OTA) upgrade scenarios. If a system power outage occurs or communication interfaces such as Unasynchronous Receiver / Transmitter (UART) or Serial Peripheral Interface (SPI) become unstable, it is highly likely that the old firmware will be erased but the new firmware will not be fully written. In this case, no valid firmware will be available for operation, directly affecting the normal execution of the DSP's core functions and rendering the product unusable.

[0021] In related technologies, solutions such as AB partitioning for overall upgrades or differential upgrades can be adopted, but each has significant shortcomings. While AB partitioning for overall upgrades improves reliability by retaining two firmware copies, the complete firmware download process is time-consuming when the firmware size is large, affecting upgrade efficiency. Differential upgrade technology only transmits the differences between the old and new versions, reducing data transmission volume, but it requires integrating complex compression / decompression algorithms and encryption / decryption modules into the secondary bootloader. It also requires restoring the complete firmware image in random access memory (RAM), which not only increases the complexity of software development but also places higher demands on the DSP's RAM resources, indirectly increasing hardware costs.

[0022] To address the aforementioned technical problems, this invention provides a firmware update method and a digital signal processor. By acquiring an upgrade command and determining the first partition to be updated and the second partition to retain data, different strategies are executed depending on whether the upgrade type is a partition upgrade or a differential upgrade. In a partition upgrade, the complete update data is written to the first partition; in a differential upgrade, only the difference data is written to the first partition, combined with copying unchanged data from the second partition. This solves the problems of poor reliability in traditional single-partition upgrades and high resource overhead in complete firmware differential upgrades. It achieves the effect of using a two-level bootloader to manage A / B partitions, thereby significantly reducing data transmission volume and accelerating OTA upgrade speed while ensuring upgrade reliability.

[0023] The embodiments of the present invention can be applied to firmware upgrade and update scenarios.

[0024] The firmware update method provided by the exemplary embodiments of the present invention will be described below with reference to the accompanying drawings and the application scenarios described above. It should be noted that the above application scenarios are only shown to facilitate understanding of the principles of the present invention, and the embodiments of the present invention are not limited in any way in this respect.

[0025] Figure 1 This is a schematic diagram illustrating the working steps of the firmware update method provided in an embodiment of the present invention. Figure 1 As shown, the firmware update method provided in this embodiment of the invention includes: Step 01: Obtain the upgrade command and determine the first firmware storage partition that needs to be updated and the second firmware storage partition that needs to retain data; Step 02: When the upgrade type of the upgrade instruction is partition upgrade, determine the storage block to be updated in the first firmware storage partition according to the upgrade instruction; Step 03: Write the acquired update firmware data to the storage block to be updated, so that the first firmware storage partition can perform firmware update; Step 04: When the upgrade type of the upgrade instruction is differential upgrade, determine the storage block to be updated and the storage block to be copied in the first firmware storage partition according to the upgrade instruction; Step 05: Write the obtained updated firmware data into the storage block to be updated, and write the block data corresponding to the second firmware storage partition into the storage block to be copied, so that the first firmware storage partition can be updated.

[0026] Specifically, step 01 obtains the upgrade command and identifies the first partition to be updated and the second partition whose data needs to be retained. Steps 02 and 03 are for partition upgrade mode. By parsing the command, the range of storage blocks to be updated in the first partition is determined, and the received complete firmware data is written to the area to complete the upgrade. Steps 04 and 05 are for differential upgrade mode. First, the blocks to be updated in the first partition and the blocks from which data needs to be copied from the second partition are determined. Finally, the differential data is written to the updated blocks, and at the same time, the unchanged data from the second partition is copied to the corresponding blocks, thereby completing the efficient upgrade.

[0027] This application embodiment can dynamically distinguish between two processing logics through upgrade instructions. During partition upgrade, the target block of the first partition is directly overwritten to ensure complete version replacement. During differential upgrade, the principle of data difference is used to transmit and write only the changed data blocks. For the unchanged parts, the original data blocks of the second partition are copied to fill them. This reduces the amount of data transmission and uses the A / B partition structure to ensure that there is always a complete and usable firmware version as a data source and rollback guarantee during the upgrade process.

[0028] This application embodiment sets up two firmware storage partitions, determines the first (to be updated) and second (reserved) partitions according to the upgrade instructions, and executes different data writing strategies for partition upgrades or differential upgrades. Essentially, it embodies the core logic of a two-level bootloader managing A / B partitions. Managing A / B partitions using a two-level bootloader means that the second-level bootloader program acts as the next stage code after the first-level bootloader, responsible for controlling the switching, update verification, and differential upgrade operations of the two firmware partitions (A and B) in the flash memory. This ensures that the system always has a usable backup firmware version, thereby achieving reliable and efficient OTA upgrades.

[0029] Compared to traditional single-partition upgrade schemes, this application's embodiment eliminates the risk of system paralysis due to unexpected upgrade interruptions through a partition isolation mechanism. Compared to the complete differential upgrade scheme, by combining block-level differential writing with data replication within partitions, it significantly reduces the network bandwidth and storage space usage of the OTA process, shortens the upgrade time, and maintains data reliability comparable to that of a complete differential upgrade, achieving the best balance between reliability, efficiency, and resource overhead.

[0030] In some implementations, step 01 above includes: Obtain the header information corresponding to each firmware storage partition. The header information shall include at least the version identifier. By comparing the header information of each partition, the version identifier corresponding to each firmware storage partition is determined. Based on the version identifier corresponding to each firmware storage partition, determine the first firmware storage partition that needs to be updated and the second firmware storage partition that needs to retain data.

[0031] Specifically, after the system switches the boot mode to download mode, it reads the header information of partitions A and B. This header information pre-stores key metadata such as version identifier, partition table structure and corresponding Flash physical address. By comparing the version identifier (such as version number or timestamp) in the header information of the two partitions, the system can automatically identify the partition with the older version as the first firmware storage partition that needs to update the data, while the partition with the newer version or in an active state is used as the second firmware storage partition that needs to retain the data.

[0032] Figure 2 This is a schematic diagram of the structure of the firmware storage partition provided in the embodiments of this application.

[0033] like Figure 2As shown, APP_Ainfo and APP_Binfo are the header information of partition A and partition B, respectively. By reading the header information of partitions A and B, all the information of the new firmware version can be obtained, including the Flash start address, partition table Section1~N, partition table Section1~NFlash address, etc., and the Flash address of the old firmware version can be obtained.

[0034] In some embodiments, step 02 above includes: Based on the size information of the firmware to be updated in the upgrade instruction, determine the storage block to be updated in the first firmware storage partition.

[0035] Step 03 above includes: erasing the storage blocks to be updated in the first firmware storage partition; The system receives the firmware data to be updated frame by frame and writes it sequentially into the storage block to be updated in the first firmware storage partition to determine the updated first firmware storage partition.

[0036] Specifically, the system parses the firmware size information to be updated carried in the upgrade command, and accordingly calculates the range of physical storage blocks that need to be overwritten within the determined first firmware storage partition, namely the "storage blocks to be updated". This usually corresponds to all or a specified area of ​​the old version of firmware stored in the partition. Then, before writing, the target blocks are erased in preparation for writing. The update data is received frame by frame as the transmission and processing unit, and is written into the erased storage blocks in strict order of the frames until all data is written, thus forming a complete updated firmware partition.

[0037] By precisely locating and dividing blocks using firmware size information in the instructions, accurate control of the update range is achieved. Furthermore, a reliable storage operation paradigm of "erase-after-sequential writing" is employed. This avoids unnecessary large-scale erasures and writes to the entire partition, saving time and flash memory lifespan. For example, the system can parse the upgrade command and determine the UpdateType field in the packet header. When the AB partition is upgraded, the steps to write to flash memory may include: a) Erase the Flash corresponding to the old area according to the size of the new firmware in the SOC command.

[0038] b) Start receiving a frame of data from the new firmware and write it to Flash, then return to the write state.

[0039] c) Repeat step b) until the last frame is written to Flash.

[0040] In some implementations, after obtaining the updated firmware from the first firmware storage partition, the firmware update method further includes: Calculate the second checksum of the firmware in the updated first firmware storage partition; The second verification value is compared with the second preset verification value sent by the host computer; If the comparison results are consistent, the firmware information in the updated first firmware storage partition will be determined as the valid version information.

[0041] Furthermore, after the last frame is written to Flash, a verification step can also be included: d) Read the firmware content from Flash, calculate the checksum, and compare it with the checksum issued by the SOC. If they match, update the packet header and write the new firmware information into App_Ainfo or App_Binfo. If they do not match, change the status to update failed.

[0042] e) The SOC issues a command to obtain the firmware version and determines whether the update was successful.

[0043] In some implementations, step 04 above includes: Parse the upgrade command to determine the number and size of the storage blocks that need to be differentially upgraded; Based on the number and size of storage blocks to be differentially upgraded as needed, and the upgrade packet header information in the second firmware storage partition, determine the storage blocks to be updated in the first firmware storage partition. The storage blocks in the first firmware storage partition, excluding the storage block to be updated, are identified as the blocks to be copied.

[0044] Specifically, the system first parses the upgrade command from the SOC, which explicitly contains the number of sections (blocks) requiring differential upgrade and the size of each section. Then, the system reads the upgrade packet header information stored in the second firmware storage partition (old partition), which serves as the data source. This packet header pre-sets the starting address and size of each section of the old firmware in Flash. By comprehensively analyzing the new section information in the command and the address layout information in the old packet header, the system can calculate the specific Flash physical address and occupied space that each section of the new firmware should be written to in the first partition, thereby accurately determining the storage blocks to be updated that need to be written with differential data.

[0045] In some implementations, based on the number and size information of storage blocks to be differentially upgraded as needed, and the upgrade packet header information in the second firmware storage partition, the storage blocks to be updated in the first firmware storage partition are determined, including: Check if the upgrade packet header information includes the upgraded marked storage block; If it exists, compare the first check value corresponding to the marked storage block with the first preset check value sent by the host computer; If the comparison results are consistent, the marked storage block will be excluded from the storage blocks to be updated.

[0046] The system first checks whether the upgrade packet header information of the second firmware storage partition contains storage blocks marked as upgraded. If such marked blocks exist, the DSP will send a notification to the host SOC, indicating that there are sections that have been upgraded. Subsequently, the host computer will send the preset check value corresponding to each marked block in sequence. The DSP will compare these sent check values ​​with the first check value of the corresponding block stored in the local upgrade packet header one by one. If the comparison results are consistent, it proves that these blocks have been successfully updated in the last upgrade, so they are excluded from the list of storage blocks to be updated this time. If the comparison is inconsistent, the system will start the processing procedure to continue the incomplete upgrade or treat it as a brand new upgrade.

[0047] In some implementations, step 05 above includes: Erase the storage blocks to be updated in the first firmware storage partition; The firmware data to be updated is received frame by frame and written sequentially to the storage block to be updated in the first firmware storage partition. For the part of the storage block to be copied that is less than the minimum erase unit of the flash memory, a predefined padding value is used to make up the minimum erase unit before writing. Enable the direct memory access channel in the digital signal processor to write the block data corresponding to the second firmware storage partition to the storage block to be copied.

[0048] Specifically, the system performs data writing and copying operations on the first firmware storage partition. First, the system erases the identified storage blocks to be updated in the target partition. Then, it begins receiving new firmware data frame by frame from the host computer. Simultaneously with each frame of data reception, the system activates the Direct Memory Access (DMA) channel within the digital signal processor to automatically read the data blocks marked as not needing updating from the second firmware storage partition. This data is then written to the corresponding physical address in the first partition via another DMA channel, thus automating the data copying process between the old and new partitions.

[0049] During the DMA data copying process described above, if the data size of a block to be copied is less than the minimum erase unit required by the flash memory's physical requirements, the system will use a predefined value to pad the remaining part of the block to the minimum unit before performing the overall write operation. This ensures that the write operation complies with the flash memory hardware specifications. After successfully receiving each frame of new firmware data, the system will write that frame of data to the corresponding erased block in the first partition. After each write operation is completed, the system will return a clear write status to the host computer. This status is used to synchronize the upgrade progress and control the advancement of subsequent processes.

[0050] In some implementations, enabling the direct memory access channel in the digital signal processor to write the block data corresponding to the second firmware storage partition into the storage block to be copied includes: Initiate the first direct memory access channel to read block data from a specified address in the second firmware storage partition; The second direct memory access channel is activated, and the read data is written to the address corresponding to the storage block to be copied in the first firmware storage partition.

[0051] Specifically, in differential upgrade, the system starts the first DMA channel to read block data from the second firmware storage partition, and simultaneously starts the second DMA channel to write the data to the address of the block to be copied in the first partition. Through hardware parallel operation, the data transfer efficiency is significantly improved, thereby speeding up the upgrade and enhancing system reliability.

[0052] In some embodiments, the system can parse the upgrade command, determine the UpdateType field in the packet header, and when performing a differential upgrade, execute the steps of writing to flash memory, including: a) Based on the number and size of the sections that need to be differentially upgraded in the SOC command, and combined with the address and size of the sections in the old partition upgrade packet header, analyze the address and size of each section in the Flash of the new firmware.

[0053] b) Check if there is an upgraded section in the upgrade packet header of the old partition. If so, notify the SOC that an upgraded section already exists. After receiving this notification, the SOC sends the checksum of each section in sequence. The DSP compares the received checksum with the DSP. If the values ​​are equal, notify the SOC that the section has been updated and repeat step b. If the values ​​are not equal, proceed to step c to start either the previous incomplete upgrade or a completely new upgrade.

[0054] c) Begin receiving one frame of data from the new firmware; d) While receiving the new firmware, enable DMA to read the sections that do not need to be updated from the new firmware partition on the Flash, and enable another DMA to write the read section content to the corresponding section address of the firmware partition to be updated. (It should be noted that since the minimum erase unit of Flash is 4KB, if the section is less than 4KB, the remaining part is filled with 0xFF.) e) After receiving a frame of data, write it to Flash and return to the write status.

[0055] f) Repeat steps b) to d) until the last frame and all Section content that does not need to be updated are written to Flash.

[0056] In some implementations, after obtaining the updated firmware from the first firmware storage partition, the firmware update method further includes: Calculate the second checksum of the firmware in the updated first firmware storage partition; The second verification value is compared with the second preset verification value sent by the host computer; If the comparison results are consistent, the firmware information in the updated first firmware storage partition will be determined as the valid version information.

[0057] Following step f above, a verification step is also included: g) Read the firmware content from Flash, calculate the checksum, and compare it with the checksum issued by the SOC. If they match, update the packet header and write the new firmware information into App_Ainfo or App_Binfo, including all information about the Secion. If they do not match, change the status to update failed.

[0058] h) The SOC issues a command to obtain the firmware version and determines whether the update was successful.

[0059] In some implementations, after obtaining the updated firmware from the first firmware storage partition, the firmware update method further includes: Read the header information of all firmware storage partitions in the flash memory to determine the storage address and length of the firmware in each partition; Based on the version count identifier in the header information, the partition with the largest version count identifier is identified as the new firmware version partition to be verified. Calculate the third checksum of the firmware in the new firmware partition and compare it with the third preset checksum carried in the upgrade command. If the comparison results match, the firmware in the new firmware partition will be moved into memory and run. If the comparison results are inconsistent, the error handling process is executed, and the validity of the firmware in the partition with the next lower version number is verified.

[0060] Specifically, after the firmware upgrade is completed, a detection process is also included. The system performs upgrade success verification and version switching, switches from download mode to boot mode, and first reads the header information of all firmware storage partitions (such as partition A and partition B) in the flash memory to obtain the key metadata of the firmware in each partition, including the storage start address, firmware length, and the count identifier (BurnCount) used to identify the version.

[0061] The system then compares these BurnCount values ​​and, based on the rule that "the BurnCount of the new version equals the BurnCount of the old version plus one," identifies the partition with the largest BurnCount value as the new firmware partition to be verified. Next, the system calculates the check value of the complete firmware within this new version partition.

[0062] The result of the third checksum comparison determines the subsequent path. If the calculated third checksum matches the third preset checksum carried in the upgrade instruction package, it proves that the new firmware is complete and valid, and the system will perform firmware boot, that is, according to the obtained address and length information, move the firmware code of the partition into RAM for execution. If the comparison is inconsistent, an error handling process is triggered, specifically by incrementing the failure counter (FailNum). If FailNum accumulates to exceed a set threshold (e.g., 3 times), the new version partition will be marked as invalid (e.g., the Valid field in the header information will be set to 1), and the system will skip this marked invalid partition during future boots. After that, the process will turn to verifying the old version partition with the next lower version count. The system will recalculate the checksum of the old firmware version and verify it to ensure that the device can fall back to a known stable version, thereby ensuring the basic boot capability of the system.

[0063] For example, changing the download mode to the launch mode, the detection process may include: a) Read the header information of partitions A and B to obtain all the information of the two firmware versions.

[0064] b) Determine the address and length of the latest firmware based on the BurnCount value (new BurnCount = old BurnCount + 1), calculate the firmware check value CheckValue, and compare it with the check value in the upgrade package header.

[0065] c) If the calculated checksum matches the checksum in the upgrade package, then proceed to step e. d) If the calculated checksum does not match the checksum in the upgrade package, increment FailNum by 1. If FailNum is greater than 3, set the Valid field to 1, and no further new versions will be run; the new version will be invalid. Additionally, for the address and length of the old firmware version, perform step b to recalculate the checksum.

[0066] e) Based on the firmware address and length, move the firmware into RAM for execution.

[0067] The firmware update method provided in this application embodiment will be further explained below based on the interaction process between the microcontroller system and the host computer.

[0068] Figure 3 This is a flowchart illustrating the interaction between the microcontroller system and the host computer provided in an embodiment of this application. Figure 3 As shown, the system-on-a-chip (SOC) can serve as the host computer, and the digital signal processor (DSP) can serve as the processor for firmware upgrades.

[0069] SOC initiates upgrade: The SOC first sends the DOWNLOAD_CMD_TYPE_START command to the DSP to request the start of the upgrade.

[0070] DSP Verification and Preparation: Upon receiving the request, the DSP first checks if the file type and length are valid. If valid, it erases the old firmware and info information to make room for writing the new firmware, and then sends a confirmation message back to the SOC.

[0071] SOC Ready: After receiving the feedback from the DSP, the SOC checks whether the "target status bit" in the confirmation signal is valid. If valid, it proceeds to the next stage; if invalid, it handles the error.

[0072] SOC sends data frames: The SOC divides the firmware into multiple data frames and sends the DOWNLOAD_CMD_TYPE_FRAME command to the DSP in sequence.

[0073] DSP verifies and programs single-frame data: After receiving each frame of data, the DSP immediately verifies it.

[0074] If the verification is successful: the DSP writes the frame data to the Flash memory and then sends a success confirmation back to the SOC.

[0075] If the verification fails: the DSP discards the frame data and sends an error code back to the SOC.

[0076] The SOC determines the subsequent actions: The SOC makes a judgment based on the feedback from the DSP.

[0077] If the return transmission is successful: The SOC continues to determine whether all frames have been sent. If not, it sends the next frame; if all frames have been sent, it proceeds to the next stage. If the return transmission is unsuccessful: The SOC performs error handling, which may include retransmitting the frame data.

[0078] SOC waits for final report: After all data frames have been sent, the SOC stops sending and enters a waiting state, ready to receive the final result report from the DSP.

[0079] The DSP performs an overall verification and reports: After confirming that all frames have been received, the DSP performs a final verification on the complete firmware written to Flash.

[0080] If the Flash data verification is correct: the DSP updates the system application information (App Info), then reports the final upgrade success result to the SOC and exits download mode. If the verification is incorrect: the DSP processes the error and reports a failure result.

[0081] Process End: Once the SOC receives the final result reported by the DSP (whether successful or not), the entire firmware upgrade process ends.

[0082] The digital signal processor provided in this embodiment of the invention includes a memory and a processor. The memory stores a computer program, and the processor is configured to execute the firmware update method of the above-described embodiments through the computer program. The embodiments of the digital signal processor include the firmware update method of the above-described embodiments, and will not be described again here.

[0083] For example, the firmware update method provided in this embodiment of the invention can be executed by a computer device, which can be a terminal or a server. The terminal can be a tablet computer, laptop computer, desktop computer, or personal computer (PC). The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, and big data and artificial intelligence platforms. However, it is not limited to these. The terminal and the server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment of the invention.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0085] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0086] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0087] If the functionality is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0088] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A firmware update method, applied to a digital signal processor, characterized in that, The digital signal processor has at least two firmware storage partitions in its flash memory, and the method includes: Obtain the upgrade command and determine the first firmware storage partition that needs to be updated and the second firmware storage partition that needs to retain data; When the upgrade type of the upgrade instruction is a partition upgrade, the storage block to be updated in the first firmware storage partition is determined according to the upgrade instruction; The acquired updated firmware data is written to the storage block to be updated, so that the first firmware storage partition can be updated. When the upgrade type of the upgrade instruction is differential upgrade, the storage block to be updated and the storage block to be copied in the first firmware storage partition are determined according to the upgrade instruction. The acquired updated firmware data is written to the storage block to be updated, and the block data corresponding to the second firmware storage partition is written to the storage block to be copied, so that the first firmware storage partition can be updated.

2. The firmware update method according to claim 1, characterized in that, The process of determining the first firmware storage partition that needs data updating and the second firmware storage partition that needs data retention includes: Obtain the header information corresponding to each firmware storage partition, wherein the header information includes at least a version identifier; By comparing the header information of each partition, the version identifier corresponding to each firmware storage partition is determined. Based on the version identifier corresponding to each firmware storage partition, determine the first firmware storage partition that needs to be updated and the second firmware storage partition that needs to retain data.

3. The firmware update method according to claim 1, characterized in that, When the upgrade type of the upgrade instruction is a partition upgrade, determining the storage block to be updated in the first firmware storage partition according to the upgrade instruction includes: Based on the size information of the firmware to be updated in the upgrade instruction, the storage block to be updated in the first firmware storage partition is determined; The step of writing the acquired updated firmware data into the storage block to be updated, so that the first firmware storage partition can perform firmware updates, includes: Erase the storage block to be updated in the first firmware storage partition; The data of the firmware to be updated is received frame by frame and written sequentially into the storage block to be updated in the first firmware storage partition to determine the updated first firmware storage partition.

4. The firmware update method according to claim 1, characterized in that, When the upgrade type of the upgrade instruction is a differential upgrade, determining the storage block to be updated and the storage block to be copied in the first firmware storage partition according to the upgrade instruction includes: The upgrade instruction is parsed to determine the number and size of the storage blocks that need to be differentially upgraded; Based on the number and size of storage blocks to be differentially upgraded as needed, and the upgrade packet header information in the second firmware storage partition, determine the storage blocks to be updated in the first firmware storage partition; The storage blocks in the first firmware storage partition other than the storage block to be updated are identified as the blocks to be copied.

5. The firmware update method according to claim 4, characterized in that, The determination of the storage blocks to be updated in the first firmware storage partition, based on the number and size information of the storage blocks to be differentially upgraded as needed, and the upgrade packet header information in the second firmware storage partition, includes: Check whether the upgrade packet header information includes an upgraded marked storage block; If it exists, compare the first verification value corresponding to the marked storage block with the first preset verification value sent by the host computer; If the comparison results are consistent, the marked storage block is excluded from the storage block to be updated.

6. The firmware update method according to claim 1, characterized in that, The step of writing the acquired updated firmware data into the storage block to be updated, and writing the block data corresponding to the second firmware storage partition into the storage block to be copied, so that the first firmware storage partition can be updated, includes: Erase the storage block to be updated in the first firmware storage partition; The firmware data to be updated is received frame by frame and written sequentially into the storage block to be updated in the first firmware storage partition. For the portion of the storage block to be copied that is less than the minimum erase unit of flash memory, a predefined padding value is used to make up the minimum erase unit before writing. Enable the direct memory access channel in the digital signal processor and write the block data corresponding to the second firmware storage partition into the storage block to be copied.

7. The firmware update method according to claim 6, characterized in that, Enabling the direct memory access channel in the digital signal processor and writing the block data corresponding to the second firmware storage partition into the storage block to be copied includes: Initiate the first direct memory access channel to read block data from a specified address in the second firmware storage partition; The second direct memory access channel is activated, and the read data is written to the address corresponding to the storage block to be copied in the first firmware storage partition.

8. The firmware update method according to claim 1, characterized in that, After obtaining the updated firmware from the first firmware storage partition, the firmware update method further includes: Calculate the second checksum of the firmware in the updated first firmware storage partition; The second verification value is compared with the second preset verification value sent by the host computer; If the comparison results are consistent, the firmware information in the updated first firmware storage partition will be determined as valid version information.

9. The firmware update method according to claim 1, characterized in that, After obtaining the updated firmware from the first firmware storage partition, the firmware update method further includes: Read the header information of all firmware storage partitions in the flash memory to determine the storage address and length of the firmware in each partition; Based on the version count identifier in the header information, the partition with the largest version count identifier is identified as the new firmware version partition to be verified. Calculate the third check value of the firmware in the new firmware partition and compare it with the third preset check value carried in the upgrade instruction. If the comparison results match, the firmware in the new version firmware partition will be moved into memory and run. If the comparison results are inconsistent, the error handling process is executed, and the validity of the firmware in the partition with the next lower version number is verified.

10. A digital signal processor, comprising a processor, flash memory, and a memory, wherein the flash memory is divided into at least two firmware storage partitions, characterized in that, The processor is configured to execute instructions stored in the memory to implement the firmware update method as described in any one of claims 1 to 9.

Images