Firmware upgrading method, electronic equipment, storage medium and program product

Abstract

The invention discloses a firmware upgrading method, electronic equipment, a storage medium and a program product, and relates to the technical field of computers, the firmware upgrading method comprises the following steps: receiving a firmware upgrading file submitted by a user through an uploading control based on a first page provided by a built-in server, caching the firmware upgrading file, and sending the cached firmware upgrading file to a server; according to the embodiment of the invention, the to-be-upgraded state is identified by updating the firmware upgrading parameter in the controller, and the upgrading operation on the target firmware is completed based on the cached firmware upgrading file. The method can effectively avoid the problems of complex system architecture and lengthy upgrade link caused by the need of relying on a special communication module and a cloud server for firmware transfer in the prior art, solves the technical problem of low firmware upgrade efficiency caused by the dependence of external components and complex interaction, and achieves the purposes that the communication module and cloud transfer do not need to be additionally configured, and the upgrade efficiency is high. The system architecture is greatly simplified, the hardware cost is reduced, and the technical effects of firmware upgrading operation efficiency and deployment convenience are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a firmware upgrade method, electronic device, storage medium, and program product. Background Technology

[0002] As the core control unit of various smart devices, the Microcontroller Unit (MCU) requires firmware upgrades to improve the reliability of MCU operation in order to optimize the functions and fix vulnerabilities of the devices in which the MCU is deployed.

[0003] In related technologies, over-the-air (OTA) firmware upgrades are typically used. This involves configuring a dedicated communication module for the MCU and relying on a cloud server to relay and write the firmware upgrade file, thus completing the MCU firmware upgrade. However, the complexity of firmware upgrades via external components such as communication modules and cloud servers is high, resulting in low efficiency. Summary of the Invention

[0004] This application provides a firmware upgrade method, electronic device, storage medium, and program product to at least solve the problem of low efficiency in firmware upgrades in related technologies.

[0005] This application provides a firmware upgrade method, including:

[0006] The first page is displayed, which includes the firmware upgrade file and upload controls for firmware upgrades.

[0007] In response to a click on the upload control, the firmware upgrade file is cached;

[0008] Update the firmware upgrade parameters in the controller. The firmware upgrade parameters are used to indicate whether to upgrade the target firmware in the controller that corresponds to the firmware upgrade file.

[0009] The target firmware is upgraded based on the cached firmware upgrade file, and information related to the upgrade of the target firmware is displayed on the first page.

[0010] This application also provides a firmware upgrade device, including: a display module, a cache module, an update module, and an upgrade module, wherein,

[0011] The display module is used to display the first page, which includes the firmware upgrade file and upload control for firmware upgrade.

[0012] The caching module is used to cache firmware upgrade files in response to click operations on the upload control;

[0013] The update module is used to update the firmware upgrade parameters in the controller. The firmware upgrade parameters are used to indicate whether to upgrade the target firmware in the controller that corresponds to the firmware upgrade file.

[0014] The upgrade module is used to upgrade the target firmware based on the cached firmware upgrade file and display information related to the upgrade of the target firmware on the first page.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above firmware upgrade methods.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described firmware upgrade methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described firmware upgrade methods.

[0018] The firmware upgrade method, electronic device, storage medium, and program product provided in this application can receive firmware upgrade files submitted by users through an upload control based on a first page provided by a built-in server. After caching the firmware upgrade files, the upgrade status is identified by updating the firmware upgrade parameters in the controller, and the upgrade operation of the target firmware is completed based on the cached firmware upgrade files. Therefore, it can effectively avoid the problems of complex system architecture and lengthy upgrade links caused by relying on dedicated communication modules and cloud servers for firmware relay in related technologies. It solves the technical problem of low firmware upgrade efficiency caused by external component dependence and complex interaction. It achieves the technical effect of significantly improving the efficiency of firmware upgrade operation and the ease of deployment while greatly simplifying the system architecture and reducing hardware costs without the need for additional configuration of communication modules and cloud relay. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application;

[0021] Figure 2A flowchart illustrating a firmware upgrade method provided in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the system architecture of the microcontroller unit provided in the embodiments of this application;

[0023] Figure 4 A schematic diagram illustrating the display of a first page as provided in an embodiment of this application;

[0024] Figure 5 A schematic diagram of the hardware architecture for the microcontroller network function provided in the embodiments of this application;

[0025] Figure 6 This is a schematic diagram of the structure of a firmware upgrade device provided in an embodiment of this application;

[0026] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, other embodiments obtained by those of ordinary skill in the art without creative effort are all within the protection scope of this application.

[0028] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] In related technologies, over-the-air (OTA) firmware upgrades are typically used. This involves configuring a dedicated communication module for the MCU and relying on a cloud server to relay and write the firmware upgrade file, thus completing the MCU firmware upgrade. However, the complexity of firmware upgrades via external components such as communication modules and cloud servers is high, resulting in low efficiency.

[0030] To address the aforementioned issues, in this embodiment, when a firmware upgrade is required, a first page is displayed, including a firmware upgrade file and an upload control. In response to a click on the upload control, the firmware upgrade file is cached. Firmware upgrade parameters in the controller are updated, indicating whether to upgrade the target firmware corresponding to the firmware upgrade file in the controller. Based on the cached firmware upgrade file, the target firmware is upgraded, and information related to the target firmware upgrade is displayed on the first page. This allows for direct reception and processing of firmware upgrade files via a built-in web server, enabling independent completion of the entire process from file caching and upgrade parameter settings to firmware upgrade. File transfer and writing can be completed locally on the device for firmware upgrade requirements, eliminating the need for external communication modules and cloud intermediaries. This achieves device-side internalization of the firmware upgrade function and autonomous operation, significantly reducing system complexity and hardware costs while effectively improving the efficiency and reliability of firmware upgrades.

