A cross-platform firmware updating method and system based on static parameter configuration and dynamic callback

Abstract

The application discloses a cross-platform firmware updating method and system based on static parameter configuration and dynamic callback, relates to the technical field of embedded systems and firmware updating, and comprises the following steps: after system power-on, performing hardware minimum system initialization and firmware updating module initialization, performing range determination on static parameters, performing non-empty determination on a callback function pointer, mapping the callback function to a bottom layer driver after success, receiving a firmware updating request and firmware file information through an information receiving callback function, erasing a Flash according to firmware size, receiving firmware files in blocks and calling a Flash writing callback function to write the Flash, performing integrity check after complete file writing, solidifying firmware logs after successful check, and closing an interrupt and jumping to an APP main program. The application realizes decoupling of firmware updating core logic and a hardware platform, supports ARM and DSP and other heterogeneous platforms with one set of code, and reduces cross-platform transplantation threshold and development and maintenance cost.

Description

Technical Field

[0001] This invention relates to the field of embedded systems and firmware update technology, and in particular to a cross-platform firmware update method and system based on static parameter configuration and dynamic callback. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) industry, embedded devices are becoming increasingly feature-rich, and their product lifecycles are generally extended to over ten years. During this long operational cycle, the need for software vulnerability patching and feature upgrades is inevitable. Firmware update capabilities have become an indispensable core function for embedded products, and their stability and flexibility directly determine the product's maintainability. However, the embedded hardware field has long been characterized by diversity: mainstream chip architectures include ARM (Cortex-M series) and DSP (TI C2000 series), storage media include different types such as internal Flash and external Flash, each with its own erase / write drivers; communication interfaces are also extremely diverse, such as UART, CAN, USB, Ethernet, Wi-Fi, and BLE. Against this backdrop, traditional firmware update solutions generally adopt a design pattern of strong coupling between core logic and underlying hardware, with upgrade processes, verification mechanisms, and Flash drivers and communication interface code tightly bound together. In practice, developers often write a separate software version for each hardware platform, resulting in extremely low software reusability. When porting between different platforms is required, developers must deeply understand the core firmware update logic and underlying driver architecture, rewriting a large amount of redundant code, leading to low porting efficiency and a high risk of errors.

[0003] On the other hand, while existing mainstream open-source solutions (such as MCUboot) offer comprehensive functionality, they suffer from significant drawbacks, including complex code configuration, large differences in build processes, and stringent portability requirements, making them unsuitable for resource-constrained MCU and DSP embedded scenarios. Therefore, the industry urgently needs a solution that can completely decouple the core firmware update logic from the hardware platform while also being lightweight, easily portable, and scalable, in order to reduce cross-platform development and maintenance costs and improve software reuse efficiency. Summary of the Invention

[0004] To address this, embodiments of the present invention provide a cross-platform firmware update method and system based on static parameter configuration and dynamic callback, which solves the problems of low cross-platform portability, poor reusability, and high development and maintenance costs caused by the strong coupling between the core firmware update logic and the hardware platform in the prior art.

