Multi-board card cooperative firmware upgrading method, system and medium for medical and beauty equipment
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ADSS DEV
- Filing Date
- 2026-03-24
- Publication Date
- 2026-07-14
Smart Images
Figure CN122387486A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded device firmware upgrade technology, and in particular to a method, system, device and medium for multi-board collaborative firmware upgrade of medical aesthetic devices. Background Technology
[0002] With the rapid development of technology in the medical aesthetics industry, the functions of medical aesthetic devices are becoming increasingly complex and integrated. They typically contain multiple independent control boards that work together to achieve various medical aesthetic functions. Typical examples include a main control board responsible for overall scheduling, a handle control board that performs specific medical aesthetic operations, a disassembly protection board to ensure safe operation, and a motor drive board that drives the actuators. Each board is equipped with an independent processor and dedicated firmware. As the core program for device operation, firmware iteration and optimization are crucial for ensuring device performance, fixing operational vulnerabilities, and expanding new functions. Therefore, firmware upgrades have become an important part of the entire lifecycle maintenance of medical aesthetic devices.
[0003] Current firmware upgrade solutions for multi-board medical aesthetic devices still have many shortcomings, making it difficult to meet the actual needs of on-site maintenance and rapid upgrades. Firstly, the upgrade process is cumbersome and requires a high level of expertise, necessitating the use of specialized tools such as JTAG and USB-to-serial adapters to connect each board individually to the host computer for upgrades. This requires not only professional technicians but also disassembly of the device, making the upgrade process time-consuming and labor-intensive. Secondly, the firmware version compatibility among multiple boards is poor. Existing solutions lack a unified version management and matching mechanism, easily leading to inconsistencies in firmware versions across boards, which in turn cause functional differences in the device. First, the firmware upgrades are often unstable and may even cause equipment failure. Second, the upgrades are not convenient or universal enough. Ordinary users or on-site service personnel cannot complete the upgrade operation independently. The firmware upgrade usually requires the device to be returned to the factory for processing or to be serviced by the manufacturer's professional engineers, which greatly increases the maintenance cost of the device and extends the maintenance cycle. Third, existing general firmware upgrade solutions such as FOTA and single serial port upgrades are only applicable to upgrade scenarios of a single device or a single main processor. They cannot be adapted to the specific hardware architecture of the main screen, main controller, and multiple slave boards of medical aesthetic equipment, and it is difficult to solve the problems of collaborative upgrades, secure transmission, and convenient control between multiple boards.
[0004] Therefore, there is an urgent need for a multi-board collaborative firmware upgrade method for medical aesthetic devices to solve the technical problems of existing multi-board firmware upgrade operations, which are cumbersome, rely on professional tools and personnel, have difficulty in matching firmware versions of different boards, which can easily lead to device malfunctions, users cannot upgrade independently, have high maintenance costs, and existing general upgrade solutions cannot be adapted to the hardware architecture of medical aesthetic devices, which consists of a main screen, a main control unit, and multiple slave boards. Summary of the Invention
[0005] To overcome the problems existing in related technologies, this disclosure provides a method, system, device, and medium for multi-board collaborative firmware upgrade of medical aesthetic devices. This addresses the technical problems of existing medical aesthetic devices, such as cumbersome multi-board firmware upgrade operations, reliance on professional tools and personnel, difficulty in coordinating and matching firmware versions of different boards leading to device malfunctions, inability for users to upgrade independently, high maintenance costs, and the inability of existing general upgrade solutions to adapt to the hardware architecture of medical aesthetic devices, which consists of a main screen, main control unit, and multiple slave boards.
[0006] This specification provides one or more embodiments of a multi-board collaborative firmware upgrade method for medical aesthetic devices, including the following steps: The interactive screen responds to the access of external storage media, reads and identifies firmware files, extracts board type, firmware file, and determines the list of boards to be upgraded; The interactive screen communicates with each board through a private communication protocol to obtain the status information of each board, determines the board to be upgraded based on the status information and the firmware file, and performs an upgrade handshake with the board to be upgraded. The interactive screen sends the firmware data of the board to be upgraded through a standard file transfer protocol. The host control board uses different data processing methods for itself and the slave boards to complete the firmware burning of each board to be upgraded. Each board verifies the firmware it has burned. If the verification is successful, it modifies the flag bit stored locally and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
[0007] Preferably, the interactive screen, in response to the access of an external storage medium, reads and identifies the firmware file, extracts the board type, firmware file, and determines the list of boards to be upgraded, specifically including the following steps: The interactive screen scans a specified directory on the external storage medium and identifies firmware files that conform to a predetermined naming rule; The corresponding board type is determined based on the file name of the firmware file, and the board type is displayed to the user in a predetermined order; In response to the user's confirmation of the card type, the corresponding card is added to the list of cards to be upgraded.
[0008] Preferably, the interactive screen communicates with each board via a proprietary communication protocol to obtain the status information of each board, determines the board to be upgraded based on the status information and the firmware file, and performs an upgrade handshake with the board to be upgraded, specifically including the following steps: The interactive screen sends query commands to each board to obtain the current version information of each board; The current version information is compared with the firmware version information to determine the board to be upgraded; Send an upgrade command to the board to be upgraded, triggering the board to reset and enter the bootloader upgrade mode; The interactive screen performs a handshake confirmation with the board that has entered the bootloader mode, preparing to start data transmission.
[0009] Preferably, the host control board uses different data processing methods for itself and subordinate boards to complete the firmware burning of each board to be upgraded, specifically including the following steps: If the card to be upgraded is a host control board, the interactive screen directly establishes a standard file transfer protocol connection with the host control board, sends firmware data packets, and the host control board directly receives and burns them into its own Flash. If the card to be upgraded is a slave card, the interactive screen sends an upgrade notification to the host control board. The host control board enters transparent forwarding mode, and the firmware data packet sent by the interactive screen is forwarded to the target slave card in real time by the host control board. The slave card receives the data packet and burns it into its own Flash.
[0010] Preferably, each board verifies the burned firmware. Upon successful verification, it modifies the locally stored flag and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process, specifically including the following steps: After the firmware of a single board is burned, the firmware is verified or the version number is compared to determine whether the upgrade is successful. If the verification is successful, the board will change the flag to the running mode state, jump from the bootloader to the new firmware's App program, and send the upgrade success status back to the interactive screen; If the verification fails, the board reports the upgrade failure status to the interactive screen; The interactive screen performs upgrades on the next board to be upgraded in a preset order until all boards to be upgraded have been processed. The interactive screen summarizes the upgrade results of all boards, generates an upgrade report and displays it. If all boards are upgraded successfully, the user is prompted to restart the device to complete the upgrade.
[0011] Preferably, the method further includes the following steps: If the upgrade verification of a single board fails, it will automatically restart and re-enter the bootloader, and initiate a handshake signal. The interactive screen allows users to re-execute the upgrade steps for the board. If a system-level problem such as communication interruption or external storage medium abnormality occurs during the upgrade process, the interactive screen records the information of the currently failed board and continues to upgrade the remaining boards to be upgraded. After the upgrade is completed, a list of failed boards is displayed, allowing users to choose to retry the entire upgrade or cancel the upgrade.
[0012] This specification provides one or more embodiments of a multi-board collaborative firmware upgrade system for medical aesthetic devices, including: The trigger module is used for the interactive screen to respond to the access of external storage media, read and identify firmware files, extract board type, firmware file and determine the list of boards to be upgraded; The handshake module is used for the interactive screen to communicate with each board through a private communication protocol, obtain the status information of each board, determine the board to be upgraded based on the status information and the firmware file, and perform an upgrade handshake with the board to be upgraded. The hierarchical transmission module is used by the interactive screen to send the firmware data of the board to be upgraded through the standard file transfer protocol. The host control board adopts different data processing methods for itself and the subordinate boards to complete the firmware burning of each board to be upgraded. The verification module is used by each board to verify the firmware burned in. After successful verification, the locally stored flag bit is modified and the system is reset to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
[0013] Preferably, the triggering module is further configured as follows: If the board to be upgraded is the host control board, the host control board receives and processes the firmware data to upgrade itself. If the card to be upgraded is a slave card, the host control board receives the firmware data and forwards it to the corresponding target slave card in real time and transparently.
[0014] This specification provides one or more embodiments of a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-board collaborative firmware upgrade method for medical aesthetic devices as described above.
[0015] This specification provides one or more embodiments of a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the multi-board collaborative firmware upgrade method for medical aesthetic devices described above.
[0016] This disclosure provides a method, system, device, and medium for multi-board collaborative firmware upgrades of medical aesthetic devices. Its advantages lie in that, through an interactive screen responding to the access of external storage media, it reads and identifies firmware files, extracts board types, firmware files, and determines a list of boards to be upgraded. It can automatically identify firmware files in external storage devices and quickly determine the types and list of boards to be upgraded based on file content, thereby simplifying user operation, avoiding manual selection errors, and improving the automation and accuracy of the upgrade process. The interactive screen communicates with each board through a proprietary communication protocol to obtain the status information of each board. Based on the status information and the firmware file, it determines the boards to be upgraded and performs an upgrade handshake with the boards to be upgraded. The proprietary protocol obtains the working status of each board in real time, ensuring that only boards with normal and matching status are included in the upgrade scope, avoiding upgrade failures due to board abnormalities or incompatible statuses. Simultaneously, the handshake mechanism establishes a reliable communication link for subsequent data transfer. The transmission lays the foundation; the interactive screen sends the firmware data of the boards to be upgraded via a standard file transfer protocol. The host control board uses different data processing methods for itself and its subordinate boards to complete the firmware burning for each board to be upgraded. The standard file transfer protocol ensures the compatibility and stability of data transmission. At the same time, the host control board adopts an appropriate data processing strategy according to its own and its subordinate boards' different roles, realizing parallel or time-sharing burning of multiple boards, thereby improving upgrade efficiency and ensuring accurate data writing. Each board verifies the burned firmware. After successful verification, it modifies the locally stored flag bit and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process. Firmware verification ensures the integrity and correctness of the burned data, preventing device failure due to data corruption. Modifying the flag bit and resetting makes the new firmware effective. At the same time, the interactive screen uniformly records the upgrade results of each board, which is convenient for subsequent query and fault tracing, ensuring the safety and reliability of the upgrade process. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in one or more embodiments of this specification or in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a multi-board collaborative firmware upgrade method for medical aesthetic devices, provided for one or more embodiments of this specification; Figure 2 The physical connection relationship between the Android screen, host control board, and each slave board provided in one or more embodiments of this specification; Figure 3 A general flowchart of a multi-board collaborative firmware upgrade method for medical aesthetic devices provided in one or more embodiments of this specification; Figure 4 This is a timing diagram illustrating the interaction between the private protocol instructions and Ymodem data between the Android screen, the host control board, and the slave board, as provided in one or more embodiments of this specification. Figure 5 Timing diagrams for slave board upgrade communication provided for one or more embodiments of this specification; Figure 6 A schematic diagram of a multi-board collaborative firmware upgrade system for medical aesthetic devices, provided for one or more embodiments of this specification; Figure 7 This is a schematic diagram of the structure of a computer device provided for one or more embodiments of this specification. Detailed Implementation
[0019] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this invention.
[0020] The present invention will now be described in detail with reference to specific embodiments and accompanying drawings.
[0021] Method Implementation Examples According to embodiments of the present invention, a multi-board collaborative firmware upgrade method for medical aesthetic devices is provided, such as... Figure 1The diagram shows a flowchart of a multi-board collaborative firmware upgrade method for medical aesthetic devices provided in this embodiment. The medical aesthetic device includes an interactive screen, a host control board, and multiple slave boards. The host control board is communicatively connected to the interactive screen and the multiple slave boards. The Android main interactive screen serves as the upgrade entry point, has a USB Host interface, runs an upgrade management program, and its Android screen application is responsible for file management, protocol scheduling, and interface interaction. The host control board acts as a data relay hub, connecting to the Android screen and each slave board via multiple UART interfaces to achieve private protocol parsing, data forwarding, and status management. For example, the host control board's UART1 connects to the Android screen and is responsible for interacting with it. The host control board's UART2 connects to the handle board. The host control board's UART3 connects to the security board. After receiving a data packet, the host control board does not forward data packets for upgrading the host control board; data packets from other boards are transparently forwarded. When the function code confirms that an upgrade is possible, the software automatically resets and enters the bootloader program, detecting a specific flag (which can be the flag mentioned in the original text or other flags). Process Description: If the firmware being upgraded is for the host control board, the host control board will not forward data but will receive data to upgrade its own firmware. If other boards are being upgraded (such as gamepad boards or security boards), the host acts as a transparent forwarding intermediary. After all board upgrade processes are completed, the boards automatically enter normal operating mode. Slave Board Cluster: Includes gamepad control boards, disassembly protection boards, etc., each with an independent bootloader, supporting proprietary protocol handshake commands and the Ymodem protocol. External Upgrade Media: USB flash drive, storing firmware files with standardized naming conventions, located in the / GoldNeedle / directory, e.g., Figure 2 The diagram shows the physical connection relationship between the Android screen, the host control board, and the various slave boards provided in this embodiment.
[0022] A multi-board collaborative firmware upgrade method for medical aesthetic devices according to an embodiment of the present invention includes the following steps: S110, the interactive screen responds to the access of the external storage medium, reads and identifies the firmware file, extracts the board type, firmware file and determines the list of boards to be upgraded, wherein the external storage medium stores firmware files with naming conventions.
[0023] S120. The interactive screen communicates with each board through a private communication protocol to obtain the status information of each board. Based on the status information and the firmware file, it determines the board to be upgraded, issues an upgrade command, and responds to the board to be upgraded, entering the upgrade-ready state of the bootloader to perform an upgrade handshake. Each board starts from the bootloader every time it is powered on. The bootloader detects the flag bit of the MCU Flash: if the flag bit is 0x55555555, it directly jumps to the App program to enter the normal operation mode; if the flag bit is 0xAAAAAAAA, it enters the upgrade mode and actively sends a handshake signal; if the flag bit is 0xFFFFFFFF, it is determined to be in an invalid state and enters the handshake process to wait for instructions; after the App program of the board starts, if it detects that the flag bit is not 0x55555555, it automatically modifies the flag bit to 0x55555555.
[0024] S130. The interactive screen sends the firmware data of the board to be upgraded via a standard file transfer protocol. The host control board uses different data processing methods for itself and its subordinate boards to complete the firmware burning for each board to be upgraded. Specifically, this includes the following steps: If the card to be upgraded is a host control board, the interactive screen directly establishes a standard file transfer protocol connection with the host control board, sends firmware data, and the host control board directly receives and burns it into its own Flash. If the card to be upgraded is a slave card, the interactive screen sends an upgrade notification to the host control board. The host control board then enters transparent forwarding mode. The firmware data packet sent by the interactive screen is forwarded to the target slave card in real time by the host control board. The slave card receives and burns the data into its own Flash memory. The host control board does not parse or cache firmware data during the transparent forwarding process. The standard file transfer protocol is the Ymodem protocol. In case of data packet forwarding errors, the Ymodem protocol fault tolerance mechanism and the timeout retransmission mechanism of the upgrade control terminal will handle the situation.
[0025] S140. Each board verifies the firmware it has burned. If the verification is successful, it modifies the flag bit stored locally and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
[0026] like Figure 3 The diagram shown is the overall flowchart of the multi-board collaborative firmware upgrade method for medical aesthetic devices provided in this embodiment.
[0027] The method provided in this embodiment responds to the access of external storage media via an interactive screen, reads and identifies firmware files, extracts board type, firmware file, and determines a list of boards to be upgraded. It can automatically identify firmware files in external storage devices and quickly determine the types and lists of boards to be upgraded based on file content, thereby simplifying user operations, avoiding manual selection errors, and improving the automation and accuracy of the upgrade process. The interactive screen communicates with each board through a proprietary communication protocol to obtain the status information of each board. Based on the status information and the firmware file, it determines the boards to be upgraded and performs an upgrade handshake with the boards to be upgraded. The proprietary protocol obtains the working status of each board in real time, ensuring that only boards with normal and matching status are included in the upgrade scope, avoiding upgrade failures due to board abnormalities or incompatible statuses. Simultaneously, the handshake mechanism establishes a reliable communication link, laying the foundation for subsequent data transmission. The interactive screen uses standard... The firmware data of the boards to be upgraded is sent via a file transfer protocol. The host control board uses different data processing methods for itself and its slave boards to complete the firmware burning for each board to be upgraded. The standard file transfer protocol ensures the compatibility and stability of data transmission. At the same time, the host control board adopts an appropriate data processing strategy according to the different roles of itself and its slave boards to achieve parallel or time-sharing burning of multiple boards, thereby improving upgrade efficiency and ensuring accurate data writing. Each board verifies the burned firmware. If the verification is successful, the flag bit in the local storage is modified and the board is reset to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process. Firmware verification ensures the integrity and correctness of the burned data, preventing device failure due to data corruption. Modifying the flag bit and resetting the board makes the new firmware effective. At the same time, the interactive screen records the upgrade results of each board for easy subsequent query and fault tracing, ensuring the safety and reliability of the upgrade process.
[0028] In one embodiment, in response to the access of an external storage medium, the interactive screen reads and identifies the firmware file, extracts the board type, firmware file, and determines the list of boards to be upgraded, specifically including the following steps: The interactive screen scans a designated directory on the external storage medium and identifies firmware files that conform to a predetermined naming rule. The firmware files are named in a fixed format as .bin files according to the board type, and the interactive screen identifies the board type by the file name.
[0029] The corresponding board type is determined based on the file name of the firmware file, and the board type is displayed to the user in a predetermined order of host control board, handle control board, disassembly protection board, and motor drive board.
[0030] The user can choose to confirm the upgrade or cancel. In response to the user's confirmation operation on the card type, the cards that have not been canceled will be added to the list of cards to be upgraded.
[0031] The method provided in this embodiment involves an interactive screen scanning a designated directory on an external storage medium to identify firmware files that conform to predetermined naming rules. It automatically locates and filters legitimate firmware files, avoiding manual searching and accidental operations by the user, thus improving the convenience and security of the upgrade process. The method determines the corresponding board type based on the firmware file's filename and displays the board types to the user in a predetermined order. The board type is parsed through filenames to ensure accurate matching. The orderly display allows the user to clearly understand the upgrade options, optimizing the interactive experience. The method responds to the user's confirmation of the board type, adding the corresponding board to the list of boards to be upgraded. This user confirmation mechanism prevents accidental upgrades or omissions, enhancing the controllability and reliability of the operation.
[0032] In one embodiment, the interactive screen communicates with each board via a private communication protocol to obtain the status information of each board, determines the board to be upgraded based on the status information and the firmware file, and performs an upgrade handshake with the board to be upgraded, specifically including the following steps: The interactive screen sends a private protocol query command of read instruction 0x83 + function code 0xD2 to each board to obtain the current version information, hardware information and CPU serial number of each board.
[0033] The current version information is compared with the firmware version information to determine the board to be upgraded.
[0034] Send an upgrade command to the board to be upgraded - a private protocol command of write command 0x82 + function code 0xD1. The command data field carries the board type identifier and upgrade flag 0x01, triggering the board to reset and enter the bootloader upgrade mode.
[0035] After receiving the upgrade command, the upgrade board sets its own MCU Flash flag to 0xAAAAAAAA, then automatically restarts and enters the bootloader mode. The interactive screen and the board that has entered the bootloader mode perform a handshake confirmation to prepare for data transmission. Specifically, after the bootloader detects that the flag is 0xAAAAAAAA, it sends a private protocol handshake command of write command 0x82 + function code 0xD0 to the upgrade control terminal. After receiving the command, the upgrade control terminal confirms that the board has entered the upgrade ready state.
[0036] The method provided in this embodiment involves the interactive screen sending query commands to each board to obtain the current version information of each board, thereby automatically collecting the current firmware version of each board and providing a data foundation for subsequent version comparison. The current version information is compared with the firmware version information to determine the boards to be upgraded. The version comparison accurately filters out the boards that need to be upgraded, avoiding invalid operations on boards that are already the latest version. An upgrade command is sent to the boards to be upgraded, triggering a board reset and entering the bootloader upgrade mode to prepare for firmware burning. The interactive screen performs a handshake confirmation with the boards that have entered the bootloader mode to prepare for data transmission. The handshake confirmation establishes a reliable communication link to ensure the stability and accuracy of subsequent data transmission.
[0037] In one embodiment, each board verifies the burned firmware. If the verification is successful, it modifies the locally stored flag and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process, specifically including the following steps: After the firmware of a single board is burned, a CRC16 check or version number comparison is performed on the firmware to determine whether the upgrade was successful.
[0038] If the verification is successful, the board will change the MCU Flash flag to 0x55555555 running mode, jump from the bootloader to the new firmware App program, and send the upgrade success status back to the interactive screen.
[0039] If the verification fails, the board will report the upgrade failure status to the interactive screen.
[0040] The interactive screen performs upgrades on the next board to be upgraded in a preset order until all boards to be upgraded have been processed.
[0041] The interactive screen summarizes the upgrade results of all boards, generates an upgrade report and displays it. If all boards are upgraded successfully, the user is prompted to restart the device to complete the upgrade.
[0042] The method provided in this embodiment involves verifying or comparing the firmware version number after a single board has been burned to determine if the upgrade was successful. Verification ensures that the firmware data is complete and the version is correct, effectively preventing device malfunctions caused by burning errors. If the verification is successful, the board changes its flag to the running mode state, jumps from the bootloader to the new firmware's App program, and feeds back the upgrade success status to the interactive screen, enabling the new firmware to take effect automatically and report its status, ensuring the device runs normally and synchronizes progress in real time after the upgrade. If the verification fails, the board reports the upgrade failure status to the interactive screen, promptly reporting the failure information so that the interactive screen can record it and take subsequent actions to prevent the device from running incorrectly. The interactive screen performs the upgrade on the next board to be upgraded in a preset order until all boards to be upgraded are processed, scheduling multiple board upgrades in an orderly manner to ensure efficient and continuous processes and avoid resource conflicts. The interactive screen summarizes the upgrade results of all boards, generates an upgrade report, and displays it. If all boards are upgraded successfully, the user is prompted to restart the device to complete the upgrade, presenting the upgrade results uniformly and providing clear operation guidance to ensure the device ultimately runs stably.
[0043] In one embodiment, the following steps are also included: If the upgrade verification of a single board fails, it will automatically restart and re-enter the bootloader, initiate a handshake signal, and the interactive screen allows users to re-execute the upgrade or cancel the upgrade steps and record the failure information.
[0044] If a system-level problem such as communication interruption or external storage medium abnormality occurs during the upgrade process, the interactive screen records the information of the currently failed board and continues to upgrade the remaining boards to be upgraded. After the upgrade is completed, a list of failed boards is displayed, allowing users to choose to retry the entire upgrade or cancel the upgrade.
[0045] The method provided in this embodiment simplifies fault handling through an automatic recovery mechanism, allowing users to retry individual failed boards, improving the fault tolerance and operational flexibility of the upgrade process, achieving anomaly isolation and task continuation, avoiding single-point failures that could lead to complete system interruption, and providing options for summarizing failed boards and batch retrying, effectively ensuring upgrade efficiency and user experience.
[0046] The upgrade method is further illustrated below through specific implementation examples: Upgrade process: Hardware environment: The Android screen and the host control board are connected via UART2 (baud rate 115200). The main control board is connected to the handle control board via UART1 (baud rate 115200). The host control board is connected to the disassembly protection board via UART3 (baud rate 115200).
[0047] 1. Upgrade Trigger and File Scan: When the user inserts a USB flash drive, the Android screen automatically scans for firmware files in the / GoldNeedle / directory, identifying files such as RF-mainboard.bin and MicroHandle.bin.
[0048] 2. Private Protocol Handshake and Status Inquiry: The Android screen sends a query command (such as function code 0xD2) to obtain information about each board and read the bin file corresponding to a specific file name. For example, RF-mainboard.bin is identified as the host control board upgrade bin file, and MicroHandle.bin is identified as the gamepad control board, etc.
[0049] The version number is extracted from the bin file; the board type is determined by a specific filename. This version number is compared with the version number in the USB drive to determine the upgrade list. For boards that need to be upgraded, send an upgrade judgment command (such as 0xD1) or receive a report from the board. After the board replies, enter the Bootloader and send a 0xD0 handshake command. Perform an upgrade handshake to confirm that the board has entered the Bootloader ready state.
[0050] 3. Hierarchical firmware transmission: like Figure 4 The diagram shown is a timing sequence diagram illustrating the interaction between the private protocol instructions and Ymodem data between the Android screen, the host control board, and the slave board provided in this embodiment.
[0051] Host control board: The Android screen sends firmware directly through Ymodem, and the host control board forwards data to the corresponding serial port according to the board type; Slave board: The Android screen notifies the host control board, which then forwards Ymodem data packets to the target slave board in real time using a "transparent forwarding" mode. For example... Figure 5 The diagram shown is a timing diagram of the slave board upgrade communication provided in this embodiment. It shows in detail how the system securely and reliably completes the firmware upgrade of a slave board (taking the gamepad control board as an example) through a hybrid mechanism of "private protocol handshake + standard Ymodem transmission" after the user confirms the upgrade.
[0052] 4. Result Verification and Restart: After each board upgrade, the CRC or version number is verified. A restart is prompted upon successful verification of all results. Private Communication Protocol Design: Table 1 shows the protocol frame structure.
[0053] Table 2 lists the key upgrade-related function codes.
[0054] Bootloader and flag mechanism: After the bootloader of each board starts, it checks the flag bits in the Flash memory: 0x55555555: Redirects to the App; 0xAAAAAAAA: Enter upgrade mode and send handshake signal; 0xFFFFFFFF: Invalid state, proceed with handshake process.
[0055] The flag bit is stored in a specific sector of the MCU's Flash memory, at the last sector location. Programmed data will not overwrite that sector. Upon power-up, the system checks the flag bit to determine whether an upgrade is needed or if the application can proceed directly. Each time power-up is activated, the program starts running from the bootloader. The bootloader checks the flag bit to determine whether to enter the upgrade process or proceed with application execution. If the application starts up and finds the flag bit not in a running state, it sets it to the running state.
[0056] Data forwarding mechanism: During slave board upgrades, the host control board acts as a transparent transmission channel, neither parsing nor buffering Ymodem data packets. It simply forwards data packets to the corresponding UART interface in real time based on the type of the upgraded board. In case of forwarding errors, the Ymodem protocol itself and the Android screen's timeout retransmission mechanism handle the situation.
[0057] Exception handling and rollback: Single board upgrade failed: The board will restart and re-enter the Bootloader handshake process. You can try the upgrade again. System-level error: Android screen recording failed on the board. Continue upgrading the remaining boards. Users can choose to retry or cancel.
[0058] System Implementation Examples According to embodiments of the present invention, a multi-board collaborative firmware upgrade system for medical aesthetic devices is provided, such as... Figure 6 The diagram shown is a structural schematic of a multi-board collaborative firmware upgrade system for medical aesthetic devices provided in this embodiment. The multi-board collaborative firmware upgrade system for medical aesthetic devices according to this embodiment includes: Trigger module 61 is used for the interactive screen to respond to the access of external storage media, read and identify firmware files, extract board type, firmware file and determine the list of boards to be upgraded.
[0059] The handshake module 62 is used for the interactive screen to communicate with each board through a private communication protocol, obtain the status information of each board, determine the board to be upgraded based on the status information and the firmware file, and perform an upgrade handshake with the board to be upgraded.
[0060] The hierarchical transmission module 63 is used by the interactive screen to send the firmware data of the board to be upgraded through the standard file transfer protocol. The host control board adopts different data processing methods for itself and the subordinate boards to complete the firmware burning of each board to be upgraded.
[0061] The verification module 64 is used to verify the firmware burned by each board. After successful verification, the locally stored flag bit is modified and the system is reset to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
[0062] The system provided in this embodiment, through the trigger module 61 interactive screen responding to the access of external storage media, reads and identifies firmware files, extracts board type, firmware files, and determines the list of boards to be upgraded. It can automatically identify firmware files in external storage devices and quickly determine the types and lists of boards to be upgraded based on file content, thereby simplifying user operation, avoiding manual selection errors, and improving the automation and accuracy of the upgrade process; the handshake module 62 interactive screen communicates with each board through a private communication protocol to obtain the status information of each board, determines the boards to be upgraded based on the status information and the firmware file, and performs an upgrade handshake with the boards to be upgraded. Through the private protocol, it obtains the working status of each board in real time, ensuring that only boards with normal and matching status are included in the upgrade scope, avoiding upgrade failures due to board abnormalities or incompatible statuses. At the same time, the handshake mechanism establishes a reliable communication link, laying the foundation for subsequent data transmission; the hierarchical transmission module 63... The interactive screen sends the firmware data of the boards to be upgraded via a standard file transfer protocol. The host control board uses different data processing methods for itself and its subordinate boards to complete the firmware burning for each board to be upgraded. The standard file transfer protocol ensures the compatibility and stability of data transmission. At the same time, the host control board adopts an appropriate data processing strategy according to the different roles of itself and its subordinate boards to achieve parallel or time-sharing burning of multiple boards, thereby improving upgrade efficiency and ensuring accurate data writing. The verification module 64 verifies the burned firmware for each board. After successful verification, it modifies the locally stored flag bit and resets the system to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process. Firmware verification ensures the integrity and correctness of the burned data, preventing device failure due to data corruption. Modifying the flag bit and resetting the system makes the new firmware effective. At the same time, the interactive screen uniformly records the upgrade results of each board for easy subsequent query and fault tracing, ensuring the safety and reliability of the upgrade process.
[0063] The embodiments of the present invention are system embodiments corresponding to the above method embodiments. The specific operations of each module processing step can be understood by referring to the description of the method embodiments, and will not be repeated here.
[0064] like Figure 7 As shown, the present invention also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements the multi-board collaborative firmware upgrade method for medical aesthetic devices in the above embodiments, or when the computer program is executed by a processor, it implements the multi-board collaborative firmware upgrade method for medical aesthetic devices in the above embodiments.
[0065] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0066] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatus or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The apparatus and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0067] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and the contents not described in detail in the specification of the present invention are known to those skilled in the art.
Claims
1. A method for multi-board collaborative firmware upgrade of medical aesthetic devices, characterized in that, Includes the following steps: The interactive screen responds to the access of external storage media, reads and identifies firmware files, extracts board type, firmware file, and determines the list of boards to be upgraded; The interactive screen communicates with each board through a private communication protocol to obtain the status information of each board, determines the board to be upgraded based on the status information and the firmware file, and performs an upgrade handshake with the board to be upgraded. The interactive screen sends the firmware data of the board to be upgraded through a standard file transfer protocol. The host control board uses different data processing methods for itself and the slave boards to complete the firmware burning of each board to be upgraded. Each board verifies the firmware it has burned. If the verification is successful, it modifies the flag bit stored locally and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
2. The multi-board collaborative firmware upgrade method for medical aesthetic equipment as described in claim 1, characterized in that, The interactive screen responds to the access of external storage media by reading and identifying firmware files, extracting board type, firmware files, and determining the list of boards to be upgraded, specifically including the following steps: The interactive screen scans a specified directory on the external storage medium and identifies firmware files that conform to a predetermined naming rule; The corresponding board type is determined based on the file name of the firmware file, and the board type is displayed to the user in a predetermined order; In response to the user's confirmation of the card type, the corresponding card is added to the list of cards to be upgraded.
3. The multi-board collaborative firmware upgrade method for medical aesthetic equipment as described in claim 2, characterized in that, The interactive screen communicates with each board through a private communication protocol to obtain the status information of each board. Based on the status information and the firmware file, it determines the board to be upgraded and performs an upgrade handshake with the board to be upgraded, specifically including the following steps: The interactive screen sends query commands to each board to obtain the current version information of each board; The current version information is compared with the firmware version information to determine the board to be upgraded; Send an upgrade command to the board to be upgraded, triggering the board to reset and enter the bootloader upgrade mode; The interactive screen performs a handshake confirmation with the board that has entered the bootloader mode, preparing to start data transmission.
4. The multi-board collaborative firmware upgrade method for medical aesthetic equipment as described in claim 1, characterized in that, The host control board uses different data processing methods for itself and its subordinate boards to complete the firmware burning for each board to be upgraded, specifically including the following steps: If the card to be upgraded is a host control board, the interactive screen directly establishes a standard file transfer protocol connection with the host control board, sends firmware data packets, and the host control board directly receives and burns them into its own Flash. If the card to be upgraded is a slave card, the interactive screen sends an upgrade notification to the host control board. The host control board enters transparent forwarding mode, and the firmware data packet sent by the interactive screen is forwarded to the target slave card in real time by the host control board. The slave card receives the data packet and burns it into its own Flash.
5. The multi-board collaborative firmware upgrade method for medical aesthetic equipment as described in claim 1, characterized in that, Each board verifies the burned firmware. If the verification is successful, it modifies the locally stored flag and resets to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process, which specifically includes the following steps: After the firmware of a single board is burned, the firmware is verified or the version number is compared to determine whether the upgrade is successful. If the verification is successful, the board will change the flag to the running mode state, jump from the bootloader to the new firmware's App program, and send the upgrade success status back to the interactive screen; If the verification fails, the board reports the upgrade failure status to the interactive screen; The interactive screen performs upgrades on the next board to be upgraded in a preset order until all boards to be upgraded have been processed. The interactive screen summarizes the upgrade results of all boards, generates an upgrade report and displays it. If all boards are upgraded successfully, the user is prompted to restart the device to complete the upgrade.
6. The multi-board collaborative firmware upgrade method for medical aesthetic equipment as described in claim 1, characterized in that, It also includes the following steps: If the upgrade verification of a single board fails, it will automatically restart and re-enter the bootloader, and initiate a handshake signal. The interactive screen allows users to re-execute the upgrade steps for the board. If a system-level problem such as communication interruption or external storage medium abnormality occurs during the upgrade process, the interactive screen records the information of the currently failed board and continues to upgrade the remaining boards to be upgraded. After the upgrade is completed, a list of failed boards is displayed, allowing users to choose to retry the entire upgrade or cancel the upgrade.
7. A multi-board collaborative firmware upgrade system for medical aesthetic equipment, characterized in that, include: The trigger module is used for the interactive screen to respond to the access of external storage media, read and identify firmware files, extract board type, firmware file and determine the list of boards to be upgraded; The handshake module is used for the interactive screen to communicate with each board through a private communication protocol, obtain the status information of each board, determine the board to be upgraded based on the status information and the firmware file, and perform an upgrade handshake with the board to be upgraded. The hierarchical transmission module is used by the interactive screen to send the firmware data of the board to be upgraded through the standard file transfer protocol. The host control board adopts different data processing methods for itself and the subordinate boards to complete the firmware burning of each board to be upgraded. The verification module is used by each board to verify the firmware burned in. After successful verification, the locally stored flag bit is modified and the system is reset to run the new firmware. The interactive screen records the upgrade results of all boards and completes the upgrade process.
8. The multi-board collaborative firmware upgrade system for medical aesthetic equipment as described in claim 7, characterized in that, The triggering module is further configured as follows: If the board to be upgraded is the host control board, the host control board receives and processes the firmware data to upgrade itself. If the card to be upgraded is a slave card, the host control board receives the firmware data and forwards it to the corresponding target slave card in real time and transparently.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the multi-board collaborative firmware upgrade method for medical aesthetic devices as described in any one of claims 1 to 6.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-board collaborative firmware upgrade method for medical aesthetic devices as described in any one of claims 1 to 6.