A firmware updating method of a controller under a master-slave board design

Abstract

This invention proposes a firmware update method for a controller with a master-slave board design, relating to the technical field of controller firmware updates. It adds a version identifier and version information to the end of the interrupt vector table in the firmware source code, which is simple, convenient, accurate, and universally applicable. It utilizes a large-capacity non-volatile memory on the motherboard and introduces a dual backup mechanism to prevent firmware update failures from causing the controller to be unable to run the RTS firmware. The host computer caches the firmware in the motherboard's non-volatile memory, and the slave board pulls the version from the motherboard's non-volatile memory, reducing the complexity of the firmware update process. For ease of management, an RTS package generator is used to package an RTS firmware package containing all RTS firmware for both the master and slave boards, and integrity verification information is added. The master and slave board bootloaders synchronize the RTS firmware version from the RTS firmware package cached in the non-volatile memory, achieving automatic distribution of RTS firmware between the master and slave boards and ensuring version compatibility.

Description

Technical Field

[0001] This invention relates to the technical field of controller firmware updates, and more specifically, to a firmware update method for a controller with a master-slave board design. Background Technology

[0002] With the development of automation technology, the number of I / O ports connected to PLCs has increased dramatically. Due to the constraints of I / O port resources in control chips, technicians typically use a master-slave board design to meet these requirements. Generally, when a controller exhibits problems, firmware updates are required to fix the defects.

[0003] However, when the controller adopts a master-slave board design, its firmware update function has the following problems: (1) The on-chip FLASH storage capacity of the controller motherboard is limited and may not be able to store all the firmware of the master and slave boards; (2) The controller needs to be stable and reliable and the firmware versions of the master and slave boards need to be matched; (3) Both the master and slave boards of the controller need to support firmware updates, but the slave board has no external communication interface; (4) Disassembling the controller after installation is extremely time-consuming, and firmware updates need to be done without disassembly to reduce time and cost; (5) The controller motherboard has a requirement for short startup time.

[0004] The current firmware update structure and hardware interfaces of the controller board are as follows: Figure 1 As shown, current controller firmware updates are generally based on IAP (In-Application Programming) technology, employing a bootload plus RTS (Codesys runtime system) architecture. The on-chip FLASH is divided into bootload and RTS areas. First, the board's bootload firmware is burned to the bootload area of ​​the on-chip FLASH. This requires burning the bootload (bootloader) to the on-chip FLASH via ICP (download / debug port, such as J-Link). Subsequently, the host computer, in conjunction with the bootload, burns the RTS firmware via the IAP download port (including but not limited to COM, CAN, etc.) and executes it. Based on this approach, existing technology also discloses an IAP method and system based on an STM32 microcontroller, relating to the technical field of microcontroller software upgrades. This solution includes the following steps: burning the BootLoader program to the microcontroller; burning the APP program to the microcontroller; running the BootLoader program to update the APP program. This method allows for remote control of program upgrades without mechanical disassembly, and can use the IAP upgrade scheme for iterative updates. However, the controller involved in using a master-slave board differs from that of a single-board STM32 microcontroller. The slave board is sealed within a casing, and the firmware update-related structure and hardware structure are as follows: Figure 2As shown, the IAP interface is generally not exposed externally, making it impossible to directly update the slave board firmware via a host computer. Especially after the controller is externally installed, disassembling the controller and flashing the firmware through the download and debugging port is not feasible due to manpower and labor costs. If the controller malfunctions and requires firmware replacement, it can only rely on manual efforts to ensure that the master and slave boards have compatible firmware versions, which is time-consuming, labor-intensive, and prone to errors. Summary of the Invention

[0005] To address the issue that the IAP interface of a controller using a master-slave board design is not exposed, making it impossible to directly update the slave board firmware via the host computer, resulting in a complex, time-consuming, and labor-intensive firmware update process, this invention proposes a firmware update method for a controller with a master-slave board design. This method is simple, convenient, highly stable, and widely applicable.

[0006] To achieve the above-mentioned technical effects, the technical solution of the present invention is as follows:

[0007] A firmware update method for a controller in a master-slave board design, the method comprising the following steps:

[0008] S1. Add version identifier and version information to the end of the interrupt vector table in the firmware source code, and compile to obtain the bootload firmware and RTS firmware for the master and slave boards.