[0005] To address the aforementioned technical problems, this invention provides a cross-platform firmware update method based on static parameter configuration and dynamic callbacks, comprising the following steps: Step S1: After the system is powered on, perform the minimum system initialization of the hardware platform. After completion, perform firmware update module initialization. The firmware update module initialization includes: determining the range of parameters in the pre-configured static parameter list and determining whether the callback function pointers in the pre-configured dynamic callback function pointer list are null. If the determination is successful, set the static parameters as the running parameters of the current firmware update module and map the callback function pointers to the corresponding underlying hardware driver functions. Step S2: After the firmware update module is initialized, according to the configuration of the communication interface, wait for and receive the firmware update interaction request through the mapped information receiving callback function. After completing the handshake confirmation, receive the firmware file information, which includes the firmware file size and integrity check value. Step S3: Based on the firmware file size and the pre-configured APP application start address and length, perform an erasure operation on the Flash area within the corresponding address range using the mapped Flash erase callback function; Step S4: After the Flash erase is completed, according to the data block size configured in the static parameter list, the firmware file content is received in blocks through the information receiving callback function. After each data block is received and verified to be correct, the mapped Flash write callback function is called to write the data block to the corresponding address of the Flash according to the endianness setting and the data length corresponding to the memory address configured in the static parameter list, and the current cumulative value of the write address is updated. This step is repeated until the entire firmware file is received and written to the Flash. Step S5: After the entire firmware file is written to Flash, read the written firmware information from the starting address of the APP application in Flash, calculate the integrity check value according to the firmware file length, and compare the calculated integrity check value with the integrity check value received in step S2. Step S6: After successful comparison, call the mapped Flash write callback function to write the firmware file size and the calculated integrity check value into the preset APP application log information address to complete the firmware log solidification. Step S7: After the firmware log is solidified, the mapped system interrupt shutdown callback function is called to disable the system interrupt, and according to the jump method configured after burning in the static parameter list, the direct jump function or the system reset callback function is called to execute the operation of jumping to the APP application main program, and the firmware update process ends.

[0006] Preferably, the static parameter list includes one or more of the following parameters: APP application address, APP application log information address, APP jump flag storage address, endianness setting, data block size, data length corresponding to memory address, jump method after burning, and backdoor delay time.

[0007] Preferably, the dynamic callback function pointer list includes one or more of the following callback function pointers: system shutdown interrupt callback function pointer, system reset or restart callback function pointer, Flash erase callback function pointer, Flash write callback function pointer, information send callback function pointer, and information receive callback function pointer.

[0008] Preferably, in step S1, the minimum system initialization of the hardware platform includes: clock initialization, interrupt vector table initialization, watchdog initialization, and communication interface initialization.

[0009] Preferably, after step S1 and before step S2, a backdoor waiting step is included: waiting to receive a firmware update request according to the backdoor delay time configured in the static parameter list; if no firmware update request is received within the backdoor delay time, the integrity verification value in the APP application log information address is read, and the firmware in the APP application area in Flash is verified for integrity. If the verification is successful, the user is directly redirected to the APP application main program; if a firmware update request is received or the integrity verification fails, the user proceeds to step S2 to execute the firmware update process.

[0010] Preferably, in step S4, after each data block is received, a local verification is performed on the data block. If the verification fails, a request is made to retransmit the data block.

[0011] Preferably, in step S5, if the comparison fails, the firmware update fails, an error log is recorded, and the system waits for the next firmware update request.

[0012] Preferably, the jump method after the burning process includes a direct jump method and a software reset method; when configured as a direct jump method, the program jumps directly to the starting address of the APP application through a function pointer; when configured as a software reset method, the program calls the system reset callback function to perform a hardware reset and then jumps to the APP application by the bootloader.

[0013] This invention also provides a cross-platform firmware update system based on static parameter configuration and dynamic callbacks, used to execute the cross-platform firmware update method based on static parameter configuration and dynamic callbacks described above. The system includes: The initialization module is used to perform the minimum system initialization of the hardware platform after the system is powered on, and then perform firmware update module initialization. The firmware update module initialization includes: determining the range of parameters in the pre-configured static parameter list, and determining whether the callback function pointers in the pre-configured dynamic callback function pointer list are null; if the determination is successful, the static parameters are set as the running parameters of the current firmware update module, and the callback function pointers are mapped to the corresponding underlying hardware driver functions. The communication handshake and file information receiving module is used to wait for and receive firmware update interaction requests through the mapped information receiving callback function according to the configuration of the communication interface after the firmware update module is initialized. After completing the handshake confirmation, it receives firmware file information, which includes firmware file size and integrity check value. The Flash erasure module is used to perform an erasure operation on the Flash region of the corresponding address range according to the size of the firmware file and the pre-configured starting address and length of the APP application through the mapped Flash erasure callback function; The firmware block receiving and writing module is used to receive firmware file content in blocks according to the data block size configured in the static parameter list after Flash erasure is completed, through the information receiving callback function. After each data block is received and verified to be correct, the module calls the mapped Flash writing callback function to write the data block to the corresponding address in Flash according to the endianness setting and data length corresponding to the memory address configured in the static parameter list, and updates the current cumulative value of the writing address. This step is repeated until the entire firmware file is received and written to Flash. The firmware integrity verification module is used to read the written firmware information from the starting address of the APP application in the Flash after the entire firmware file has been written to the Flash, calculate the integrity verification value according to the length of the firmware file, and compare the calculated integrity verification value with the integrity verification value received in step S2. The firmware log solidification module is used to call the mapped Flash write callback function after a successful comparison, and write the firmware file size and the calculated integrity verification value into the preset APP application log information address to complete the firmware log solidification. The system jump control module is used to call the mapped system interrupt shutdown callback function to disable system interrupts after the firmware log is solidified, and to call the direct jump function or system reset callback function according to the jump method configured after burning according to the static parameter list, and to perform the operation of jumping to the main program of the APP application, and the firmware update process ends.

