USB communication abnormity processing method, computing device and storage medium

Abstract

The invention relates to a USB communication abnormity processing method, computing equipment and a storage medium, the method is applied to a USB host, and the method comprises the following steps: in response to communication abnormity of the USB host and the USB equipment, sending a reset signal to the USB equipment through an auxiliary channel of a non-USB channel; after it is determined that the USB device receives the reset signal for resetting and releases reset, the USB host enters waiting time; and in response to detecting the connection event with the USB device, initiating a first enumeration to the USB device after the waiting time to reestablish the USB communication connection with the USB device. According to the method provided by the invention, the recovery time after the communication is abnormal is reduced, and meanwhile, only the equipment with the communication abnormity is reset, so that the influence on other services in the system is reduced, and the user experience is further improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method for handling USB communication anomalies, a computing device, and a storage medium. Background Technology

[0002] As embedded systems become increasingly complex, multi-processor collaborative architectures have become the mainstream solution for meeting high-performance computing needs. In such systems, Universal Serial Bus (USB) is often used for high-speed interconnection between processors due to its advantages in transmission efficiency and deployment cost. However, in scenarios where multiple processors are interconnected via USB within a device, due to physical layer inaccessibility, once a communication anomaly occurs (e.g., the host cannot recognize the device), and manual plugging and unplugging cannot restore the connection, the only method to restore the connection is to force a system reset. However, restoring the entire system is time-consuming (e.g., ≥20 seconds), and system reset also causes associated service terminals to stop running, resulting in a poor user experience. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure provides a method for handling USB communication anomalies, a computing device, and a storage medium.

[0004] In a first aspect, embodiments of this disclosure provide a method for handling USB communication anomalies, applied to a USB host, comprising: In response to a communication failure between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel that is not part of the USB channel. After confirming that the USB device has received a reset signal, reset, and released the reset, the USB host enters a wait time; and In response to the detection of a connection event with a USB device, after a waiting period, initiate the first enumeration to re-establish the USB communication connection with the USB device.

[0005] Secondly, embodiments of this disclosure provide a method for handling USB communication anomalies, applied to a USB device, including: Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to an abnormal communication between the USB host and the USB device; Perform a reset and release the reset after a first duration; and receive a first enumeration initiated by the USB host, and re-establish a USB communication connection with the USB host in response to the first enumeration, wherein the first enumeration is initiated by the USB host after the USB device releases the reset and enters a waiting period in response to detecting a connection event with the USB device, and after the waiting period.

[0006] Thirdly, embodiments of this disclosure provide a method for handling USB communication anomalies, applied to a computing device including a USB host and a USB device, comprising: In response to a communication failure between the USB host and the USB device, the USB host sends a reset signal to the USB device through an auxiliary channel other than the USB channel. The USB device receives a reset signal sent by the USB host, performs a reset, and releases the reset after a first duration. USB host enters waiting time; In response to detecting a connection event with a USB device, the USB host initiates the first enumeration of the USB device after a waiting period; and The USB device receives the first enumeration and responds to it to re-establish the USB communication connection with the USB host.

[0007] Fourthly, embodiments of this disclosure provide a computing device, including a USB host and a USB device, wherein the USB host is configured as follows: In response to a communication failure between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel that is not part of the USB channel. The system determines that the USB device receives a reset signal, resets, releases the reset, and enters a wait time; and In response to the detection of a connection event with a USB device, after a waiting period, initiate the first enumeration to re-establish the USB communication connection with the USB device; The USB device is configured as follows: Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to an abnormal communication between the USB host and the USB device; Perform a reset and release the reset after a first duration; and The system receives the first enumeration initiated by the USB host and responds to the first enumeration to re-establish the USB communication connection with the USB host. The first enumeration is initiated by the USB host after the USB device releases and resets and enters a waiting period, in response to the detection of a connection event with the USB device, and after the waiting period.

[0008] Fifthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0009] The USB communication exception handling method disclosed herein includes: in response to a communication exception between the USB host and the USB device, sending a reset signal to the USB device via an auxiliary channel other than the USB channel; determining that the USB device receives the reset signal, resets, and releases the reset signal, and then the USB host enters a waiting period; and in response to detecting a connection event with the USB device, initiating a first enumeration to re-establish the USB communication connection with the USB device after the waiting period. The method provided in this application, by resetting the USB device, eliminates the need for a system-level reboot of the entire device, reducing recovery time after a communication exception. Furthermore, by only resetting the device with the communication exception, it reduces the impact on other services in the system, thereby improving the user experience. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0011] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating the physical implementation of USB deployment for related technologies; Figure 2 A schematic diagram of a dual-SoC USB master-slave architecture provided in this embodiment of the disclosure; Figure 3 A flowchart for the recovery of an internal interconnection scenario provided for related technologies; Figure 4 A flowchart illustrating a method for handling USB communication errors provided in this embodiment of the disclosure; Figure 5 A schematic diagram of another dual-SoC USB master-slave architecture provided in this disclosure embodiment; Figure 6 A flowchart illustrating a method for handling USB communication errors provided in this embodiment of the disclosure; Figure 7 A flowchart illustrating a method for handling USB communication errors provided in this embodiment of the disclosure; Figure 8This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure; Figure 9 A recovery flowchart based on USB master-slave collaboration using a non-USB channel is provided for embodiments of this disclosure; Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure. Detailed Implementation