[0031] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] This section describes the specific application environment architecture or hardware architecture upon which the firmware upgrade method depends. (References) Figure 1 , Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application. Please refer to [link / reference]. Figure 1 This includes electronic devices and terminal devices. Electronic devices can be any device with on-device computing capabilities, such as servers and terminal devices. Terminal devices can be devices with web browsers, such as mobile phones, tablets, and laptops. Electronic devices contain an MCU (Microcontroller Unit). Users can access a page related to MCU firmware upgrades provided by the electronic device through the terminal device, and perform firmware upgrades through this page, thus completing the firmware upgrade.

[0033] Figure 2 This is a flowchart illustrating a firmware upgrade method provided in an embodiment of this application, as shown below. Figure 2 As shown, embodiments of this application provide a firmware upgrade method, which is described in detail below:

[0034] S201, Display the first page.

[0035] The execution subject of this application embodiment can be an electronic device or a firmware upgrade device installed in the electronic device. The firmware upgrade device can be implemented by software or by a combination of software and hardware.

[0036] The first page includes firmware upgrade files and upload controls for firmware upgrades.

[0037] The first page is a visual web page interface generated and sent to the user's browser by a web server integrated in the MCU main program. In other words, the first page can be a web page, so users can access the web page through a standard browser without installing any special software.

[0038] In some embodiments, the electronic device can create web services, such as the httpd component in the lwIP protocol stack, through a lightweight Hypertext Transfer Protocol (HTTP) server library in the main application of the MCU to provide firmware upgrade functionality. The HTTP server library is used to implement HTTP rules and receive and process browser requests.

[0039] The created web service interacts with the user through an HTML page (the first page), which contains a file upload form configured with... <input type="file"> This type of upload control receives the firmware file selected by the user and directs the form submission to a specific server endpoint, such as / firmware / upload. To ensure efficient operation of this functionality in resource-constrained embedded environments, the complete HTML code is converted into a binary array in C language form using compile-time tools during development and directly embedded into the MCU's firmware. This forms a complete built-in web service solution that can independently provide a standard web-based human-machine interface without relying on external storage or file systems.

[0040] The firmware upgrade file can be a program file used to update the old firmware of the MCU. In some embodiments, the user can load or copy the firmware upgrade file to the local device so that the firmware upgrade file can be selected and uploaded to the form on the first page.

[0041] The upload control can be a component on the first page; for example, the upload control can be a component in HTML.<inputtype="file"> Button. Users can click the upload control to trigger a file selection dialog box, where they can select a firmware upgrade file from their local device and upload it to the MCU.

[0042] In some embodiments, the first page includes multiple interactive components, specifically including: an upload area that triggers file selection, a file selection box, a selection button, a restart device button, a refresh status button, a progress bar component and progress text, a log information container, and an update flag status display.

[0043] After the first page loads, the electronic device can obtain the Document Object Model (DOM) of the first page, i.e., DOM elements. When the user clicks on the file upload area, a click event is actually triggered on the hidden file selection input box, thus popping up the file selection window. After the user selects the firmware upgrade file through the file selection box, the selected file name can be obtained and the log area can display the prompt message "Selected file: [file name]", ensuring that the user is clearly aware of the currently selected file.

[0044] When a user confirms the file selection and clicks the upload button, the electronic device needs to verify whether the user has selected a file. If no file has been selected, an error message will be displayed in the log area; if a file has been selected, the file type and size will be verified to ensure that only firmware upgrade files that meet the requirements are allowed to be uploaded.

[0045] S202. In response to a click on the upload control, cache the firmware upgrade file.

[0046] In some embodiments, after the user clicks the upload control on the first page, the electronic device receives the firmware upgrade file selected by the user for upload. Since the old firmware inside the MCU may be running, the firmware upgrade file needs to be cached first.

[0047] In some embodiments, the electronic device may cache the firmware upgrade file in response to a click operation on the upload control by: obtaining user permissions; and caching the firmware upgrade file in response to a click operation on the upload control when the user's permissions indicate that the user has permission to upgrade the controller's firmware.

[0048] User permissions can be defined as the user's permission to perform firmware upgrades on the MCU; that is, user permissions can be defined as different access levels for different users.

[0049] In some embodiments, to ensure system security and prevent unauthorized operations, the electronic device first performs user permission verification before responding to an upload operation. Specifically, the system obtains the permission information of the currently logged-in user and determines whether the permission includes permission to upgrade the controller's firmware. Only when the user has the corresponding permission will the system continue to perform subsequent file receiving and caching operations; otherwise, a permission error message is returned to the client and the process is terminated. By introducing a permission control mechanism, the problem of system failure caused by accidental operation or upgrade is effectively avoided.

[0050] For example, electronic devices can integrate multi-level user access control (e.g., role-based access control) into web pages, enabling operations such as caching firmware files uploaded by users with the required permissions. Specifically, by embedding a role-based access control mechanism in the web server, users are divided into roles such as administrators and regular users, and differentiated permissions are assigned to different roles. For instance, administrators can perform sensitive operations such as firmware uploads and log viewing, while regular users can only view device status. This technique, through permission isolation, prevents unauthorized users from making mistakes or launching attacks, significantly improving system security and controllability.

[0051] In some embodiments, the electronic device may process the firmware upgrade file before caching it by: verifying the type and integrity of the firmware upgrade file and obtaining the verification result; and caching the firmware upgrade file when the verification result is successful.