[0009] S2. The motherboard expands with a large-capacity non-volatile memory, uses an RTS packet generator to package an RTS firmware package containing all RTS firmware of the master and slave boards, and adds integrity verification information.

[0010] S3. Introduce a dual backup mechanism, dividing the non-volatile memory into region 0 and region 1, and determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on integrity verification information;

[0011] S4. Power on the motherboard's bootload firmware, determine whether area 0 and area 1 correspond to the active area or the backup area respectively, and select to enter download mode or run the RTS firmware according to the conditions.

[0012] S5. Download mode: The RTS firmware package is burned to the backup area of ​​the non-volatile memory on the motherboard via the host computer, and then the system is reset and executed to S4.

[0013] S6. The motherboard runs RTS firmware, synchronizes the motherboard RTS firmware from the motherboard RTS firmware package stored in the active area of ​​non-volatile memory, and runs it.

[0014] S7. Power on the bootload firmware of the slave board, initiate the slave board RTS firmware initialization request, the motherboard returns the slave board RTS firmware initialization information, and the slave board pulls the RTS firmware from the motherboard according to the initialization information;

[0015] S8. The motherboard transmits the slave board's RTS firmware, the slave board verifies the RTS firmware, and after the slave board's RTS firmware verification is successful, it jumps to run the RTS firmware.

[0016] This technical solution implements firmware updates for both master and slave boards via the motherboard. Version identifiers and information are added to the end of the interrupt vector table in the firmware source code, making it simple, convenient, accurate, and universally applicable. The motherboard is expanded with a large-capacity non-volatile memory, and a dual backup mechanism is introduced to prevent firmware update failures from causing the controller to be unable to run the RTS firmware. The host computer caches the firmware in the motherboard's non-volatile memory, and the slave board retrieves the version from the motherboard's non-volatile memory. This decomposes a complex three-party interaction into two end-to-end interactions, reducing the complexity of the firmware update process. For ease of management, an RTS package generator is used to package all RTS firmware for both master and slave boards, and integrity verification information is added. The master and slave board bootloaders synchronize the RTS firmware version from the RTS firmware package cached in the non-volatile memory, achieving automatic distribution of RTS firmware between the master and slave boards and ensuring version compatibility.

[0017] Preferably, the firmware initializes the interrupt vector table and C language runtime environment through assembly code. The starting address of the interrupt vector table is fixed, near the starting address of the assembly code, and the number of interrupt vectors is limited. The content of the interrupt vector table is a pointer to an interrupt handling function or a null pointer pointing to an address in SRAM or on-chip flash. When adding a version identifier and version information to the end of the interrupt vector table in the firmware source code, the on-chip flash space of the master and slave boards is planned. According to the on-chip flash space planning of the master and slave boards, if the version identifier satisfies the condition of being a non-null pointer and not within the on-chip flash and SRAM address space, the version information can be extracted from the firmware by searching the firmware binary code. The version information includes the firmware version number, firmware type, and compilation time.

[0018] Here, the method of adding the version identifier and version information to the end of the firmware interrupt vector table and directly extracting the version information from the compiled firmware binary file is simple, convenient, highly accurate, and universally applicable, and can be implemented on various microcontroller models.

[0019] Preferably, the process for extracting version information from the firmware is as follows:

[0020] S11. Traverse the interrupt vector table;

[0021] S12. Check if a version identifier is present. If yes, extract the version information and end; otherwise, determine if the interrupt handler function pointer is out of range. If yes, execute step S13; otherwise, return to step S11.

[0022] S13. Perform error handling and end.

[0023] Preferably, in step S2, the RTS package generator packages the RTS firmware of the master and slave boards into a unified RTS firmware package. The RTS firmware package includes three parts: RTS firmware package header, RTS firmware record, and RTS firmware. The RTS firmware package header contains integrity verification information, write-back integrity verification information, download sequence number, RTS firmware package version, number of firmware in the firmware package, and firmware package length. Each RTS firmware record provides information about an RTS firmware, including firmware type, firmware version, firmware verification information, firmware length, and the starting address of the firmware in the RTS firmware package. The RTS firmware package is formed by aligning and linking the RTS firmware package header, RTS firmware record, and the compiled RTS firmware binary bin file.