[0013] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0014] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0015] As the complexity of embedded systems increases, multi-processor collaborative architectures (such as heterogeneous computing of Central Processing Units (CPUs) and Graphics Processing Units (GPUs), and distributed processing of multiple System-on-Chips (SoCs)) have become the mainstream solution to meet the demands of high-performance computing. In such systems, the selection of the inter-processor interconnect bus must consider characteristics such as transmission efficiency, deployment cost, and development convenience. Specifically, in terms of transmission efficiency, it must support gigabit-level real-time data streams (e.g., computer vision point cloud data); in terms of deployment cost, the hardware complexity must be controllable; and in terms of development convenience, it must have mature debugging toolchain support. In embedded system internal interconnection scenarios, the USB protocol has become a superior choice due to its unique advantages. Specifically, the USB protocol is flexible and supports multiple adaptive modes of USB 2.0 / 3.0 (e.g., 5Gbps SuperSpeed ​​mode). In terms of hardware costs, it eliminates the need for a dedicated SerDes PHY (compared to the high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe)), reduces the number of cabling layers by 50%, and has a relatively mature ecosystem with native driver support from mainstream RTOS / Linux and complete debugging tools (such as USBlyzer / Wireshark).

[0016] In a USB-based communication system, there can typically be a USB host and one or more USB devices. The USB host is the control center of the USB system, responsible for initializing communication, managing bus resources, allocating addresses, and controlling data transmission. The USB devices are connected to the USB host and respond to the host's commands to execute data transmission.

[0017] Currently, in systems using USB to interconnect multiple processors (such as SoC, CPU, GPU, FPGA, etc.), there is a certain probability of communication anomalies where the host cannot recognize the device. For USB devices that are independent external devices, the connection can be restored by manually plugging and unplugging them. However, in USB systems where devices are interconnected internally via PCB traces, enclosed connectors, or internal fixed cables, the physical layer connection is inaccessible, and the only way to restore the connection is by restarting the single-ended or dual-ended processor system. This method has significant drawbacks, including long recovery times, impact on system integrity, and poor user experience. For example, system restarts can take several seconds to tens of seconds, and restarts can cause related modules to malfunction or critical services to be interrupted.

[0018] Figure 1 The diagram illustrates the physical implementation of USB deployment for related technologies. In the scenario of internal device interconnection, USB deployment mainly adopts three types of physical implementations: direct connection at the PCB level, enclosed connectors, and internal shielded cables. Among them, direct connection at the PCB level is characterized by good signal integrity and the lowest cost. Enclosed connectors are characterized by good maintainability and resistance to mechanical stress. Internal shielded cables are characterized by flexible layout, but have high requirements for electromagnetic shielding.

[0019] Figure 2 This is a schematic diagram of a dual-SoC USB master-slave architecture provided in an embodiment of this disclosure. The host (also called the host SoC) outputs USB signals (e.g., USB 2.0 differential pairs D+ / D- and USB 3.0 ultra-high-speed transceiver signals, such as...). Figure 2 As shown), the device (Device), also known as the coprocessor SoC (Device SoC), is configured in OTG Device mode to receive corresponding signals.

[0020] Understandable. Figure 2 The example shown is merely one example of a USB system provided in this disclosure. This disclosure does not limit the type of chip that makes up the USB system. For example, it can be one or more of a CPU, MCU, microcontroller, FPGA or SOC, as long as it includes the USB protocol for internal communication and has a USB host and at least one USB device.

[0021] Figure 3 This document provides a recovery flowchart for an internal interconnect scenario. When a communication anomaly occurs where the host cannot recognize the device, the recovery process is as follows: Before establishing valid data transmission, a device enumeration process must be completed. If device enumeration fails, a physical reset is attempted. The physical layer is then checked for accessibility. If it is an external USB and the physical layer is accessible, communication is restored by manually unplugging and replugging the USB. If it is an internal interconnect USB and the physical layer is inaccessible, a forced system restart is performed, resulting in a costly recovery. Furthermore, the enumeration process is prone to failure due to hardware layer anomalies. For example, a fault source could be a host-side PHY (physical layer) anomaly, manifesting in some examples as insufficient USB 2.0 differential signal amplitude (<300mV). Another example is a device-side controller status error, manifesting in some examples as an inability to respond to SETUP token packets. Yet another example is signal integrity degradation, manifesting in some examples as USB 3.0 RxEQ training failure. When the Host and Device are fixedly connected via board-level direct connection (e.g., PCB traces) or enclosed connectors (e.g., board-to-board connectors), there are problems such as physical layer inaccessibility, lack of external operable interfaces (compared to the external USB Type-C interface), cables encapsulated inside the device housing, and failure of solutions for manually unplugging and replugging the USB. Therefore, a forced system restart is required, resulting in high recovery costs.

