Firmware burning device and method for wearable device

Abstract

The application provides a kind of wearable equipment firmware programming device and method, it is related to firmware programming technical field.The application integrates online mode and offline mode in the same device, and automatically selects working mode according to the connection state of first interface module and host computer and whether to store effective programming package by master module.In research and development and production line scene, the device adopts online mode, and uses USB composite device to connect host computer, and provides transparent channel to wearable equipment through charging contact by virtual serial port, and stores effective programming package from host computer in response to package operation, to meet the needs of online debugging and host computer programming;In after-sales and on-site scene, the device adopts offline mode, and the master module controls the second interface module to execute offline programming operation on wearable equipment through charging contact in response to start trigger event, so as to realize firmware programming in two scenes of adapting finished wearable equipment online debugging and offline upgrading on the same device.

Description

Technical Field

[0001] This invention relates to the field of firmware burning technology, and in particular to a firmware burning apparatus and method for wearable devices. Background Technology

[0002] Wearable devices such as TWS (True Wireless Stereo) earphones and smart glasses, due to their small size and high integration, typically use charging contacts as the sole external electrical interface for charging and data transmission. In mass production or after-sales repair scenarios, it is necessary to flash firmware (upgrade / repair) these packaged wearable devices.

[0003] However, existing firmware flashing devices fall into two categories. One type connects to a host computer via a USB (Universal Serial Bus) interface, transmitting firmware data to the wearable device under the host computer's control. This flashing process heavily relies on a computer and a dedicated toolchain, and cannot perform the flashing operation independently without a host computer. The other type of device, while capable of independent flashing without a host computer, typically uses an interface designed for bare Flash chips or development boards, making it difficult to directly adapt to finished wearable devices that only expose charging contacts. These two types of devices correspond to online debugging and offline upgrade scenarios, respectively. R&D production lines and after-sales service sites require two different tools, resulting in fragmented operation methods. Summary of the Invention

[0004] The purpose of this invention is to provide a firmware burning device and method for wearable devices, so as to adapt firmware burning for both online debugging and offline upgrade scenarios of finished wearable devices on the same device.

[0005] In a first aspect, the present invention provides a firmware burning device for a wearable device, including a main control module, and a first interface module, a storage module, and a second interface module connected to the main control module; the first interface module is used to connect to a host computer to obtain a valid burning package; the storage module is used to store the valid burning package; the second interface module is used to connect to the wearable device through the charging contacts of the wearable device to burn the wearable device based on the valid burning package. The main control module is used to automatically enter online mode or offline mode based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid burning package. In online mode, the main control module controls the first interface module to connect to the host computer via a USB composite device; the USB composite device includes a virtual serial port and virtual storage; the virtual serial port is used to provide a transparent transmission channel to the wearable device through the charging contacts via the second interface module; the virtual storage is used to obtain a valid burning package from the host computer and store it in the storage module in response to the packaging operation. In offline mode, the main control module responds to the start-up trigger event and controls the second interface module to perform offline burning operations on the wearable device through the charging contacts.

[0006] In an optional implementation, the main control module is further configured to: in online mode and when the storage module stores a valid programming package, respond to the start programming command issued by the host computer, pause the transparent transmission channel and autonomously execute the entire programming process based on the valid programming package; during programming, the first interface module maintains a connection with the host computer to report the programming progress to the host computer; and automatically restore the transparent transmission channel after programming is completed.

[0007] In an optional implementation, the virtual storage is an MSC virtual USB drive; the virtual storage obtains a valid programming package from the host computer by receiving the programming package file written to the virtual USB drive by the host computer and writing the programming package file to the package delivery area of ​​the storage module. The main control module is also used to: determine that the burning package file has been stored successfully when the cumulative time without write operations in the package delivery area reaches the first preset time, and it is confirmed that the burning package file has fallen into the package delivery area corresponding to the directory entry in the root directory of the disk, and the byte count written to the package delivery area reaches the file length declared in the directory entry; and to perform format verification on the burning package file; when the verification is valid, the burning package file is marked as a valid burning package; when the verification is invalid, the burning package file is deleted and the first interface module is controlled to re-enumerate the virtual USB drive.

[0008] In an optional implementation, the main control module is further configured to: decompress the valid burning package after the burning package file has been verified as valid and marked as a valid burning package, and before performing the burning operation, to obtain several partition images, each partition image corresponding to a target partition in the flash memory of the wearable device; parse the storage layout description of the valid burning package, add an image header to each partition image, and generate a boot partition table recording the offset and length of each target partition; linearly reassemble the boot partition table and each partition image with added image headers into a target burning package of a preset format according to the target partition order, write the target burning package into the burning package partition of the storage module, and persistently save the source file name of the valid burning package; wherein, during decompression and linear reassembly, the main control module refuses to execute the burning request.

[0009] In an optional implementation, the startup trigger event includes one or more of the following: the second interface module detects that the wearable device is in place, receives a button trigger signal, the device is powered on, and receives a startup programming command sent by the host computer via a virtual serial port.

[0010] In an optional implementation, the main control module is further configured to, when controlling the second interface module to perform offline programming operations on the wearable device, bring the wearable device into a programmable state according to one or a combination of the following wake-up paths: Soft reset wake-up path: Send a wake-up string via the single-line serial port of the second interface module at an adapted baud rate; send a soft reset command frame conforming to the programming protocol frame format at the running baud rate; periodically send handshake characters at the boot baud rate and listen for the boot program's ready prompts; Power-off reset carrier wake-up path: Disconnect the power supply to the wearable device and maintain it for a second preset duration to allow the wearable device to be completely powered off and reset; after the power supply to the wearable device is restored, send a carrier bit sequence through the charging contacts to allow the wearable device to switch to serial communication mode; switch the charging contacts to single-wire serial communication state to enter the burning protocol session.

[0011] In an optional implementation, the main control module is further configured to: inject a programming agent program into the memory of the wearable device via the XMODEM protocol through the single-line serial port of the second interface module when performing offline programming operations; and interact with the programming agent program according to the session frame format after the programming agent program runs to perform session programming operations. The session writing operation includes: Negotiate to increase the serial port baud rate; The boot partition table of the target burning package is distributed; Firmware data is streamed partition by partition according to the boot partition table; during the distribution process, it is read from the burning package partition of the storage module and sent at the same time; each session frame waits for the wearable device's response, and if it times out or has a verification error, it is retransmitted according to the original frame sequence number; During the distribution process, the boot partition is skipped and the differential partition is skipped. Differential partition skipping includes obtaining the identification information of each target partition of the wearable device before distributing firmware data partition by partition, and comparing it with the identification information of the corresponding partition in the target flashing package. If they match, the distribution and flashing operation of that partition is skipped.

[0012] In an optional implementation, the second interface module includes two independent single-wire serial ports, each of which is connected to a wearable device via a charging contact. The main control module is also used to: control two single-wire serial ports in parallel to perform offline burning operations on two wearable devices.

[0013] In an optional implementation, the host computer includes a computer, mobile phone, or tablet with USB host functionality; the main control module is also used to generate a burning result file after the offline burning operation is completed, and to provide the host computer with a virtual USB flash drive file via virtual storage in online mode.

[0014] Secondly, the present invention provides a firmware burning method for a wearable device, applicable to the firmware burning apparatus for a wearable device in any of the foregoing embodiments; the method includes: The main control module automatically enters the online or offline mode workflow based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid burning package. In online mode, the main control module controls the first interface module to connect to the host computer via a USB composite device, which includes a virtual serial port and virtual storage; through the virtual serial port, the second interface module provides a transparent transmission channel to the wearable device via charging contacts; in response to the packaging operation, the valid burning package is obtained from the host computer via the virtual storage and stored in the storage module. In offline mode, the main control module responds to the start-up trigger event and controls the second interface module to perform offline burning operations on the wearable device through the charging contacts.