[0052] In some embodiments, the electronic device performs a verification process on the firmware upgrade file before caching it. This verification process specifically includes: type verification to confirm that the firmware upgrade file's format conforms to expectations; and integrity verification to verify that the data in the firmware upgrade file has not been corrupted or damaged during transmission. The electronic device calculates a checksum of the firmware upgrade file (e.g., a checksum or CRC checksum) and compares it with the expected value to obtain the verification result. If the verification result is successful, the firmware upgrade file is cached; if the verification fails, an error message is returned to the user. This mechanism ensures that only complete and correct firmware files can enter the upgrade process, preventing upgrade failures due to file errors from the outset.

[0053] For example, when verifying the file type of the firmware upgrade file, the file extension is checked to ensure that the uploaded file is in a specific format supported by the embedded system, such as a firmware upgrade file in the .bin or .hex format. When verifying the file size of the firmware upgrade file, the file size is compared with a preset capacity threshold to ensure that it does not exceed the upper limit of the storage space allocated to the firmware cache area. For example, if the capacity threshold is 256KB, the file size of the firmware upgrade file is checked to see if it is less than 256KB.

[0054] The subsequent file upload and caching operations will only begin if the firmware upgrade file passes both type and size checks simultaneously. If either check fails, the operation will immediately terminate and a clear error message will be returned to the user. By implementing a dual-check mechanism, invalid files with incompatible formats or exceeding size limits can be effectively intercepted, preventing upgrade process anomalies caused by file mismatches from the source, and significantly improving the robustness and success rate of the firmware upgrade process.

[0055] In some embodiments, the electronic device may verify the firmware upgrade file based on the following implementation: the firmware upgrade file includes multiple data packets; for the i-th data packet; the type and integrity of the i-th data packet are verified; after the verification result of the i-th data packet is passed, the type and integrity of the (i+1)-th data packet are verified; i takes the values ​​1, 2, ..., N-1 in sequence, where N is the number of data packets.

[0056] In some embodiments, the electronic device verifies the firmware upgrade file by adopting a packet-by-packet reception and packet-by-packet verification strategy. Specifically, for the first received data packet, the electronic device verifies the file type and data packet size of the data packet. If it is determined that both meet the requirements, the electronic device verifies the file type and data packet size of the second data packet, and so on, until the file type and data packet size of the Nth data packet are verified. If the verification result meets the requirements, the firmware upgrade file is cached.

[0057] In some embodiments, the electronic device receives and verifies firmware data via a firmware upload processing endpoint (e.g., / firmware / upload) on its web server. When a user submits a form containing a firmware upgrade file, the corresponding processing function is invoked, employing a packet-by-packet reception and verification mechanism: each data packet of the firmware upgrade file is received sequentially, and the accumulated checksum (e.g., checksum value) is updated in memory in real time after each data packet is received, thereby performing the verification calculation. After all data packets have been received, the final calculated memory verification result is compared with the expected checksum preset in the firmware file or calculated independently. This verification mechanism, by synchronously performing verification calculations during transmission, avoids secondary traversal of received data to save computational resources and ensures that only after rigorous verification of file integrity can the complete firmware data be written to the designated firmware cache by calling the MCU's underlying Flash programming interface. This achieves efficient and reliable data verification and storage in resource-constrained embedded environments.

[0058] In some embodiments, the electronic device may cache the firmware upgrade file when the verification result is successful, based on the following implementation: when the verification result is successful, determine the memory occupied by the firmware upgrade file; determine the remaining storage space used to cache the firmware upgrade file; if the remaining storage space is greater than or equal to the occupied memory, cache the firmware upgrade file; if the remaining storage space is less than the occupied memory, clear the historical upgrade files in the storage space and cache the firmware upgrade file.

[0059] The memory usage can be the file size of the firmware upgrade file; for example, the firmware upgrade file size is 256KB.

[0060] Historical upgrade files can be cached firmware upgrade files from a historical period.

[0061] After verifying the type and size of the firmware upgrade file, the electronic device can determine the file size of the firmware upgrade file based on the verification result. It then determines the size of the buffer area in the MCU used to cache the firmware upgrade file, checks the remaining storage space in the buffer area, and decides whether it can store the received firmware upgrade file. If the remaining storage space is greater than or equal to the occupied memory, it indicates that the current buffer area can store the received firmware upgrade file, and it can be cached directly, or previously cached firmware upgrade files can be cleared. If the remaining storage space is less than the occupied memory, it indicates that the current buffer area cannot store the received firmware upgrade file. Previously cached upgrade files need to be cleared, the storage space in the current buffer area needs to be released, and the newly received firmware upgrade file needs to be cached.

[0062] S203. Update the firmware upgrade parameters in the controller.

[0063] Among them, the firmware upgrade parameter is used to indicate whether to upgrade the target firmware in the controller that corresponds to the firmware upgrade file.

[0064] In some embodiments, after caching the firmware upgrade file, the electronic device can modify the firmware upgrade parameters in a specific area of ​​the controller to indicate that the old firmware in the controller needs to be upgraded. For example, the firmware upgrade parameter can be updated to the hexadecimal value 0xAA to indicate that there is a cached firmware upgrade file and the old firmware of the MCU needs to be upgraded. When no upgrade is triggered, the firmware upgrade parameter can be the hexadecimal value 0x00.

[0065] S204. Based on the cached firmware upgrade file, upgrade the target firmware and display information related to the target firmware upgrade on the first page.

[0066] In some embodiments, the electronic device may upgrade the target firmware based on a cached firmware upgrade file in the following manner: restarting the controller; after determining that the controller has restarted, reading the firmware upgrade parameters; when the firmware upgrade parameters indicate that the target firmware corresponding to the firmware upgrade file in the controller should be upgraded, obtaining the cached firmware upgrade file; and overwriting the target firmware with the cached firmware upgrade file.