[0014] This invention also provides a computer storage medium storing a computer software product, the computer software product including several instructions to cause a computer device to execute the cross-platform firmware update method based on static parameter configuration and dynamic callback described above.

[0015] As can be seen from the above technical solutions, this invention application has the following beneficial effects: First, this invention adopts a modular architecture design that combines static parameter configuration with dynamic callback functions. Static parameters adapt to different Flash capacities, endianness settings, memory address-to-data length, App main program startup address, reset methods, and other static hardware characteristics. Callback functions encapsulate dynamic driver operations such as Flash read / write and communication interface information transmission and reception. The core upgrade process and verification mechanism are completely separated from the Flash driver and communication interface code, allowing adaptation to different hardware platforms without modifying the core framework. This breaks the limitation of traditional firmware update software that can only adapt to a single hardware platform. A single core codebase can uniformly support heterogeneous embedded platforms such as ARM (Cortex-M series) and DSP (TI C2000 series), greatly improving the reusability of embedded software across different product lines.

[0016] Secondly, this invention, through a unified hardware driver callback interface specification, eliminates the need for porting personnel to understand the core firmware update logic. They only need to implement the underlying Flash driver and communication interface driver functions according to the standard interface and modify the corresponding configuration parameters to complete the porting across different hardware platforms. Compared to similar products, even non-core developers can quickly complete the porting work, significantly shortening the project development cycle and reducing software development and maintenance costs. Furthermore, this invention adopts a lightweight design, making it suitable for resource-constrained MCU and DSP embedded scenarios, solving the problem of traditional solutions being difficult to deploy in resource-constrained environments.

[0017] Third, based on modular design and a callback mechanism, this invention allows for easy replacement of hardware platforms, communication interfaces, or Flash chips when new ones are needed. Only the corresponding driver implementation needs to be added and configuration parameters modified, without requiring core code refactoring. This reduces the difficulty and cost of later maintenance, enabling the product to quickly respond to feature upgrades and vulnerability fixes, effectively ensuring rapid iteration and upgrade capabilities throughout its lifecycle of over ten years. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly described below. Referring to the drawings will make the features and advantages of the present invention clearer. The drawings are illustrative and should not be construed as limiting the present invention in any way. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart of a cross-platform firmware update method based on static parameter configuration and dynamic callback provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of the firmware update startup process in an embodiment of the present invention; Figure 3 This is a schematic diagram of the firmware update execution process in an embodiment of the present invention; Figure 4 This is a block diagram of a cross-platform firmware update system based on static parameter configuration and dynamic callback provided in an embodiment of the present invention. Detailed Implementation

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