[0015] The firmware burning device and method for wearable devices provided by this invention integrate online and offline modes into a single device. The main control module automatically selects the working mode based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid burning package. In R&D and production line scenarios, the device adopts online mode, connecting to the host computer via a USB composite device. A virtual serial port provides a transparent transmission channel to the wearable device through charging contacts. The virtual storage responds to the packaging operation, obtaining and storing a valid burning package from the host computer, thus meeting the needs of online debugging and host computer burning. In after-sales and field scenarios, after the device is disconnected from the host computer, the main control module automatically switches to offline mode and responds to the start trigger event, controlling the second interface module to perform offline burning operations on the wearable device through the charging contacts. Therefore, the same device can simultaneously cover both online debugging and offline upgrade scenarios, eliminating the need to prepare two separate tools for different scenarios. The operation method is unified, and the offline mode directly adapts to finished wearable devices that only expose charging contacts, requiring no additional burning interface. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the structure of a firmware burning device for a wearable device provided in an embodiment of the present invention; Figure 2 This invention provides an architectural diagram of a firmware burning device for a wearable device. Figure 3 This is a schematic diagram of an upgraded packaging process provided by an embodiment of the present invention; Figure 4An offline programming engine state machine provided in an embodiment of the present invention; Figure 5 A timing diagram of a power-off reset carrier wake-up path provided in an embodiment of the present invention; Figure 6 A data path comparison diagram between online and offline modes provided in an embodiment of the present invention; Figure 7 A hardware block diagram of a firmware burning device for a wearable device provided in an embodiment of the present invention; Figure 8 A key circuit block diagram of a firmware burning device for a wearable device provided in an embodiment of the present invention; Figure 9 This is a flowchart illustrating a firmware burning method for a wearable device provided in an embodiment of the present invention.

[0018] Icons: 101 - Main control module; 102 - First interface module; 103 - Storage module; 104 - Second interface module. Detailed Implementation

[0019] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] To facilitate understanding of the technical solutions in the embodiments of the present invention, some terms are defined as follows: 1. USB Composite Device: A single USB physical interface simultaneously presents multiple functions to a computer. The firmware burning device for wearable devices provided in this embodiment of the invention (hereinafter referred to as "this device") simultaneously presents two CDC (Communications Device Class) virtual serial ports and one MSC (Mass Storage Class) virtual USB flash drive.

[0021] 2. CDC: USB communication device class, which appears as a serial port on a computer, i.e., COM port; COM stands for Communication Port.

[0022] 3. MSC: USB Mass Storage Device, which appears as a USB flash drive on a computer; the computer reads and writes by sector (512 bytes per sector).

[0023] 4. FAT (File Allocation Table) file system: This file system relies on the FAT table and directory entries to manage files. The FAT table records the location of file data in the form of cluster chains. Directory entries are file descriptions in the root directory area, with each entry being 32 bytes long and containing information such as the file name, starting cluster number, and file length.

[0024] 5. UART (Universal Asynchronous Receiver-Transmitter): also known as a serial port. A single-wire UART is a half-duplex serial port where the transmit and receive signals share a single signal line; a two-wire UART has separate signal lines for transmitting and receiving.

[0025] 6. Transparent Transmission (Online Mode): This device forwards USB virtual serial port data and UART data bidirectionally without parsing them itself. The computer software is like directly connecting to the serial port of the target device (i.e., wearable device).

[0026] 7. DUT (Device Under Test): The target device that is being upgraded or tested. In this embodiment of the invention, it refers to finished wearable devices such as TWS earphones and smart glasses.

[0027] 8. Charging contacts: Metal contacts that make contact between the wearable device and the charging case, serving both power supply and communication functions.

[0028] 9. 5V communication carrier: Outputs a sequence of high and low levels (bit string or pulse width waveform) on the charging contact power supply line according to the agreed timing, which is used to send wake-up or mode switching commands to devices that are in a power-off or charging state.

[0029] 10. Firmware Package (Upgrade Package): A complete firmware package format containing multiple partition image files of the target device; each partition image includes an image header (magic number, length, and checksum). In this embodiment of the invention, the operation of "copying the firmware package to a USB flash drive" is collectively referred to as firmware loading.

[0030] 11. Programming Protocol Frame: The frame format of the programming or debugging protocol in this embodiment of the invention includes a preamble, module number, header CRC8 checksum, and data CRC32 checksum. During the programming session, both parties interact in packets according to this format. CRC stands for Cyclic Redundancy Check. Packet-based interaction refers to the entire block of data being divided into multiple packets (frames) and interacting packet by packet.

[0031] 12. XMODEM: A classic serial file transfer protocol. Data is sent in fixed-size blocks, each with a sequence number and checksum. The receiver acknowledges each block and supports timeout retransmission. This device uses this protocol to inject the burning agent program into the target device's memory (hereinafter referred to as target memory).

[0032] 13. Programming Agent: This is a program injected into the target memory by XMODEM and runs in place of the bootloader to handle the high-speed programming session (including baud rate negotiation, partition writing, read-back verification and parameter writing). It is the second-level target side (i.e. the side where the target device is located) of the programming session.

[0033] 14. Linearized Recombination Burning Package (Internal Format): This device decompresses the firmware upgrade package locally and reorganizes it into a continuous layout that can be directly read and played back in sequence (referred to as "linearized recombination" in this embodiment of the invention) to generate an image set, including each partition image and its image header, boot partition table and source file name; zero-parse direct playback during offline burning.

[0034] 15. Baud Rate: The number of signal units (rate) transmitted per second via a serial port. Both communicating parties must use the same baud rate to recognize each other's data. This invention involves three baud rates: adaptation baud rate (a low rate agreed upon during the wake-up phase), running baud rate (the rate used by the target normal firmware), and boot baud rate (the default rate of the target bootloader).

[0035] 16. Magic Number: A pre-agreed specific value written at the beginning or end of the data structure to identify the data type and verify its validity. The receiver first checks whether these bytes are equal to the agreed value to confirm the validity of the data format and exclude irrelevant files. This device uses this to distinguish the firmware upgrade package of the target device from its own upgrade package.

[0036] 17. Cluster / Cluster Chain: A cluster is the smallest unit of disk space allocation in a file system; the clusters occupied by a file are linked together in a "cluster chain" through the file allocation table, so the file content can be stored non-contiguously on the disk (fragmentation).

[0037] 18. Partitions / Partition Tables: A partition refers to a region of the target device's flash memory divided according to its purpose (such as the boot program area, application area, and resource area); the partition table (i.e., the boot partition table) is a table that describes the location and size of each partition for the boot program to look up.

[0038] 19. Boot program: The first program to run after the target device's main control chip is reset. It is stored in the read-only memory and has the ability to receive data via serial port and write to flash memory.

[0039] 20. Host computer tools: Dedicated upgrade or burning software that runs on the computer side.

[0040] 21. Re-enumeration: This device actively disconnects and reconnects the USB, forcing the computer to re-recognize the device and reread the contents of the USB drive.

[0041] Wearable devices such as TWS earphones and smart glasses often require firmware upgrades or reflashing after leaving the factory (at the end of the production line, in stores, after-sales service outlets, or on-site). These devices do not have exposed debugging interfaces; the only physical channel is the single-wire serial port on their charging contacts. Before an upgrade, a precise "power off → power on → carrier wake-up → mode switching" sequence must be executed to bring the device into a programmable state.

[0042] Existing firmware flashing solutions have the following main shortcomings: 1. Online programming solutions heavily rely on computers and dedicated toolchains. Currently, the common approach consists of a programming environment comprised of a computer, dedicated host computer software, and a USB-to-serial adapter. All operations, including software installation, serial port identification, firmware package selection, and wake-up timing control, are performed by the host computer. This environment is difficult to provide in retail stores, after-sales personnel, and on-site environments. Different operating systems also require separate maintenance of tool versions, resulting in high deployment costs and poor portability.

[0043] 2. Existing offline programmers are not suitable for finished wearable devices. Commercially available offline programmers are mainly designed for bare dies or semi-finished circuit boards, using debugging interfaces such as SWD (Serial Wire Debug) and JTAG (Joint Test Action Group). Firmware loading requires pre-installing the firmware into the programmer via configuration software on a computer, and it lacks target power supply control and charging contact carrier wake-up capabilities. It cannot pull pre-packaged finished wearable devices into programming mode, nor does it provide any online debugging channels.

[0044] 3. The charging case upgrade solution relies on wireless channels and is positioned as a consumer product. Existing solutions for "upgrading earphones from a charging case" require the upgrade package to be transferred to the charging case via Bluetooth or a mobile application. This relies on the accompanying application, wireless link, and the limited resources of a consumer-grade charging case, and is not a universal engineering or after-sales tool.

[0045] 4. Online debugging and offline upgrades require two separate sets of equipment. R&D and production lines need to use transparent serial ports for online debugging and PC programming, while after-sales and on-site operations require computer-free offline upgrades. Currently, two different tools must be prepared, and the operation methods are disconnected.

[0046] To address the aforementioned issues, this invention provides a firmware burning device and method for wearable devices. When connected to a computer, the device functions as a multi-channel serial port transparent bridge, supporting online burning and debugging, and remains transparent. When the user copies the firmware upgrade package into a USB flash drive simulated by the device, the device becomes an autonomous burner, capable of independently controlling power supply, carrier wake-up, protocol burning, verification, and result feedback for wearable devices such as headphones, without the need for a computer.