[0022] To address the aforementioned technical problems, this disclosure provides a method for handling USB communication anomalies. It only resets the USB subsystem (e.g., USB controller and PHY), avoiding interruptions to associated services (e.g., GPU rendering / real-time audio / video streaming), thus achieving precise fault isolation. Simultaneously, it compresses recovery time from 20 seconds (system restart) to ≤500ms, achieving millisecond-level recovery. Furthermore, it reuses existing hardware resources (e.g., GPIO / UART), incurring no additional material costs and achieving zero-cost deployment. This will be described in detail through one or more of the following embodiments.

[0023] This disclosure provides a method for handling USB communication errors, applicable to various scenarios involving USB communication errors. This method can be executed by a USB communication error handling device, which can be implemented in software and / or hardware and integrated into a computing device. The computing device can include, but is not limited to, mobile terminals such as handheld 3D scanners, fixed 3D scanners, intraoral scanners, facial scanners, implant navigation systems, smartphones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet PCs (Tablet Personal Computers), PMPs (Portable Multimedia Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable devices, and fixed terminals such as digital televisions, desktop computers, and smart home devices.

[0024] Figure 4 A flowchart illustrating a USB communication exception handling method provided in this disclosure, applied to a USB host, specifically includes: Figure 4 The following steps are shown: S401. In response to a communication error between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel other than the USB channel.

[0025] Understandably, the USB host monitors the communication status with each USB device in real time. If a communication anomaly is detected with a particular USB device, a reset signal is sent to the USB device via an auxiliary channel (not a USB channel). In other words, when communication between the USB host and the USB device is impossible via conventional USB channels such as USB 2.0 differential pairs D+ / D- and / or USB 3.0 UltraSpeed ​​Transceiver due to a communication anomaly, an auxiliary channel (a non-USB channel, such as a general purpose input / output pin or other suitable communication channel) is activated between the USB host and the USB device. Subsequently, the USB device with the communication anomaly is located, and a reset signal is sent to it. By accurately resetting the USB device, the impact on other related services / devices is reduced, effectively avoiding reliance on a system-level reboot.

[0026] In some examples, a master processor in a computing device is defined as the USB host described herein, and one or more slave processors in the computing device are defined as the USB devices described herein.

[0027] Understandably, the master processor (e.g., the main SoC / CPU) is defined as the USB host, responsible for controlling the entire USB communication process, enumerating and identifying devices, and actively requesting or sending data to slave processors. Slave processors (e.g., GPUs / coprocessors) are defined as USB devices, which mostly passively wait for instructions from the master processor and can only transfer data when queried by the master processor.

[0028] In some examples, communication anomalies refer to monitored enumeration failure events or signal integrity anomalies.

[0029] In some examples, the USB host can be configured with a real-time detection mechanism to trigger a reset process on the host (USB device) by monitoring communication anomalies such as enumeration failure events or signal integrity errors, and sending a reset signal to the device. Communication anomalies refer to detected USB enumeration failure events (e.g., inability to respond to SETUP token packets) or signal integrity errors (e.g., insufficient D+ / D- voltage).

[0030] For example, Figure 5 This diagram illustrates another dual-SoC USB master-slave architecture provided in this embodiment. The HostSoC is the USB host, and the DeviceSoC is the USB device. The communication between the USB host and the USB device includes a conventional USB channel (e.g., a USB 2.0 / 3.0 channel) and an auxiliary channel (e.g., GPIO or other suitable communication channel). In the event of a communication anomaly in the USB channel, i.e., when the Host cannot detect the Device (e.g., the Device does not respond or there is a data error), the Host sends a reset signal to the Device via the auxiliary channel GPIO.

[0031] In some examples, the auxiliary channel is at least one of GPIO, UART, SPI, and I2C.

[0032] Understandably, GPIO (General-Purpose Input Output) is a general-purpose digital signal pin whose function can be flexibly configured by software. It can output high and low levels to control other circuits, or input levels to read external status. UART (Universal Asynchronous Receiver Transmitter) is a serial data transmission protocol that uses asynchronous communication. It requires only two signal lines (transmit and receive) to achieve full-duplex communication without clock synchronization. SPI (Serial Peripheral Interface) is a high-speed, full-duplex synchronous serial communication bus using a master-slave mode. It typically includes four signal lines: clock, data input, data output, and chip select. The communication rate can be flexibly configured by the host. I2C (Inter-Integrated Circuit) is a synchronous, half-duplex serial communication bus consisting of clock and data lines. It supports multiple master and slave devices connected to the same bus, identifying communication objects through addresses. These communication interfaces can all serve as auxiliary communication channels between a USB host and USB devices. The auxiliary channel offers a variety of cooperative signals, and the reset function can be implemented using existing GPIO resources without incurring additional hardware costs (such as dedicated circuits or chips). Furthermore, in terms of compatibility, it supports protocols such as USB 1.x / 2.0 / 3.0, making it suitable for various embedded SoC architectures (such as ARM and x86).

[0033] Optionally, before sending a reset signal to the USB device via an auxiliary channel other than the USB channel, the following steps are also included: The USB host performs a reset, which includes resetting the USB controller and physical layer interface of the USB host; after the USB host releases the reset, it initiates a second enumeration to the USB device; and in response to the failure of the second enumeration, it sends a reset signal to the USB device through an auxiliary channel other than the USB channel.

[0034] Understandably, when a USB host cannot detect a USB device, it can first perform a reset operation, such as resetting the USB controller and PHY on the host side. Automatic reset by the USB host itself is more efficient than notifying the USB device to perform a reset. In some cases, the USB host itself may malfunction, causing communication abnormalities with the USB device. In such situations, automatic reset by the USB host can significantly improve communication recovery speed. After releasing the reset, the USB host initiates a second enumeration to attempt to re-enumerate the USB device. If the second enumeration fails, a reset signal is sent to the USB device through an auxiliary channel other than the USB channel. If the second enumeration succeeds, the communication recovery process terminates.

[0035] It should be noted that the success rate of enumeration initiated after the USB host automatically resets is usually low, because in real-world scenarios, most communication anomalies originate from the Device side (USB device).

[0036] Understandably, in a USB system, enumeration refers to the process by which the system actively discovers, identifies, and configures newly connected devices; that is, the process of re-detecting and connecting new devices. The basic enumeration process includes: 1) Physical connection: The device is plugged into the USB port, and the host detects a voltage change (e.g., a change in the D+ or D- line level), knowing that a new device has been connected. 2) Reset the device: The host sends a reset signal (e.g., a low level lasting at least 10ms) to reset the device to its default state (e.g., address 0). 3) Obtain the device descriptor: The host sends a GET_DESCRIPTOR request through the default control pipe (e.g., address 0, endpoint 0) to obtain basic information about the device, such as the USB version, device class, subclass, maximum packet size (MaxPacketSize), vendor ID (VID) and product ID (PID), manufacturer name, product name, etc. 4) Assign a unique address: The host sends a SET_ADDRESS request to assign a unique non-zero address (1~127) to the device. Afterward, the host uses this new address to communicate with the device (no longer address 0). 5) Obtain Configuration Descriptor: The host requests the configuration descriptor again to learn about the device's supported configurations (there may be multiple), the number of interfaces, the number of endpoints, etc. 6) Obtain Interface & Endpoint Descriptors: The host further obtains detailed information for each interface and endpoint (e.g., data transfer type: control, bulk, interrupt, synchronous). 7) Select Configuration: The host sends a SET_CONFIGURATION request to select a valid configuration (usually only one). At this point, the device enters the "configured" state and can begin data transfer. 8) Driver Loading: The host operating system uses the VID, PID, class code, and other information from the device descriptor to find and load the appropriate driver (e.g., HID driver for keyboard and mouse, Mass Storage driver for USB flash drive). 9) Device Ready: Enumeration is complete; the device can function normally, and the host can exchange data with it.