[0020] Example 1: To address the problems of low cross-platform portability, poor reusability, and high development and maintenance costs caused by the strong coupling between the core firmware update logic and the hardware platform in existing technologies, this invention proposes a cross-platform firmware update method based on static parameter configuration and dynamic callbacks, such as... Figure 1 As shown, the method includes the following steps: In step S1, after the system powers on, the minimum system initialization of the hardware platform is performed first. Specifically, the initialization of the minimum hardware system includes clock initialization, interrupt vector table initialization, watchdog timer initialization, and communication interface initialization. The communication interface can be initialized using UART, CAN, USB, Ethernet, Wi-Fi, BLE, or other interface types depending on the actual hardware configuration. After hardware initialization, the firmware update module initialization begins. Firmware update module initialization includes two key steps: first, determining the range of parameters in the pre-configured static parameter list to ensure that each parameter value is within a reasonable and valid range; second, checking the non-null value of callback function pointers in the pre-configured dynamic callback function pointer list to ensure that each callback function pointer has been correctly assigned a value. Upon successful checking, the static parameters are set as the operating parameters of the current firmware update module, and the callback function pointers are mapped to the corresponding underlying hardware driver functions, including Flash erase / write driver functions, communication transmit / receive driver functions, and system interrupt disable / reset function functions. Through the above static parameter range checking and callback function pointer non-null checking, system failures caused by abnormal parameters and null pointers are effectively prevented, ensuring that subsequent operations can be executed smoothly.

[0021] The static parameter list includes the following parameters: APP application address, which is the starting address of the App program, the starting address of the firmware update, and the starting address for jumping to the App after the firmware update; APP application log information address, which is the storage address of the App program length and checksum. After power-on, it is used to calculate the App checksum and compare it with the stored value to complete the integrity check before executing the jump action; APP jump flag, which is an address set in the system storage as a flip flag variable to determine whether it is a normal power-on or a jump from the App to the firmware update program for firmware update; endianness setting, which is to combine data according to the byte alignment standard when writing firmware to Flash; data block size, which is to set according to the sector size or a multiple of the byte alignment value when writing firmware to Flash to improve the data writing speed; memory address corresponding to data length, which is different for different chips. For ARM series, one address corresponds to 1 byte, and for DSP, one address corresponds to 2 bytes; jump method after burning, including direct jump or chip software reset; backdoor delay time, which is the backdoor burning waiting time, used to wait for whether the firmware update instruction is received. After the hardware powers on and starts, there is a delay before jumping to the App.

[0022] The dynamic callback function pointer list includes the following callback function pointers: system interrupt disable callback function pointer, used to disable system interrupt function; system reset or restart callback function pointer, used to execute software reset function after firmware update; Flash erase callback function pointer, used to erase Flash function; Flash write callback function pointer, used to write Flash function; information send callback function pointer, used by communication module to send information during firmware update; and information receive callback function pointer, used by communication module to receive firmware file and interactive information during firmware update.

[0023] After step S1 and before step S2, a backdoor waiting step is also included: waiting to receive a firmware update request according to the backdoor delay time configured in the static parameter list. If no firmware update request is received within the backdoor delay time, the integrity verification value in the APP application log information address is read, and the firmware in the APP application area of ​​Flash is verified for integrity. If the verification passes, the process directly jumps to the APP application main program; if a firmware update request is received or the integrity verification fails, the process proceeds to step S2 to execute the firmware update process.

[0024] In step S2, after the firmware update module is initialized, it waits for and receives firmware update interaction requests through the mapped information receiving callback function according to the communication interface configuration. Specifically, it first waits for the firmware update interaction request according to the receiving function configured in the communication module. After receiving the interaction information, it performs a handshake confirmation. After confirmation, it begins to receive firmware file information, which includes the firmware file size and integrity check value. After replying with confirmation, it proceeds to the next step.

[0025] In step S3, based on the firmware file size and the pre-configured starting address and length of the APP application, an erasure operation is performed on the Flash region within the corresponding address range using the mapped Flash erase callback function. Specifically, based on the App's starting address and firmware file size, an erasure operation is performed on the Flash region within the corresponding length range to prepare for subsequent firmware writing.