[0047] This device simulates a USB flash drive that works with any USB host: in addition to computers, devices with USB host functionality such as mobile phones and tablets can also be recognized as ordinary USB flash drives after being connected via an OTG (On-The-Go) adapter cable. Simply download the latest firmware upgrade package from the cloud using the manufacturer's mobile application and copy it into the device to complete the installation. Furthermore, the device's main controller can integrate Bluetooth radio frequency, allowing the mobile application to wirelessly transfer upgrade packages to the device via Bluetooth Low Energy, meeting the need for continuous firmware updates anytime, anywhere, without requiring a computer.

[0048] The background and prior art of the embodiments of the present invention will be described in detail below.

[0049] Background 1: The contact communication and programming principle of finished earphones.

[0050] TWS earbuds and charging case are connected via 2 to 3 metal contacts, which simultaneously handle charging and communication. The industry commonly uses single-wire serial ports, dedicated single-bus chips, or power line carrier communication. The earbud chip's bootloader supports receiving firmware via this serial port: the controller sends frames conforming to the programming protocol (including preamble, packet segmentation, and CRC checksum), writing the image to the earbud flash memory partition by partition. A specific timing sequence is required before the upgrade session begins: the earbuds are powered off to reset, and upon power-on, a pre-defined carrier sequence is sent on the power line, immediately switching the earbuds into serial communication (programming) mode.

[0051] Background 2: Complete firmware package.

[0052] The programmer ecosystem uses a complete firmware package to describe all the firmware of a device. The complete firmware package contains multiple partition images, each with a 32-byte image header (including magic number, length, and checksum). During programming, each partition is written to and verified one by one according to the partition table.

[0053] Existing Solution 1: USB to serial bridge + online programming by host computer.

[0054] In this solution, the firmware burning device provides a transparent transmission channel, through which tools on the computer directly communicate with the headset bootloader to complete the burning process. The drawback of this solution is that all burning logic resides on the computer side; the device itself only acts as a transparent transmission bridge and cannot perform any burning operations independently when disconnected from the computer.

[0055] Existing Solution 2: Offline programmer.

[0056] This type of solution first uses computer configuration software to pre-store the firmware into the programmer, and then performs offline programming on the target device. Its shortcomings are: it is designed for bare die debugging ports (SWD, JTAG, etc.), lacks the power supply control and carrier wake-up timing required for finished devices, has no transparent transmission mode, and the programming target is "chips on the circuit board" rather than "finished devices that are packaged and have only charging contacts remaining".

[0057] Option 3: Upgrade the earphones using the charging case.

[0058] In this type of solution, the upgrade package enters the charging case wirelessly (via Bluetooth or a mobile app), and the charging case then transmits the upgrade package to the earphones via contacts. Its limitations are: reliance on a wireless data transfer link and accompanying application; the charging case is a consumer product rather than an engineering tool and does not provide online pass-through or debugging capabilities; and the method of loading the upgrade package is not user-friendly for after-sales personnel.

[0059] In summary, existing solutions have the following limitations: online solutions rely on computers and dedicated software, resulting in high barriers to entry for environment setup; offline programmers cannot be adapted to finished devices that only expose charging contacts, and packaging still requires dedicated configuration software; charging box solutions require packaging via wireless links and applications, which involves long links and the devices are positioned as consumer products. None of these three solutions can simultaneously meet the needs of online debugging during the R&D phase and offline upgrades during the after-sales phase on the same device, requiring users to maintain two sets of tools for different scenarios.

[0060] Based on this, embodiments of the present invention provide a single portable wearable device and method for firmware burning, applicable to firmware upgrades of finished devices such as TWS earphones and smart glasses that only expose charging contacts in production lines, stores, and after-sales scenarios, and can achieve: 1) When connected to a computer, it is a multi-channel serial port transparent transmission bridge, supporting online burning / debugging of existing host computer tools, maintaining the complete usability of the existing tool ecosystem; 2) Offline upgrade package loading is completed by copying the firmware package file to a USB flash drive, without any configuration software required; 3) After being disconnected from the computer, it can autonomously control the power supply, wake up the carrier, burn the protocol, verify and provide feedback on the results of the finished wearable device; 4) The online and offline modes share the same set of target physical interfaces and control resources, making one machine usable for both purposes.

[0061] To facilitate understanding of this embodiment, a firmware burning device for a wearable device disclosed in this embodiment of the invention will first be described in detail.

[0062] like Figure 1As shown in the figure, an embodiment of the present invention provides a firmware burning device for a wearable device, including a main control module 101, a first interface module 102, a storage module 103 and a second interface module 104 connected to the main control module 101.

[0063] The first interface module 102 is used to connect to a host computer to obtain a valid programming package. The storage module 103 is used to store the valid programming package. The second interface module 104 is used to connect to the wearable device through the charging contacts of the wearable device to program the wearable device based on the valid programming package.

[0064] The main control module 101 is used to automatically enter the online mode or offline mode workflow based on the connection status between the first interface module 102 and the host computer, and whether the storage module 103 stores a valid burning package.

[0065] In online mode, the main control module 101 controls the first interface module 102 to interface with the host computer via a USB composite device. The USB composite device includes a virtual serial port and virtual storage. The virtual serial port is used to provide a transparent transmission channel to the wearable device via the charging contacts through the second interface module 104. The virtual storage is used to retrieve a valid burning package from the host computer and store it in the storage module 103 in response to the packaging operation.

[0066] In offline mode, the main control module 101 responds to the start trigger event and controls the second interface module 104 to perform offline burning operations on the wearable device through the charging contacts.

[0067] This invention integrates online and offline modes into a single device. The main control module 101 automatically selects the operating mode based on the connection status between the first interface module 102 and the host computer, and whether the storage module 103 stores a valid programming package. In R&D and production line scenarios, the device uses online mode, connecting to the host computer via a USB composite device. A virtual serial port provides a transparent transmission channel to the wearable device through charging contacts. The virtual storage responds to the packaging operation, retrieving and storing a valid programming package from the host computer, thus meeting the needs of online debugging and host computer programming. In after-sales and field scenarios, after the device is disconnected from the host computer, the main control module 101 automatically switches to offline mode and responds to the start trigger event, controlling the second interface module 104 to perform offline programming operations on the wearable device through the charging contacts. Therefore, the same device can simultaneously cover both online debugging and offline upgrade scenarios, eliminating the need to prepare two separate tools for different scenarios. The operation method is unified, and the offline mode directly adapts to finished wearable devices that only expose charging contacts, requiring no additional programming interface.

[0068] In some possible embodiments, the main control module 101 is further configured to: in online mode and when the storage module 103 stores a valid programming package, respond to the start programming command issued by the host computer, pause the transparent transmission channel and autonomously execute the entire programming process based on the valid programming package; during programming, the first interface module 102 maintains a connection with the host computer to report the programming progress to the host computer; and automatically restore the transparent transmission channel after programming is completed.

[0069] In this embodiment of the invention, when the device is connected to the host computer in online mode, it can not only be used as a transparent transmission bridge (i.e., a transparent transmission channel), but also pause the transparent transmission function and autonomously take over the burning process after receiving a start burning command from the host computer. This allows the device to independently complete the burning task while maintaining a connection with the host computer and provide real-time progress feedback to the host computer. After burning is complete, the device automatically restores the transparent transmission channel and returns to the online transparent transmission state. This approach utilizes the triggering and monitoring capabilities of the host computer while retaining the burning logic on the device side, achieving flexible and controllable online autonomous burning.

[0070] In some possible embodiments, the virtual storage can be an MSC virtual USB drive. The method for obtaining a valid burning package from the host computer is as follows: receiving the burning package file written to the virtual USB drive by the host computer and writing the file to the package delivery area of ​​storage module 103. The main control module 101 uses a triple criterion when determining that file storage is complete: First, the cumulative time without write operations in the package delivery area reaches a first preset time (the first preset time can be set according to actual needs and is not limited here); second, confirming that the burning package file has fallen into the package delivery area corresponding to the directory entry in the disk root directory; and finally, the byte count written to the package delivery area reaches the file length declared in the directory entry. When the above three conditions are met simultaneously, the main control module 101 determines that file storage is complete and performs format verification on the burning package file; if the verification is valid, the file is marked as a valid burning package; if the verification is invalid, the file is deleted and the first interface module 102 is controlled to re-enumerate the virtual USB drive so that the user can retry.