[0067] Restarting the controller can be used to restart the MCU. In some embodiments, to ensure that the upgrade operation is not interfered with by the currently running target firmware, the electronic device can be restarted by the user manually turning the power off and on, by the MCU restart triggered by the watchdog timer, or by a soft restart triggered by the web server after updating the firmware upgrade parameters. This is used to release the space occupied by the old firmware of the MCU and avoid the situation where the new firmware cannot be written and the upgrade cannot be performed during operation.

[0068] In some embodiments, after determining that the MCU has restarted, after initializing the current hardware, it is necessary to read the firmware upgrade parameters of a specific area to determine whether the user has initiated an upgrade request, that is, whether the current firmware upgrade parameters have been updated to a specific value, such as the hexadecimal value 0xAA. In this way, the electronic device can upgrade the old firmware of the MCU. If the current firmware upgrade parameters have not been updated, such as the hexadecimal value 0x00, the old firmware will continue to run normally.

[0069] In some embodiments, after confirming the need for a firmware upgrade, a specific firmware update operation is performed. This operation mainly includes two steps: obtaining the cached firmware upgrade file, i.e., reading the complete new firmware data from a firmware cache area dedicated to temporary storage; and overwriting the target firmware with the cached firmware upgrade file, i.e., writing the new firmware data to the application area where the device's main program is stored through erasure (i.e., clearing old firmware data to avoid mixing old and new data) and programming operations, thereby completing the firmware replacement. The core advantage of this "read from the cache area, write to the application area" overwrite mechanism lies in its security and reliability. Throughout the entire file upload and verification phase, the currently running main program remains unmodified and in a stable state, minimizing the risk of the device becoming unusable due to unexpected interruptions during the upgrade process.

[0070] In some embodiments, the electronic device may overwrite the target firmware with a cached firmware upgrade file by copying the cached firmware upgrade file and then overwriting the target firmware with the copied firmware upgrade file to upgrade the target firmware.

[0071] The cached firmware upgrade file can be a new version of firmware uploaded and temporarily stored via a web server.

[0072] The target firmware can be an older version of firmware that needs to be replaced and is currently running.

[0073] In some embodiments, the electronic device can perform a copy operation on the new firmware upgrade file cached in the firmware cache area, read the firmware data into the processing unit, and write the copied firmware data into the storage area where the target firmware is located. This copy-and-overwrite method replaces the old firmware version, thereby achieving a firmware upgrade. This process ensures that the new firmware can completely and accurately replace the original firmware content in the target area.

[0074] In some embodiments, the electronic device may, after overwriting the target firmware with the copied firmware upgrade file, further include: reading the overwritten firmware upgrade file; performing an integrity check on the overwritten firmware upgrade file and the cached firmware upgrade file to obtain a check result; clearing the cached firmware upgrade file when the check result indicates that the file overwriting is complete; and clearing the overwritten firmware upgrade file and re-copying the cached firmware upgrade file when the check result indicates that the file overwriting is incomplete.

[0075] The overwritten firmware upgrade file can contain new firmware data that has already been written to the target firmware area.

[0076] Integrity verification can be used to verify whether data remains intact during transmission and storage using specific algorithms (such as CRC check).

[0077] In some embodiments, after the firmware overwrite operation is completed, the electronic device can read the overwritten firmware file data from the target area and compare it with the original cached firmware upgrade file for integrity verification. When the verification result indicates that the file overwrite is complete, the original file in the cache is cleared to free up storage space; when the verification result indicates that the file overwrite is incomplete, the potentially corrupted firmware file in the target area is immediately cleared, and the copy process from the cache to the target area is re-executed. This verification retry mechanism constitutes a complete fault-tolerant processing closed loop, effectively ensuring the reliability of the firmware overwrite process and preventing upgrade failures due to transmission or write errors.

[0078] In some embodiments, during and after the upgrade process, the electronic device can display upgrade-related information to the user on a first page. For example, during firmware overwrite, a progress bar can be used to display the current upgrade progress in real time; after a successful or failed upgrade, a clear result prompt can be displayed. This information provides the user with clear operational feedback, making the entire upgrade process transparent and controllable.

[0079] Below, in conjunction with Figure 3 The system architecture of the MCU is explained through specific examples.

[0080] Figure 3For a schematic diagram of the system architecture of the microcontroller unit provided in the embodiments of this application, please refer to [link / reference]. Figure 3 The internal Flash memory of the MCU includes the Bootloader program area, application program area, firmware cache area, and flag bit storage area.

[0081] The Bootloader program area starts at address 0x0800 0000 and is 32KB in size. This area stores the MCU system's startup code and the core logic for firmware updates. It is the first program to run after the device powers on. The Bootloader program area initializes the basic hardware, checks the update status, and determines whether to perform a firmware update or jump to the main application based on the check results. The independence and stability of the code in this area are fundamental to ensuring reliable system startup and upgrades.

[0082] In some embodiments, the Bootloader program area serves as the core component for system startup, and its implementation process begins with the initialization of basic hardware in the main function. After initialization, the Bootloader first reads the update flag in the flag storage area to determine its status: if the flag is detected to be in the "update required" state, the firmware update process is initiated, copying the complete firmware data temporarily stored in the firmware cache to the APP program area. To ensure the accuracy of data transmission, CRC checks are performed before and after the copy operation to guarantee the integrity of the firmware data. After confirming the successful completion of the copy operation, the Bootloader immediately clears the update flag to ensure the system can start normally subsequently. Finally, it uses a function pointer jump to locate the reset interrupt vector address in the APP program area and executes the new main application, completing the seamless connection between system startup and firmware update.

[0083] The application area starts at address 0x0800 8000 and has a size of 256KB. This area stores the device's main application, which implements all the device's core business functions. Furthermore, the lightweight web server in this solution is also integrated within this application, enabling the device to respond to network requests and provide a web-based interactive interface for firmware upgrades. This area is the target area that needs to be updated during firmware upgrades.