[0037] Optionally, when a USB host connects to multiple USB devices, sending a reset signal to the USB devices via an auxiliary channel other than the USB channel includes: In response to normal communication between the USB host and at least one USB device, a reset signal is sent to the USB device experiencing communication failure via an auxiliary channel other than the USB channel.

[0038] Understandably, when a USB host is simultaneously communicating with multiple USB devices, it's necessary to check whether the USB host and the other USB devices (excluding the target USB device with the communication error) also have communication problems. In other words, before resetting the USB host, the communication status between the USB host and other USB devices is checked. If the USB host is communicating normally with any of the other USB devices, a reset signal is sent to the target USB device with the communication error via an auxiliary channel (not part of the USB channel). Alternatively, the USB host can perform a reset first and then send a reset signal to the target USB device for more precise location of the faulty USB. If the USB host is communicating normally with at least one USB device, it indicates that the USB host is not faulty, and the communication error is caused by a fault in the target USB device. If the USB host and all other USB devices have communication errors, the USB host is reset. After the USB host releases the reset, a second enumeration is initiated with the USB devices. See the example above for a detailed implementation description.

[0039] S402. After confirming that the USB device has received the reset signal, reset, and released the reset, the USB host enters the waiting time.

[0040] Understandably, based on the above S401, after the USB device (the target USB device experiencing a communication anomaly) detects the reset signal sent by the USB host through the auxiliary channel, it performs a reset operation, resetting its own USB controller and PHY. After the USB host confirms that the USB device has received the reset signal, performed the reset, and released the reset, it enters a waiting period to ensure the stability of the PHY. For example, the waiting period can be 200ms. The waiting period can be understood as the time spent waiting for the device to reset, and can be counted from the time the device receives the reset signal.

[0041] S403. In response to detecting a connection event with a USB device, after a waiting period, initiate the first enumeration to the USB device to re-establish the USB communication connection with the USB device.