[0071] By mapping a virtual USB drive to the package delivery area of ​​storage module 103 and employing a triple completion determination mechanism of "write free window + directory entry parsing + byte counting," a firmware package loading method without any configuration software is achieved. Users simply copy the firmware package file (i.e., the burning package file) into the device as if operating a regular USB drive, and the device automatically completes the storage completion determination and format verification. If verification fails, invalid files are automatically deleted and the USB drive is re-enumerated, ensuring the robustness of the loading process and a good user experience.

[0072] In some possible embodiments, the main control module 101 is further configured to: decompress the valid burning package after it has been verified as valid and marked as a valid burning package, and before performing the burning operation, to obtain several partition images, each partition image corresponding to a target partition in the flash memory of the wearable device; parse the storage layout description of the valid burning package, add an image header to each partition image, and generate a boot partition table recording the offset and length of each target partition; linearly reassemble the boot partition table and each partition image with added image headers into a target burning package of a preset format according to the target partition order; write the target burning package into the burning package partition of the storage module 103, and persistently save the source file name of the valid burning package. During decompression and linear reassembly, the main control module 101 refuses to execute the burning request.

[0073] After the firmware package passes verification, the device does not directly use the original ZIP package for burning, but performs preprocessing locally. Specifically, the device decompresses the ZIP compressed firmware package, reads it according to the file allocation table cluster chain, and is compatible with out-of-order and fragmented disk writing from the host computer. After decompression, several partition images are obtained, each corresponding to a target partition in the wearable device's flash memory (such as a bootloader area, application area, resource area, etc.). Subsequently, the device parses the storage layout description in the firmware package, adds an image header (containing magic number, length, checksum, etc.) to each partition image, and generates a boot partition table recording the offset and length of each target partition. Finally, the device linearly reassembles the boot partition table and each partition image with added image headers into a target burning package of a preset format according to the target partition order, writes it to the burning package partition of storage module 103, and persistently saves the source file name of the valid burning package.

[0074] In this way, during offline programming, the device can directly read and play back data sequentially from the programming package partition without any parsing operations, achieving zero-parsing direct playback and greatly improving the efficiency of offline programming. Simultaneously, programming requests are rejected during decompression and linearization reassembly, avoiding read-write conflicts.

[0075] In some possible embodiments, the above-described device further includes one or more of a Bluetooth module, an SD (Secure Digital) card slot, and a TF (TransFlash, also known as microSD) card slot; the main control module 101 is also used to write the acquired valid programming package into the same valid programming package area of ​​the storage module 103 via mutual exclusion arbitration of the packaging channel; wherein, the packaging channel includes at least one of a USB flash drive channel via virtual storage, a serial port protocol channel via a virtual serial port, a Bluetooth wireless channel via the Bluetooth module, an SD card channel via the SD card slot, and a TF card channel via the TF card slot. Based on this, the packaging operation may include at least one of the following methods: copying the programming package file to virtual storage via the USB flash drive channel, sending the programming package file via the serial port protocol channel via the virtual serial port, transmitting the programming package file wirelessly via Bluetooth, copying the programming package file to virtual storage via the SD card channel, and copying the programming package file to virtual storage via the TF card channel.

[0076] In addition to the virtual USB drive channel and serial port protocol channel, the device can also acquire firmware packages via Bluetooth wireless channel, SD card channel, or TF card channel. Multiple packaging channels share the same valid burning package area through a mutual exclusion arbitration mechanism, ensuring that only one channel is performing write operations at any given time, thus avoiding data conflicts. This multi-channel design allows the device to flexibly adapt to different usage scenarios: it can use the USB drive channel or serial port protocol channel in an environment with a computer, the Bluetooth wireless channel in an environment without a computer but with a mobile phone, and the SD card or TF card channel when a memory card is available.

[0077] In some possible embodiments, the startup trigger event includes one or more of the following: the second interface module 104 detects that the wearable device is in place, receives a button trigger signal, the device is powered on, and receives a startup programming command sent by the host computer via a virtual serial port.

[0078] Specifically, this embodiment provides the following four triggering methods for offline programming: 1. Target presence detection triggered.

[0079] The device continuously monitors the load status or communication response signal through the second interface module 104. When a wearable device (such as TWS earphones) is connected, a change in characteristic impedance between the charging contacts or the detection of a predetermined response signal indicates that the target device is present and automatically initiates the offline programming process. This method is suitable for mass production line scenarios, where operators only need to place the target device without any additional operations.

[0080] 2. Triggered by button press.

[0081] The device housing has physical buttons. After packaging and placing the target device, the operator can press the button to trigger offline programming. This method is suitable for repair shops or after-sales scenarios, and the operator can manually control the programming start time as needed.

[0082] 3. Power-on trigger.

[0083] The device is configured for power-on scanning mode. When the device is connected to a 5V power supply, it automatically detects whether a valid programming package exists in the storage module 103, and automatically starts programming when the target device is detected. This method is suitable for unattended or automated production line scenarios; the device automatically enters the working state after being powered on.

[0084] 4. Triggered by host computer command.

[0085] When the device is connected to a host computer or other computer, the host computer sends a start programming command via a virtual serial port. Upon receiving the start programming command, the device pauses the current transparent transmission channel and autonomously takes over the programming process. The USB connection remains open during programming, and the host computer can monitor the progress in real time. This method is suitable for R&D and debugging scenarios, allowing engineers to remotely trigger and monitor the programming process from a computer.

[0086] The above triggering methods can be combined. For example, the device can be configured as a combination mode of "target presence detection + button triggering": after the operator places the target device, the device automatically detects its presence, but the burning process will only start after the button is pressed to confirm, in order to prevent accidental triggering.

[0087] In some possible embodiments, the main control module 101 is further configured to, when controlling the second interface module 104 to perform an offline programming operation on the wearable device, bring the wearable device into a programmable state according to one or a combination of the following wake-up paths: Soft reset wake-up path: Send a wake-up string via the single-wire serial port of the second interface module 104 at an adapted baud rate; send a soft reset command frame conforming to the burning protocol frame format at the running baud rate; periodically send handshake characters at the boot baud rate and listen for the boot program's ready prompts; Power-off reset carrier wake-up path: Disconnect the power supply to the wearable device and maintain it for a second preset duration to allow the wearable device to completely power off and reset; after reconnecting the power supply to the wearable device, send a carrier bit sequence through the charging contacts to switch the wearable device to serial communication mode; switch the charging contacts to single-wire serial communication state to enter the programming protocol session. The second preset duration can be set according to actual needs and is not limited here.

