Firmware device for controlling a system and method of booting
Patent Information
- Application Number
- CN202210098124.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-01-27
- Publication Date
- 2026-09-15
- Estimated Expiration
- 2042-01-27
AI Technical Summary
依此方式,对于拥有上百个组态之产品的制造商而言,将导致上百份固件档案在烧录和维护时的复杂度增加
[0023] The beneficial effects of this invention are as follows: Since the firmware architecture is configured with the boot signature detection module, the basic function module, and the burning module, the control system can effectively detect whether the firmware file in the firmware architecture is complete and undamaged (that is, whether the previous firmware file burning process was successfully completed) by executing the boot signature detection module before the boot program. Even if the firmware file is detected to be incomplete, the updated or backed-up firmware file can be overwritten to the memory module to complete the boot program through the execution of the basic function module and the burning module. In addition, the mechanism of identifying the firmware program parts containing specific signature codes in the main blocks through the customized firmware confirmation module in the boot block can effectively reduce the complexity of firmware maintenance.
Smart Images

Figure CN116561753B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a firmware architecture, and more particularly to a firmware architecture for a control system. Background Technology
[0002] A microcontroller is a miniature computer system that integrates a central processing unit, memory, timer (counter), and various input / output interfaces onto a single chip. The biggest advantage of a microcontroller is its small size yet rich functionality, allowing it to perform exceptionally well in various applications such as computers, home appliances, industry, medical, and aerospace.
[0003] When a microcontroller is operating, it continuously executes firmware instructions (specifically, the software responsible for controlling hardware behavior) stored in flash memory to perform related operations. When the firmware needs to be updated or upgraded due to factors such as added features, design changes, or bug fixes, the corresponding new firmware file (e.g., a binary file represented by ".bin") can be written to flash memory using software tools. This "writing" operation or process is called flashing. However, during firmware flashing, the flashing process can often be interrupted due to factors such as software tool failure, power outages, or human error. As a result, the microcontroller may fail to operate normally because it has executed incomplete firmware, or in severe cases, it may not be able to boot up or perform a re-flashing operation, causing great inconvenience to the user.
[0004] Furthermore, for products requiring customized firmware functionality or those with multiple firmware configurations, manufacturers typically create multiple corresponding firmware files for different customization needs, and then burn each firmware file into the corresponding customized product. Taking A-series and B-series computer products containing the same microcontroller as an example, the configuration of the microcontroller's general-purpose input / output (GPIO) in the A-series computer product is called IO_A, while the configuration of the GPIO in the B-series computer product is called IO_B. Typically, during firmware development, two different firmware files, such as ForIO_A.bin and ForIO_B.bin, need to be created, and the corresponding firmware file needs to be burned into each computer product before shipment. This approach increases the complexity of burning and maintaining hundreds of firmware files for manufacturers with hundreds of configurations.
[0005] Therefore, how to solve the problems of microcontrollers failing to power on and / or failing to re-flash firmware, as well as how to reduce the complexity of firmware maintenance, has become one of the issues that related technical fields want to address. Summary of the Invention
[0006] The purpose of this invention is to provide a firmware architecture that overcomes at least one of the disadvantages of the prior art.
[0007] The firmware architecture provided by the present invention is applicable to a control system and is stored in a memory module of the control system, which includes at least a boot block and a main block, and includes a firmware file, a boot signature detection module, a basic function module and a burning module.
[0008] The firmware file is stored in the main block.
[0009] The power-on signature detection module is stored in the power-on block and is executed by the control system in a power-on program to detect whether a predetermined power-on signature code exists in the main block.
[0010] The basic functional modules are stored in the boot block and can be executed by the control system after detecting that the predetermined boot signature code does not exist in the main block during the boot program, so that the control system can at least perform power management and pin initialization during the boot program.
[0011] The burning module is stored in the boot block and can be executed by the control system when a burning request is received in the boot program, so that the control system responds to the burning request by overwriting an updated firmware file or a backup firmware file containing the predetermined boot signature code into the main block as the firmware file.
[0012] In some implementations, the updated firmware file and the backup firmware file each contain the predetermined boot signature code at the end of their contents.
[0013] In some implementations, the burning request includes the updated firmware file, and the control system overwrites the updated firmware file as the firmware file into the main block when executing the burning module.
[0014] In some implementations, the memory module is configured with a file block located at a specific memory address and storing the backup firmware file. The burning request includes the specific memory address. When the control system executes the burning module, it reads the backup firmware file stored in the file block according to the specific memory address and overwrites the backup firmware file into the main block as the firmware file.
[0015] In some implementations, the firmware architecture further includes a customized firmware verification module stored in the boot block. The firmware file contains multiple firmware program sections, each containing a unique signature code at its beginning. When the control system successfully executes the boot procedure and receives an input code, the customized firmware verification module can be executed by the control system to identify a firmware program section containing the same unique signature code as the input code from the firmware program sections, as the target firmware program section to be executed subsequently.
[0016] Another object of the present invention is to provide a power-on method that overcomes at least one of the disadvantages of the prior art.
[0017] The present invention provides a power-on method applicable to a control system and implemented by a processor included in the control system. The control system further includes a memory module storing at least a power-on signature detection module, a basic function module, a programming module, and a firmware file. The power-on method includes the following steps: (A) detecting, via the execution of the power-on signature detection module, whether a predetermined power-on signature code exists at the end of the content of the firmware file; (B) when the predetermined power-on signature code is detected at the end of the content of the firmware file, performing power management and pin initialization of the control system via the execution of the basic function module; and (C) upon receiving a programming request, in response to the programming request, overwriting an updated firmware file or a backup firmware file containing the predetermined power-on signature code as the firmware file to the memory module via the execution of the programming module.
[0018] In some embodiments, the power-on method further includes the following steps after step (C): (D) repeating step (A); and (F) when the processor detects in step (D) that the firmware file does not have the predetermined power-on signature code, repeating steps (B), (C), and (A) in sequence until the processor detects that the firmware file has the predetermined power-on signature code.
[0019] In some implementations, in step (C), the updated firmware file and the backup firmware file each contain the predetermined boot signature code at the end of their contents.
[0020] In some implementations, in step (C), the burning request includes the updated firmware file, and the processor overwrites the updated firmware file as the firmware file to the memory module.
[0021] In some embodiments, the memory module is configured with a file block located at a specific memory address and storing the backup firmware file. In step (C), the burning request includes the specific memory address, and the processor reads the backup firmware file stored in the file block according to the specific memory address, and overwrites the backup firmware file as the firmware file to the memory module.
[0022] In some embodiments, the memory module further stores a customized firmware verification module. The firmware file contains multiple firmware program sections, and each firmware program section contains a unique signature code at its beginning. The boot method, after step (F), further includes the following step: (G) Upon receiving an input code, the customized firmware verification module executes to identify a firmware program section containing the same unique signature code as the input code from the firmware program sections, as the target firmware program section to be executed subsequently.
[0023] The beneficial effects of this invention are as follows: Since the firmware architecture is configured with the boot signature detection module, the basic function module, and the burning module, the control system can effectively detect whether the firmware file in the firmware architecture is complete and undamaged (that is, whether the previous firmware file burning process was successfully completed) by executing the boot signature detection module before the boot program. Even if the firmware file is detected to be incomplete, the updated or backed-up firmware file can be overwritten to the memory module to complete the boot program through the execution of the basic function module and the burning module. In addition, the mechanism of identifying the firmware program parts containing specific signature codes in the main blocks through the customized firmware confirmation module in the boot block can effectively reduce the complexity of firmware maintenance. Attached Figure Description
[0024] Other features and effects of the present invention will be clearly presented in the embodiments with reference to the accompanying drawings, wherein: Figure 1 It is a block diagram that exemplarily illustrates a configuration of a control system, which includes the firmware architecture of the first embodiment of the present invention; Figure 2 This is a schematic diagram, exemplarily illustrating how the firmware architecture of the first embodiment is configured in a firmware block of a memory module of the control system; Figure 3 This is a schematic diagram illustrating, by way of example, the composition of a firmware file in the described embodiment; Figure 4 This is a schematic diagram illustrating, by way of example, the contents of a backup firmware file stored in the memory module; Figure 5 It is a flowchart, explaining Figure 2 How a processor of the control system executes a power-on method according to the first embodiment of the present invention; Figure 6 It is a block diagram, exemplarily illustrating another configuration of the control system, which includes the firmware architecture of the second embodiment of the present invention; Figure 7 This is a schematic diagram illustrating, by way of example, the configuration of the firmware architecture described in the second embodiment; Figure 8 It is a flowchart, explaining Figure 6 How a processor of the control system executes a power-on method according to a second embodiment of the present invention; and Figure 9 This is a schematic diagram illustrating, by way of example, the contents of an updated firmware file received by the control system. Detailed Implementation
[0025] Before the invention is described in detail, it should be noted that similar elements are represented by the same numbers in the following description.
[0026] Figure 1 An exemplary control system 100 is illustrated, which may include, for example, an input module 30 and a microprocessor unit 10 electrically connected to the input module 30. The microprocessor unit 10 may be implemented as a single-chip microcontroller and may include a processor 1 and a memory module 2 electrically connected to the processor 1. In this embodiment, the memory module 2 may be configured with a firmware block 22 and a file block 21, wherein the firmware block 22 is, for example, constructed of an erasable read-only memory (such as flash memory) and stores a firmware architecture according to an embodiment of the present invention, and the file block 21 is, for example, constructed of read-only memory (ROM) and stores a backup firmware file required by the control system 100 in a specific memory location therein. However, in other embodiments, the memory module 2 may also be implemented as an external memory module (not shown) independent of the microprocessor unit 10 but electrically connected to the processor 1, or only the file block 21 may be implemented in another memory independent of the microprocessor unit 10 (not shown). It should be noted that, as Figure 4 As shown, the backup firmware file contains a predetermined boot signature code (e.g., a specific code with a fixed length) at the end of its content. The input module 30 may include, for example, a mouse, keyboard, or any user input device.
[0027] See Figure 2In this embodiment, the firmware block 22 includes a boot block 221 and a main block 222, and the firmware architecture includes, for example, a boot signature detection module, a basic function module, a burning module and a customized firmware confirmation module stored in the boot block 221, and a firmware file stored in the main block 222.
[0028] The power-on signature detection module can be executed by the processor 1 to detect the predetermined power-on signature code.
[0029] The basic functional modules can be executed by the processor 1, at least performing power management and pin initialization as described in the microprocessor unit 10, to ensure that the microprocessor unit 10 can provide normal operation of the standardized system.
[0030] The programming module can be executed by the processor 1 to perform the relevant programming work.
[0031] The custom firmware verification module can be executed by the processor 1 to verify the custom firmware, particularly when the control system 100 can be used to control multiple different models or types of custom electronic products, to verify the custom firmware of each custom electronic product.
[0032] In this embodiment, the firmware file in the main block 222, after successful burning, typically includes multiple firmware program sections and a predetermined boot signature code located at each end. Each firmware program section contains a unique signature code at its beginning. For example, such as... Figure 3 As shown, the firmware file includes, for example, (but not limited to) firmware program portion #1, firmware program portion #2, firmware program portion #3, and firmware program portion #4, as well as the predetermined boot signature code. Firmware program portion #1 contains a specific signature code #1, firmware program portion #2 contains a specific signature code #2, firmware program portion #3 contains a specific signature code #3, and firmware program portion #4 contains a specific signature code #4. Note that the backup firmware file stored in the file block 21, in addition to containing the predetermined boot signature code, also contains the aforementioned firmware program portions (…). Figure 4 (Not shown).
[0033] See below. Figure 1 , Figure 2 and Figure 5This document details how the processor 1, in conjunction with the firmware architecture's boot signature detection module, basic function module, burning module, and customized firmware confirmation module, executes the boot method of the first embodiment of the present invention. The boot method includes the following steps S51-S56, which constitute the boot program of the control system 100.
[0034] In step S51, the processor 1, through the execution of the boot signature detection module, detects whether the predetermined boot signature code exists at the end of the content of the firmware file currently stored in the main block 222. If the detection result is positive, it means that the firmware file has been successfully burned and completely stored in the main block 222, and the process proceeds to step S55. Conversely, if the detection result is negative, it means that the previous burning process did not completely store the firmware file (such as...) Figure 3 As shown, the firmware file was successfully burned into the main block 222, so that the firmware file did not have the predetermined boot signature code. Therefore, the process will proceed to step S52.
[0035] When the processor 1 detects that the firmware file does not contain the predetermined boot signature code at the end, in step S52, the processor 1 performs at least the following functions via the execution of the basic functional module: power management and pin initialization of the microprocessor unit 10, to ensure that the microprocessor unit 10 can provide normal operation of the standardized system.
[0036] Then, in step S53, the processor 1 checks whether it has received a programming request from the input module 30. If the processor 1 confirms that it has received the programming request from the input module 30, the process proceeds to step S54. In this embodiment, the programming request includes the specific memory address. Conversely, if the processor 1 has not received any programming request from the input module 30, the process continues to step S53 (until the processor 1 receives a programming request).
[0037] In step S54, after receiving the burning request from the input module 30, the processor 1, through the execution of the burning module, reads the backup firmware file stored in the file block 21 according to the specific memory address contained in the burning request, and overwrites the backup firmware file as the firmware file to the main block 222 of the firmware block 22 of the memory module 2 (see...). Figure 2 ).
[0038] To ensure that the processor 1 has successfully performed the burning process in step S54, the process will return to step S51 so that the processor 1 can repeat step S51. When the detection result of the processor 1 in step S51 is negative (i.e., the firmware file does not have the predetermined boot signature code), the processor 1 will repeat steps S52, S53, and S54 in sequence until the processor 1 (in step S51) detects that the firmware file has the predetermined boot signature code, thereby ensuring that the firmware file stored in the main block 222 is a complete firmware file.
[0039] When the processor 1 confirms that the firmware file contains the predetermined boot signature code, after receiving an input code generated, for example, by manually operating the input module 30 (step S55), the processor 1 then, in step S56, through the execution of the customized firmware confirmation module, confirms a firmware program section containing the specific signature code identical to the input code from firmware program sections #1 to #4 as the target firmware program section to be executed subsequently (boot program completion). For example, if the control system 100 is used to control a specific customized electronic product, and the target firmware program section corresponding to the specific customized electronic product is, for example, firmware program section #2, in this case, after receiving an input code identical to the specific signature code #2 in step S55, the processor 1 confirms the firmware program section #2 from the firmware file based on the input code in step S56 for subsequent execution.
[0040] See Figure 6 An exemplary control system 100' is illustrated, which is generally similar in configuration to Figure 1 The control system 100. The control system 100' differs from the control system 100 in that: a microprocessor unit 10' includes a memory module 2' which is only configured to store the firmware block 22 for storing the firmware architecture of the second embodiment of the present invention. Furthermore, in this embodiment, as... Figure 7 As shown, the firmware architecture includes only the boot signature detection module, the basic function module, and the burning module stored in the boot block 221, and a firmware file stored in the main block 222. Note that in this embodiment, the firmware file, after successful burning, typically includes the predetermined boot signature code at its end.
[0041] See below. Figure 6 , Figure 7 and Figure 8This document details how the processor 1, in conjunction with the boot signature detection module, the basic function module, and the burning module of the firmware architecture, executes the boot method of the second embodiment of the present invention. The boot method includes the following steps S81-S84, which constitute the boot program of the control system 100'.
[0042] First, in step S81, similar to Figure 5 In step S51, the processor 1, through the execution of the boot signature detection module, detects whether the predetermined boot signature code exists at the end of the content of the firmware file currently stored in the main block 222. If the detection result is positive, the boot process is completed; otherwise, the process proceeds to step S82.
[0043] In step S82, similar to Figure 5 In step S52, the processor 1 performs power management and pin initialization of the microprocessor unit 10' via the execution of the basic function module to provide normal operation of the standardized system.
[0044] Then, in step S83, the processor 1 confirms whether it has received a burning request from the input module 30. If the processor 1 confirms that it has received the burning request from the input module 30, the process proceeds to step S84. In this embodiment, since the control system 100' cannot provide any backup firmware files, the system maintainer can manually operate the input module 30 to cause the input module 30 to generate the burning request based on a desired update firmware file from an external source (e.g., the cloud, USB flash drive, or other storage device) (i.e., the burning request includes the update firmware file). Conversely, if the processor 1 does not receive any burning request from the input module 30, the process continues to step S83 (until the processor 1 receives a burning request).
[0045] In step S84, the processor 1, via the execution of the burning module, overwrites the updated firmware file contained in the burning request as the firmware file to the main block 222 of the firmware block 22 of the memory module 2' (see...). Figure 7 ).
[0046] Similarly, to ensure that the processor 1 has successfully performed a burning process in step S84, the process will return to step S81 so that the processor 1 can repeat step S81. When the detection result of the processor 1 in step S81 is negative (i.e., the firmware file does not have the predetermined boot signature code), the processor 1 will repeat steps S82, S83, and S84 in sequence until the processor 1 (in step S81) detects that the firmware file has the predetermined boot signature code, thereby ensuring that the firmware file stored in the main block 222 is a complete firmware file. Thus, the boot process is completed.
[0047] In summary, since the firmware architecture is configured with the boot signature detection module, the basic function module, and the burning module, the control system 100, 100' can effectively detect whether the firmware file in the firmware architecture is complete and undamaged (that is, whether the previous firmware file burning process was successfully completed) by executing the boot signature detection module before the boot process. Even if the firmware file is detected to be incomplete due to the absence of the predetermined boot signature code, the updated or backed-up firmware file can be overwritten to the main block 222 of the memory module 2, 2' to complete the boot process through the execution of the basic function module and the burning module. Furthermore, the mechanism of identifying the firmware program portions containing the specific signature code in the main block 222 through the customized firmware verification module in the boot block 221 can effectively reduce the complexity of firmware maintenance for multiple different models or types of customized electronic products. Therefore, the firmware architecture and boot method based on the firmware architecture of the present invention can indeed achieve the purpose of the present invention.
[0048] The above description is merely a preferred embodiment of the present invention and should not be construed as limiting the scope of the present invention. Any simple equivalent changes and modifications made in accordance with the claims and description of the present invention shall still fall within the scope of the present invention.
Claims
1. A firmware device, suitable for a control system and stored in a memory module comprising at least a Boot Block and a Main Block, characterized in that, And includes: A firmware file is stored in the main block; A boot signature detection module is stored in the boot block and is executed by the control system in a boot program to detect whether there is a predetermined boot signature code at the end of the firmware file in the main block, so as to determine whether the firmware file is complete. A basic functional module, stored in the boot block, can be executed by the control system after detecting in the boot process that the predetermined boot signature code is missing in the main block due to incomplete firmware file, so that the control system can at least perform power management and pin initialization during the boot process; and A burning module is stored in the boot block and can be executed by the control system when a burning request is received in the boot program, so that the control system responds to the burning request by overwriting an updated firmware file or a backup firmware file containing the predetermined boot signature code into the main block as the firmware file. The updated firmware file and the backup firmware file each contain the predetermined boot signature code at the end of their contents.
2. The firmware device according to claim 1, characterized in that, The burning request includes the updated firmware file, and the control system overwrites the updated firmware file as the firmware file into the main block when executing the burning module.
3. The firmware device according to claim 1, characterized in that, The memory module is planned to have a file block located at a specific memory address and storing the backup firmware file. The burning request includes the specific memory address, and when the control system executes the burning module, it reads the backup firmware file stored in the file block according to the specific memory address and overwrites the backup firmware file as the firmware file into the main block.
4. The firmware device according to claim 1, characterized in that, It also includes a customized firmware verification module stored in the boot block: The firmware file contains multiple firmware program parts, and each firmware program part contains a unique signature code at the beginning of the firmware program part. and After the control system successfully executes the boot procedure and receives an input code, the customized firmware verification module can be executed by the control system so that the control system can identify a firmware program part containing the same specific signature code as the input code from the firmware program part as the target firmware program part to be executed subsequently.
5. A power-on method, applicable to a control system and implemented by a processor included in the control system, the control system further comprising a memory module storing at least a power-on signature detection module, a basic function module, a programming module, and a firmware file, characterized in that, The power-on method includes the following steps: (A) By executing the boot signature detection module, the system detects whether there is a predetermined boot signature code at the end of the firmware file content, so as to determine whether the firmware file is complete. (B) When it is detected that the firmware file is incomplete because the predetermined boot signature code is not present at the end of the content, the power management and pin initialization of the control system are performed through the execution of the basic function module. (C) Upon receiving a burning request, the burning module executes the burning request to overwrite the memory module with an updated firmware file or a backup firmware file containing the predetermined boot signature code. (D) Repeat step (A); and (F) When the processor detects in step (D) that the firmware file does not have the predetermined boot signature code, steps (B), (C), and (A) are executed sequentially until the processor detects that the firmware file has the predetermined boot signature code.
6. The power-on method according to claim 5, characterized in that, In step (C), the updated firmware file and the backup firmware file each contain the predetermined boot signature code at the end of their contents.
7. The power-on method according to claim 6, characterized in that, In step (C), the burning request includes the updated firmware file, and the processor overwrites the updated firmware file as the firmware file to the memory module.
8. The power-on method according to claim 6, characterized in that, The memory module is planned to have a file block located at a specific memory address and storing the backup firmware file. In step (C), the burning request includes the specific memory address, and the processor reads the backup firmware file stored in the file block according to the specific memory address, and overwrites the backup firmware file as the firmware file to the memory module.
9. The power-on method according to claim 5, characterized in that, The memory module also stores a customized firmware verification module. The firmware file contains multiple firmware program sections, and each firmware program section has a unique signature code at its beginning. After step (F), the following steps are also included: (G) Upon receiving an input code, the customized firmware verification module executes the input code to identify a firmware program portion containing the same specific signature code as the input code from the firmware program portion as the target firmware program portion to be executed subsequently.
Citation Information
Patent Citations
Using system BIOS to update embedded controller firmware
US20040030877A1
Similar boot time for multiple displays
US20210326149A1
Method, apparatus, and computer-readable medium for storing data associated with a firmware program
US8661425B1