[0042] Understandably, based on the S402 above, the USB host will detect USB connection events while entering the waiting time to ensure that the USB device and USB host establish a physical connection. One possible scenario is that the USB host detects a connection event with the USB device during the waiting time. In this case, the first enumeration to the USB device needs to be initiated only after the waiting time has ended; that is, the execution priority of the waiting time is higher than the connection event and the enumeration event. Another possible scenario is that the connection event with the USB device is detected after the waiting time has ended, and the first enumeration to the USB device is initiated. The first enumeration can be understood as a re-enumeration. Re-enumeration refers to the process of forcing the USB host to rediscover and configure a connected USB device. Its core purpose is to simulate a physical "plug-and-play" operation, but it is implemented entirely through logical or electrical means without actually disconnecting the physical connection. This process bypasses a system restart, compressing the recovery time to the millisecond level. In actual engineering, re-enumeration after a USB device reset usually succeeds, re-establishing the communication connection between the USB device and the USB host, ensuring synchronization of the two ends' states.

[0043] Understandably, this application employs a collaborative reset strategy between the host and device sides, essentially a soft reboot of the USB module. The hierarchical reset logic includes a host-side priority reset followed by a synchronized device-side reset. First, it attempts to reset the host's USB controller and PHY (e.g., adjusting D+ / D- voltage, resetting registers). If the host-side reset still fails to enumerate, it sends a notification reset signal to the device via GPIO, causing the device / slave to reset its USB controller and PHY. Additionally, the host waits 200ms before actively initiating a re-enumeration to ensure that the host and device enter a consistent enumeration state after the reset, achieving dual-end state synchronization.

[0044] Optionally, after initiating the first enumeration of the USB device after the wait time, the method further includes: In response to the failure of the first enumeration, the USB host performs a reset; after the USB host releases the reset, it initiates a third enumeration for the USB device.

[0045] Understandably, embodiments of this disclosure can also include a circuit breaker mechanism. If the first enumeration fails, the process of automatically resetting the USB host, resetting the USB device, and initiating a re-enumeration of USB is executed repeatedly, or the process of resetting the USB device and initiating a re-enumeration of USB is executed repeatedly. If both fail, the circuit breaker is triggered. Additionally, the number of iterations can be set. For example, if enumeration still fails after three iterations, a detailed error log is recorded, a system-level abnormal event is reported, and a safety circuit breaker is executed (e.g., shutting down USB power / resetting the system). The error log can record detailed fault timestamps, error codes, and the number of resets, facilitating subsequent analysis and optimization.

[0046] The communication recovery process described in this article may include: When the USB host detects a communication anomaly with the USB device, it automatically resets and sends a third enumeration to the USB device after the reset is released. If the third enumeration fails, the USB host sends a reset signal to the USB device through an auxiliary channel. The USB device responds to the reset signal, performs a reset, and releases. Simultaneously, the USB host enters a waiting period and checks for device connection events. Upon detecting a connection event, the USB host initiates a first enumeration with the USB device. If the first enumeration also fails, the above steps are repeated.

[0047] Another communication recovery process described in this article may include: When the USB host detects a communication anomaly with the USB device, it sends a reset signal to the USB device via an auxiliary channel. The USB device responds to the reset signal, performs a reset, and releases. The USB host then enters a waiting period and checks for device connection events. Upon detecting a connection event, the USB host initiates the first enumeration with the USB device. If the first enumeration fails, the USB host automatically resets and sends a second enumeration to the USB device after the reset is released. If the second enumeration also fails, the above steps are repeated.

[0048] This disclosure provides a method for handling USB communication anomalies, applied between a master processor (USB host) and one or more slave processors (USB devices) interconnected within a computing device. It achieves zero-cost deployment by reusing existing auxiliary channels (e.g., GPIO). Specifically, when the USB host detects a communication anomaly such as command timeout or no response while communicating with a USB device via the USB bus, it sends a reset signal to the USB device via GPIO. This instructs the USB device to automatically trigger a hardware reset of its internal USB subsystem (including the USB controller and PHY) without affecting its core tasks (e.g., GPU rendering calculations). After the USB device resets and releases, the USB host waits for a certain period before re-enumerating the USB device via the USB bus, re-establishing the USB connection, and restoring normal communication. The method provided in this application strictly limits the scope of communication fault recovery to the faulty USB link itself, restoring communication without affecting other system components, effectively avoiding related service interruptions, and achieving precise fault location. Furthermore, by only resetting the controller and PHY of the USB device with the communication fault, the faulty unit is automatically isolated and reset, reducing the communication recovery time from over 20 seconds required for a full system restart to milliseconds. In addition, it enables seamless self-healing of communication failures, ensuring the continuity of critical services and improving user experience. Furthermore, it eliminates the need for manual intervention or system-level restarts.

[0049] Figure 6A flowchart illustrating a method for handling USB communication errors provided in this disclosure, applied to a USB device, specifically includes: Figure 6 The following steps are shown: S601. Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to an abnormal communication between the USB host and the USB device.

[0050] Understandably, USB devices can detect reset signals sent by the USB host through the auxiliary channel in real time, or USB devices can periodically detect reset signals.