[0088] Specifically, before offline programming, the main control module 101 uses one or a combination of two wake-up paths to put the wearable device into a programmable state. The soft reset wake-up path is suitable for scenarios where the target firmware (the wearable device's application firmware) is still running: the main control module 101 sequentially sends a wake-up string at the adapted baud rate, sends a soft reset command frame at the running baud rate, and periodically sends handshake characters and listens for ready prompts at the boot baud rate, without needing to disconnect the target's power supply. The power-off reset carrier wake-up path is suitable for scenarios where the target is powered off or charging: the main control module 101 first disconnects the target's power supply and maintains it for a second preset duration to fully reset it. After powering back on, it sends a carrier bit sequence through the charging contacts to switch the target to serial communication mode, and then switches the contacts to single-wire serial communication mode to enter the programming session.

[0089] By providing two wake-up paths and supporting their combination, the device can adapt to wearable devices of different states and models, ensuring that the target device can be reliably pulled into the burning mode in various scenarios without the need to modify the device firmware for different devices.

[0090] In some possible embodiments, the main control module 101 is further configured to: inject a burning agent program into the memory of the wearable device via the XMODEM protocol through the single-line serial port of the second interface module 104 when performing offline burning operations; and interact with the burning agent program according to the session frame format after the burning agent program runs to perform session burning operations.

[0091] The session programming operation may include: Negotiate to increase the serial port baud rate; The boot partition table of the target burning package is distributed; Firmware data is streamed partition by partition according to the boot partition table; during the distribution process, the data is read from the burning package partition of storage module 103 and sent at the same time; each session frame waits for the wearable device's response, and if a timeout or verification error occurs, it is retransmitted according to the original frame sequence number; During the distribution process, the boot partition is skipped, and differential partition skipping is performed. Differential partition skipping involves obtaining the identification information of each target partition of the wearable device before distributing firmware data partition by partition, and comparing it with the identification information of the corresponding partition in the target flashing package. If they match, the distribution and flashing operation of that partition is skipped. The identification information can be a version number or a hash value.

[0092] Through a two-level session design, the device can inject a high-efficiency burning agent into the target device, replacing the original bootloader for high-speed burning. The streaming method allows the device to burn large firmware packages without requiring a large amount of memory, reducing hardware costs through read-and-send functionality. The difference partition skipping function further shortens upgrade time, especially during firmware version iterations, by burning only the changed partitions, significantly improving efficiency.

[0093] In some possible embodiments, the second interface module 104 may include two independent single-wire serial ports, each of which is connected to a wearable device through a charging contact; the main control module 101 is also used to: control the two single-wire serial ports in parallel to perform offline burning operations on the two wearable devices.

[0094] By using dual-channel parallel programming, the device can simultaneously upgrade two wearable devices, such as earphones, reducing batch programming time by half and significantly improving work efficiency in production lines and after-sales scenarios.

[0095] In some possible embodiments, the host computer may include a computer, mobile phone, or tablet with USB host functionality. The main control module 101 is also used to generate a burning result file after the offline burning operation is completed, and to provide the host computer with a virtual USB flash drive file via virtual storage in online mode.

[0096] Specifically, the host computer is not limited to a computer; devices with USB host functionality, such as mobile phones and tablets, can also be recognized as ordinary USB flash drives and read the resulting files after being connected via an OTG adapter cable. Furthermore, whether the burning process was successful can be indicated in real time by a dual-color indicator light or a buzzer (different sounds correspond to successful and failed burning). For example, the dual-color indicator light includes a red LED and a green LED; the green LED lights up when burning is successful, and the red LED lights up when burning fails. This allows after-sales or on-site personnel to check the burning results using their mobile phones without needing to carry a computer.

[0097] For ease of understanding, the firmware burning device for the aforementioned wearable device will be described in detail below.

[0098] Taking wearable devices, such as headphones, as an example, Figure 2As shown, the main control module is the main control processor, the first interface module is a USB composite device interface controller, the storage module is the device's flash memory, and the second interface module includes two serial ports, a target power supply switch, and a 5V communication carrier generator. The device appears as a USB composite device to an external optional computer (host computer tool / file manager), including two CDC virtual serial ports (CDC0 virtual serial port and CDC1 virtual serial port) and an MSC virtual USB flash drive. These three are integrated into the USB composite device interface controller and interact with the main control processor. The main control processor internally includes a pass-through engine (online mode), packet reception and pre-depacketization, an offline burning engine (dual-session state machine), and a timing controller (power supply / carrier / baud rate), and is connected to the device's flash memory. The flash memory is divided into four areas: a packet delivery area for temporarily storing the original firmware upgrade package file sent via USB flash drive or serial port; a burning package area for storing generated custom-format burning packages; a result log area; and the device's own firmware area. The device provides two configurable serial ports (supporting three pin modes: dual single-wire, single single-dual, and dual dual-wire) to the target (i.e., the earphones), a target power switch (controlling the target power supply via a general-purpose output pin), and a 5V communication carrier generator (outputting a bit string or a custom pulse width waveform on the power supply line). The device ultimately connects to the left and right earphones via charging contacts, forming a complete online and offline programming pathway.

[0099] I. Online Mode (Pass-through Bridge).

[0100] Two CDC virtual serial ports establish bidirectional transparent forwarding with two target serial ports, allowing the computer software to connect as if directly to a headphone serial port. Baud rate, pin mode, and USB speed are configured via an in-band control protocol. Control frames are demarcated by pre-defined frame start and frame end markers, distinguishing them from the transparent data stream. This control protocol simultaneously enables the target power switch and 5V carrier transmission commands, allowing the host computer tool to complete the entire timing sequence of "power off → power on → carrier wake-up → session programming." This mode maintains the complete usability of the existing host computer ecosystem and also serves as a debugging channel during the R&D phase.

[0101] II. Upgrade packaging.

[0102] like Figure 3 As shown, the device's virtual USB drive directly maps the flash memory package delivery area to a writable delivery area on the disk (the disk sector address range corresponds one-to-one with the flash memory partition; the device does not run a file system). The operator copies the firmware package file into the virtual USB drive using a file manager in any operating system, thus completing the loading process, as follows: 1) When the computer writes sectors to the logical delivery area of ​​the virtual USB drive, the data is directly streamed to the packet delivery area in the flash memory. The flash memory is erased incrementally in 4KB granularities: the device maintains an erased bitmap, and each USB write command only erases the sectors touched by the current write and not yet erased. At the same time, a background task pre-erases the sectors before the current write position. This mechanism avoids the traditional whole-area pre-erasure method (which takes several seconds) blocking the USB write command callback, thus preventing the computer from determining that the USB drive has timed out and causing the drive letter to freeze.

[0103] The scheduling strategy for the background pre-erase task is as follows: The device maintains a write cursor indicating the next expected sector at the current USB write position. The background task always prefetches and erases N sectors (N is configurable, with a default value of 8) in front of this cursor, ensuring that the sector hit by the new write has been erased in advance. When the write cursor moves forward due to a new sector being written, the background task is rescheduled, thereby minimizing the waiting latency of the USB write command.

[0104] 2) The device determines copy completion based on a triple completion criterion: a write idle window (approximately 1.5 seconds without new writes); parsing the disk root directory entry to find the file falling within the packet delivery area (i.e., directory entry parsing); and the number of bytes flowing in being greater than or equal to the file length declared in the directory entry (i.e., byte count). Verification only proceeds when all three criteria are met simultaneously, thus ensuring compatibility with out-of-order writes, system file writes, and cache delayed refreshes in the operating system.

[0105] 3) After copying, the device performs firmware package format verification, including the magic number of the package header, the partition table, and the magic number, length, and checksum of each partition image header. If verification passes, the firmware package file is retained on the virtual USB drive, the device illuminates the ready indicator light, and enters the burning state. If verification fails or irrelevant files are dragged in, the device automatically deletes the firmware package file from the disk view (clearing directory entries and releasing the file allocation chain), then actively disconnects and reconnects the USB (i.e., re-enumerates). The computer reads the clean disk again, and the user can immediately retry. This mechanism solves the inherent constraint under the MSC protocol that devices cannot actively notify the computer that "the file has been deleted."

[0106] After successful verification, the device further performs pre-unpacking and linear reconstruction locally. Specifically, the device decompresses the ZIP-compressed firmware package, reads it according to the file allocation table cluster chain, and is compatible with out-of-order and fragmented disk writes; it parses the storage layout description, adds an image header to each partition image, and generates a boot partition table; then, it writes the above content as a flashing package in its own format to the flashing package partition, and persistently saves the source file name as well. During offline flashing, the device can directly replay the flashing package without any parsing operations. During pre-unpacking, the device refuses to execute flashing requests and reports the "unpacking in progress" status to the host computer to prevent read / write conflicts.

[0107] 4) The same firmware package can also be distributed via the CDC serial port channel (i.e., the CDC protocol channel), suitable for situations where a computer is available but a USB flash drive is inconvenient. The two packaging channels use mutual exclusion arbitration to ensure that only one channel is allowed to write at a time, and that the data is written to the same package delivery area. Furthermore, the flashing configuration (including the number of channels, routing mode, baud rate at each stage, whether to flash the boot partition, and the target Bluetooth name, etc.) can also be dragged in as a text configuration file via this delivery channel and persisted, or it can be configured via the CDC control protocol. Configurations from both sources are written to the same persistent configuration file.

[0108] The mutual exclusion arbitration of the two packet delivery channels (virtual USB flash drive delivery channel and CDC protocol channel) is implemented through a state machine lock on the device side. The state machine maintains a "packet delivery area occupancy flag," which must be acquired by either channel before initiating a write operation. The channel that has acquired the flag has exclusive write rights, and the write request of the other channel will be rejected, reporting a "channel occupied" status code to the host computer. The flag is automatically released when the current channel completes packet verification (whether successful or not) and the device completes subsequent processing (such as illegal file deletion and re-enumeration), or when the current channel's write timeout (default 30 seconds without new data).

[0109] 5) The mounting host is not limited to a computer. Devices with USB host functionality, such as mobile phones and tablets, can also be recognized as ordinary USB flash drives after being connected via an OTG adapter cable. The operator can use the mobile phone's file manager to copy the latest firmware upgrade package downloaded from the cloud by the manufacturer's application into the USB flash drive, triggering a write judgment, verification, and pre-unpacking process that is completely identical to that of mounting on a computer. In scenarios where product firmware is continuously iterated, after-sales or store personnel do not need to carry a computer; they can use their mobile phones to install the latest firmware onto the device at any time.

