Terminal firmware upgrading method based on mobile communication module
By setting multiple flash areas in the energy metering terminal MCU and using UDP connections to communicate with the cloud server, the terminal firmware's breakpoint resuming and rollback functions are realized, which solves the problem of excessive terminal energy consumption and lack of rollback functions in the existing technology. problems, improving the stability and upgrade efficiency of the terminal.
Patent Information
- Application Number
- CN202411609480.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-12
- Publication Date
- 2025-01-24
AI Technical Summary
The existing technology cannot achieve breakpoint continuous transmission during the terminal firmware upgrade process, resulting in excessive terminal energy consumption and network congestion, and lack of rollback function, resulting in firmware defects that cannot be resolved in time.
By setting four flash areas, Boot area, APP area, APP_BAK area and USER_DATA area in the terminal MCU, and using UDP connection to communicate with the cloud server, the terminal actively sends upgrade requests and designated frame download requests to achieve breakpoint resume and Rollback function.
It realizes the resumable download of terminal firmware, reduces terminal energy consumption and network congestion, and provides a rollback function to ensure that the terminal will not become bricked under any circumstances, saving manpower, material and financial resources.
Smart Images

Figure CN119364342A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of wireless communications, and in particular relates to a terminal firmware upgrading method based on a mobile communication module. Background Art
[0002] With the development of the Internet of Things and wireless communication technologies, energy metering terminals such as smart water meters make extensive use of battery-powered low-power technologies, and external communications make extensive use of wireless communication technologies such as NB, 4G, and 5G. In order to meet the new demands constantly put forward by users and allow users to have a good user experience, the installed energy metering terminals are constantly facing the need for wireless remote firmware upgrades (FOTA: Firmware Over-The-Air).
[0003] For battery-powered energy metering terminals, energy saving is the first issue to be considered. Currently, when the terminal is upgraded through the platforms of telecom operators such as OneNet, OC, AEP, etc., the entire upgrade file needs to be transmitted each time the upgrade is performed, and breakpoint resumption cannot be achieved. For terminal upgrades at installation locations with poor wireless signals and poor communications, the probability of transmitting the entire upgrade file in one upgrade is low. If the entire upgrade file is repeatedly transmitted multiple times, a large amount of electric energy will be wasted. The present invention realizes breakpoint resumption upgrade of the terminal, which can greatly reduce terminal battery energy consumption.
[0004] Energy metering terminals such as water meters are often large in number and widespread. Although the time they connect to the cloud server is discrete, a large number of terminals may still be upgraded at the same time, which is a severe test for the processing capacity of the cloud server. The terminal of the present invention uses UDP connection with the cloud server. The upgrade process is completely dominated by the terminal. The cloud server only sends a response frame according to the requirements of the terminal, which greatly reduces the load of the cloud server and enables it to serve a large number of terminal upgrades.
[0005] For upgraded terminals, if there is no rollback function, when the running new firmware has defects and cannot connect to the cloud server, its upgrade again often requires on-site processing by after-sales personnel, which consumes a lot of manpower and material resources. The present invention realizes the rollback function of terminal firmware, so that the terminal device will not become a brick under any circumstances. The problem of defects in the new firmware can be easily solved by remote upgrading again, thereby saving a lot of manpower, material and financial resources.
[0006] Application number: 202411166926.8; Invention name: Terminal firmware upgrade method, system, device and medium based on communication module; The system includes a communication module, a terminal MCU and a cloud platform, and the method includes: the communication module determines whether to upgrade the terminal firmware according to the upgrade instruction sent by the cloud platform, and if it is upgraded, obtains the firmware upgrade file in the cloud platform according to the preset upgrade protocol, and sends the firmware upgrade prompt information to the terminal MCU, wherein the firmware upgrade prompt information includes the summary information of the firmware upgrade file; the terminal MCU receives the firmware upgrade prompt information, determines whether to upgrade the terminal firmware according to the summary information, and if it is upgraded, sends the preset upgrade instruction to the communication module to read the firmware upgrade file and upgrade the terminal firmware.
[0007] The above patent upgrade process is dominated by the cloud platform, and the cloud server needs to serve a large number of terminal upgrades; the cloud server is under heavy load, and the terminal does not have the firmware breakpoint resume upgrade function. The entire upgrade file needs to be transmitted in one upgrade, which greatly increases the terminal battery energy consumption.
[0008] Application No. 202410442588.X; Invention Name: Remote Upgrade Method and System for IoT Terminals; By downloading the target firmware corresponding to the IoT terminal through the over-the-air download technology, it is possible to remotely upgrade the firmware of the IoT terminal without having to arrive at the IoT terminal site. At the same time, by configuring the corresponding 5 FLASH partitions during the firmware compilation process, and setting the relevant information in the firmware upgrade process in the corresponding FLASH partitions, not only in the OTA firmware upgrade process, it provides an accurate reference for firmware copying, jumping, and rolling back, ensuring the security, integrity, and reliability of the IoT terminal during the upgrade process, even if the upgrade fails, the IoT terminal can be restarted without manual arrival at the site, and the normal firmware program can be run every time it is started, and the user can set the corresponding FLASH partition for the firmware of different IoT terminals, thereby ensuring that the upgrade process can be applied to IoT terminals with different architectures and ensuring the flexibility of the upgrade process.
[0009] The terminal of this patent does not have the function of resuming firmware upgrade after breakpoints. Since smart water meters and other equipment are mostly installed in water and electricity wells, the signal is easily affected, resulting in breakpoints in the upgrade. It is also possible that too many smart water meters are connected to the cloud platform, causing breakpoints in the firmware upgrade. Re-downloading all data will greatly increase the battery energy consumption of the terminal. Summary of the invention
[0010] In view of the deficiencies of the above-mentioned prior art, the technical problem to be solved by the present invention is: how to provide a terminal firmware upgrade method based on a mobile communication module, wherein the energy metering terminal actively sends an upgrade request to the cloud server, and the cloud server responds to decide whether to perform the firmware upgrade, the energy metering terminal actively sends a specified frame download request to the cloud server, and the cloud server sends the request frame data, and has a breakpoint resumption function, thereby reducing terminal energy consumption and network congestion caused by repeated downloads of the energy metering terminal.
[0011] In order to solve the above technical problems, the present invention adopts the following technical solutions: a terminal firmware upgrade method based on a mobile communication module, which is used in an energy metering terminal firmware upgrade system based on a mobile communication module. The energy metering terminal firmware upgrade system includes a cloud server and an energy metering terminal. The energy metering terminal includes an MCU, the MCU is connected to a metering module, and the MCU is wirelessly connected to the cloud server via the mobile communication module. The key lies in that it includes the following steps;
[0012] Step 1: MCU controls the mobile communication module to establish a UDP connection with the cloud server through the telecom operator's wireless network and the Internet, and sends the device identity information of the energy metering terminal to the cloud server;
[0013] Step 2: The cloud server determines whether to respond to the energy metering terminal for upgrade based on the local upgrade configuration file; if upgrade is required, a response frame of basic upgrade information is sent to the energy metering terminal; if upgrade is not required, a response frame of "No_Task" is sent; "No_Task" means no upgrade is required;
[0014] Step 3: The energy metering terminal performs necessary verification on the received response frame. If it is the basic information for upgrading, after the verification is passed, the upgrade file is downloaded frame by frame from the cloud server and the next frame ID is recorded. The next frame ID is "next_frame_ID". If there is a breakpoint, data transmission will be continued from the next frame ID. The upgrade file is used to generate a new firmware and complete the upgrade of the energy metering terminal firmware. If it is "No_Task", the upgrade is terminated. The next frame ID is the position of the next frame.
[0015] The terminal firmware upgrade method based on the mobile communication module is key in that the MCU flash is provided with four areas: Boot area, APP area, APP_BAK area, and USER_DATA area; the Boot area stores the startup program BootLoader, which has the function of erasing and programming the APP area and APP_BAK area; the APP area stores the currently running firmware; the APP_BAK area stores the backup firmware, and temporarily stores the downloaded upgrade file during the upgrade; the USER_DATA area stores the terminal operation parameters and some parameters of the new firmware during the upgrade;
[0016] The device identity information includes the device ID, the version number of the currently used firmware, the IMEI of the mobile communication module, and the frame CRC check; the basic upgrade information includes the new firmware version number, the number of upgrade file frames, the upgrade file length, the upgrade file CRC, the upgrade file differential attribute, the old firmware length, the old firmware CRC, the new firmware length, and the new firmware CRC; the new firmware version number is "new_version";
[0017] In step 2, the cloud server determines whether to upgrade the energy metering terminal, including:
[0018] The cloud server performs CRC verification on the received device identity information, and does not respond if the verification fails; after the verification is passed, it compares whether the firmware version currently used by the energy metering terminal is the same as the version number of the device to be upgraded in the upgrade configuration file on the cloud server. If they are not the same, it responds with "No_Task". If they are the same, it checks the upgrade target range according to the local upgrade configuration file; if it is a full upgrade, or the terminal's device ID or IMEI exists in the upgrade target list of the upgrade configuration file, the cloud server responds with the basic upgrade information of the energy metering terminal, otherwise it responds with "No_Task".
[0019] The contents of the upgrade configuration file on the cloud server include: the old firmware version number, the new firmware version number, all device options, the target device list, and the upgrade file attributes; the all device options indicate the upgrade object range, Y: all terminal devices with the same version number as the old firmware; N: terminal devices with the same version number as the old firmware and whose device ID or IMEI exists in the target device list of the upgrade configuration file; the target device list includes device ID, device ID range, IMEI, IMEI range; the upgrade file attributes indicate whether the upgrade file is a differential file of the new firmware relative to the old firmware or the new firmware itself;
[0020] In step three, the energy metering terminal records the new firmware version number and the next frame ID. The next frame ID is used as a breakpoint and as the starting frame number when it is upgraded again in the future.
[0021] The key to the terminal firmware upgrade method based on the mobile communication module is that the cloud server performs CRC verification on the received device identity information, performs CRC calculation on the received frame data, compares the calculation result with the received frame CRC value, and does not respond to the terminal if they are different; the frame CRC value is located at the end of the frame.
[0022] The frame received here is the device identity information.
[0023] The key to the terminal firmware upgrade method based on the mobile communication module is that the energy metering terminal performs CRC verification on the received response frame, performs CRC calculation on the received frame data, compares the calculation result with the received frame CRC value, and discards the response if they are different, and resends the device identity information or frame request to the cloud server; the frame CRC value is located at the end of the frame.
[0024] The terminal firmware upgrade method based on the mobile communication module is described, and its key lies in that the verification after the energy metering terminal receives the basic information of the upgrade includes: performing CRC calculation on the old firmware in the APP area to obtain crc_app, performing CRC calculation on the firmware in the APP_BAK area to obtain crc_bak, if the new firmware version number is the same as the version number in the APP area, and the new firmware CRC is the same as the calculated crc_app, then the upgrade is not performed, and a response of "Update_OK" is sent to the cloud server to end the upgrade; if the new firmware version number is the same as the version number in the APP_BAK area, and the new firmware CRC is the same as the calculated crc_bak, then the upgrade is not performed, and a response of "Update_OK" is sent to the cloud server to end the upgrade; if the upgrade file attribute is a differential file, crc_app is compared with the received old firmware CRC, and the upgrade is ended if they are not the same; if the above three conditions are not met, the upgrade process is started. If the new firmware version number is different from the new firmware version number of the last upgrade saved in the USER_DATA area, the new firmware version number saved in the USER_DATA area is cleared (new_version is set to null), the next frame ID (next_frame_ID is set to 0), and the upgrade file attributes.
[0025] The key to the terminal firmware upgrade method based on the mobile communication module is that after the energy metering terminal receives the basic upgrade information and passes the verification, the step of obtaining the upgrade file includes:
[0026] Step a: The energy metering terminal reads the value of next_frame_ID from the USER_DATA area;
[0027] Step b: Send a frame request to the cloud server: "Frame, next_frame_ID", "Frame, next_frame_ID" means to obtain the frame data with the upgrade file number next_frame_ID;
[0028] Step c: the energy metering terminal receives frame data whose frame sequence number is the value of next_frame_ID;
[0029] Step d: The energy metering terminal increases the value of next_frame_ID by 1. If the value of next_frame_ID is less than the number of frames in the upgrade file, go to step b. If the value of next_frame_ID is equal to the number of frames in the upgrade file, indicating that all frame data of the upgrade file has been obtained, "Update_OK" is sent to the cloud server to end the download of the upgrade file.
[0030] When there is no breakpoint, the initial value of next_frame_ID is zero.
[0031] The key to the terminal firmware upgrade method based on the mobile communication module is that, during the process of the energy metering terminal downloading the upgrade file frame by frame from the cloud server, each frame is downloaded, the frame header and frame tail are removed and the data is stored in the APP_BAK area. If the request for a certain frame of data times out without a response, the energy metering terminal resends the request frame. When the set number of repeated requests is unsuccessful, the new firmware version number, next_frame_ID, and upgrade file attribute information are saved in the USER_DATA area for use in the next upgrade, thereby realizing the breakpoint resume function.
[0032] The key to the terminal firmware upgrade method based on the mobile communication module is that after the energy metering terminal completes downloading from the cloud server, the number of downloaded frames saved in the USER_DATA area is cleared (next_frame_ID is set to 0 for the next upgrade).
[0033] If the upgrade file is not a differential file, the file in the APP_BAK area is the new firmware. If the upgrade file is a differential file, the old firmware in the APP area and the differential file in the APP_BAK area are de-differentiated to obtain the new firmware, which is then saved in the APP_BAK area and the correctness of the new firmware is verified.
[0034] The correctness verification of the new firmware includes: calculating the crc_bak of the firmware in the APP_BAK area; whether the version number of the new firmware is the same as the version number of the new firmware in the upgrade basic information; whether crc_bak is the same as the new firmware CRC in the upgrade basic information. If any of the version number and CRC are different, the verification fails. Only when the two are the same, the verification is considered passed.
[0035] The key to the terminal firmware upgrade method based on the mobile communication module is that after the new firmware in the APP_BAK area is generated and verified, the BootLoader of the MCU is started to exchange the old firmware in the APP area with the new firmware in the APP_BAK area, and run the new firmware in the APP area.
[0036] The terminal firmware upgrade method based on the mobile communication module is described, and its key lies in that the new firmware function includes: comparing the firmware version number of the APP area with the new_version saved in the USER_DATA area, and if they are the same, starting the countdown timer for connecting to the cloud server; periodically connecting to the cloud server during the countdown period, and once the connection is successful, clearing the new_version saved in the USER_DATA area and stopping the countdown timer. If the cloud server cannot be successfully connected after the countdown expires, starting the BootLoader of the MCU to exchange the new firmware in the APP area with the old firmware in the APP_BAK area, and running the old firmware in the APP area to realize the firmware rollback function, ensure that the energy metering terminal and the cloud server connection function are normal, and avoid the terminal from becoming bricked.
[0037] Significant effect: The present invention provides a terminal firmware upgrade method based on a mobile communication module, in which the energy metering terminal actively sends an upgrade request to the cloud server, and the cloud server responds to decide whether to perform the firmware upgrade. The energy metering terminal actively sends a specified frame download request to the cloud server, and the cloud server sends the request frame data, and has a breakpoint resumption function, which reduces the terminal energy consumption and network congestion caused by repeated downloads of the energy metering terminal. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 This is a diagram of the firmware upgrade system for energy metering terminals based on mobile communication modules;
[0039] Figure 2 Upgrade configuration file infographic for cloud servers;
[0040] Figure 3 The process diagram of periodically requesting upgrade information for the energy metering terminal MCU;
[0041] Figure 4 Provide a verification process diagram before upgrading the energy metering terminal;
[0042] Figure 5 A process diagram of requesting an upgrade file data frame for an energy metering terminal;
[0043] Figure 6 Figure 1. Process diagram of downloading the upgrade file for the energy metering terminal. DETAILED DESCRIPTION
[0044] The present invention will be further described in detail below in conjunction with the accompanying drawings.
[0045] The present invention discloses a method and system for upgrading the firmware of an energy metering terminal based on a mobile communication module. The method is applied to the firmware upgrade of the energy metering terminal based on the mobile communication module. The system includes a cloud server and an energy metering terminal. The energy metering terminal includes a mobile communication module, a microcontroller (MCU), and a metering module. The method includes: the MCU controls the mobile communication module to establish a UDP connection with the cloud server through the wireless network and the Internet of the telecommunications operator, and sends the device identity information of the energy metering terminal to the cloud server. The cloud server determines whether to upgrade the terminal according to the local upgrade configuration file. If no upgrade is required, the terminal is replied with "No_task". If upgrade is required, the terminal is replied with basic upgrade information. The terminal uses the received basic upgrade information to perform CRC verification on the firmware of the APP area and APP_BAK area in the MCU. After the verification is passed, the terminal actively downloads frame requests starting from next_frame_ID from the cloud server frame by frame according to the next frame ID (next_frame_ID) stored locally. After receiving the frame request, the cloud server sends the corresponding frame data to the terminal. If the terminal fails to obtain frame data for multiple consecutive times, the new firmware version number (new_version) and the number of frames downloaded are recorded locally. This data is used as the starting frame number for future upgrades (i.e., the next frame ID, next_frame_ID), and the upgrade is terminated. If all frame data of the upgrade file are successfully obtained, the frame data are combined to generate an upgrade file. According to the differential attributes of the upgrade file, it is determined whether the upgrade file needs to be de-differentialized. If the upgrade file is a differential file, it is differentially restored to generate a new firmware. If the upgrade file is not a differential file, it is the new firmware. The new firmware is verified using the received basic upgrade information, and the verified new firmware is written to the APP_BAK area of the MCU. Run BootLoader to swap the old firmware in the APP area with the new firmware in the APP_BAK area, run the new firmware, and start the countdown timer for connecting to the cloud server. In normal use of the energy metering terminal, the MCU will periodically control the mobile communication module to execute the connection with the cloud server. If the connection is successful, the local saved new_version will be cleared and the countdown timer will be stopped. If the connection to the cloud server fails continuously and the countdown expires, the new firmware in the APP area will be swapped with the old firmware in the APP_BAK area, and the old firmware in the APP area will be re-run to achieve firmware rollback. The method of the present invention can solve the problems of breakpoint continuation, firmware rollback, and easy blocking of cloud servers in handling a large number of terminals for concurrent upgrades during the firmware upgrade of the energy metering terminal.
[0046] The present invention relates to a terminal firmware upgrade method based on a mobile communication module, and specifically relates to an energy metering terminal, especially to the field of smart water meters. The invention aims to solve the breakpoint continuation and firmware rollback problems of terminal upgrades, and at the same time improve the ability of cloud servers to serve a large number of terminals for concurrent upgrades.
[0047] like Figure 1-Figure 6 As shown, an embodiment of the present invention provides a terminal firmware upgrade method and system based on a mobile communication module. The method is applied to the firmware upgrade of an energy metering terminal based on a mobile communication module. The system includes a cloud server and an energy metering terminal.
[0048] The cloud server is a computer device including a memory and a processor. The memory stores a computer program and an upgrade configuration file. The method is implemented when the processor executes the computer program.
[0049] The energy metering terminal is composed of a mobile communication module, a microcontroller (MCU), and a metering module, and has an enterprise-level unique device ID. The mobile communication module has an internationally unique identification code IMEI (International Mobile Equipment Identity).
[0050] The method includes: dividing the flash of the MCU into four areas: Boot area, APP area, APP_BAK area, and USER_DATA area. The Boot area stores the startup program BootLoader, which has the function of erasing and programming the APP and APP_BAK areas; the APP area stores the currently running firmware; the APP_BAK area stores the backup firmware, and temporarily stores the downloaded upgrade files during the upgrade; the USER_DATA area stores the terminal operation parameters and some parameters of the new firmware during the upgrade.
[0051] The method includes: MCU periodically controls the mobile communication module to establish a UDP (User Datagram Protocol) connection with the cloud server through the wireless network of the telecommunications operator and the Internet, and sends an upgrade request frame, and the cloud server sends a response frame after receiving it. The request frame and the response frame both use CRC for error control, and the CRC value is located at the end of each frame. Among them, the MCU is connected to a clock module, and the corresponding upgrade timing of the smart metering terminal is obtained through the clock module. The mobile communication module is timed to establish a UDP (User Datagram Protocol) connection with the cloud server through the wireless network of the telecommunications operator and the Internet, and send an upgrade request frame. The corresponding timing of the clock module of each smart metering terminal is discrete, such as 10:00, 12:30, 15:26, 20:15..., which avoids network congestion caused by multiple terminals requesting upgrades from the cloud server at the same time.
[0052] Once a UDP connection is established with the cloud server, the MCU sends the device identity information to the cloud server. After receiving the device identity information, the cloud server first verifies the correctness of the frame, calculates the CRC of the received frame and compares it with the CRC at the end of the frame, does not discard the frame data at the same time, and does not make any response to the terminal. The device identity information includes the device ID, the firmware version number of the terminal's current firmware, and the IMEI of the mobile communication module.
[0053] After the cloud server verifies the correctness of the frame, it determines whether the terminal needs to be upgraded based on the local upgrade configuration file. If no upgrade is required, it replies to the terminal with "No_task". If an upgrade is required, it replies to the terminal with basic upgrade information. The basic upgrade information is: "Update_To: new firmware version number, upgrade file frame number, upgrade file length, upgrade file CRC, upgrade file differential attributes, old firmware length, old firmware CRC, new firmware length, new firmware CRC"; "No_task" means no upgrade is required.
[0054] The content of the upgrade configuration file includes: old firmware version number, new firmware version number, all device options, target device list, and upgrade file attributes. The all device option indicates the upgrade object range, Y: all terminal devices with the same version number as the old firmware; N: terminal devices with the same version number as the old firmware and whose device ID or IMEI exists in the target device list of the upgrade configuration file. The target device list includes device ID, device ID range, IMEI, and IMEI range. The upgrade file attributes indicate whether the upgrade file is a differential file of the new firmware relative to the old firmware or the new firmware itself.
[0055] After receiving any response frame from the cloud server, the terminal performs CRC verification on the received response frame. Specifically: calculate the frame data CRC, compare the calculation result with the received frame CRC value (at the end of the frame), and if they are different, discard the response frame and resend the device identity information frame or frame request to the cloud server.
[0056] When the terminal receives the response "No_task" from the cloud server, it indicates that there is no upgrade task, and the upgrade is immediately terminated and the terminal enters the sleep state to save energy.
[0057] When the terminal receives the basic upgrade information from the cloud server, the CRC calculation is performed on the old firmware in the APP area to obtain crc_app, and the CRC calculation is performed on the firmware in the APP_BAK area to obtain crc_bak. If the received "new firmware version number" is the same as the version number in the APP area, and the received "new firmware CRC" is the same as the calculated crc_app, it indicates that the currently running firmware is the new firmware and does not need to be upgraded. The terminal responds "Update_OK" to the cloud server, immediately ends the upgrade and enters the dormant state; the received "new firmware version number" is the same as the version number in the APP_BAK area, and the received "new firmware CRC" is the same as the calculated crc_bak, indicating that the firmware in the APP_BAK area is the new firmware and does not need to be upgraded. The terminal responds "Update_OK" to the cloud server, starts the BootLoader, exchanges the firmware in the APP area with the APP_BAK area, and runs the firmware in the APP area; if the received "upgrade file attribute" is a differential file, the crc_app is compared with the received "old firmware CRC", if they are not the same, the upgrade is immediately terminated and the dormant state is entered; if the above three conditions are not met, the upgrade process is started. If the new firmware version number is different from the new firmware version number of the last upgrade saved in the USER_DATA area, clear the new firmware version number saved in the USER_DATA area (set new_version to null), next frame ID (set next_frame_ID to 0), and upgrade file attributes.
[0058] After the terminal receives the basic information of the upgrade and passes the verification, it reads next_frame_ID from the USER_DATA area and sends a frame request to the cloud server: Frame, next_frame_ID, indicating that it wants to obtain the frame data of the upgrade file with the sequence number next_frame_ID. After the terminal receives the frame data with the sequence number next_frame_ID, next_frame_ID increases by 1. If next_frame_ID is less than the number of frames in the upgrade file, it sends "Frame, next_frame_ID" to obtain the next frame. If next_frame_ID is equal to the number of frames in the upgrade file, indicating that all frame data of the upgrade file has been obtained, it sends "Update_OK" to end the download of the upgrade file.
[0059] The next_frame_ID saved in the USER_DATA area may be set to 0 by the aforementioned verification, or it may be the number of frames that have been partially downloaded last time. It is used as the starting frame number of this upgrade, corresponding to this upgrade starting from the beginning or the last breakpoint, so it must be read from the USER_DATA area for use.
[0060] When the terminal downloads the upgrade file frame by frame from the cloud server, it removes the frame header and frame tail for each frame downloaded and stores the data in the APP_BAK area. If the request for a frame of data times out without a response, the terminal resends the request frame "Frame, next_frame_ID". When the set number of repeated requests is unsuccessful, the new firmware version number (new_version), the number of downloaded frames (equal to next_frame_ID), the upgrade file attributes and other information are saved in the USER_DATA area for use in the next upgrade (to realize the breakpoint resume function), and the upgrade is terminated and the terminal enters the sleep state.
[0061] After the terminal completes downloading from the cloud server, clear the number of downloaded frames saved in the USER_DATA area (set next_frame_ID to 0 for the next upgrade).
[0062] If the upgrade file is not a differential file, the file in the APP_BAK area is the new firmware. If the upgrade file is a differential file, the old firmware in the APP_BAK area and the differential file in the APP area are de-differentiated and the result (new firmware) is saved in the APP_BAK area, and then the correctness of the new firmware is verified.
[0063] The correctness verification of the new firmware includes: calculating the crc_bak of the firmware in the APP_BAK area; whether the version number of the new firmware is the same as the version number of the new firmware in the upgrade basic information; whether crc_bak is the same as the new firmware CRC in the upgrade basic information. If any of the version number and CRC are different, the verification fails. Only when the two are the same, the verification is considered passed.
[0064] After the APP_BAK area firmware is verified, the BootLoader of the MCU is started to swap the old firmware in the APP area with the new firmware in the APP_BAK area, and run the new firmware in the APP area.
[0065] The new firmware needs to include the following functions: compare the version number in the APP area with the new_version saved in the USER_DATA area. If they are the same, start the countdown timer for connecting to the cloud server. Periodically connect to the cloud server during the countdown period. Once the connection is successful, clear the new_version saved in the USER_DATA area and stop the countdown timer. If the cloud server cannot be successfully connected after the countdown expires, start the MCU's BootLoader to exchange the new firmware in the APP area with the old firmware in the APP_BAK area, and run the old firmware in the APP area to implement the firmware rollback function, ensure that the terminal and the cloud server are connected normally, and avoid the terminal from becoming bricked.
[0066] Bricking refers to an electronic product (such as a mobile phone, a game console, etc.) that cannot be used normally due to some reason, usually manifested as being unable to boot or enter the operating system. In the present invention, bricking refers to a firmware upgrade that is successful but cannot connect to the cloud server.
[0067] The main reasons for bricking are as follows: flashing failure, hardware damage, system file damage, firmware defects, etc. When the device is bricked, users usually need to contact professional maintenance personnel or send it back to the manufacturer for repair.
[0068] A system for upgrading the firmware of an energy metering terminal based on a mobile communication module, the key of which is that it includes at least one computer device as a cloud server, the computer device includes a memory and a processor, an upgrade configuration file and a computer program that can be run on the processor are stored in the memory, and the method for upgrading the firmware of the energy metering terminal is implemented.
[0069] The above are only preferred implementations of the present invention. It should be pointed out that a number of modifications and improved technical solutions made by those skilled in the art without departing from the technical solution should also be deemed to fall within the scope of protection required by the claims.
Claims
1. A terminal firmware upgrade method based on a mobile communication module, used in an energy metering terminal firmware upgrade system based on a mobile communication module, the energy metering terminal firmware upgrade system includes a cloud server and an energy metering terminal, the energy metering terminal includes an MCU, the MCU is connected to a metering module, and the MCU is wirelessly connected to the cloud server via the mobile communication module, characterized in that: The method comprises the following steps: Step 1: MCU controls the mobile communication module to establish a UDP connection with the cloud server through the telecom operator's wireless network and the Internet, and sends the device identity information of the energy metering terminal to the cloud server; Step 2: The cloud server determines whether to perform an upgrade reply on the energy metering terminal according to the local upgrade configuration file; If an upgrade is required, a response frame of basic upgrade information is sent to the energy metering terminal; if an upgrade is not required, a "No_Task" response frame is sent; Step 3: The energy metering terminal verifies the received response frame. If it is the basic information for upgrading, after the verification is passed, the upgrade file is downloaded frame by frame from the cloud server and the next frame ID is recorded. The next frame ID is "next_frame_ID". If a breakpoint occurs, the data is continued from the next frame ID. The upgrade file is used to generate a new firmware and complete the upgrade of the energy metering terminal firmware. If it is "No_Task", the upgrade is terminated.
2. A terminal firmware upgrade method based on a mobile communication module according to claim 1, characterized in that: The MCU's flash is set up with four areas: Boot area, APP area, APP_BAK area, and USER_DATA area; the Boot area stores the startup program BootLoader, which has the function of erasing and programming the APP area and APP_BAK area; the APP area stores the currently running firmware; the APP_BAK area stores the backup firmware and temporarily stores the downloaded upgrade files during the upgrade; the USER_DATA area stores the operating parameters of the energy metering terminal and some parameters of the new firmware during the upgrade; The device identity information includes the device ID, the version number of the currently used firmware, the IMEI of the mobile communication module, and the frame CRC check; the basic upgrade information includes the new firmware version number, the number of upgrade file frames, the upgrade file length, the upgrade file CRC, the upgrade file differential attribute, the old firmware length, the old firmware CRC, the new firmware length, and the new firmware CRC; the new firmware version number is "new_version"; In step 2, the cloud server determines whether to upgrade the energy metering terminal, including: The cloud server performs CRC verification on the received device identity information. If the verification fails, no response is given. After the verification passes, the cloud server compares whether the firmware version currently used by the energy metering terminal is the same as the version number of the device to be upgraded in the upgrade configuration file on the cloud server. If they are not the same, the cloud server responds with "No_Task". If they are the same, the cloud server checks the upgrade target range according to the local upgrade configuration file. If all upgrades are required, or the device ID or IMEI of the terminal exists in the upgrade target list of the upgrade configuration file, the cloud server responds with basic upgrade information for the energy metering terminal. Otherwise, the cloud server responds with "No_Task". The contents of the upgrade configuration file on the cloud server include: the old firmware version number, the new firmware version number, all device options, the target device list, and the upgrade file attributes; the all device options indicate the upgrade object range, Y: all terminal devices with the same version number as the old firmware; N: terminal devices with the same version number as the old firmware and whose device ID or IMEI exists in the target device list of the upgrade configuration file; the target device list includes device ID, device ID range, IMEI, IMEI range; the upgrade file attributes indicate whether the upgrade file is a differential file of the new firmware relative to the old firmware or the new firmware itself; In step three, the energy metering terminal records the new firmware version number and the next frame ID. The next frame ID is used as a breakpoint and as the starting frame number when it is upgraded again in the future.
3. A terminal firmware upgrade method based on a mobile communication module according to claim 1, characterized in that: The cloud server performs CRC verification on the received device identity information, performs CRC calculation on the received frame data, and compares the calculation result with the received frame CRC value. If they are different, the energy metering terminal will not respond; the frame CRC value is located at the end of the frame.
4. A terminal firmware upgrade method based on a mobile communication module according to claim 1, characterized in that: The energy metering terminal performs CRC verification on the received response frame, performs CRC calculation on the received frame data, and compares the calculation result with the received frame CRC value. If they are different, the response is discarded and the device identity information or frame request is resent to the cloud server; the frame CRC value is located at the end of the frame.
5. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: The verification after the energy metering terminal receives the basic upgrade information includes: CRC calculation of the old firmware in the APP area to obtain crc_app, CRC calculation of the firmware in the APP_BAK area to obtain crc_bak, if the new firmware version number is the same as the version number in the APP area, and the new firmware CRC is the same as the calculated crc_app, then the upgrade will not be performed, and a response of "Update_OK" will be sent to the cloud server to end the upgrade; if the new firmware version number is the same as the version number in the APP_BAK area, and the new firmware CRC is the same as the calculated crc_bak, then the upgrade will not be performed, and a response of "Update_OK" will be sent to the cloud server to end the upgrade; if the upgrade file attribute is a differential file, crc_app will be compared with the received old firmware CRC, and the upgrade will be ended if they are not the same; if the above three conditions are not met, the upgrade process will be started; if the new firmware version number is different from the new firmware version number of the last upgrade saved in the USER_DATA area, the new firmware version number, next frame ID, and upgrade file attributes saved in the USER_DATA area will be cleared.
6. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: After the energy metering terminal receives the basic upgrade information and passes the verification, the steps to obtain the upgrade file include: Step a: The energy metering terminal reads the value of next_frame_ID from the USER_DATA area; Step b: Send a frame request to the cloud server: "Frame, next_frame_ID", "Frame, next_frame_ID" means to obtain the frame data with the upgrade file number of next_frame_ID; Step c: the energy metering terminal receives frame data with a frame number of next_frame_ID; Step d: The energy metering terminal increases the value of next_frame_ID by 1. If the value of next_frame_ID is less than the number of frames in the upgrade file, go to step b. If the value of next_frame_ID is equal to the number of frames in the upgrade file, indicating that all frame data of the upgrade file has been obtained, "Update_OK" is sent to the cloud server to end the download of the upgrade file.
7. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: When the energy metering terminal downloads the upgrade file frame by frame from the cloud server, it removes the frame header and frame tail for each frame downloaded and stores the data in the APP_BAK area. If there is no response when requesting a certain frame of data, the energy metering terminal resends the request frame. When the set number of repeated requests is unsuccessful, the new firmware version number, next_frame_ID, and upgrade file attribute information are saved in the USER_DATA area for use in the next upgrade.
8. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: After the energy metering terminal has finished downloading from the cloud server, clear the next_frame_ID saved in the USER_DATA area; if the upgrade file is not a differential file, the file in the APP_BAK area is the new firmware. If the upgrade file is a differential file, perform a differential operation on the old firmware in the APP area and the differential file in the APP_BAK area to obtain the new firmware, save the new firmware in the APP_BAK area, and then verify the correctness of the new firmware; The correctness verification of the new firmware includes: calculating the crc_bak of the firmware in the APP_BAK area; whether the version number of the new firmware is the same as the version number of the new firmware in the upgrade basic information; whether crc_bak is the same as the new firmware CRC in the upgrade basic information. If any of the version number and CRC are different, the verification fails. Only when the two are the same, the verification is considered passed.
9. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: After the new firmware in the APP_BAK area is generated and verified, the BootLoader of the MCU is started to swap the old firmware in the APP area with the new firmware in the APP_BAK area, and run the new firmware in the APP area.
10. A terminal firmware upgrade method based on a mobile communication module according to claim 2, characterized in that: The new firmware functions include: comparing the firmware version number in the APP area with the new_version saved in the USER_DATA area. If they are the same, the countdown timer for connecting to the cloud server is started; periodically connecting to the cloud server during the countdown period. Once the connection is successful, the new_version saved in the USER_DATA area is cleared and the countdown timer is stopped. If the cloud server cannot be successfully connected after the countdown expires, the MCU's BootLoader is started to exchange the new firmware in the APP area with the old firmware in the APP_BAK area, and the old firmware in the APP area is run.
Citation Information
Patent Citations
Remote upgrading method and system of Internet of Things terminal
CN118540220A
Terminal firmware upgrading method, system and equipment based on communication module and medium
CN118689514A