[0051] Optionally, before receiving the reset signal sent by the USB host, the following is also included: Receive the second enumeration sent by the USB host, and respond to the second enumeration to establish a USB communication connection with the USB host. The second enumeration is initiated after the USB host performs a reset and releases the reset. If the second enumeration is successful, the USB communication exception handling process ends. Alternatively, if the second enumeration fails, wait for the receive reset signal sent by the USB host.

[0052] Understandably, before receiving the reset signal from the USB host via the auxiliary channel, the USB device receives a second enumeration initiated by the USB host after automatic reset and reset release. That is, before resetting, the USB host first attempts to reset and performs an enumeration operation to determine if it can rediscover the USB device and re-establish communication. If the USB device responds to this second enumeration and re-establishes communication with the USB host, the USB device does not need to reset and can directly end the communication recovery process. If the second enumeration fails, the USB device needs to reset and continues to wait for the reset signal from the USB host.

[0053] S602, perform a reset and release the reset after a first duration; and receive a first enumeration initiated by the USB host, and re-establish the USB communication connection with the USB host in response to the first enumeration, wherein the first enumeration is initiated by the USB host after the USB device releases the reset and enters a waiting time, in response to detecting a connection event with the USB device, and after the waiting time.

[0054] Understandably, based on the above S601, after detecting the reset signal, the USB device performs a reset operation, resetting its own USB controller and PHY. Simultaneously, it maintains the reset state for at least a first duration, i.e., releasing the reset after the first duration. For example, the first duration could be 100ms or other suitable duration. The first duration can be understood as the initialization duration of the USB device, and waiting for the first duration can be understood as waiting for the software installed on the USB device to start and reset. Understandably, the specific first duration can be determined according to the USB protocol. Subsequently, in response to the first enumeration, the USB communication connection with the USB host is re-established. The operations performed by the USB host are as described in the above embodiment and will not be repeated here.

[0055] In some examples, a reset is performed and then released after a first duration, including: Perform a reset, resetting the USB controller and physical layer interface of the USB device; Release the reset after the first duration and wait for the second duration.

[0056] Understandably, a USB device performing a reset operation primarily resets the USB controller and PHY. It waits for a first duration, releases the reset, and then waits for a second duration; that is, it maintains the reset state for the first duration, releases the reset, and waits for the second duration. Understandably, the sum of the first and second durations for the USB device can be the waiting time for the USB host.

[0057] For example, the first duration can be 100ms as mentioned above, the second duration can also be 100ms, or the first and second durations can be other suitable durations. This disclosure provides a method for handling USB communication anomalies, applied to a USB device. When the USB device receives a reset signal, it resets its USB controller and PHY, waits 200ms, and then receives a re-enumeration initiated by the USB host. This ensures that the USB host and USB device enter a consistent enumeration state after reset, achieving dual-end state synchronization and effectively improving stability and reset success rate.

[0058] Figure 7 A flowchart of a USB communication exception handling method provided in this disclosure embodiment is applied to a computing device including a USB host and a USB device, specifically including as follows: Figure 7 The following steps are shown: In this context, a master processor in a computing device is defined as a USB host, and one or more slave processors in the computing device are defined as USB devices.

[0059] S701. In response to a communication error between the USB host and the USB device, the USB host sends a reset signal to the USB device through an auxiliary channel other than the USB channel.

[0060] S702: The USB device receives a reset signal sent by the USB host, performs a reset, and releases the reset after a first duration.

[0061] S703, USB host enters waiting time.

[0062] S704: In response to detecting a connection event with a USB device, the USB host initiates the first enumeration to the USB device after a waiting period. S705: The USB device receives the first enumeration and responds to the first enumeration to re-establish the USB communication connection with the USB host.

[0063] Understandably, the specific implementation details of S701-S705 are described in the above embodiments and will not be repeated here.

[0064] Based on the above embodiments, Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure. The computing device includes a USB host and a USB device, wherein... Optionally, the USB host is configured as follows: In response to a communication anomaly between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel other than the USB channel; the USB device is determined to have received the reset signal, reset, and release the reset, and then enters a waiting period; and in response to the detection of a connection event with the USB device, the first enumeration is initiated to the USB device after the waiting period to re-establish the USB communication connection with the USB device.

[0065] In this context, a master processor in a computing device is defined as a USB host, and one or more slave processors in the computing device are defined as USB devices.

[0066] Optionally, the USB device is configured as follows: Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to an abnormal communication between the USB host and the USB device; perform a reset and release the reset after a first duration; and receive a first enumeration initiated by the USB host, and re-establish the USB communication connection with the USB host in response to the first enumeration, wherein the first enumeration is initiated by the USB host after the USB device releases the reset and enters a waiting time in response to detecting a connection event with the USB device, and after the waiting time.

[0067] Understandably, the specific implementation details of the USB device and USB host are described in the above embodiments and will not be repeated here.