[0110] Furthermore, the device's main control chip integrates a Bluetooth RF transceiver (onboard antenna). After pairing with the device via Bluetooth Low Energy, the mobile application can write the upgrade package into packets in the packet delivery area, serving as a third packet delivery channel alongside the virtual USB drive channel and the serial port protocol channel, also managed by the aforementioned mutual exclusion arbitration mechanism. Subsequent verification, pre-unpacking, and offline flashing processes are completely reused. Thus, the mobile phone can load the latest firmware onto the device without needing to connect a data cable.

[0111] III. Offline Mode: Onboard burning engine.

[0112] like Figure 4 As shown, when a valid programmable file exists in the programmable area, the device disconnects from the computer (powered only by a 5V power supply or a general USB power supply) and operates as an independent programmer, as follows: (1) Trigger.

[0113] There are four triggering methods, and you can choose any one of them: 1) Target presence detection: After detecting a load or communication response on the charging contacts, the device automatically begins the programming process; 2) Button trigger: Manually trigger the programming process using the buttons on the device; 3) Power-on scanning: The device automatically scans and begins programming after power-on; 4) Host computer command trigger: When the device is connected to the computer, a start command is sent via the virtual serial port to trigger the programming. At this time, the computer is only responsible for triggering and checking the progress; the entire programming process is still completed autonomously by the device.

[0114] (2) Target wake-up and media switching timing.

[0115] Depending on the status and media requirements of the target product (i.e., wearable device), two types of wake-up paths can be selected, and these two paths can be combined (e.g., performing carrier wake-up first, followed by a soft reset handshake). All timing parameters are configurable, including the serial port baud rate, handshake timeout, carrier sequence content, bit duration, and power-off hold time T1 for each stage. These parameters can be persistently saved via text configuration files or by sending them to a host computer, or they can be included in the firmware package. Therefore, the same device can be adapted to different target products without modifying the firmware.

[0116] Path 1 is a soft reset wake-up, suitable for products where the target firmware is already running. This path includes the following steps: First, send the agreed-upon wake-up string on the target serial port at the appropriate baud rate; second, switch to the running baud rate and send a soft reset command frame conforming to the programming protocol frame format; subsequently, switch to the boot baud rate, periodically send handshake characters, and listen for the bootloader's ready prompts. The above three steps of "wake-up → reset → handshake" are retried as a whole loop until the target enters the bootloader. The target power supply does not need to be cut off throughout the process. This path is a pure serial port command timing sequence and does not involve power lines or carrier lines.

[0117] Path two is power-off reset carrier wake-up, suitable for products where the target is powered off or charging, or where the contact role must be switched via a power line carrier command before the programming process can begin. This path includes the following steps: Figure 5 As shown, firstly, the timing controller disconnects the target power supply and holds for time T1, causing the target to be completely powered off and reset; secondly, after power is restored, the agreed carrier bit sequence is sent on the power supply line to switch the target from charging or normal mode to serial communication (programming) mode; subsequently, the contact role is switched to single-wire serial port, entering the programming protocol session.

[0118] (3) Protocol burning session.

[0119] The onboard burning engine and the target session are divided into two levels.

[0120] The first level is the injection of the programming agent: After the target enters the boot program, the device injects the programming agent program into the target memory and runs it via the XMODEM protocol; the sender sends the first block of data only after receiving the ready character from the receiver. Each block of data carries verification information and supports automatic retransmission after timeout; the end of the programming agent image is aligned to the agreed length and a start magic number is appended so that the boot program can jump to execution after confirming that the reception is complete.

[0121] The second level is session-based programming: The device and the programming agent interact according to the session frame format, which includes a frame header, frame trailer, sequence number, command code, length, and payload CRC checksum. The session-based programming process includes the following steps: First, negotiating to increase the serial port baud rate; second, sending the boot partition table; subsequently, streaming firmware data partition by partition according to the programming package partition table. During the sending process, data is read from and sent simultaneously from the device's flash memory, eliminating the need for the device to have memory to hold the entire packet. Each session frame waits for a response from the target, and if a timeout or checksum error occurs, the data is retransmitted according to the original frame sequence number. During the sending process, boot partitions can be skipped according to the configuration; and target personalized parameters, such as key-value pairs of parameter names and values, such as Bluetooth names, can be written.

[0122] The soft reset command frame follows the programming protocol frame format, including a preamble, module number, header CRC8, and data CRC32, which is completely consistent with the implementation verified in the long-term online programming of the host computer tool.

[0123] As an optional optimization, differential partition skipping is supported: before burning, the version number or hash value of each target partition is read and compared with the version number or hash value of the corresponding partition in the burning package. If they match, the burning operation of that partition is skipped, thereby shortening the upgrade time.

[0124] (4) Dual-path parallel operation.

[0125] The device has two single-wire serial ports, each connected to one earphone (left and right ear). The two independent burning session state machines proceed in parallel under the time-division scheduling of the main controller, and a pair of earphones can be upgraded at the same time in one operation.

[0126] The time-division scheduling mechanism for dual-path parallel upgrades is as follows: The main controller polls the two single-wire serial ports at fixed time slices (e.g., 10 milliseconds per path) and maintains an independent programming session state machine instance for each path. Both paths share the same programming package data, achieving concurrent access through mutual exclusion of read and write pointers—when one path is in the partition reading phase, it exclusively holds the programming package read pointer, while the other path waits; after reading is complete, the pointer is immediately released for the other path to use, thus avoiding copying two programming packages in the flash memory. This mechanism supports mixed programming scenarios where the two paths target different product models (e.g., the left earbud is the mass-production version, and the right earbud is the engineering version), as long as the programming configurations (such as the wake-up timing parameter set) carried by each path do not conflict.

[0127] (5) Verification and result feedback.

[0128] After each partition is written, a read-back verification is performed immediately. After all partitions are written, the device commands the target to reset and run the new firmware, and reads the target version number again via carrier wave or serial port to confirm that the upgrade has taken effect. The burning result is indicated in real time by a dual-color indicator light or a buzzer. At the same time, the device writes detailed results for each device and each partition to the result log area, which is mapped to a result file (such as RESULT.TXT) on a virtual USB drive. After the device is plugged back into the computer, the user can view the batch upgrade records with Notepad, forming a tool-free result read-back channel.

[0129] When connected to a computer, users can also query the channel-by-channel burning stage and byte-level progress in real time via a virtual serial port, including the source file name of the resident burning package and the failure stage code. The host computer tool displays the progress in real time as a progress bar and can issue a stop command at any time.

[0130] (6) Failure protection.

[0131] If any partition fails to be burned, the device will automatically retry N times. After the number of retries is exhausted, the device will keep the target in boot mode and display a red warning light, waiting to be triggered again. Since the target boot program is stored in read-only memory, a burning interruption will not prevent the target from re-entering the burning mode. After the device itself is powered off and restarted, it will automatically return to the ready-to-burn state based on the still valid burning packages in the burning package area.

[0132] IV. Mode Selection.

[0133] The device automatically determines its operating mode based on two conditions: whether the USB is connected to the computer host (i.e., whether the first interface module is connected to the host computer) and whether a valid programmable package exists in the programmable package area (i.e., whether the storage module stores a valid programmable package). When connected to the host, both the CDC virtual serial port and the virtual USB flash drive are available, with online mode taking priority. Pass-through (providing a pass-through channel) and package loading (obtaining a valid programmable package from the host computer and storing it in the storage module) coexist. When not connected to the host but a valid programmable package exists, it enters an offline waiting-to-burn state (i.e., waiting-to-burn state). No mode switch is required throughout the entire process. When connected to the host, the device also provides a third operating mode—online autonomous burning: the host computer only needs to issue a start command, and the device will pause the pass-through bridge and take over the same target serial port to autonomously complete the entire burning process. During this period, the USB remains online (i.e., the first interface module remains connected to the host computer), and the host computer can query the burning progress in real time. After burning is complete, the device automatically restores the pass-through bridge. The programming logic is always executed by the device itself; the computer only serves as the sender of trigger commands and the observation window for programming progress.

[0134] like Figure 6As shown, the device connects to a computer (in online mode) via two CDC virtual serial ports and one MSC virtual USB drive. Internally, the device integrates a transparent transmission engine, packet receiving and pre-depacketizing modules, flash memory (including packet delivery and programming areas), an offline programming engine (covering timing control, protocol interaction, and verification functions), and a target interface (including power supply control, carrier generation, and two serial ports). The target interface connects to the headphone's charging contacts.

