A single-chip microcomputer firmware upgrading method

Abstract

The application belongs to the single-chip microcomputer firmware upgrading technical field, and specifically discloses a single-chip microcomputer firmware upgrading method, which comprises the following steps: receiving an upgrading command of an upper computer through a network port during APP program running and distinguishing the upgrading command into two categories, under the first category, the APP program requests and checks firmware data packets, writes the firmware data packets into an SD card and edits an auxiliary file after the checking, restarts and jumps to a BOOT program, and under the second category, the APP program directly jumps to the BOOT program after editing the auxiliary file; in the BOOT program, if an upgrading command is parsed from the network port, the firmware data packets are requested and checked, the firmware data packets are written into a FLASH and the auxiliary file is edited after the checking, and then the APP program is started, if the upgrading command is not parsed, the auxiliary file is read from the SD card, firmware files are read from the SD card according to firmware information when an upgrading operation is executed, the firmware files are decoded and written into the FLASH, and the APP program is started. The application realizes centralized firmware upgrading of multiple control boards.

Description

Technical Field

[0001] This application belongs to the field of microcontroller firmware upgrade technology, and more specifically, relates to a microcontroller firmware upgrade method. Background Technology

[0002] Battery formation and capacity testing equipment, as specialized equipment for battery production, has non-standard characteristics. The production process may change during verification, and the supporting testing environment may also change. At this time, it is necessary to upgrade the microcontroller firmware of the control board to adapt to the new production requirements.

[0003] Traditionally, firmware upgrades for microcontrollers are performed using tools like J-Link to burn the firmware. However, this method has several drawbacks: in large modularization cabinets with dozens or even hundreds of control boards, manually plugging and unplugging J-Link for upgrades is extremely time-consuming, failing to meet the needs of rapid line replacement or maintenance in the field; the complex production environment makes it easy for operators to introduce static electricity or cause short circuits by carrying external burning tools, and often requires disassembling the chassis to insert the burning port, while also failing to guarantee the integrity and legitimacy of the firmware during the upgrade process; furthermore, the lack of a unified version management mechanism makes it impossible to trace the upgrade history of each device, and once a batch of upgrades fails, it is difficult to quickly roll back or repair.

[0004] Therefore, how to achieve efficient, secure, and version-traceable centralized firmware upgrades for multiple control boards is an urgent problem that needs to be solved. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this application is to provide a single-chip microcomputer firmware upgrade method that enables centralized firmware upgrades for multiple control boards in a way that is efficient, secure, and has version traceability capabilities.

[0006] To achieve the above objectives, in a first aspect, this application provides a microcontroller firmware upgrade method, applied to a control board containing a microcontroller, a network port, and an SD card in a battery formation or capacity grading device. The firmware of the microcontroller is divided into an APP program and a BOOT program. The method includes the following steps: S10, During the operation of the APP program, an upgrade command issued by the host computer is received through the network port. The upgrade command is divided into a first type of upgrade command that upgrades within the APP program and a second type of upgrade command that jumps to the BOOT program for upgrade. S20, when the first type of upgrade command is received, the APP program requests a firmware data packet from the host computer and verifies the received firmware data packet, which has been encrypted and encoded and has a checksum added. If the verification passes, the firmware data packet is written to the corresponding file in the SD card according to its number, and an auxiliary file is edited to record the firmware information. If the verification fails, the APP program requests the host computer to resend the corresponding firmware data packet. After the firmware data packet is received, the APP program restarts the microcontroller and jumps to the BOOT program. S30, when the second type of upgrade command is received, the APP program edits the auxiliary file, restarts the microcontroller, and jumps to the BOOT program; S40, in the BOOT program, when the upgrade command is parsed from the data received from the network port, the host computer is requested to request a firmware data packet according to the upgrade command. The received firmware data packet is verified. After the verification is passed, the firmware data packet is written to the specified FLASH location according to the number and the auxiliary file is edited to record the firmware information. Then, the program jumps to the APP program startup location and starts the APP program. S50, in the BOOT program, if the upgrade command is not parsed from the network port or no network port data is received, the SD card is checked for normal operation. If the SD card is normal, the auxiliary file is read and the firmware information in the auxiliary file is used to determine whether to perform the upgrade operation. If the upgrade operation is determined to be performed, the firmware file is read from the SD card, decoded and written to the specified FLASH location, and then the program is redirected to the APP program startup location and the APP program is started.