[0068] Based on the above embodiments, Figure 9This disclosure provides a recovery flowchart for USB master-slave collaboration based on a non-USB channel, applicable to a computing device. The computing device includes a USB host and a USB device, specifically including, for example... Figure 9 The following steps are shown: 1) A USB communication anomaly is detected; 2) The USB host's USB controller and PHY are reset; 3) The USB host attempts to enumerate the USB device; 4) If enumeration fails, the USB host sends a reset signal via GPIO; 5) The USB device responds to the reset signal and resets its own USB controller and PHY; 6) The USB device maintains the reset state for a first duration; 7) The USB device releases the reset and waits for a second duration; 8) The USB host detects a USB connection event; 9) The USB host enters the waiting time; 10) The USB host initiates a re-enumeration; 11) If the re-enumeration fails, steps 2) to 10) are repeated, and the number of retries is counted; 12) If the number of retries exceeds a preset threshold, a log is recorded, the system is notified, and circuit breaking is performed, while the process is terminated; 13) If the enumeration is successful, the process ends.

[0069] Understandably, the specific implementations of 1) to 13) above are as described in the above embodiments and will not be repeated here.

[0070] The USB communication exception handling device provided in this disclosure embodiment can execute the processing flow provided in the USB communication exception handling method embodiment. The USB communication exception handling device (hereinafter referred to as the first processing device) is applied to a USB host. The first processing device includes a signal sending unit, a determining unit, and an enumeration unit, wherein: The signal transmitting unit is used to send a reset signal to the USB device through an auxiliary channel other than the USB channel in response to a communication failure between the USB host and the USB device. The determining unit is used to determine the USB host enters a waiting time after the USB device receives a reset signal, resets, and releases the reset; and The enumeration unit is used to respond to the detection of a connection event with a USB device, and after a waiting period, initiate the first enumeration to re-establish the USB communication connection with the USB device.

[0071] In this context, a master processor in a computing device is defined as a USB host, and one or more slave processors in the computing device are defined as USB devices.

[0072] Optionally, the first processing device is also used for: The USB host is reset, which includes resetting the USB controller and physical layer interface of the USB host. After the USB host releases and resets, it initiates a second enumeration of the USB device. In response to the failure of the second enumeration, a reset signal is sent to the USB device via an auxiliary channel that is not a USB channel.

[0073] Optionally, the first processing device is also used for: In response to the failure of the first enumeration, the USB host performs a reset; The third enumeration is initiated on the USB device after the USB host releases and resets.

[0074] Among them, communication anomalies refer to the monitoring of enumeration failure events or signal integrity anomalies.

[0075] Optionally, the first processing device is also used for: In response to normal communication between the USB host and at least one USB device, a reset signal is sent to the USB device experiencing communication failure via an auxiliary channel other than the USB channel.

[0076] The auxiliary channel is at least one of GPIO, UART, SPI, and I2C.

[0077] The USB communication exception handling device of this disclosure can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0078] The USB communication error handling device provided in this disclosure embodiment can execute the processing flow provided in the USB communication error handling method embodiment. The USB communication error handling device (hereinafter referred to as the second processing device) is applied to a USB device. The second processing device includes a signal receiving unit and an execution unit, wherein: The signal receiving unit is used to receive a reset signal sent by the USB host. The reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to an abnormal communication between the USB host and the USB device. The execution unit performs a reset and releases the reset after a first duration; and receives a first enumeration initiated by the USB host, and re-establishes a USB communication connection with the USB host in response to the first enumeration, wherein the first enumeration is initiated by the USB host after the USB device releases the reset and enters a waiting time, in response to detecting a connection event with the USB device, and after the waiting time.

[0079] Optionally, the execution unit is used for: Perform a reset, resetting the USB controller and physical layer interface of the USB device; Release the reset after the first duration and wait for the second duration.

[0080] Optionally, the second processing unit is also used for: Receive the second enumeration sent by the USB host, and respond to the second enumeration to establish a USB communication connection with the USB host; If the second enumeration succeeds, the USB communication exception handling process ends; or, if the second enumeration fails, wait for the USB host to send a receive reset signal.

[0081] The USB communication exception handling device of this disclosure can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0082] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this disclosure. See below for details. Figure 10 The diagram illustrates a structural schematic suitable for implementing the computing device 1000 in the embodiments of this disclosure. The computing device 1000 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as handheld 3D scanners, fixed 3D scanners, intraoral scanners, facial scanners, implant navigation systems, mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (e.g., vehicle navigation terminals), wearable electronic devices, etc., as well as fixed terminals such as digital TVs, desktop computers, smart home devices, etc. Figure 10 The computing device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0083] like Figure 10 As shown, the computing device 1000 may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1008 into a random access memory (RAM) 1003 to implement a USB communication exception handling method as described in the embodiments of this disclosure. Various programs and data required for the operation of the computing device 1000 are also stored in the RAM 1003. The processing unit 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0084] Typically, the following devices can be connected to the I / O interface 1005: input devices 1006 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1007 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1008 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows computing device 1000 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 10A computing device 1000 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0085] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the above-described method for handling USB communication exceptions. In such embodiments, the computer program can be downloaded and installed from a network via communication device 1009, or installed from storage device 1008, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of embodiments of this disclosure.