[0135] The device supports three channels: Channel 1 is an online transparent transmission channel (e.g., Figure 6 (As shown by the solid line in the middle), data passes through the computer, CDC, and transparent transmission engine to the target serial port, and the device is transparent; Path 2 is the packaging path (as shown by the solid line in the middle). Figure 6 (As shown by the dashed line in the middle), data is transmitted via USB flash drive or serial port, package delivery area, pre-unpacking area to the burning package area; Path 3 is the offline burning path (such as... Figure 6 (As shown by the solid line reversal), data travels from the burning package area through the offline burning engine and the target interface to the target; the computer may not be present. In online autonomous burning mode, the computer only issues a start command through the control terminal of channel 1, and the burning process is executed along channel 3, with progress reported in real time by the CDC.

[0136] V. Upgrade the device itself.

[0137] The device's own firmware can also be upgraded by dragging and dropping it into the virtual USB drive. The device firmware package and the target firmware package are distinguished by a magic number file format, so the same delivery channel can serve both "upgrading the target device" and "upgrading the device itself" purposes simultaneously.

[0138] VI. Hardware Components.

[0139] like Figure 7 As shown, the device hardware is centered around a master control chip with an integrated USB 2.0 device controller. The differential data pairs (DP / DN) of the USB Type-C interface are directly connected to the USB 2.0 data pins of the master control chip; its configuration channel (CC) pin declares to the host that this device is a powered device through a 5.1kΩ pull-down resistor; the 5V bus (VBUS) is filtered by a ferrite bead and electrostatic discharge protection device before serving as the sole power input for the entire device—the device has no built-in battery and can operate by plugging it into a computer or any general USB power supply device.

[0140] The power supply section consists of two adjustable linear regulators: the first regulates the VBUS 5V to approximately 3.85V to power the main control chip; the second outputs a 3.8V target power supply, whose enable pin is controlled by the normally open general-purpose output pin of the main control chip (corresponding to the hardware implementation of the "target power supply switch"). Pulling the enable pin low cuts off the target power supply, working in conjunction with the "power-off reset - power-on - carrier wake-up" timing sequence. Internally, the main control chip further generates 1.9V / 1.2V / 0.8V core voltages through three step-down power supplies, with an external 32MHz crystal oscillator providing the clock.

[0141] The main control chip has two serial ports (serial port 0 and serial port 1), with serial port 1 being a spare trace. These ports are used to assign pins to charging contacts or debug headers using three different routing modes. The startup mode pin selects its routing mode via pull-up or pull-down levels during power-on. The human-machine interface includes an indicator light (for indicating readiness or programming results), a button (for offline triggering), and a manual reset test point. The main control chip also integrates a Bluetooth RF transceiver with an onboard antenna, providing the hardware foundation for the mobile phone to wirelessly load the upgrade package via Bluetooth Low Energy. The target device (finished headset) is connected via a communication / 5V switching circuit (dual-channel analog switch) and charging contacts (contact 1, contact 2, and ground). The power level selection is controlled by the main control chip.

[0142] like Figure 8 As shown, the communication / 5V switching circuit ( Figure 8 (b) and the target power supply control circuit ( Figure 8 (a) Together, they constitute the key interactive circuit between the device and the target equipment. Among them, the target power supply control adopts an adjustable linear regulator to convert the USB bus 5V to 3.8V target power supply. Its enable terminal is controlled by the normally open domain output of the master control (target power supply switch) - pulling down the enable will cut off the target power supply, which is used for the timing control of "power-off reset - power-on - carrier wake-up"; the 3.8V target power supply also serves as the input of "power supply / carrier mode" in the communication / 5V switching circuit.

[0143] The communication / 5V switching circuit uses a dual-channel analog switch. The common terminal of each channel is connected to an external charging contact. One selection terminal connects to the 3.8V target power supply (power supply or carrier mode), and the other selection terminal connects to the main control serial port transceiver pin (communication mode). The selection control terminal is driven by the main control normally open domain pin. Thus, the same pair of contacts can electronically switch between two uses: "powering the target or transmitting a carrier" and "single-wire serial communication with the target." The 5V communication carrier is the high and low level sequence generated on the contact power line by the main control's bit-sequential switching mode (or controlling the target power supply enable). During pass-through and programming sessions, when the switch is switched to the communication mode, the contacts become a single-wire serial port.

[0144] It should be noted that the above embodiments are merely illustrative. In practical applications, the single-wire serial port of the target interface can be replaced with a single-bus (1-Wire), half-duplex RS485, SWD, SPI (Serial Peripheral Interface), or I2C (Inter-Integrated Circuit) boot interface; carrier wake-up can be replaced with a specific voltage step sequence, pulse width encoding, near-field communication, or magnetic presence signal. The virtual USB flash drive of the packaging channel can be replaced or paralleled with a CDC protocol channel, Bluetooth, Wi-Fi, SD or TF card slot; the upgrade package can be a full package or a differential package. The write idle window in the copy completion judgment can be replaced with an agreed end flag file or a host eject (SCSI (Small Computer System Interface) eject command) event, etc. The triggering method can be target presence detection, button triggering, timed triggering, or "automatic burning after disconnection" scheduled by the host computer when online. The indicator lights or buzzers in the result feedback can be replaced with screen display, low-power Bluetooth broadcast, or query via virtual serial port after plugging back into the computer; the log file format is not limited. The number of parallel channels is not limited to two, and multiple devices can be cascaded to form a mass production workstation. The target device can be a wearable finished device such as headphones or smart glasses that is programmed via charging contacts or serial port. The interface between the device and the computer is not limited to USB; it can be Type-C or wireless, in which case the online mode is implemented via wireless serial port.

[0145] In summary, the key points of the embodiments of the present invention include: 1. Online / Offline Dual-Mode Integrated Architecture: The same device connects to the computer via a USB composite device (multi-channel CDC virtual serial port plus MSC virtual USB flash drive), providing a transparent transmission bridge and packaging channel; when offline, it reuses the same target physical interface (charging contact single-wire serial port) and control resources (power switch, carrier generator) to autonomously perform programming. The working mode is automatically selected based on two conditions: host presence and the existence of valid packets.

[0146] 2. Packaging method without professional software: The offline programmer's upgrade package is loaded by copying the firmware package file to a virtual USB drive—the disk segment is directly mapped to the flash memory partition. A triple-checking process of "writing to free window, directory entry parsing, and byte counting" is used to perform package format verification, automatically deleting illegal files and re-enumerating them. The packaging channel can be expanded to three parallel channels: virtual USB drive, serial port protocol, and Bluetooth wireless, with mutual exclusion arbitration writing to the same package delivery area.

[0147] 3. Finished equipment wake-up and media switching timing: Soft reset wake-up (adapting baud rate wake-up string, running baud rate reset command frame, guiding baud rate handshake loop retry) and "power failure reset - power on again - power line carrier sequence wake-up - contact switching to single-line serial port" are two types of timings that can be selected and combined according to the product. The timing parameters are carried by the configuration file or upgrade package and can be configured with the package.

[0148] 4. Onboard partition-level burning engine: The device pre-decompresses and linearly reassembles the upgrade package into a custom format burning package (read according to the file allocation table cluster chain, compatible with fragmented disk writing). During burning, the burning agent is first injected into the target memory via XMODEM, and then high-speed burning is performed via session frames. The package is streamed partition by partition and read back for verification. It supports baud rate negotiation for speed-up, skipping the boot partition and skipping the difference partition.

[0149] 5. Dual-channel parallel upgrade: Supports simultaneous burning of a pair of earphones (left and right ears).

[0150] 6. Tool-free result rereading: Upgrade results are reread in the form of a virtual USB drive file (RESULT.TXT), allowing you to view batch records without additional tools.

[0151] The embodiments of the present invention have the following advantages: Compared to the online solution of "computer plus host computer tool": the upgrade site only requires this device and one 5V power supply. The operator only needs to copy the firmware package file into the USB flash drive simulated by the device to complete the packaging. After placing it on the target device, the result can be read by the indicator light. Anyone can perform the operation. At the same time, the online transparent transmission capability is fully retained, and R&D and after-sales use a single tool, eliminating the need to maintain two sets of equipment.

[0152] Compared to offline programmers: no computer configuration or software installation is required; simply copying the file completes the loading process. This device is designed for finished devices with only charging contacts remaining, and features power supply control and carrier wake-up timing capabilities, which are not structurally present in SWD or JTAG programmers. Furthermore, it provides a transparent pass-through debugging channel, which is not available in programmer-type products.

[0153] Compared to charging case upgrade solutions: the packaging does not rely on Bluetooth, mobile applications, or wireless links, and the upgrade package originates from auditable documentation. The device adopts an engineering tool form, supporting dual-path parallel processing, batch processing, and result log readback. The burning protocol directly reaches the target bootloader, does not require the earphone application firmware to be healthy, and can repair devices with damaged application firmware.

[0154] This invention also provides a firmware flashing method for wearable devices, which is applied to the firmware flashing apparatus for wearable devices described in the foregoing embodiments. See also Figure 9 The diagram shows a flowchart of a firmware flashing method for a wearable device. The method mainly includes the following steps: In step S910, the main control module automatically enters the online or offline mode workflow based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid programming package. In online mode, step S920 is executed; in offline mode, step S930 is executed.

[0155] In step S920, the main control module controls the first interface module to connect to the host computer via a USB composite device, which includes a virtual serial port and virtual storage; through the virtual serial port, the second interface module provides a transparent transmission channel to the wearable device via charging contacts; in response to the packaging operation, the valid burning package is obtained from the host computer via the virtual storage and stored in the storage module.

[0156] In step S930, the main control module responds to the start trigger event and controls the second interface module to perform offline burning operation on the wearable device through the charging contacts.

[0157] In this embodiment of the invention, online and offline modes are integrated into the same device. The main control module automatically selects the working mode based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid programming package. In R&D and production line scenarios, the device adopts online mode, connecting to the host computer via a USB composite device. The virtual serial port provides a transparent transmission channel to the wearable device through the charging contacts. The virtual storage responds to the packaging operation, obtaining and storing a valid programming package from the host computer, thus meeting the needs of online debugging and host computer programming. In after-sales and field scenarios, after the device is disconnected from the host computer, the main control module automatically switches to offline mode and responds to the start trigger event, controlling the second interface module to perform offline programming operations on the wearable device through the charging contacts. Therefore, the same device can simultaneously cover both online debugging and offline upgrade scenarios, eliminating the need to prepare two separate tools for different scenarios. The operation method is unified, and the offline mode directly adapts to finished wearable devices that only expose charging contacts, without requiring an additional programming interface.

[0158] The method provided in this embodiment has the same implementation principle and technical effect as the aforementioned device embodiment. For the sake of brevity, any parts not mentioned in the method embodiment can be referred to the corresponding content in the aforementioned device embodiment.

[0159] In all examples shown and described herein, any specific values ​​should be interpreted as merely exemplary and not as limitations; therefore, other examples of exemplary embodiments may have different values.

[0160] 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; and 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.

Claims

1. A firmware burning device for a wearable device, characterized in that, It includes a main control module, and a first interface module, a storage module, and a second interface module connected to the main control module; the first interface module is used to connect to a host computer to obtain a valid programming package; the storage module is used to store the valid programming package; the second interface module is used to connect to the wearable device through the charging contacts of the wearable device to program the wearable device based on the valid programming package. The main control module is used to automatically enter online mode or offline mode based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid burning package. In the online mode, the main control module controls the first interface module to interface with the host computer via a USB composite device; the USB composite device includes a virtual serial port and virtual storage; the virtual serial port is used to provide a transparent transmission channel to the wearable device through the charging contacts via the second interface module; the virtual storage is used to obtain a valid burning package from the host computer and store it in the storage module in response to the packaging operation. In the offline mode, the main control module responds to the start trigger event and controls the second interface module to perform an offline burning operation on the wearable device through the charging contact.

2. The apparatus according to claim 1, characterized in that, The main control module is also configured to: in the online mode and when the storage module stores a valid programming package, respond to the start programming command issued by the host computer, pause the transparent transmission channel and autonomously execute the entire programming process based on the valid programming package; during programming, the first interface module maintains a connection with the host computer to report the programming progress to the host computer; and automatically restore the transparent transmission channel after programming is completed.

3. The apparatus according to claim 1, characterized in that, The virtual storage is an MSC virtual USB drive; the virtual storage obtains a valid programming package from the host computer by receiving the programming package file written to the virtual USB drive by the host computer and writing the programming package file to the package delivery area of ​​the storage module. The main control module is further configured to: determine that the burning package file has been stored successfully when the cumulative duration of no write operation in the package delivery area reaches a first preset duration, and it is confirmed that the burning package file has fallen into the package delivery area corresponding to the directory entry in the root directory of the disk, and the byte count written to the package delivery area reaches the file length declared by the directory entry; and perform format verification on the burning package file; when the verification is valid, mark the burning package file as the valid burning package. If the verification fails, the burning package file is deleted and the first interface module is controlled to re-enumerate the virtual USB drive.

4. The apparatus according to claim 3, characterized in that, The main control module is also used to: after the burning package file is verified as valid and marked as a valid burning package, and before the burning operation is performed, decompress the valid burning package to obtain several partition images, each of the partition images corresponding to a target partition in the flash memory of the wearable device; parse the storage layout description of the valid burning package, add an image header to each partition image, and generate a boot partition table that records the offset and length of each target partition; The boot partition table and the partition images with added image headers are linearly reassembled into a target burning package in the target partition order. The target burning package is written into the burning package partition of the storage module, and the source file name of the valid burning package is also permanently saved. During decompression and linear reassembly, the main control module refuses to execute the burning request.

5. The apparatus according to claim 1, characterized in that, The startup trigger event includes one or more of the following: the second interface module detects that the wearable device is in place, receives a button trigger signal, the device is powered on, and receives a startup burning command issued by the host computer through the virtual serial port.

6. The apparatus according to claim 1, characterized in that, The main control module is also used to, when controlling the second interface module to perform offline programming operations on the wearable device, to bring the wearable device into a programmable state according to one or a combination of the following wake-up paths: Soft reset wake-up path: Send a wake-up string via the single-line serial port of the second interface module at an adapted baud rate; send a soft reset command frame conforming to the programming protocol frame format at the running baud rate; The handshake characters are sent periodically at the boot baud rate, and the bootloader's ready prompts are listened for. Power-off reset carrier wake-up path: Disconnect the power supply to the wearable device and maintain it for a second preset duration to allow the wearable device to be completely powered off and reset; after reconnecting the power supply to the wearable device, send a carrier bit sequence through the charging contact to allow the wearable device to switch to serial communication mode; switch the charging contact to single-wire serial communication state to enter the programming protocol session.

7. The apparatus according to claim 4, characterized in that, The main control module is also used to: inject a burning agent program into the memory of the wearable device via the XMODEM protocol through the single-line serial port of the second interface module when performing offline burning operation; After the programming agent program runs, it interacts with the programming agent program according to the session frame format to perform the session programming operation; The session programming operation includes: Negotiate to increase the serial port baud rate; Distribute the boot partition table of the target burning package; Firmware data is streamed partition by partition according to the boot partition table; during the distribution process, the data is read from the burning package partition of the storage module and sent simultaneously; each session frame waits for the wearable device's response, and if a timeout or verification error occurs, the data is retransmitted according to the original frame sequence number; During the distribution process, the boot partition is skipped, and the difference partition skipping is performed. The difference partition skipping includes obtaining the identification information of each target partition of the wearable device before distributing firmware data partition by partition, and comparing it with the identification information of the corresponding partition in the target flashing package. If they match, the distribution and flashing operation of that partition is skipped.

8. The apparatus according to claim 1, characterized in that, The second interface module includes two independent single-wire serial ports, each of which is connected to a wearable device through a charging contact. The main control module is also used to: control the two single-line serial ports in parallel to perform offline burning operations on the two wearable devices.

9. The apparatus according to claim 1, characterized in that, The host computer includes one of a computer, mobile phone, or tablet with USB host functionality; the main control module is also used to generate a burning result file after the offline burning operation is completed, and to provide the host computer with a virtual USB flash drive file via the virtual storage in the online mode.

10. A method for flashing firmware onto a wearable device, characterized in that, A firmware burning apparatus for a wearable device according to any one of claims 1-9; the method comprising: The main control module automatically enters online or offline mode based on the connection status between the first interface module and the host computer, and whether the storage module stores a valid burning package. In the online mode, the main control module controls the first interface module to connect to the host computer via a USB composite device, the USB composite device including a virtual serial port and virtual storage; through the virtual serial port, the second interface module provides a transparent transmission channel to the wearable device via the charging contacts; in response to the packaging operation, a valid burning package is obtained from the host computer via the virtual storage and stored in the storage module; In the offline mode, the main control module responds to the start trigger event and controls the second interface module to perform an offline burning operation on the wearable device through the charging contact.

Images