[0024] The RTS firmware package includes integrity verification information, which can be used to verify whether the firmware update was successful.

[0025] Preferably, the integrity verification information is obtained by calculating the feature values ​​of other characters in the RTS firmware package, excluding the integrity verification information and the written-back integrity verification information fields, using the MD5 / CRC32 algorithm; the other fields of the RTS firmware package, excluding the integrity verification information, the written-back integrity verification information, and the download sequence number, are extracted from the compiled binary bin file.

[0026] Preferably, in step S3, the process of determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on the integrity verification information is as follows:

[0027] S31. Check if the integrity check information of region 0 / region 1 is all 0xFF. If so, there is no complete RTS firmware package in region 0 / region 1 of the non-volatile memory. Otherwise, proceed to step S32.

[0028] S32. Determine whether the integrity verification information fields of region 0 / region 1 and the integrity verification information written back are equal. If they are equal, a complete RTS firmware package exists in region 0 / region 1 of the non-volatile memory; otherwise, a complete RTS firmware package does not exist in region 0 / region 1 of the non-volatile memory.

[0029] Preferably, in step S4, the motherboard's bootload firmware is powered on, and the criteria for determining whether region 0 and region 1 correspond to the active region or the backup region are as follows:

[0030] If both region 0 and region 1 contain complete RTS firmware packages, then the region that most recently successfully downloaded the RTS firmware package is the active region. The process for determining the region that most recently successfully downloaded the RTS firmware package is as follows: compare the download sequence number fields of the two regions. If the difference is 1, then the region with the larger download sequence number is the active region; if the difference is greater than 1, then the region with the smaller download sequence number is the active region.

[0031] If only one of regions, region 0 and region 1, contains a complete RTS firmware package, then the region containing the complete RTS firmware package is the active region.

[0032] If neither region 0 nor region 1 has RTS firmware, then region 0 is the backup region and region 1 is the active region.

[0033] The process of selecting to enter download mode or run RTS firmware based on the following conditions must be met:

[0034] If neither region 0 nor region 1 has a complete RTS firmware package, then proceed directly to download mode;

[0035] If a complete RTS firmware package exists in either region 0 or region 1, then before jumping to the motherboard RTS firmware execution, it is determined whether to enter download mode: the hardware is designed with a debug I / O port, and the level of the debug I / O port is checked to determine whether to enter download mode or jump to the motherboard RTS firmware execution.

[0036] Here, a dual backup mechanism is introduced to avoid the phenomenon that the controller cannot run the RTS firmware due to firmware update failure. Each time the motherboard is powered on, there is a selection process to enter download mode or RTS mode.

[0037] Preferably, the integrity verification information, the write-back integrity verification information, and the download sequence number in the packaged RTS firmware package are all 0xFF.

[0038] Preferably, the process of burning the RTS firmware package to the backup area of ​​the motherboard's non-volatile memory via a host computer is as follows:

[0039] S51. Query board information. The motherboard reports the motherboard type and download number. The download number is the active area download number plus 1.

[0040] S52. The host computer replaces the download sequence number field in the RTS firmware package with the download sequence number reported by the motherboard, then calculates the integrity verification information of the RTS firmware package at this time, and replaces the integrity verification information field in the RTS firmware package. At this time, the integrity verification information field written back is still all 0xff.

[0041] S53. The host computer initiates an initialization request for the RTS firmware package, informing the motherboard of the integrity verification information and length of the RTS firmware package;

[0042] S54. The motherboard initiates an RTS firmware package transmission request. The host computer only needs to passively respond to the request, transmit the RTS firmware package to the motherboard and cache it in the non-volatile memory backup area.

[0043] S55. After the transmission is completed, the motherboard verifies the RTS firmware package, calculates the integrity verification information of the RTS firmware package, and compares it with the integrity verification information sent by the host computer during firmware package initialization request. If they are consistent, the integrity verification information is written back to the integrity verification information field address written back to the backup area.

[0044] Preferably, an integrity verification information field is added to the RTS firmware package as a verification success identifier. The verification identifier is written after the first successful verification after the non-volatile memory is burned, so that it is not necessary to re-verify every time it is powered on.