[0086] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0087] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0088] The aforementioned computer-readable medium may be included in the aforementioned computing device; or it may exist independently and not assembled into the computing device.

[0089] Optionally, when one or more of the above-described programs are executed by the computing device, the computing device may also execute other steps of the above embodiments.

[0090] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or gateway that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or gateway. Without further limitations, an element defined by the phrase "comprising the handling of a USB communication exception" does not exclude the presence of other identical elements in the process, method, article, or gateway that includes the element.

[0096] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for handling USB communication errors, applied to a USB host, comprising: In response to a communication failure between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel other than the USB channel. After the USB device receives the reset signal, resets, and releases the reset, the USB host enters a waiting period. as well as In response to the detection of a connection event with the USB device, a first enumeration is initiated with the USB device after the waiting time to re-establish the USB communication connection with the USB device.

2. The method according to claim 1, wherein, A master processor in the computing device is defined as the USB host, and one or more slave processors in the computing device are defined as the USB device.

3. The method according to claim 1, wherein, Before sending a reset signal to the USB device via an auxiliary channel other than the USB channel, the process also includes: The USB host is reset, wherein the reset includes resetting the USB controller and physical layer interface of the USB host; After the USB host releases and resets, a second enumeration is initiated for the USB device. In response to the failure of the second enumeration, a reset signal is sent to the USB device via an auxiliary channel other than the USB channel.

4. The method according to claim 1, further comprising: In response to the failure of the first enumeration, the USB host performs a reset; After the USB host releases and resets, a third enumeration is initiated on the USB device.

5. The method according to claim 1, wherein, The communication anomaly refers to the monitoring of enumeration failure events or signal integrity anomalies.

6. The method according to claim 1, wherein, The USB host is connected to multiple USB devices, and sending a reset signal to the USB devices through an auxiliary channel other than the USB channel includes: In response to normal communication between the USB host and at least one USB device, a reset signal is sent to the USB device experiencing communication failure via an auxiliary channel other than the USB channel.

7. The method according to any one of claims 1-6, wherein, The auxiliary channel is at least one of GPIO, UART, SPI, and I2C.

8. A method for handling USB communication errors, applied to a USB device, comprising: Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to a communication failure between the USB host and the USB device; Perform a reset and release the reset after a first duration; and The system receives a first enumeration initiated by the USB host and, in response to the first enumeration, re-establishes a USB communication connection with the USB host. The first enumeration is initiated by the USB host after the USB device releases and resets into a waiting period, in response to detecting a connection event with the USB device.

9. The method according to claim 8, wherein, The process of performing a reset and releasing the reset after a first duration includes: Perform a reset, resetting the USB controller and physical layer interface of the USB device; Release the reset after the first duration and wait for the second duration.

10. The method according to claim 8, wherein, Before receiving the reset signal sent by the USB host, the method further includes: Receive the second enumeration sent by the USB host, and establish a USB communication connection with the USB host in response to the second enumeration, wherein the second enumeration is initiated by the USB host after resetting and releasing the reset; If the second enumeration is successful, the USB communication exception handling process ends; or, if the second enumeration fails, the system waits for a reset signal sent by the USB host.

11. A method for handling USB communication errors, applied to a computing device including a USB host and a USB device, comprising: In response to a communication anomaly between the USB host and the USB device, the USB host sends a reset signal to the USB device through an auxiliary channel other than the USB channel. The USB device receives a reset signal sent by the USB host, performs a reset, and releases the reset after a first duration. The USB host enters a waiting period; In response to detecting a connection event with the USB device, the USB host initiates a first enumeration to the USB device after the waiting time; and The USB device receives the first enumeration and, in response to the first enumeration, re-establishes a USB communication connection with the USB host.

12. The method according to claim 10, wherein, One of the main processors in the computing device is defined as the USB host, and one or more slave processors in the computing device are defined as the USB device.

13. A computing device comprising a USB host and a USB device, wherein, The USB host is configured as follows: In response to a communication failure between the USB host and the USB device, a reset signal is sent to the USB device via an auxiliary channel other than the USB channel. The USB device is determined to receive the reset signal, perform a reset, release the reset, and enter a waiting period; as well as In response to the detection of a connection event with the USB device, after the waiting time, a first enumeration is initiated to the USB device to re-establish the USB communication connection with the USB device. The USB device is configured as follows: Receive a reset signal sent by the USB host, wherein the reset signal is sent by the USB host through an auxiliary channel other than the USB channel in response to a communication failure between the USB host and the USB device; Perform a reset and release the reset after a first duration; and The system receives a first enumeration initiated by the USB host and, in response to the first enumeration, re-establishes a USB communication connection with the USB host. The first enumeration is initiated by the USB host after the USB device releases and resets into a waiting period, in response to detecting a connection event with the USB device.

14. The computing device according to claim 13, wherein, One of the main processors in the computing device is defined as the USB host, and one or more slave processors in the computing device are defined as the USB device.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the USB communication exception handling method as described in any one of claims 1 to 12.

Images