[0084] The firmware cache starts at address 0x0804 8000 and has a size of 256KB. This area serves as temporary storage space for storing firmware upgrade files uploaded via the web page. Throughout the entire process of receiving and verifying firmware upgrade files, it ensures that the currently running application code is not modified or corrupted, thereby minimizing the impact of the upgrade process on system stability.

[0085] The flag storage area uses the last page of Flash, starting at address 0x080F000. One byte is stored at a fixed offset address on this page as the firmware update flag (i.e., firmware upgrade parameter). This area can store system status flags, which are used to transmit signals between the application area (APP program area) and the bootloader program area to indicate whether an upgrade is needed.

[0086] Optionally, electronic devices can introduce a dynamic Flash partition management mechanism. By dynamically adjusting the Flash partition size to adapt to the storage requirements of different firmware versions, this effectively solves the problem of wasted or insufficient storage space that may be caused by a fixed partitioning strategy. Specifically, by integrating a dynamic partitioning algorithm into the Bootloader program area, the Flash storage space allocation scheme can be intelligently adjusted before performing a firmware upgrade by parsing the metadata of the firmware upgrade file (e.g., size information in the file header). In practice, the optimal partition layout is dynamically calculated based on the actual size of the firmware, and the internal partition mapping table and Bootloader configuration parameters are updated, thereby achieving flexible configuration of the APP program area and firmware cache area sizes.

[0087] For example, when a small firmware upgrade file is detected (e.g., 128KB), the electronic device can reduce the firmware cache from 256KB accordingly, while expanding the freed-up storage space for the application area, thereby significantly improving storage resource utilization. When a large firmware upgrade file is detected (e.g., close to 256KB), the firmware cache capacity is maintained or expanded to ensure sufficient buffer space during the upgrade process. This dynamic partitioning strategy not only effectively avoids upgrade failures due to insufficient cache, but also lays a solid foundation for seamless upgrades and fast rollback by supporting the simultaneous storage of multiple firmware versions. This improves Flash storage efficiency while further enhancing the reliability and flexibility of system upgrades.

[0088] exist Figure 2In the illustrated embodiment, when a firmware upgrade is required, a first page is displayed, including a firmware upgrade file and an upload control. In response to a click on the upload control, the firmware upgrade file is cached. Firmware upgrade parameters in the controller are updated, indicating whether to upgrade the target firmware corresponding to the firmware upgrade file. Based on the cached firmware upgrade file, the target firmware is upgraded, and information related to the target firmware upgrade is displayed on the first page. This allows for direct reception and processing of firmware upgrade files via a built-in web server, enabling independent completion of the entire process from file caching and upgrade parameter settings to the final firmware upgrade. File transfer and writing can be completed locally on the device for firmware upgrade requirements, eliminating the need for external communication modules and cloud intermediaries. This achieves device-side internalization of the firmware upgrade function and autonomous operation, significantly reducing system complexity and hardware costs while effectively improving the efficiency and reliability of firmware upgrades.

[0089] Based on any of the above embodiments, the method by which an electronic device displays information related to the upgrade of the target firmware on a first page will be described in detail.

[0090] Figure 4 This is a schematic diagram illustrating the display of a first page according to an embodiment of this application. Please refer to [link / reference]. Figure 4 ,include:

[0091] S401, Obtain the upgrade progress of the target firmware.

[0092] Upgrade progress indicates the degree of completion of the firmware upgrade process, and is usually expressed as a percentage. Specifically, upgrade progress can include the progress of firmware upgrade file upload, firmware upgrade file verification, and firmware upgrade file upgrade process.

[0093] In some embodiments, the electronic device can obtain real-time upgrade progress by monitoring key nodes in the firmware upgrade process. For example, during the firmware upgrade file upload phase, the electronic device can calculate the upload progress based on the ratio of the number of received data packets to the total number of data packets; during the firmware upgrade file write cache phase, the electronic device can calculate the write progress based on the ratio of the amount of programmed data to the total firmware size. This progress information provides the data basis for subsequent status display.

[0094] S402. Update the upgrade status of the target firmware based on the upgrade progress.

[0095] The upgrade status is used to indicate the corresponding upgrade steps in the upgrade process of the target firmware. For example, the upgrade status can be a status identifier for different stages in the upgrade process, used to describe the specific operation steps currently being performed. For example, the upgrade status can be file verification in progress, preparing for upgrade, upgrade complete, etc.

[0096] In some embodiments, electronic devices can establish a mapping relationship between upgrade progress and upgrade status. That is, when the progress is in different intervals, corresponding status text is displayed. For example, 0%-30% progress corresponds to "File Uploading," 30%-50% corresponds to "Verifying Files," 50%-70% corresponds to "Erase Old Firmware," 70%-90% corresponds to "Write New Firmware," and 90%-100% corresponds to "Upgrade Complete." This phased status indication allows users to clearly understand the specific steps of the upgrade process.

[0097] In some embodiments, electronic devices can provide users with intuitive feedback on the upload process through UI elements such as a progress bar on the first page. This feedback can include file verification, upload progress, and final completion status. Throughout the process, the progress bar can be updated in real time to display status and text descriptions, and key operation records can be added to the log container to provide users with complete operation visualization and status viewing.

[0098] For example, an electronic device provides users with a complete visual feedback of the firmware upgrade process through its web interface. When the user triggers the firmware upload, it enters the verification phase, displaying a progress bar and status text indicating "Verifying files". After successful verification, the progress updates to 10%, and the message "Verification successful, starting upload" is displayed.