[0045] When the master and slave boards switch to RTS firmware, the RTS firmware is synchronized from the active area. The motherboard only provides the slave board firmware update process in its RTS firmware.

[0046] Here, the RTS firmware package contains download order information. Combined with the firmware package integrity verification process, the controller only jumps to the latest downloaded RTS firmware package when the firmware update is successful; otherwise, it continues to run the old RTS firmware package. This improves the stability and reliability of the controller and reduces maintenance costs.

[0047] Compared with the prior art, the beneficial effects of the technical solution of the present invention are:

[0048] This invention proposes a firmware update method for a controller with a master-slave board design. Version identifiers and information are added to the end of the interrupt vector table in the firmware source code, making it simple, convenient, accurate, and universally applicable. A large-capacity non-volatile memory is extended on the motherboard, and a dual backup mechanism is introduced to prevent firmware update failures from causing the controller to be unable to run the RTS firmware. The host computer caches the firmware in the motherboard's non-volatile memory, and the slave board pulls the version from the motherboard's non-volatile memory. This decomposes a complex three-party interaction into two end-to-end interactions, reducing the complexity of the firmware update process. For ease of management, an RTS package generator is used to package all RTS firmware for both the master and slave boards, and integrity verification information is added. The master and slave board bootloaders synchronize the RTS firmware version from the RTS firmware package cached in the non-volatile memory, achieving automatic distribution of RTS firmware between the master and slave boards and ensuring version compatibility. Attached Figure Description

[0049] Figure 1 This diagram illustrates the current controller board firmware update structure and hardware interface as presented in the background section of this invention.

[0050] Figure 2 This diagram illustrates the firmware update-related structure and hardware structure of the controller using a master-slave board as proposed in the background section of this invention.

[0051] Figure 3This is a flowchart illustrating the firmware update method for the controller under the master-slave board design proposed in Embodiment 1 of the present invention.

[0052] Figure 4 This is a schematic diagram illustrating the on-chip Flash space planning of the master and slave boards proposed in Embodiment 2 of the present invention.

[0053] Figure 5 This is a schematic diagram illustrating the process of extracting version information from firmware as proposed in Embodiment 2 of the present invention;

[0054] Figure 6 This is a schematic diagram showing the structure of the RTS firmware package proposed in Embodiment 3 of the present invention. Detailed Implementation

[0055] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent.

[0056] To better illustrate this embodiment, some parts of the accompanying drawings may be omitted, enlarged, or reduced, and do not represent the actual dimensions;

[0057] It is understandable to those skilled in the art that some well-known details may be omitted from the accompanying drawings.

[0058] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0059] The positional relationships depicted in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent.

[0060] Example 1

[0061] like Figure 3 As shown in the figure, this embodiment proposes a firmware update method for a controller under a master-slave board design. The method includes the following steps:

[0062] S1. Add version identifier and version information to the end of the interrupt vector table in the firmware source code, and compile to obtain the bootload firmware and RTS firmware for the master and slave boards.

[0063] S2. The motherboard expands with a large-capacity non-volatile memory, uses an RTS packet generator to package an RTS firmware package containing all RTS firmware of the master and slave boards, and adds integrity verification information.

[0064] S3. Introduce a dual backup mechanism, dividing the non-volatile memory into region 0 and region 1, and determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on integrity verification information;

[0065] S4. Power on the motherboard's bootload firmware, determine whether area 0 and area 1 correspond to the active area or the backup area respectively, and select to enter download mode or run the RTS firmware according to the conditions.

[0066] S5. Download mode: The RTS firmware package is burned to the backup area of ​​the non-volatile memory on the motherboard via the host computer, and then the system is reset and executed to S4.

[0067] S6. The motherboard runs RTS firmware, synchronizes the motherboard RTS firmware from the motherboard RTS firmware package stored in the active area of ​​non-volatile memory, and runs it.

[0068] S7. Power on the bootload firmware of the slave board, initiate the slave board RTS firmware initialization request, the motherboard returns the slave board RTS firmware initialization information, and the slave board pulls the RTS firmware from the motherboard according to the initialization information;

[0069] S8. The motherboard transmits the slave board's RTS firmware, the slave board verifies the RTS firmware, and after the slave board's RTS firmware verification is successful, it jumps to run the RTS firmware.