[0007] As a further preferred embodiment, in step S20, the encryption encoding process adopts a hybrid encryption algorithm based on XOR operation and bitwise operation, and the encryption formula is Ci=(Pi⊕ Ki) ≫ Si, where Ci is the data of the i-th byte after encryption, Pi is the data of the i-th byte of the original firmware, Ki is the i-th byte of the dynamic key, ⊕ is the bitwise XOR operation, >> is the logical right shift operation, and Si is the bitwise offset.

[0008] As a further preferred embodiment, the dynamic key is composed of a hash sequence generated from the MAC address of the control board; the checksum is a CRC16 checksum.

[0009] As a further preferred embodiment, the auxiliary file is a binary file containing a device MAC field, a firmware version field, a CRC32 checksum field, a firmware package size field, and an encryption method identifier field.

[0010] As a further preferred embodiment, in step S20, the auxiliary file includes a device MAC field; when the APP program receives the firmware data packet, it also reads the device MAC field in the auxiliary file. If the device MAC field is inconsistent with the MAC of the control board itself, the received firmware data packet is discarded and a negative response signal is sent to the host computer.

[0011] As a further preferred embodiment, when the APP program or the BOOT program requests the host computer to resend the corresponding firmware data packet, if the number of resends exceeds the limit, data reception will be stopped and an alarm indication will be issued.

[0012] As a further preferred embodiment, in step S50, determining whether to perform an upgrade operation based on the firmware information in the auxiliary file specifically involves: parsing the firmware version field in the auxiliary file; if the version indicated by the firmware version field is higher than the version currently recorded by the BOOT program, then determining to perform an upgrade operation; otherwise, skipping the upgrade process and directly jumping to the APP program startup location to start the APP program.

[0013] As a further preferred embodiment, the host computer simultaneously sends upgrade commands to multiple control boards via Ethernet. The host computer uses a time-division multiplexing polling mechanism to send firmware data packets to each control board sequentially. Each control board replies with an acknowledgment signal after receiving the firmware data packet. The host computer sets a sliding window for each control board, and each control board can buffer a maximum of two data packets. When the buffer is full, the control board pauses replying with acknowledgment signals. After detecting a timeout, the host computer reduces the sending rate and retransmits the data. Each control board independently runs CRC16 verification before writing to FLASH, and reports progress data to the host computer via UDP broadcast after completing 10% of the data writing.

[0014] As a further preferred option, an exception handling step is also included: when the APP program detects a heartbeat timeout during the Ethernet upgrade process, it stops writing and locks the FLASH in the current state. After restarting, if the BOOT program detects that the FLASH is not marked as completed, it jumps back to the original APP program; when the SD card is removed during the SD card writing process, the hardware watchdog does not detect a write completion signal within a specified time and resets the microcontroller. After the reset, the corrupted firmware is not executed.

[0015] Secondly, this application provides a microcontroller firmware upgrade system, which applies the microcontroller firmware upgrade method described in any of the above claims, including a host computer and multiple control boards. The host computer is used to send firmware data packets that have been encrypted and encoded and have added verification codes, and to receive progress data reported by each control board. Each control board includes a microcontroller, a network port, and an SD card. The firmware of the microcontroller is divided into an APP program and a BOOT program. The control board communicates with the host computer through the network port, stores the firmware data packets and auxiliary files through the SD card, and executes the microcontroller firmware upgrade method.