[0099] During the firmware upgrade file upload phase, a progressive progress update mechanism is used to demonstrate the file transfer process. By periodically incrementing the progress percentage and refreshing the progress bar in real time, when the progress reaches 100%, the upgrade status can be set to "Upload Complete," and the process of simulating firmware writing to Flash memory begins, while simultaneously logging the operation "Writing to Flash Memory."

[0100] Once the firmware update is ready, the page displays the status changes of "Firmware successfully written to free Flash address" and "Update flag set," and finally prompts the user to "Please restart the device to complete the update." During the firmware upgrade phase after the device restarts, the upgrade process is displayed through an upgrade progress bar, showing a real-time "Updating" status. After the upgrade is complete, automatic cleanup is triggered, including clearing the update flag and completing the jump to the new application (i.e., the firmware upgrade file). This complete visual process ensures that the user is fully aware of the upgrade process and guides the user to perform necessary operations through clear status prompts, significantly improving the transparency of the firmware upgrade process and the user experience.

[0101] S403: The upgrade progress and upgrade status are displayed on the first page.

[0102] In some embodiments, the electronic device pushes the obtained upgrade progress and status information to the client browser in real time via a web server. Display methods include, but are not limited to: progress bar animation, percentage display, status text prompts, and color-changing indicators. For example, a dynamically growing progress bar combined with the text prompt "Writing new firmware (75%)" provides the user with intuitive visual feedback.

[0103] In some embodiments, the electronic device may, after displaying information related to the upgrade of the target firmware on the first page, further include: resetting the firmware upgrade parameters after the target firmware upgrade is completed; monitoring the operating status of the target firmware on the controller; determining that the target firmware upgrade is successful when the operating status is normal; and restoring the upgraded target firmware to the target firmware before the upgrade when the operating status is abnormal.

[0104] Among them, the firmware upgrade parameters after reset are used to indicate that the target firmware in the controller should not be upgraded.

[0105] In some embodiments, after the electronic device completes the firmware upgrade, the firmware upgrade parameters also need to be reset: when the target firmware upgrade is complete, the bootloader will reset the firmware upgrade parameters, that is, clear the update flag. This ensures that the upgrade process will not be erroneously repeated on the next system startup, avoiding the occurrence of upgrade loops.

[0106] The running status is either running normally or running abnormally, which indicates the health status of the target firmware after the upgrade.

[0107] "Running normally" indicates that the upgraded target firmware can start stably and perform functions.

[0108] Operational errors are used to indicate that there are defects in the target firmware after the upgrade, such as boot failure, hardware errors, etc.

[0109] In some embodiments, after an electronic device completes a firmware upgrade and jumps to the new firmware, it initiates a continuous status monitoring mechanism. The operational status can be determined in various ways: using a watchdog timer to monitor for system deadlocks or crashes; using a heartbeat mechanism to check the survival of core processes; monitoring system resource usage (e.g., memory leaks, stack overflows); and checking hardware error flags. This monitoring process typically continues throughout the first operating cycle after the upgrade, ensuring a comprehensive assessment of the stability of the new firmware.

[0110] In some embodiments, when the electronic device monitoring controller maintains normal operation for a preset period of time (e.g., 24 hours) without triggering any abnormal monitoring conditions, the electronic device can confirm that the firmware upgrade was successful.

[0111] In some embodiments, electronic devices can utilize a status monitoring and rollback mechanism, which involves continuously monitoring the operational status of the new firmware after an upgrade. This is achieved through methods such as a watchdog timer or heartbeat detection to determine if the new firmware is functioning correctly. Otherwise, an automatic rollback operation is triggered, restoring the device to the stable version before the upgrade. This security mechanism provides additional protection for the upgrade process, effectively preventing system bricking due to firmware defects.

[0112] This allows for continuous monitoring of the new firmware's operational status after the upgrade is complete. Based on the monitoring results, it intelligently determines whether the upgrade was successful and automatically triggers the firmware restoration mechanism to revert to the stable version before the upgrade when an operational anomaly is detected. Therefore, it effectively solves the problem of devices becoming bricked due to the lack of a post-upgrade verification mechanism in firmware upgrade solutions. It overcomes the technical defects caused by firmware flaws, such as the inability to self-recover and the need for manual intervention in maintenance. It achieves closed-loop management and security protection of the firmware upgrade process, significantly reducing device maintenance costs while ensuring upgrade reliability, and significantly improving the success rate and fault tolerance of embedded system firmware updates.

[0113] Through the aforementioned complete display and processing mechanism, this solution achieves full-process management from visual monitoring of the upgrade process to post-upgrade security assurance, significantly improving system reliability and user experience.

[0114] exist Figure 4In the illustrated embodiment, since the upgrade progress can be acquired and displayed in real time during the firmware upgrade process, the corresponding upgrade step status can be dynamically updated based on the progress information, and the progress and status information can be displayed synchronously on the first page, and the firmware upgrade parameters can be automatically reset to cancel the upgrade indication status after the upgrade is completed, the technical problems of opaque upgrade process and inability of users to perceive real-time progress and operation steps caused by the lack of visual feedback in traditional upgrade solutions are effectively solved. It achieves the technical effect of providing complete upgrade process feedback through hierarchical status prompts and progress visualization, improving user operation experience and system observability, while avoiding repeated upgrades through the automatic parameter reset mechanism, and ensuring stable system operation.

[0115] Below, in conjunction with Figure 5 The hardware architecture of microcontroller network functions is explained through specific examples.