[0070] This embodiment mainly implements the following measures to reduce the complexity of the firmware update process and ensure that the performance requirements of firmware updates are met:

[0071] (1) Rationally plan the responsibilities of bootload and RTS firmware;

[0072] The controller is only flashed with bootload firmware at the factory, and the bootload is not updated after leaving the factory in principle. Therefore, the bootload firmware should follow the principle of the simplest design and only perform two tasks: RTS firmware update and loading and running RTS firmware.

[0073] (2) Expanding non-volatile memory simplifies firmware update process

[0074] The motherboard expands to a large-capacity non-volatile memory to cache firmware. The host computer caches the firmware to the motherboard's non-volatile memory, and the slave board pulls the version from the motherboard's non-volatile memory. This breaks down a complex interaction involving three parties into two end-to-end interactions, reducing process complexity.

[0075] (3) Add version information to firmware

[0076] To facilitate management, version information is added to the bootload firmware and RTS firmware of the master and slave boards. The information includes firmware version number, firmware type, compilation time, etc.

[0077] (4) Introduce a dual backup mechanism to cache firmware

[0078] To prevent firmware update failures from causing the controller to be unable to run the RTS firmware, a dual backup mechanism is introduced, dividing the non-volatile memory into region 0 and region 1, one of which is the active region and the other is the backup region. The active region is read-only, while the backup region is writable. The active region and the backup region automatically switch based on a specific mechanism.

[0079] (5) Design firmware package format and automatic switching process for dual backup

[0080] To facilitate management, the RTS firmware of the master and slave boards is packaged into a unified RTS firmware package, and integrity verification information is added. Based on the integrity verification information, it is determined whether area 0 and area 1 of the non-volatile memory are active areas or backup areas. The bootloader of the master and slave boards synchronizes the RTS firmware version from the RTS firmware package cached in the non-volatile memory, thereby realizing automatic distribution of RTS firmware between the master and slave boards and ensuring version compatibility.

[0081] (6) Reduce motherboard power-on time

[0082] When the motherboard powers on, it needs to verify the firmware, including integrity verification of the non-volatile memory and on-chip flash. The bottleneck is that the integrity verification of the non-volatile memory is time-consuming due to hardware bandwidth constraints. Therefore, an integrity verification information field is added to the RTS firmware package as a verification success indicator. After the first successful verification after burning the non-volatile memory, the verification indicator is written, eliminating the need for re-verification on each power-on. In addition, to avoid the motherboard bootload waiting for the slave board to synchronize the RTS firmware, which would cause the motherboard power-on timeout, the motherboard only provides the slave board firmware update process in its RTS firmware.

[0083] Example 2

[0084] In this embodiment, the firmware initializes the interrupt vector table and C language runtime environment through assembly code. The starting address of the interrupt vector table is fixed, near the starting address of the assembly code, and the number of interrupt vectors is limited. The content of the interrupt vector table consists of interrupt handling function pointers or null pointers pointing to SRAM or on-chip flash addresses. When adding version identifiers and version information to the end of the interrupt vector table in the firmware source code, the on-chip flash space of the master and slave boards is planned. According to the on-chip flash space planning of the master and slave boards, if the version identifier satisfies the condition of being a non-null pointer and not within the on-chip flash or SRAM address space, the version information can be extracted from the firmware by searching the firmware binary code. The version information includes firmware version number, firmware type, and compilation time. The on-chip flash space planning of the master and slave boards is as follows: Figure 4 As shown.

[0085] The method of adding the version identifier and version information to the end of the firmware interrupt vector table and directly extracting the version information from the compiled firmware binary file is simple, convenient, highly accurate, and universally applicable, and can be implemented on various microcontroller models.

[0086] Taking STMicroelectronics' STM32 series chips as an example, version information can be added to its initialization assembly code, as shown below:

[0087]

[0088]

[0089] like Figure 5 As shown, the process for extracting version information from firmware is as follows:

[0090] S11. Traverse the interrupt vector table;

[0091] S12. Check if a version identifier is present. If yes, extract the version information and end; otherwise, determine if the interrupt handler function pointer is out of range. If yes, execute step S13; otherwise, return to step S11.

[0092] S13. Perform error handling and end.

[0093] Example 3