[0016] This application has the following advantages: It receives upgrade commands from the host computer via the network port and, during the APP program's operation, distinguishes between two types of upgrade commands and executes corresponding preprocessing procedures. Then, it jumps to the BOOT program to complete the firmware writing to the FLASH via either the network port or SD card. This allows for simultaneous one-to-many upgrades via a control board connected to a computer via a network cable, improving upgrade efficiency. Furthermore, this upgrade method eliminates the need for external programming tools; the upgrade operation is performed directly using the device's existing network cable and SD card, reducing the risk of static electricity or short circuits caused by external programming tools. In most cases, the upgrade can be completed without disassembling the chassis, making it more convenient and safer. In addition, after writing the firmware to the FLASH, this application writes the upgrade version and record to the corresponding FLASH location. The host computer also retains the upgrade version and record. On-site personnel and maintenance personnel can track the device upgrade status through these records, enabling traceability of the device upgrade history and facilitating the recording of device operation history. Attached Figure Description

[0017] Figure 1 This is a block diagram of the control board module provided in this application; Figure 2 This is the microcontroller program flowchart provided in this application; Figure 3 This is a flowchart of the APP receiving firmware provided in this application; Figure 4 This is a flowchart of the BOOT upgrade APP firmware provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] It should be understood that, in the description of this application, the terms "first" and "second," etc., are used to distinguish different objects, rather than to describe a specific order of objects.

[0020] This application aims to provide a dual-mode security upgrade method based on existing Ethernet ports and SD cards. By introducing packet encryption, CRC integrity verification, breakpoint resumption, and parallel upgrade handshake protocol, it achieves efficient, secure, and foolproof (anti-misoperation) centralized upgrades for multiple control boards.

[0021] like Figure 1 As shown, the formation and capacity distribution equipment control board includes modules such as power supply, network port (for communication with the host computer), SD card, and microcontroller. To adapt to the field environment and facilitate upgrades and maintenance, the microcontroller firmware consists of two parts: a BOOT program (boot program) and an APP program (application program), as shown below. Figure 2 As shown.

[0022] In actual production operation, the APP program serves as the main program, controlling the operation of the equipment and exchanging information with the host computer in real time. The host computer acts as the user interface; user operations on the equipment and firmware upgrades for the microcontroller can all be performed through the host computer. The host computer and the microcontroller exchange data via a network cable. Therefore, this method selects the network port as the primary interface for upgrades.

[0023] like Figure 3 As shown, when the user operates the host computer to upgrade the microcontroller firmware, the APP program will receive the upgrade command sent by the host computer. The upgrade command is divided into two types: upgrade within the APP and upgrade by jumping to the BOOT program, and each type executes a different process.

[0024] The first method involves an in-app upgrade command. The app requests firmware data from the host computer, which then sends the data. To ensure the firmware is the correct one and prevents an incorrect firmware upgrade, the host computer encrypts the original firmware data, divides it into multiple data packets, and adds CRC16 checks to prevent data loss or errors during transmission. When the app receives the firmware data packet, it checks the firmware encoding and checksum. If the data and checksum are incorrect, the packet is considered invalid, discarded, and the host computer is requested to resend the data. If the resend limit is exceeded, data reception stops, an alarm is triggered, and manual intervention is required. When the data and checksum are correct, the firmware packet is written to the corresponding file on the SD card, and auxiliary files are edited for SD card upgrade operation. Once the complete firmware reception is complete, the app restarts the microcontroller and enters the BOOT program.

[0025] The second method involves the APP directly editing the auxiliary file when the upgrade command is executed in the BOOT program. This restarts the microcontroller and jumps into the BOOT program.

[0026] like Figure 4As shown, when upgrading the APP firmware in the BOOT program, it first analyzes the data received from the network port to see if it contains an upgrade command, and then performs the corresponding two operations.