[0026] In step S4, after the Flash erase is complete, the firmware file content is received in blocks according to the data block size configured in the static parameter list, via the information receiving callback function. After each data block is received, a local verification is performed. If the verification fails, a retransmission of the data block is requested. If the verification is successful, the mapped Flash write callback function is called to write the data block to the corresponding address in the Flash, based on the endianness setting and data length corresponding to the memory address configured in the static parameter list. Data write counts are maintained, and the cumulative address value is calculated using the memory address-to-data-length parameter to align the data and address mappings and ensure the overall integrity and correctness of the firmware. This step is repeated cyclically, receiving and writing data to the corresponding Flash location in blocks until the entire firmware file is received and written to the Flash according to the configured size.

[0027] In step S5, after the entire firmware file is written to Flash, the written firmware information is read from the starting address of the APP application in Flash, the integrity check value is calculated according to the firmware file length, and the calculated integrity check value is compared with the integrity check value received in step S2. If the comparison fails, the firmware update fails, an error log is recorded, and the system waits for the next firmware update request; if the comparison succeeds, the process proceeds to step S6.

[0028] In step S6, after successful comparison, the mapped Flash write callback function is called to write the firmware file size and the calculated integrity verification value into the preset APP application log information address, thus completing the firmware log solidification for use in subsequent power-on startup integrity verification.

[0029] In step S7, after the firmware log is solidified, the mapped system interrupt disable callback function is called to disable system interrupts. Then, according to the jump method configured in the static parameter list after burning, either a direct jump function or a system reset callback function is called to jump to the main program of the APP application, ending the firmware update process. Specifically, the jump method after burning includes a direct jump mode and a software reset mode: when configured as a direct jump mode, execution jumps directly to the starting address of the APP application via a function pointer; when configured as a software reset mode, a hardware reset is performed by calling the system reset callback function, and then the bootloader jumps to the APP application.

[0030] like Figure 2As shown, the overall process of firmware update startup is as follows: After the system powers on, the minimum system initialization of the hardware platform is performed, including the initialization of the clock, interrupt vector table, watchdog timer, and communication interfaces (UART / CAN / NET, etc.); after the hardware initialization is completed, the firmware update module is initialized; after initialization, the startup module flag information is checked. If no firmware update request information is received, the complete verification information value in the App log information is read, and the complete verification information is calculated by reading the App value in Flash based on the App start information and length in the log information; after the complete verification is successful, the system waits for the update instruction according to the configured backdoor delay time. If no firmware update request is received within the waiting time, the system jumps to the APP main program, and the firmware update ends; if the complete verification fails or a firmware request is received within the waiting time, the firmware update process begins.

[0031] The specific process of firmware update is as follows: According to the configured communication module, wait to receive the firmware update start command, perform a handshake confirmation after receiving the interaction information, and then wait to receive firmware information log information (including firmware size and complete checksum). According to the configured data block size, start receiving file content information in blocks; file block transmission verification, if the verification fails, it can be retransmitted; after the entire firmware is transmitted, perform integrity verification; if the verification is successful, write the firmware information to the corresponding address of Flash for subsequent integrity verification after power-on; after writing is completed, call the system interrupt disable function and perform direct jump or system reset to the APP main program, and the firmware update work is completed.

[0032] like Figure 3 As shown, the detailed process of firmware update execution is as follows: After system initialization, static parameter range detection is performed first. If successful, a check is performed to ensure the callback function pointer address is null, thus preventing abnormal information and ensuring the smooth execution of subsequent processes. If the check is correct, callback function mapping is performed, mapping the Flash driver, communication interface, system interrupt disable, system reset, and other functional functions to their corresponding function pointers. After mapping, firmware file reception is performed. First, the firmware file size and integrity check value are received. After information reception is completed, the Flash is erased. After erasure, the firmware file is received in blocks according to the agreed data block size. The receiving and verification of each block is repeated until the entire firmware file is received correctly. After firmware file reception and verification are completed, the firmware file size and check information are written to the firmware log address. The system interrupt disable callback function is called, and then the system is reset or directly jumps to the APP program address. The firmware update execution is complete.