[0094] In step S2, the RTS packet generator packages the RTS firmware of the master and slave boards into a unified RTS firmware package, such as... Figure 6 As shown, the RTS firmware package consists of three parts: the RTS firmware header, the RTS firmware record, and the RTS firmware itself. The RTS firmware header contains integrity verification information, write-back integrity verification information, download sequence number, RTS firmware package version, number of firmware files in the firmware package, and firmware package length. Each RTS firmware record provides information about an RTS firmware file, including firmware type, firmware version, firmware verification information, firmware length, and the starting address of the firmware in the RTS firmware package. Since non-volatile memory is generally operated on a page basis (256 / 1024 / 2048 bytes), for ease of operation, the RTS firmware package is formed by aligning and linking the RTS firmware header, RTS firmware record, and the compiled RTS firmware binary bin file. The RTS firmware package contains its own integrity verification information, which can be used to verify whether the firmware update was successful.

[0095] In this embodiment, the integrity verification information is obtained by calculating the feature values ​​of other characters in the RTS firmware package, excluding the integrity verification information and the written-back integrity verification information fields, using the MD5 / CRC32 algorithm. However, in specific implementations, it is not limited to the MD5 / CRC32 algorithm. Except for the integrity verification information, the written-back integrity verification information, and the download sequence number, other fields of the RTS firmware package are extracted from the compiled binary bin file.

[0096] The process of determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on integrity verification information is as follows:

[0097] S31. Check if the integrity check information of region 0 / region 1 is all 0xFF. If so, there is no complete RTS firmware package in region 0 / region 1 of the non-volatile memory. Otherwise, proceed to step S32.

[0098] S32. Determine whether the integrity verification information fields of region 0 / region 1 and the integrity verification information written back are equal. If they are equal, a complete RTS firmware package exists in region 0 / region 1 of the non-volatile memory; otherwise, a complete RTS firmware package does not exist in region 0 / region 1 of the non-volatile memory.

[0099] In step S4, the motherboard's bootload firmware is powered on. The criteria for determining whether region 0 and region 1 correspond to the active region or the backup region are as follows:

[0100] If both region 0 and region 1 contain complete RTS firmware packages, then the region that most recently successfully downloaded the RTS firmware package is the active region. The process for determining the region that most recently successfully downloaded the RTS firmware package is as follows: compare the download sequence number fields of the two regions. If the difference is 1, then the region with the larger download sequence number is the active region; if the difference is greater than 1, then the region with the smaller download sequence number is the active region.

[0101] If only one of regions, region 0 and region 1, contains a complete RTS firmware package, then the region containing the complete RTS firmware package is the active region.

[0102] If neither region 0 nor region 1 has RTS firmware, then region 0 is the backup region and region 1 is the active region.

[0103] The process of selecting to enter download mode or run RTS firmware based on the following conditions must be met:

[0104] If neither region 0 nor region 1 has a complete RTS firmware package, then proceed directly to download mode;

[0105] If a complete RTS firmware package exists in either region 0 or region 1, then before jumping to the motherboard RTS firmware execution, it is determined whether to enter download mode: the hardware is designed with a debug I / O port, and the level of the debug I / O port is checked to determine whether to enter download mode or jump to the motherboard RTS firmware execution.

[0106] The integrity verification information, write-back integrity verification information, and download sequence number in the packaged RTS firmware package are all 0xFF. The process of burning the RTS firmware package to the backup area of ​​the motherboard's non-volatile memory via the host computer is as follows:

[0107] S51. Query board information. The motherboard reports the motherboard type and download number. The download number is the active area download number plus 1.

[0108] S52. The host computer replaces the download sequence number field in the RTS firmware package with the download sequence number reported by the motherboard, then calculates the integrity verification information of the RTS firmware package at this time, and replaces the integrity verification information field in the RTS firmware package. At this time, the integrity verification information field written back is still all 0xff.

[0109] S53. The host computer initiates an initialization request for the RTS firmware package, informing the motherboard of the integrity verification information and length of the RTS firmware package;

[0110] S54. The motherboard initiates an RTS firmware package transmission request. The host computer only needs to passively respond to the request, transmit the RTS firmware package to the motherboard and cache it in the non-volatile memory backup area.