[0116] Figure 5 For a schematic diagram of the hardware architecture of the microcontroller network function provided in the embodiments of this application, please refer to [link / reference]. Figure 5 The core processor uses a GD32F470 microcontroller, which integrates an Ethernet MAC module and runs the FreeRTOS real-time operating system and LWIP protocol stack. The physical layer interface PHY is a DP83848CVV, which establishes a data connection with the MCU via an RMII interface. The network interface includes an RJ45 connector with an integrated transformer, which connects to the PHY via MDI differential signal lines. The architecture also includes an SPI Flash memory module, which is internally divided into four logical areas to store the Bootloader program, the main application program, the newly upgraded firmware, and update flags.

[0117] Below, based on Figure 5 The firmware upgrade process is explained below:

[0118] Firmware Upload and Verification: Users access the firmware upgrade page provided by the MCU's built-in web server through a browser on a remote client. In the firmware upgrade window, they select a new firmware file (firmware upgrade file) and trigger the upload operation (upload control). After receiving the firmware file data packet, the web server verifies data integrity through a checksum verification. If verification fails, an error message is returned to the client; if verification succeeds, the complete firmware data is written to the firmware cache area of ​​the MCU Flash, and an update flag (firmware upgrade parameter) is set in the flag storage area, marking the existence of firmware to be updated, thus completing the upgrade preparation stage.

[0119] Firmware Update and Reboot: After the MCU system reboots, the Bootloader program runs. The Bootloader checks the status of the flag storage area. If the flag (firmware upgrade parameters) is not set, it directly jumps to the APP program area to execute the main application. If the flag (firmware upgrade parameters) is set, it reads the new firmware data (firmware upgrade file) from the firmware cache area, copies it to the APP program area to overwrite the old program, and completes the firmware upgrade operation. After the upgrade is complete, the Bootloader clears the flag (resetting the firmware upgrade parameters) to ensure normal startup next time. Finally, it jumps to the new APP program area starting address and runs the updated main application, completing the entire upgrade process.

[0120] Based on the above process, this solution provides a web-based MCU remote upgrade method and system. It integrates a lightweight web server directly into the MCU's firmware, allowing users to access the device and upgrade its firmware via any standard web browser. No specialized tools or applications are required, simplifying the upgrade process, improving convenience and reliability, and effectively reducing system costs and the risk of device bricking. Specifically, a lightweight web service can be developed and integrated onto the MCU platform, with a firmware upload function within the web service. This bypasses cloud server intermediaries, enabling direct firmware transfer between the browser and the MCU. This transforms firmware upgrades from a tool-dependent, professional operation into a one-click browser upgrade, providing a universal upgrade infrastructure for IoT devices.

[0121] In this way, on the one hand, by integrating a lightweight web server into the MCU firmware, users can easily complete the entire firmware upgrade process using only a general web browser, without needing to install special software or use special tools. On the other hand, the architecture design that separates the bootloader and application programs places the core upgrade logic in an independent bootloader area, ensuring that the upgrade process can still proceed even if the application area is corrupted, significantly reducing the risk of device bricking. Simultaneously, a firmware verification mechanism ensures the integrity of data transmission. Furthermore, it can fully utilize the device's existing network connectivity and internal storage resources, eliminating the need for additional dedicated communication modules or complex cloud systems, effectively saving hardware and development costs. Moreover, this solution has good versatility and is applicable to various MCU platforms that support network connectivity and have Flash partitioning capabilities, including but not limited to mainstream models such as STM32, ESP32, and GD32, demonstrating broad applicability.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0123] Figure 6 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. Figure 6 As shown, embodiments of this application also provide a firmware upgrade device 60, including: a display module 61, a cache module 62, an update module 63, and an upgrade module 64, wherein,

[0124] Display module 61 is used to display a first page, which includes a firmware upgrade file and an upload control for firmware upgrade.

[0125] The caching module 62 is used to cache firmware upgrade files in response to a click operation on the upload control;

[0126] Update module 63 is used to update the firmware upgrade parameters in the controller. The firmware upgrade parameters are used to indicate whether to upgrade the target firmware in the controller that corresponds to the firmware upgrade file.

[0127] Upgrade module 64 is used to upgrade the target firmware based on the cached firmware upgrade file and display information related to the upgrade of the target firmware on the first page.

[0128] For a description of the features in the embodiment corresponding to the firmware upgrade device, please refer to the relevant description in the embodiment corresponding to the firmware upgrade method, which will not be repeated here.

[0129] In one possible implementation, the cache module 62 is specifically used for:

[0130] Obtain user permissions;

[0131] When the user's permissions indicate that the user has permission to upgrade the controller's firmware, the firmware upgrade file is cached in response to a click on the upload control.

[0132] In one possible implementation, the device includes a verification module, which is specifically used for:

[0133] The type and integrity of the firmware upgrade file are verified, and the verification results are obtained.

[0134] If the verification result is successful, the firmware upgrade file is cached.

[0135] In one possible implementation, the cache module 62 is further configured to:

[0136] If the verification result is successful, determine the memory usage of the firmware upgrade file;

[0137] Determine the remaining storage space available for firmware upgrade files;

[0138] If the remaining storage space is greater than or equal to the occupied memory, cache the firmware upgrade file.

[0139] If the remaining storage space is less than the occupied memory, clear the historical upgrade files in the storage space and cache the firmware upgrade files.

[0140] In one possible implementation, upgrade module 64 is specifically used for:

[0141] Restart the controller;

[0142] After confirming the controller restart, read the firmware upgrade parameters;

[0143] When the firmware upgrade parameters indicate that the target firmware corresponding to the firmware upgrade file should be upgraded in the controller, the cached firmware upgrade file is retrieved.

[0144] Overwrite the target firmware with the cached firmware upgrade file.

[0145] In one possible implementation, the upgrade module 64 is further configured to:

[0146] Copy the cached firmware upgrade file;

[0147] The copied firmware upgrade file is used to overwrite the target firmware in order to upgrade the target firmware.