[0033] As can be seen from the above technical solution, the present invention proposes a cross-platform firmware update method based on static parameter configuration and dynamic callback. By adopting a modular encapsulation method that separates the application logic layer and the hardware abstraction layer, the module startup initialization, firmware upgrade, and integrity verification logic are completely independent of the hardware platform. By configuring parameters and mapping callback functions, it can adapt to different hardware platforms without modifying the core code, thus achieving complete decoupling between the core firmware update logic and the hardware platform.

[0034] Example 2: like Figure 4 As shown, this embodiment of the invention provides a cross-platform firmware update system based on static parameter configuration and dynamic callback, used to execute the cross-platform firmware update method based on static parameter configuration and dynamic callback of Embodiment 1 above. The system includes: The initialization module performs minimal system initialization of the hardware platform after system power-on, followed by firmware update module initialization. Firmware update module initialization includes: determining the range of parameters in a pre-configured static parameter list and checking for null values ​​in callback function pointers in a pre-configured dynamic callback function pointer list. Upon successful checks, the static parameters are set as the running parameters for the current firmware update module, and the callback function pointers are mapped to the corresponding underlying hardware driver functions. Specifically, the minimal hardware system initialization includes initialization of the clock, interrupt vector table, watchdog timer, and communication interface. After hardware initialization, firmware update module initialization begins, checking the data range of static parameters and the callback function pointers for null values ​​to ensure smooth execution of subsequent operations. Upon successful checks, configuration information is set, and the callback function pointers are mapped to Flash erase / write driver functions, communication transmit / receive driver functions, and system interrupt disable / reset function functions.

[0035] The communication handshake and file information receiving module is used after the firmware update module is initialized. Based on the communication interface configuration, it waits for and receives firmware update interaction requests through a mapped information receiving callback function. After completing the handshake confirmation, it receives firmware file information, including the firmware file size and integrity check value. Specifically, according to the communication module configuration, the receiving function waits for firmware update interaction requests. After the interaction request is confirmed, it begins configuring firmware information, including firmware size and firmware check information. After receiving confirmation, it proceeds to the next step.

[0036] The Flash erase module is used to perform erase operations on the Flash area within the corresponding address range based on the firmware file size and the pre-configured starting address and length of the APP application, through the mapped Flash erase callback function.

[0037] The firmware block receiving and writing module is used to receive firmware file content in blocks according to the data block size configured in the static parameter list after Flash erasure. Each received data block, after verification, is written to the corresponding address in Flash by calling the mapped Flash write callback function, based on the endianness setting and memory address corresponding data length configured in the static parameter list, and the current cumulative write address value is updated. This process is repeated until the entire firmware file is received and written to Flash. Specifically, the module begins by receiving firmware file content in blocks according to the configured data block size. After each block is received and verified, the Flash write callback function is called to write the data to the corresponding address, based on the endianness setting and memory address corresponding data block length. Data write counts are maintained, and the cumulative address value is calculated using the memory address corresponding data length parameter. Data and address mapping are aligned to ensure the overall integrity and correctness of the firmware. This process is repeated block-by-block cumulative reception and writing to the corresponding Flash location until the firmware file completes the entire file reception and verification process according to the configured size.

[0038] The firmware integrity verification module is used to read the written firmware information from the starting address of the application program in the Flash after the entire firmware file has been written to the Flash, calculate the integrity verification value according to the firmware file length, and compare the calculated integrity verification value with the integrity verification value received in step S2. Specifically, after the firmware file is transferred and written to the Flash, the firmware information is read from the starting address of the Flash and the integrity verification value is calculated according to the firmware length, and then compared with the previously received integrity verification value for verification.