[0027] In the first scenario, if an upgrade command is included, the BOOT program will request the host computer to send the APP firmware data. Upon receiving the request, the host computer will execute the distribution action. To ensure the firmware data is the required upgrade firmware and prevent upgrading to the wrong firmware, the host computer will specifically encrypt and encode the original firmware data, dividing it into multiple data packets as required. Furthermore, to prevent data loss and errors during transmission, CRC16 and other verification methods will be added. When the APP receives the firmware data packet, it will check the firmware encoding and checksum. If the matching data and checksum are incorrect, the current data packet is considered invalid, discarded, and a request for retransmission from the host computer will be sent. If the number of retransmissions exceeds the limit, data reception will stop, an alarm will be triggered, and manual intervention will be required. When the matching data and checksum are correct, the firmware packet is written to the designated FLASH location according to its number, and the auxiliary files on the SD card are edited to facilitate SD card upgrade operations. Once the complete firmware reception is complete, the upgrade version and record are written to the corresponding FLASH location, and BOOT will jump to the APP program startup location to directly launch the APP program.

[0028] The second method involves the BOOT program performing the upgrade operation from the SD card if the network port data does not contain the upgrade command or if no network port data is received. First, it checks if the SD card is functioning correctly; if not, an alarm sounds and manual intervention is required. If the SD card is functioning correctly, it reads the instruction file from the SD card and checks the upgrade instructions in the tutorial file. If the instructions do not require an upgrade, it jumps to the APP program location and starts the APP program. If the tutorial file indicates an upgrade is required, it analyzes the APP firmware file. If the firmware file's encoding method, checksum, etc., are abnormal, an alarm sounds and manual intervention is required; if everything is normal, the upgrade operation continues. The BOOT program extracts data packets from the APP firmware file according to the specified format, decodes them, writes them to the corresponding FLASH memory, and rewrites the auxiliary file. Once all firmware data has been written to FLASH, the upgrade version and record are written to the corresponding FLASH location for easy tracking and maintenance. Then, the BOOT program jumps to the APP program startup location and starts the APP program.

[0029] In addition, if the operator does not want to upgrade via the network port, they can also use an SD card as the upgrade medium. The encrypted firmware file and the written auxiliary file are copied to the SD card and inserted into the control board to perform the firmware upgrade operation.

[0030] To improve security and success rate, and to handle emergencies, this application includes the following features: (1) Host computer-side "targeted encryption encoding" algorithm To enhance security and prevent firmware from being intercepted, tampered with, or flashed onto the wrong device during transmission, the host computer encrypts the original firmware data before sending it.