[0148] In one possible implementation, the apparatus further includes a processing module, which is specifically used for:

[0149] Read the overwritten firmware upgrade file;

[0150] Perform integrity verification on the overwritten firmware upgrade file and the cached firmware upgrade file, and obtain the verification result;

[0151] If the verification result indicates that the file is completely overwritten, clear the cached firmware upgrade files;

[0152] If the verification result indicates that the file overwrite is incomplete, clear the overwritten firmware upgrade file and re-copy the cached firmware upgrade file.

[0153] In one possible implementation, the upgrade module 64 is further configured to:

[0154] Get the upgrade progress of the target firmware;

[0155] Based on the upgrade progress, update the upgrade status of the target firmware. The upgrade status is used to indicate the corresponding upgrade steps of the target firmware at each upgrade progress stage.

[0156] The upgrade progress and status are displayed on the first page.

[0157] In one possible implementation, the device further includes a reset module, which is specifically used for:

[0158] After the target firmware upgrade is completed, the firmware upgrade parameters are reset. The reset firmware upgrade parameters are used to indicate that the target firmware in the controller will not be upgraded.

[0159] Monitor the operating status of the target firmware of the controller, which is either normal or abnormal.

[0160] If the running status is normal, the target firmware upgrade is confirmed to be successful;

[0161] When the running status is abnormal, the upgraded target firmware will be restored to obtain the target firmware before the upgrade.

[0162] For a description of the features in the embodiment corresponding to the firmware upgrade device, please refer to the relevant description in the embodiment corresponding to the firmware upgrade method, which will not be repeated here.

[0163] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 71 and a memory 72. Optionally, the electronic device 70 further includes a communication component 73. The processor 71, memory 72, and communication component 73 are connected via a bus.

[0164] In a specific implementation, at least one processor 71 executes computer execution instructions stored in memory 72, causing at least one processor 71 to execute the firmware upgrade method embodiment described above.

[0165] The specific implementation process of processor 71 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0166] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0167] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0168] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0169] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the firmware upgrade method embodiments described above when running.

[0170] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0171] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

[0172] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

[0173] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for specific applications, but such implementations should not be considered beyond the scope of this application.

[0174] The firmware upgrade method provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A firmware upgrade method, characterized in that, include: Display a first page, which includes a firmware upgrade file and an upload control for firmware upgrades; In response to a click operation on the upload control, the firmware upgrade file is cached; The firmware upgrade parameters in the controller are updated. These firmware upgrade parameters are used to indicate whether to upgrade the target firmware in the controller that corresponds to the firmware upgrade file. Based on the cached firmware upgrade file, the target firmware is upgraded, and information related to the upgrade of the target firmware is displayed on the first page.

2. The method according to claim 1, characterized in that, In response to a click operation on the upload control, the firmware upgrade file is cached, including: Obtain user permissions; When the user's permissions indicate that the user has permission to upgrade the firmware of the controller, the firmware upgrade file is cached in response to the click operation of the upload control.

3. The method according to claim 1, characterized in that, Before caching the firmware upgrade file, the method further includes: The type and integrity of the firmware upgrade file are verified, and the verification result is obtained. When the verification result is successful, the firmware upgrade file is cached.

4. The method according to claim 3, characterized in that, When the verification result is successful, the firmware upgrade file is cached, including: When the verification result is successful, the memory occupied by the firmware upgrade file is determined. Determine the remaining storage space to cache the firmware upgrade file; If the remaining storage space is greater than or equal to the occupied memory, the firmware upgrade file is cached. If the remaining storage space is less than the occupied memory, clear the historical upgrade files in the storage space and cache the firmware upgrade files.

5. The method according to claim 1, characterized in that, Based on the cached firmware upgrade file, the target firmware is upgraded, including: Restart the controller; After confirming that the controller has restarted, read the firmware upgrade parameters; When the firmware upgrade parameters indicate that the target firmware corresponding to the firmware upgrade file in the controller should be upgraded, the cached firmware upgrade file is obtained. The cached firmware upgrade file is used to overwrite the target firmware.

6. The method according to claim 5, characterized in that, Overwrite the target firmware with the cached firmware upgrade file, including: Copy the cached firmware upgrade file; The copied firmware upgrade file is used to overwrite the target firmware in order to upgrade the target firmware.

7. The method according to claim 6, characterized in that, After overwriting the target firmware with the copied firmware upgrade file, the method further includes: Read the overwritten firmware upgrade file; The integrity of the overwritten firmware upgrade file and the cached firmware upgrade file is verified to obtain the verification result. When the verification result indicates that the file is completely overwritten, clear the cached firmware upgrade file; If the verification result indicates that the file overwrite is incomplete, the overwritten firmware upgrade file is cleared, and the cached firmware upgrade file is copied again.

8. The method according to claim 1, characterized in that, The first page displays information related to the upgrade of the target firmware, including: Obtain the upgrade progress of the target firmware; Based on the upgrade progress, update the upgrade status of the target firmware, whereby the upgrade status indicates the corresponding upgrade step for the target firmware at the upgrade progress stage. The upgrade progress and upgrade status are displayed on the first page.

9. The method according to claim 8, characterized in that, After the first page displays information related to the upgrade of the target firmware, the method further includes: After the target firmware upgrade is completed, the firmware upgrade parameters are reset. The reset firmware upgrade parameters are used to indicate that the target firmware in the controller will not be upgraded. Monitor the operating status of the target firmware of the controller, wherein the operating status is normal operation or abnormal operation; When the operating status is normal, it is determined that the target firmware upgrade was successful; When the running status is abnormal, the upgraded target firmware is restored to obtain the target firmware before the upgrade.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the firmware upgrade method as described in any one of claims 1 to 9 when executing the computer program.

Images