[0039] The firmware log solidification module, upon successful verification, calls the mapped Flash write callback function to write the firmware file size and the calculated integrity check value to a preset APP application log information address, thus completing the firmware log solidification. Specifically, after successful verification, the Flash write callback function is called to write the App verification information and file size value to the corresponding area of ​​the Flash firmware log, completing the firmware update and integrity check.

[0040] The system jump control module is used to call the mapped system interrupt shutdown callback function to disable system interrupts after the firmware log is solidified, and to call the direct jump function or system reset callback function according to the jump method configured after burning according to the static parameter list, and to perform the operation of jumping to the main program of the APP application, thus ending the firmware update process.

[0041] This embodiment provides a cross-platform firmware update system based on static parameter configuration and dynamic callback, used to implement the aforementioned cross-platform firmware update method based on static parameter configuration and dynamic callback. Therefore, the specific implementation of the cross-platform firmware update system based on static parameter configuration and dynamic callback can be found in the previous section on the embodiment of the cross-platform firmware update method based on static parameter configuration and dynamic callback. To avoid redundancy, it will not be repeated here.

[0042] Example 3: This invention provides a computer storage medium storing a computer software product, which includes several instructions to cause a computer device to execute the aforementioned cross-platform firmware update method based on static parameter configuration and dynamic callback.

[0043] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0044] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0045] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0046] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A cross-platform firmware update method based on static parameter configuration and dynamic callback, characterized in that, Includes the following steps: Step S1: After the system is powered on, perform the minimum system initialization of the hardware platform. After completion, perform firmware update module initialization. The firmware update module initialization includes: determining the range of parameters in the pre-configured static parameter list and determining whether the callback function pointers in the pre-configured dynamic callback function pointer list are null. If the determination is successful, set the static parameters as the running parameters of the current firmware update module and map the callback function pointers to the corresponding underlying hardware driver functions. Step S2: After the firmware update module is initialized, according to the configuration of the communication interface, wait for and receive the firmware update interaction request through the mapped information receiving callback function. After completing the handshake confirmation, receive the firmware file information, which includes the firmware file size and integrity check value. Step S3: Based on the firmware file size and the pre-configured APP application start address and length, perform an erasure operation on the Flash area within the corresponding address range using the mapped Flash erase callback function; Step S4: After the Flash erase is completed, according to the data block size configured in the static parameter list, the firmware file content is received in blocks through the information receiving callback function. After each data block is received and verified to be correct, the mapped Flash write callback function is called to write the data block to the corresponding address of the Flash according to the endianness setting and the data length corresponding to the memory address configured in the static parameter list, and the current cumulative value of the write address is updated. This step is repeated until the entire firmware file is received and written to the Flash. Step S5: After the entire firmware file is written to Flash, read the written firmware information from the starting address of the APP application in Flash, calculate the integrity check value according to the firmware file length, and compare the calculated integrity check value with the integrity check value received in step S2. Step S6: After successful comparison, call the mapped Flash write callback function to write the firmware file size and the calculated integrity check value into the preset APP application log information address to complete the firmware log solidification. Step S7: After the firmware log is solidified, the mapped system interrupt shutdown callback function is called to disable the system interrupt, and according to the jump method configured after burning in the static parameter list, the direct jump function or the system reset callback function is called to execute the operation of jumping to the APP application main program, and the firmware update process ends.

2. The cross-platform firmware update method based on static parameter configuration and dynamic callback as described in claim 1, characterized in that, The static parameter list includes one or more of the following parameters: APP application address, APP application log information address, APP jump flag storage address, endianness setting, data block size, data length corresponding to memory address, jump method after burning, and backdoor delay time.

3. The cross-platform firmware update method based on static parameter configuration and dynamic callback as described in claim 1, characterized in that, The list of dynamic callback function pointers includes one or more of the following callback function pointers: system shutdown interrupt callback function pointer, system reset or restart callback function pointer, Flash erase callback function pointer, Flash write callback function pointer, information send callback function pointer, and information receive callback function pointer.