[0031] Algorithm Design: A hybrid encryption algorithm based on XOR and Shift is adopted, with the following formula: Ci = (Pi ⊕ Ki) ≫ Si Where Ci: the i-th byte of data after encryption; Pi: the i-th byte of data in the original firmware; Ki: the i-th byte of the dynamic key (a hash sequence generated from the device's MAC address to ensure that different devices have different decryption keys); ⊕: bitwise XOR operation; ≫: logical right shift operation; Si: offset (Si=imod8, dynamically changes with the byte position, increasing the difficulty of cracking).

[0032] Auxiliary file generation: The host computer will generate an auxiliary file (binary file) containing a "device ID-key mapping table" and a "version number" according to the above algorithm, and distribute it together with the encrypted firmware package.

[0033] (2) The data structure of the “auxiliary file” and the SD card coordination logic Data structure: Auxiliary file custom binary structure, containing the following fields: Device_MAC (target device MAC), Firmware_Version (new firmware version), CRC32_Checksum (encryption packet checksum), File_Size (packet size), and Encryption_Method (encryption method identifier).

[0034] Collaborative logic: Ethernet upgrade mode: After receiving data from the host computer, the APP program first compares the Device_MAC in the auxiliary file with that of the local machine. If they do not match, the data packet is discarded and a NACK (negative acknowledgment) signal is sent to the host.

[0035] SD Card Upgrade Mode: The BOOT program scans the root directory of the SD card upon startup. If an auxiliary file is detected, its Firmware_Version is parsed. If the version number is higher than the version currently recorded in the BOOT log, the upgrade process is allowed; otherwise, it is skipped to prevent downgrade attacks or duplicate upgrades.

[0036] (3) Handshake protocol and conflict avoidance for parallel upgrades of multiple control boards This solution supports the host computer to simultaneously send upgrade commands to multiple control boards (all online devices under the same network segment of the host computer's IP) via Ethernet.

[0037] Handshake Protocol: After the host computer sends a broadcast upgrade command, the APP programs on each control board enter a listening state. The host computer uses a Time Division Multiplexing (TDMA) polling mechanism: it first sends a small chunk of data to device A, and device A immediately replies with an ACK upon receiving it. Only after receiving the ACK does the host computer send data to the next device.

[0038] Congestion avoidance: A sliding window mechanism is set up, with each device buffering a maximum of 2 data packets. If the window is full, the device will pause replying to ACKs. The host computer will automatically slow down and retransmit after detecting a timeout to prevent network storms.

[0039] Independent verification and progress reporting: Each control board independently runs a CRC16 check before writing data to Flash. Every 10% of the data is written, a progress bar is broadcast to the host computer via UDP, and the host computer interface displays the status of each channel in real time.

[0040] (4) Anomaly handling effects and recovery mechanisms This method incorporates a robust mechanism for handling and recovering from abnormal circuit breakers. Simulated Scenario 1 (Network cable disconnection / host computer outage): If the Ethernet upgrade is interrupted midway, the APP program detects a heartbeat timeout (e.g., no data for 3 consecutive seconds), immediately stops writing, and locks the Flash in its current state. After restarting the device, the BOOT program detects that the Flash is not marked as "upgrade complete" and automatically jumps back to the original APP program, ensuring that the device does not crash.

[0041] Simulated Scenario 2 (SD Card Removal): If the SD card is removed during the writing process, the hardware watchdog will reset the microcontroller if it does not detect a write completion signal within a specified time. Because the BOOT program has integrity checks, corrupted firmware will not be executed after the reset.

[0042] Recovery time: After various abnormal interruptions, the average time for the device to power on again and attempt recovery is < 2 seconds. Flash integrity verification pass rate reaches 100%.

[0043] (5) Comparison of data (as shown in Table 1) and beneficial effects Table 1. Quantitative comparison between the method of this application and the traditional J-Link one-by-one programming method:

[0044] The current calibration method in this scheme has the following advantages: 1. This upgrade method can achieve one-to-many upgrades. As long as the control board is connected to the computer via a network cable, it can be upgraded simultaneously, thus improving upgrade efficiency.

[0045] 2. This upgrade method does not require additional upgrade tools. The upgrade operation can be performed directly through the device's original network cable, SD card, etc., which is more convenient and secure.

[0046] 3. This upgrade method will leave upgrade version and records on the host computer and the microcontroller software. On-site personnel and maintenance personnel can track the equipment upgrade status through the records and match them with the equipment production software to facilitate the recording of equipment operation history.

[0047] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for upgrading firmware of a microcontroller, characterized in that, A control board comprising a microcontroller, a network port, and an SD card, used in battery formation or capacity testing equipment, wherein the firmware of the microcontroller is divided into an APP program and a BOOT program, and the method includes the following steps: S10, During the operation of the APP program, an upgrade command issued by the host computer is received through the network port. The upgrade command is divided into a first type of upgrade command that upgrades within the APP program and a second type of upgrade command that jumps to the BOOT program for upgrade. S20, when the first type of upgrade command is received, the APP program requests a firmware data packet from the host computer and verifies the received firmware data packet, which has been encrypted and encoded and has a verification code added. If the verification is successful, the firmware data packet is written to the corresponding file in the SD card according to the number, and the auxiliary file is edited to record the firmware information. If the verification fails, a request is sent to the host computer to resend the corresponding firmware data packet; After the firmware data packet is received, the APP program restarts the microcontroller and jumps to the BOOT program; S30, when the second type of upgrade command is received, the APP program edits the auxiliary file, restarts the microcontroller, and jumps to the BOOT program; S40, in the BOOT program, when the upgrade command is parsed from the data received from the network port, the host computer is requested to request a firmware data packet according to the upgrade command. The received firmware data packet is verified. After the verification is passed, the firmware data packet is written to the specified FLASH location according to the number and the auxiliary file is edited to record the firmware information. Then, the program jumps to the APP program startup location and starts the APP program. S50, in the BOOT program, if the upgrade command is not parsed from the network port or no network port data is received, the SD card is checked for normal operation. If the SD card is normal, the auxiliary file is read and the firmware information in the auxiliary file is used to determine whether to perform the upgrade operation. If the upgrade operation is determined to be performed, the firmware file is read from the SD card, decoded and written to the specified FLASH location, and then the program is redirected to the APP program startup location and the APP program is started.

2. The microcontroller firmware upgrade method as described in claim 1, characterized in that, In step S20, the encryption encoding process adopts a hybrid encryption algorithm based on XOR operation and bitwise operation. The encryption formula is Ci=(Pi⊕ Ki) ≫ Si, where Ci is the data of the i-th byte after encryption, Pi is the data of the i-th byte of the original firmware, Ki is the i-th byte of the dynamic key, ⊕ is the bitwise XOR operation, >> is the logical right shift operation, and Si is the bitwise offset.

3. The microcontroller firmware upgrade method as described in claim 2, characterized in that, The dynamic key consists of a hash sequence generated from the MAC address of the control board; the checksum is a CRC16 checksum.

4. The microcontroller firmware upgrade method as described in claim 1, characterized in that, The auxiliary file is a binary file that contains a device MAC field, a firmware version field, a CRC32 checksum field, a firmware package size field, and an encryption method identifier field.

5. The microcontroller firmware upgrade method as described in claim 1, characterized in that, In step S20, the auxiliary file contains a device MAC field; when the APP program receives the firmware data packet, it also reads the device MAC field in the auxiliary file. If the device MAC field is inconsistent with the MAC of the control board itself, the received firmware data packet is discarded and a negative response signal is sent to the host computer.

6. The microcontroller firmware upgrade method as described in claim 1, characterized in that, When the APP program or the BOOT program requests the host computer to resend the corresponding firmware data packet, if the number of resends exceeds the limit, data reception will be stopped and an alarm will be issued.

7. The microcontroller firmware upgrade method as described in claim 1, characterized in that, In step S50, it is determined whether to perform an upgrade operation based on the firmware information in the auxiliary file. Specifically, the firmware version field in the auxiliary file is parsed. If the version indicated by the firmware version field is higher than the version currently recorded by the BOOT program, it is determined to perform an upgrade operation. Otherwise, the upgrade process will be skipped and the app will be launched directly from the app launch location.

8. The microcontroller firmware upgrade method as described in claim 1, characterized in that, The host computer simultaneously sends upgrade commands to multiple control boards via Ethernet. It employs a time-division multiplexing polling mechanism to sequentially send firmware data packets to each control board. Each control board replies with an acknowledgment signal upon receiving the firmware data packet. The host computer sets a sliding window for each control board, with each board buffering a maximum of two data packets. When the buffer is full, the control board pauses replying with acknowledgment signals. Upon detecting a timeout, the host computer reduces the sending rate and retransmits the data. Each control board independently performs CRC16 verification before writing to the FLASH memory. After completing 10% of the data writing, each control board reports its progress to the host computer via UDP broadcast.

9. The microcontroller firmware upgrade method as described in claim 1, characterized in that, It also includes exception handling steps: when the APP program detects a heartbeat timeout during the Ethernet upgrade process, it stops writing and locks the FLASH in the current state. After restarting, if the BOOT program detects that the FLASH is not marked as upgraded, it jumps back to the original APP program; when the SD card is removed during the SD card writing process, the hardware watchdog does not detect a write completion signal within a specified time and resets the microcontroller. After the reset, the corrupted firmware is not executed.

10. A microcontroller firmware upgrade system, employing the microcontroller firmware upgrade method as described in any one of claims 1 to 9, characterized in that, The system includes a host computer and multiple control boards. The host computer is used to send firmware data packets that have been encrypted and encoded and have added verification codes, and to receive progress data reported by each control board. Each control board includes a microcontroller, a network port, and an SD card. The firmware of the microcontroller is divided into an APP program and a BOOT program. The control board communicates with the host computer through the network port, stores firmware data packets and auxiliary files through the SD card, and executes the microcontroller firmware upgrade method.

Images