[0111] S55. After the transmission is completed, the motherboard verifies the RTS firmware package, calculates the integrity verification information of the RTS firmware package, and compares it with the integrity verification information sent by the host computer during firmware package initialization request. If they are consistent, the integrity verification information is written back to the integrity verification information field address written back to the backup area.

[0112] An integrity verification field is added to the RTS firmware package as a verification success identifier. This identifier is written after the first successful verification following the initial flashing of the non-volatile memory, eliminating the need for re-verification upon each power-on. When the master and slave boards switch to RTS firmware operation, the RTS firmware is synchronized from the active area. The motherboard only provides the slave board firmware update process within its own RTS firmware. The RTS firmware package contains download order information. Combined with the firmware package integrity verification process, the controller only switches to the latest downloaded RTS firmware package upon successful firmware update; otherwise, it continues to run the older RTS firmware package. This improves the controller's stability and reliability, and reduces maintenance costs.

[0113] The embodiments described are merely examples to clearly illustrate the present invention and are not intended to limit the implementation of the invention. 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 describe all possible implementations. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A firmware update method for a controller in a master-slave board design, characterized in that, The method includes the following steps: S1. Add version identifier and version information to the end of the interrupt vector table in the firmware source code, and compile to obtain the bootload firmware and RTS firmware for the master and slave boards. S2. The motherboard expands with a large-capacity non-volatile memory, uses an RTS packet generator to package an RTS firmware package containing all RTS firmware of the master and slave boards, and adds integrity verification information. S3. Introduce a dual backup mechanism, dividing the non-volatile memory into region 0 and region 1, and determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on integrity verification information; S4. Power on the motherboard's bootload firmware, determine whether area 0 and area 1 correspond to the active area or the backup area respectively, and select to enter download mode or run the RTS firmware according to the conditions. When the motherboard's bootloader firmware powers on, the criteria for determining whether region 0 and region 1 correspond to the active or backup region are as follows: If both region 0 and region 1 contain complete RTS firmware packages, then the region that most recently successfully downloaded the RTS firmware package is the active region. The process for determining the region that most recently successfully downloaded the RTS firmware package is as follows: compare the download sequence number fields of the two regions. If the difference is 1, then the region with the larger download sequence number is the active region. If the difference is greater than 1, then the region with the smaller download sequence number is the active region. If only one of regions, region 0 and region 1, contains a complete RTS firmware package, then the region containing the complete RTS firmware package is the active region. If neither region 0 nor region 1 has RTS firmware, then region 0 is the backup region and region 1 is the active region. S5. Download mode: The RTS firmware package is burned to the backup area of ​​the non-volatile memory on the motherboard via the host computer, and then the system is reset and executed to S4. The process of burning the RTS firmware package to the backup area of ​​the motherboard's non-volatile memory via a host computer is as follows: S51. Query board information. The motherboard reports the motherboard type and download serial number. The download serial number is the active zone download serial number plus 1. S52. The host computer replaces the download sequence number field in the RTS firmware package with the download sequence number reported by the motherboard, then calculates the integrity verification information of the RTS firmware package at this time, and replaces the integrity verification information field in the RTS firmware package. At this time, the integrity verification information field written back is still all 0xff. S53. The host computer initiates an initialization request for the RTS firmware package, informing the motherboard of the integrity verification information and length of the RTS firmware package; S54. The motherboard initiates an RTS firmware package transmission request. The host computer only needs to passively respond to the request, transmit the RTS firmware package to the motherboard and cache it in the non-volatile memory backup area. S55. After the transmission is completed, the motherboard verifies the RTS firmware package, calculates the integrity verification information of the RTS firmware package, and compares it with the integrity verification information sent by the host computer during firmware package initialization request. If they match, the integrity verification information is written back to the integrity verification information field address written back to the backup area. S6. The motherboard runs RTS firmware, synchronizes the motherboard RTS firmware from the motherboard RTS firmware package stored in the active area of ​​non-volatile memory, and runs it. S7. Power on the bootload firmware of the slave board, initiate the slave board RTS firmware initialization request, the motherboard returns the slave board RTS firmware initialization information, and the slave board pulls the RTS firmware from the motherboard according to the initialization information; S8. The motherboard transmits the slave board's RTS firmware, the slave board verifies the RTS firmware, and after the slave board's RTS firmware verification is successful, it jumps to run the RTS firmware.