4. The cross-platform firmware update method based on static parameter configuration and dynamic callback as described in claim 1, characterized in that, In step S1, the minimum system initialization of the hardware platform includes: clock initialization, interrupt vector table initialization, watchdog initialization, and communication interface initialization.

5. The cross-platform firmware update method based on static parameter configuration and dynamic callback according to claim 1, characterized in that, After step S1 and before step S2, a backdoor waiting step is also included: waiting to receive a firmware update request according to the backdoor delay time configured in the static parameter list; if no firmware update request is received within the backdoor delay time, the integrity verification value in the APP application log information address is read, and the firmware in the APP application area in Flash is verified for integrity. If the verification is successful, the user is directly redirected to the APP application main program; if a firmware update request is received or the integrity verification fails, the user proceeds to step S2 to execute the firmware update process.

6. The cross-platform firmware update method based on static parameter configuration and dynamic callback according to claim 1, characterized in that, In step S4, after each data block is received, a local verification is performed on the data block. If the verification fails, a request is made to retransmit the data block.

7. The cross-platform firmware update method based on static parameter configuration and dynamic callback according to claim 1, characterized in that, In step S5, if the comparison fails, the firmware update fails, an error log is recorded, and the system waits for the next firmware update request.

8. The cross-platform firmware update method based on static parameter configuration and dynamic callback according to claim 1, characterized in that, The jump method after the burning process includes a direct jump method and a software reset method. When configured as a direct jump method, the program jumps directly to the starting address of the APP application through a function pointer. When configured as a software reset method, the program calls the system reset callback function to perform a hardware reset and then jumps to the APP application by the bootloader.

9. A cross-platform firmware update system based on static parameter configuration and dynamic callback, characterized in that, The system is used to execute the cross-platform firmware update method based on static parameter configuration and dynamic callback as described in any one of claims 1 to 8, the system comprising: The initialization module is used to perform the minimum system initialization of the hardware platform after the system is powered on, and then perform firmware update module initialization. The firmware update module initialization includes: determining the range of parameters in the pre-configured static parameter list, and determining whether the callback function pointers in the pre-configured dynamic callback function pointer list are null; if the determination is successful, the static parameters are set as the running parameters of the current firmware update module, and the callback function pointers are mapped to the corresponding underlying hardware driver functions. The communication handshake and file information receiving module is used to wait for and receive firmware update interaction requests through the mapped information receiving callback function according to the configuration of the communication interface after the firmware update module is initialized. After completing the handshake confirmation, it receives firmware file information, which includes firmware file size and integrity check value. The Flash erasure module is used to perform an erasure operation on the Flash region of the corresponding address range according to the size of the firmware file and the pre-configured starting address and length of the APP application through the mapped Flash erasure callback function; The firmware block receiving and writing module is used to receive firmware file content in blocks according to the data block size configured in the static parameter list after Flash erasure is completed, through the information receiving callback function. After each data block is received and verified to be correct, the module calls the mapped Flash writing callback function to write the data block to the corresponding address in Flash according to the endianness setting and data length corresponding to the memory address configured in the static parameter list, and updates the current cumulative value of the writing address. This step is repeated until the entire firmware file is received and written to Flash. The firmware integrity verification module is used to read the written firmware information from the starting address of the APP application in the Flash after the entire firmware file has been written to the Flash, calculate the integrity verification value according to the length of the firmware file, and compare the calculated integrity verification value with the integrity verification value received in step S2. The firmware log solidification module is used to call the mapped Flash write callback function after a successful comparison, and write the firmware file size and the calculated integrity verification value into the preset APP application log information address to complete the firmware log solidification. The system jump control module is used to call the mapped system interrupt shutdown callback function to disable system interrupts after the firmware log is solidified, and to call the direct jump function or system reset callback function according to the jump method configured after burning according to the static parameter list, and to perform the operation of jumping to the main program of the APP application, and the firmware update process ends.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer software product, which includes several instructions to cause a computer device to execute the cross-platform firmware update method of static parameter configuration and dynamic callback as described in any one of claims 1 to 8.

Images