2. The firmware update method for the controller under the master-slave board design according to claim 1, characterized in that, The firmware initializes the interrupt vector table and C language runtime environment through assembly code. The starting address of the interrupt vector table is fixed, near the starting address of the assembly code, and the number of interrupt vectors is limited. The contents of the interrupt vector table are pointers to interrupt handling functions or null pointers pointing to SRAM or on-chip flash addresses. When adding version identifiers and version information to the end of the interrupt vector table in the firmware source code, the on-chip flash space of the master and slave boards is planned. According to the on-chip flash space planning of the master and slave boards, if the version identifier satisfies the condition of being a non-null pointer and not within the on-chip flash or SRAM address space, the version information can be extracted from the firmware by searching the firmware binary code. The version information includes firmware version number, firmware type, and compilation time.

3. The firmware update method for the controller under the master-slave board design according to claim 2, characterized in that, The process for extracting version information from firmware is as follows: S11. Traverse the interrupt vector table; S12. Check if a version identifier is present. If so, extract the version information and end; otherwise, determine if the interrupt handler function pointer is out of range. If so, execute step S13. Otherwise, return to step S11; S13. Perform error handling and end.

4. The firmware update method for the controller under the master-slave board design according to claim 1, characterized in that, In step S2, the RTS packet generator packages the RTS firmware of the master and slave boards into a unified RTS firmware package. The RTS firmware package includes three parts: RTS firmware packet header, RTS firmware record, and RTS firmware. The RTS firmware packet header contains integrity verification information, write-back integrity verification information, download sequence number, RTS firmware package version, number of firmware in the firmware package, and firmware package length. Each RTS firmware record provides information about an RTS firmware, including firmware type, firmware version, firmware verification information, firmware length, and the starting address of the firmware in the RTS firmware package. The RTS firmware package is formed by aligning and linking the RTS firmware packet header, RTS firmware record, and the compiled RTS firmware binary bin file.

5. The firmware update method for the controller under the master-slave board design according to claim 4, characterized in that, The integrity verification information is obtained by calculating the feature values ​​of other characters in the RTS firmware package, excluding the integrity verification information and the written-back integrity verification information fields, using the MD5 / CRC32 algorithm. The other fields of the RTS firmware package, excluding the integrity verification information, the written-back integrity verification information, and the download sequence number, are extracted from the compiled binary bin file.

6. The firmware update method for the controller under the master-slave board design according to claim 5, characterized in that, In step S3, the process of determining whether a complete RTS firmware package exists in region 0 and region 1 of the non-volatile memory based on the integrity verification information is as follows: S31. Check if the integrity check information of region 0 / region 1 is all 0xFF. If so, there is no complete RTS firmware package in region 0 / region 1 of the non-volatile memory. Otherwise, proceed to step S32. S32. Determine whether the integrity verification information fields of region 0 / region 1 and the integrity verification information written back are equal. If they are equal, a complete RTS firmware package exists in region 0 / region 1 of the non-volatile memory; otherwise, a complete RTS firmware package does not exist in region 0 / region 1 of the non-volatile memory.

7. The firmware update method for the controller under the master-slave board design according to claim 6, characterized in that, The process of selecting to enter download mode or run RTS firmware based on the following conditions must be met: If neither region 0 nor region 1 has a complete RTS firmware package, then proceed directly to download mode; If a complete RTS firmware package exists in either region 0 or region 1, then before jumping to the motherboard RTS firmware execution, it is determined whether to enter download mode: the hardware is designed with a debug I / O port, and the level of the debug I / O port is checked to determine whether to enter download mode or jump to the motherboard RTS firmware execution.

8. The firmware update method for the controller under the master-slave board design according to claim 7, characterized in that, The integrity verification information, write-back integrity verification information, and download sequence number in the packaged RTS firmware are all 0xFF.

9. The firmware update method for the controller under the master-slave board design according to claim 1, characterized in that, Add a write-back integrity verification information field to the RTS firmware package as a verification success identifier. Write the verification identifier after the first successful verification after burning to non-volatile memory, so that there is no need to re-verify every time you power on. When the master and slave boards switch to RTS firmware, the RTS firmware is synchronized from the active area. The motherboard only provides the slave board firmware update process in its RTS firmware.

Images