Exception handling method and device of universal serial bus device and storage medium

Abstract

An exception processing method and device of a universal serial bus (USB) device and a storage medium are disclosed. The method comprises: obtaining data transmission exception information of a target USB device; determining a starting processing operation from among a first processing operation for removing a stop transmission state of an endpoint of an exception range indication, a second processing operation for resetting the endpoint of the exception range indication, and a third processing operation for resetting the target USB device based on the data transmission exception information; detecting whether data transmission of the target USB device is resumed after the starting processing operation is executed; when the data transmission is not resumed, sequentially executing processing operations located after the starting processing operation in a preset execution order of the first processing operation, the second processing operation, and the third processing operation, and detecting whether the data transmission is resumed; and generating an exception processing result of the target USB device. The present application has the technical effect of improving the reliability of exception processing of the USB device.

Description

Technical Field

[0001] This application relates to the field of abnormal handling technology for Universal Serial Bus (USB) devices, and in particular to an abnormal handling method, apparatus, and storage medium for USB devices. Background Technology

[0002] Universal Serial Bus (USB) devices are widely used in printers, cameras, storage devices, and other external devices that need to interact with electronic devices. USB devices can transmit data through one or more endpoints, with different endpoints handling data transmission tasks in different directions or of different types. Electronic devices typically control USB devices through device connection interfaces provided by the operating system and transmit data with the USB devices through corresponding endpoints. During data transmission, endpoints may fail to continue transmitting data due to transmission errors, timeouts, or abnormal states. In some existing error handling methods, when a data transmission anomaly occurs on a USB device, data transmission is usually restored by resetting the entire USB device. However, when the data transmission anomaly only occurs at some endpoints, resetting the entire USB device will simultaneously affect other endpoints or interfaces of the device and may require re-establishing device connections and communication configurations, thus affecting the continuity of data transmission. Therefore, how to appropriately handle USB device anomalies based on the actual circumstances of the data transmission anomaly is a crucial issue. Summary of the Invention

[0003] In view of this, this application provides a method, apparatus, and storage medium for handling exceptions in a Universal Serial Bus (USB) device, aiming to improve the efficiency of exception handling in USB devices and reduce the impact of exception handling on data transmission of normal endpoints and interfaces in the device. In a first aspect, a method for handling exceptions in a USB device is provided, comprising: acquiring data transmission exception information of a target USB device, the data transmission exception information including exception type, exception range, and device response status, wherein the exception range is used to characterize at least one endpoint or the target USB device where the exception occurred; determining a starting processing operation from a first processing operation, a second processing operation, and a third processing operation based on the data transmission exception information, wherein the first processing operation is used to release the stopped transmission state of the endpoint indicated by the exception range, the second processing operation is used to reset the endpoint indicated by the exception range, and the third processing operation is used to reset the target USB device; executing the starting processing operation, and detecting whether data transmission of the target USB device has resumed after execution; when data transmission has not resumed, sequentially executing processing operations following the starting processing operation according to a preset execution order of the first, second, and third processing operations, and detecting whether data transmission has resumed after each processing operation, until data transmission resumes or the third processing operation is completed; and generating an exception handling result for the target USB device.

[0004] The above-described exception handling methods for Universal Serial Bus (USB) devices can select the appropriate initial processing operation based on the exception type, exception scope, and device response status. For data transmission exceptions that can be recovered through endpoint processing, the number of times the entire target USB device needs to be reset can be reduced, minimizing the impact of exception handling on normal endpoints and interfaces. For data transmission exceptions that have not been recovered after endpoint processing, subsequent processing operations can continue to be executed according to a preset execution order, thus balancing the efficiency of handling local exceptions with the effectiveness of handling overall device exceptions. By checking the data transmission status after each processing operation, unnecessary subsequent processing can be terminated in a timely manner, improving the reliability of USB device exception handling and the continuity of data transmission.

[0005] Optionally, the data transmission anomaly information also includes: historical anomaly frequency, anomaly time interval, and endpoint transmission type; the historical anomaly frequency is used to characterize the number of times data transmission anomalies occur in a preset number of historical data transmissions, and the anomaly time interval is used to characterize the time interval between the current data transmission anomaly and the previous data transmission anomaly; based on the data transmission anomaly information, a starting processing operation is determined from the first processing operation, the second processing operation, and the third processing operation, including: determining the number of abnormal endpoints based on the anomaly range; determining the device response status based on whether a response to the status query request is received from the target universal serial bus device within a preset response time; and matching the anomaly type, the number of abnormal endpoints, the device response status, the historical anomaly frequency, the anomaly time interval, and the endpoint transmission type with preset anomaly handling rules to determine the starting processing operation.

[0006] Optionally, the preset exception handling rules include: when the device response status indicates that the target UPS device does not return a response within a preset response time, or the historical exception frequency reaches a preset frequency threshold, the third processing operation is determined as the starting processing operation; when the device response status indicates that the target UPS device returns a response within a preset response time, the historical exception frequency does not reach the preset frequency threshold, and the number of exception endpoints is at least two, the third processing operation is determined as the starting processing operation; when the device response status indicates that the target UPS device returns a response within a preset response time, the historical exception frequency does not reach the preset frequency threshold, and the number of exception endpoints is one, the first processing operation or the second processing operation is determined as the starting processing operation according to the exception type and the endpoint transmission type.

[0007] Optionally, the first, second, and third processing operations are each set with a corresponding preset execution duration. The first processing operation includes: clearing the endpoint stop status indicated by the exception range using an endpoint stop status clearing instruction provided by the Universal Serial Bus device file system; the second processing operation includes: resetting the endpoint indicated by the exception range using an endpoint reset instruction provided by the Universal Serial Bus device file system; the third processing operation includes: resetting the target Universal Serial Bus device using a device reset instruction provided by the Universal Serial Bus device file system; when the execution duration of any processing operation reaches the corresponding preset execution duration and the processing operation has not been completed, it is determined that data transmission has not been restored.

[0008] Optionally, the exception handling method is applied to the Android system, which includes an application layer, a Universal Serial Bus Hardware Abstraction Layer (USBHLS) service, and a kernel driver layer. The USBHLS service is configured with access permissions to USBH device nodes and includes a hardware abstraction layer wrapper. The hardware abstraction layer wrapper provides an exception handling interface to the application layer through the Android Interface Definition Language (API), and translates the calls to the exception handling interface into calls to the USBH operation interface provided by the kernel driver layer, so as to obtain data transmission exception information and perform a first processing operation, a second processing operation, or a third processing operation.

[0009] Optionally, it also includes: after the target UPS device completes enumeration, caching the device identification information and device configuration information of the target UPS device, wherein the device identification information includes the manufacturer identifier, product identifier, and device category, and the device configuration information includes device configuration parameters, interface configuration parameters, and endpoint configuration parameters; after performing the third processing operation, obtaining the current device address of the target UPS device after reset; when no corresponding device configuration information is found based on the current device address, matching the device configuration information cached by the target UPS device before reset based on the manufacturer identifier, product identifier, and device category of the target UPS device after reset; and restoring data transmission with the target UPS device based on the matched device configuration information.

[0010] Optionally, it also includes: after performing a bulk transfer through the bulk transfer endpoint of the target universal serial bus device, detecting the buffer state of the bulk transfer endpoint; when it is determined from the buffer state that there is residual data at the bulk transfer endpoint, generating data transmission exception information corresponding to the bulk transfer endpoint, and determining the first processing operation as the start processing operation to release the stop transmission state of the bulk transfer endpoint.

[0011] Optionally, detecting whether data transmission of the target UPS device has been restored includes: performing transmission function verification on the endpoint indicated by the anomaly range and performing device configuration integrity verification on the target UPS device; when the transmission function verification and device configuration integrity verification pass, determining that data transmission has been restored; the anomaly handling result includes the actual processing operation performed, the anomaly handling time, whether data transmission has been restored, and whether the device address of the target UPS device has changed, and feeding back the anomaly handling result to the system layer.

[0012] In a second aspect, an exception handling apparatus for a Universal Serial Bus (USB) device is provided, comprising: an acquisition unit, configured to acquire data transmission exception information of a target USB device, the data transmission exception information including exception type, exception range, and device response status, the exception range being used to characterize at least one endpoint or the target USB device where the exception occurred; a processing operation determination unit, configured to determine a starting processing operation from a first processing operation, a second processing operation, and a third processing operation based on the data transmission exception information, wherein the first processing operation is used to release the stop transmission state of the endpoint indicated by the exception range, the second processing operation is used to reset the endpoint indicated by the exception range, and the third processing operation is used to reset the target USB device; an execution unit, configured to execute the starting processing operation and, after execution, detect whether data transmission of the target USB device has been restored; when data transmission has not been restored, the processing operations following the starting processing operation are executed sequentially according to a preset execution order of the first processing operation, the second processing operation, and the third processing operation, and the data transmission is detected after each execution of a processing operation, until data transmission is restored or the third processing operation is completed; and a generation unit, configured to generate an exception handling result for the target USB device.

[0013] Thirdly, a computer-readable storage medium is provided having instructions stored thereon, which, when executed by a processor, implement the exception handling method for a universal serial bus device as provided in the first aspect. Attached Figure Description

[0014] The accompanying drawings used in the description of the embodiments of this disclosure are briefly introduced below: Figure 1 A flowchart illustrating an exception handling method for a universal serial bus device provided in some embodiments of this application is shown. Figure 2 A flowchart illustrating a method for determining the initial processing operation in some embodiments of this application is shown; Figure 3 A schematic diagram of the structure of an exception handling device for a universal serial bus device provided in some embodiments of this application is shown. Detailed Implementation

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the specific implementation methods of this application will be described below with reference to the accompanying drawings. The accompanying drawings described below are merely some embodiments of this application. For those skilled in the art, other drawings or embodiments can be obtained based on these drawings or embodiments without creative effort. Adjustments and improvements made without departing from the concept of this application are all within the protection scope of this application.

[0016] In this application, unless otherwise expressly specified and limited, ordinal numbers, such as "first," "second," etc., are used only to distinguish and describe related objects, and should not be construed as indicating or implying the relative importance or order between related objects; furthermore, they do not represent the quantity of related objects. "Multiple" includes two or more, and other quantifiers are similar.

[0017] Universal Serial Bus (USB) devices can connect to mobile phones, tablets, computers, or other electronic devices via a USB interface, and transmit data between the electronic device and the external device. Common USB devices include printers, cameras, storage devices, and barcode scanners. USB devices typically have one or more endpoints for data transmission, which can serve as logical channels for receiving or sending data. Different endpoints can have different transmission directions and types, and each can undertake different data transmission tasks.

[0018] During data transmission, interruptions may occur due to transmission errors, timeouts, endpoint status anomalies, or device response failures. The scope of impact may vary depending on the specific data transmission anomaly. Existing anomaly handling methods typically involve re-initiating transmission after a failure or performing a full reset of the Universal Serial Bus (USB) device. A full device reset affects multiple endpoints and interfaces simultaneously and may interrupt ongoing data transmissions at other endpoints. After the reset, the electronic device may also need to re-establish the connection and restore interface selection or parameter configuration. Therefore, when an anomaly occurs only at a single endpoint, directly resetting the entire device may amplify the impact of the anomaly and increase the recovery time.

[0019] Taking the Android system as an example, applications typically initiate data transmission through the system's Universal Serial Bus (USB) device connection interface. Existing application-layer interfaces have limited support for endpoint-level exception handling capabilities, and access to underlying device nodes and kernel operation interfaces may be subject to system permission controls. Therefore, when a partial exception occurs at an endpoint, applications cannot directly select the appropriate endpoint handling operation based on the state of the abnormal endpoint. In practice, a complete device reset is often used to restore data transmission.

[0020] Furthermore, existing anomaly handling processes lack a comprehensive assessment of the anomaly type, scope, and device response status. For localized anomalies, excessive use of overall device reset may affect normal endpoints and interfaces. For larger-scale device anomalies, performing only localized processing may fail to effectively restore data transmission. Therefore, existing technologies struggle to balance the efficiency of handling localized anomalies with the effectiveness of handling overall device anomalies.

[0021] In view of this, this application provides a method, apparatus and storage medium for handling exceptions in a Universal Serial Bus (USB) device, in order to improve the efficiency of exception handling in the USB device and reduce the impact of exception handling on the data transmission of normal endpoints and interfaces in the device.

[0022] The following description is in conjunction with the accompanying drawings: Please refer to Figure 1 This document illustrates a flowchart of an exception handling method for a universal serial bus device provided in some embodiments of this application. The method includes at least the following steps: S110: Obtain data transmission anomaly information of the target Universal Serial Bus device. The data transmission anomaly information includes anomaly type, anomaly range, and device response status. The anomaly range is used to characterize at least one endpoint or the target Universal Serial Bus device where the anomaly occurred. S120: Based on the data transmission exception information, determine the starting processing operation from the first processing operation, the second processing operation and the third processing operation, wherein the first processing operation is used to release the stop transmission state of the endpoint indicated by the exception range, the second processing operation is used to reset the endpoint indicated by the exception range, and the third processing operation is used to reset the target universal serial bus device. S130: Perform the initial processing operation and, after completion, check whether the data transmission of the target universal serial bus device has resumed; S140: When data transmission is not restored, the processing operations following the initial processing operation are executed sequentially according to the preset execution order of the first processing operation, the second processing operation, and the third processing operation. After each processing operation is executed, it is checked whether data transmission has been restored, until data transmission is restored or the third processing operation is completed. S150: Generate the exception handling result for the target Universal Serial Bus device.

[0023] The above implementation can monitor the execution of data transmission during the data transmission process of the target UPS device and obtain corresponding data transmission exception information when the data transmission is not completed as expected. The data transmission exception information can be determined based on the return result of the data transmission operation, the execution status, and the current status of the target UPS device. For example, a data transmission exception can be determined to have occurred when the data transmission operation returns an error, fails to complete within the expected time, or the target UPS device does not respond normally.

[0024] An exception type characterizes the manifestation of a data transmission failure, such as a transmission request execution error, data transmission timeout, endpoint failure to transmit, or device communication anomaly. An exception scope characterizes the objects involved in the data transmission failure. When an exception occurs at one or more endpoints of the target UPS device, the exception scope can determine the endpoint identifier, transmission direction, or other information that distinguishes the endpoint. When the exception cannot be limited to a specific endpoint, or when the exception affects the entire target UPS device, the exception scope can indicate the entire target UPS device. This distinguishes between localized exceptions occurring at endpoints and exceptions occurring throughout the entire device.

[0025] Device response status characterizes whether the target UPS device is still able to respond to requests from electronic devices. For example, a status query request can be sent to the target UPS device, and the device response status can be determined based on whether a corresponding response is received. Further, based on the returned response, it can be determined that the device as a whole is still communicable, and the anomaly may be concentrated on some endpoints. When no response is returned, it indicates that the anomaly may have affected the entire device. The anomaly type, anomaly scope, and device response status together describe the data transmission anomaly, providing a basis for selecting subsequent processing operations.

[0026] In step S120 above, a correspondence between data transmission error information and processing operations can be established in advance, and the processing operation to be executed first can be determined based on the data transmission error information obtained this time. The starting processing operation indicates the processing operation executed first in this error handling process, and does not mean that it needs to start from the first processing operation every time an error occurs.

[0027] The first processing operation addresses the stopped transmission state of an endpoint, acting solely on the endpoint. This operation can remove the corresponding endpoint from the stopped transmission state without altering the overall operating state of the target UPS device. The second processing operation resets the endpoints indicated by the exception range, restoring their transmission state to one capable of resuming data transmission. The third processing operation acts on the entire UPS device, resetting the target UPS device when endpoint processing fails to meet exception recovery requirements or when the exception affects the entire device.

[0028] When determining the initial handling operation, the appropriate operation can be selected based on whether the exception can be identified as originating from a specific endpoint, whether the target UPS device can still return a response, and the endpoint status reflected by the exception type. When the exception is concentrated at an endpoint and the device as a whole can still respond, the handling operation applied to the endpoint can be prioritized to reduce the impact of exception handling on other endpoints and interfaces. When the exception involves the entire target UPS device, or when the data transmission exception information indicates that endpoint handling is not applicable to this exception, the handling operation applied to the entire device can be determined as the initial handling operation. Therefore, it is not necessary to use the same handling method for all data transmission exceptions, nor is it necessary to try all handling operations sequentially when it is clearly inapplicable.

[0029] After executing the defined initial processing operations, the data transmission status of the target UPS device can be checked to determine whether the current processing operation has eliminated the data transmission anomaly. The detection method can correspond to the type of data transmission that caused the anomaly. For example, a data transmission request of the same type as before the anomaly can be re-initiated, and whether the data transmission has resumed can be determined based on whether the data transmission request completes normally. Alternatively, the status of the corresponding endpoint or the target UPS device can be queried, and the status query results can be used to determine whether data transmission can continue.

[0030] If the detection result indicates that data transmission has been restored, the current exception handling process can be stopped to avoid unnecessary impact on the target universal serial bus device from continuing to perform other processing operations. If the detection result indicates that data transmission has not yet been restored, the subsequent processing steps will proceed.

[0031] The first, second, and third processing operations described above are executed in a preset order according to their impact on the overall device. This ensures that, based on the position of the initial processing operation, only those operations following the initial operation and still necessary to execute are performed. For example, when the first processing operation is determined to be the initial operation, if data transmission has not yet recovered after executing the first operation, the second processing operation is executed; if data transmission has not yet recovered after executing the second operation, the third processing operation is executed. When the second processing operation is determined to be the initial operation, there is no need to execute the first processing operation preceding it; if data transmission has not yet recovered after executing the second operation, the third processing operation is executed.

[0032] After each processing operation, the system can re-check whether data transmission of the target UPS device has been restored. If any processing operation restores data transmission, subsequent processing operations are stopped. Furthermore, after the third processing operation is completed, the current preset processing flow ends regardless of whether data transmission has been restored. This avoids resetting the entire device if endpoint processing has already restored data transmission, and also avoids continuing with overall device processing if endpoint processing fails to restore data transmission, thus forming an abnormal handling process from local endpoint processing to overall device processing.

[0033] Finally, an anomaly handling result can be generated based on the execution status of each processing operation and the detection results of data transmission status during this anomaly handling process. This result informs the system whether the data transmission has been restored and is used for subsequent device status display, fault alarm, or maintenance.

[0034] The above-described exception handling methods for Universal Serial Bus (USB) devices can select the appropriate initial processing operation based on the exception type, exception scope, and device response status. For data transmission exceptions that can be recovered through endpoint processing, the number of times the entire target USB device needs to be reset can be reduced, minimizing the impact of exception handling on normal endpoints and interfaces. For data transmission exceptions that have not been recovered after endpoint processing, subsequent processing operations can continue to be executed according to a preset execution order, thus balancing the efficiency of handling local exceptions with the effectiveness of handling overall device exceptions. By checking the data transmission status after each processing operation, unnecessary subsequent processing can be terminated in a timely manner, improving the reliability of USB device exception handling and the continuity of data transmission.

[0035] In some embodiments of this application, the data transmission anomaly information further includes: historical anomaly frequency, anomaly time interval, and endpoint transmission type; the historical anomaly frequency is used to characterize the number of times data transmission anomalies occur in a preset number of historical data transmissions, and the anomaly time interval is used to characterize the time interval between the current data transmission anomaly and the previous data transmission anomaly. Figure 2 A flowchart illustrating a method for determining the initial processing operation in some embodiments of this application is shown. The method includes: S210: Determine the number of abnormal endpoints based on the abnormal range; S220: Determine the device response status based on whether a response to the status query request is received from the target Universal Serial Bus device within a preset response time. S230: Match the anomaly type, number of anomaly endpoints, device response status, historical anomaly frequency, anomaly time interval, and endpoint transmission type with preset anomaly handling rules to determine the initial processing operation.

[0036] The historical anomaly frequency, anomaly time interval, and endpoint transmission type mentioned above can be used to supplement the description of the current data transmission anomaly in terms of its duration, occurrence pattern, and transmission scenario. The historical anomaly frequency can be determined based on the anomaly records of the target universal serial bus device in a preset number of historical data transmissions. For example, the number of anomalies in the last ten data transmissions can be counted. A higher historical anomaly frequency indicates that the current anomaly may not be an isolated incident, but may be related to a persistent anomaly in the endpoint status, device status, or communication link. The anomaly time interval can be determined based on the occurrence time of the current data transmission anomaly and the occurrence time of the previous data transmission anomaly to distinguish between continuous, intermittent, or sporadic data transmission anomalies. The endpoint transmission type characterizes the data transmission method used by the endpoint experiencing the anomaly, such as batch transmission or interrupted transmission. Different transmission types may differ in data organization, transmission timing, and anomaly manifestation. Therefore, combining the endpoint transmission type to determine the initial processing operation can avoid making processing decisions based solely on a single anomaly type. The number of abnormal endpoints can be determined based on the endpoint information carried in the anomaly range, thereby reflecting the scope of the anomaly's impact and determining whether the current anomaly is still suitable for endpoint-level processing.

[0037] The device's response status can be determined by sending a status query request to the target UPS device. If a response is received from the target UPS device within a preset response time, the target UPS device is considered to be in a responsive state. If no response is received within the preset response time, the target UPS device is considered to be in a non-responsive state. The preset response time can be adjusted according to the device type, communication rate, or actual response requirements.

[0038] Pre-defined anomaly handling rules can establish a correspondence between different combinations of anomaly characteristics and the first, second, and third processing operations. After obtaining the anomaly type, number of anomaly endpoints, device response status, historical anomaly frequency, anomaly time interval, and endpoint transmission type corresponding to the current data transmission anomaly, this information can be combined. One or more indicators can be selected as anomaly characteristics to match with the pre-defined anomaly handling rules, and the processing operation corresponding to the matching result is determined as the initial processing operation. For example, for data transmission anomalies affecting only a single endpoint, where the target UPS device can still respond normally, and with a low historical anomaly frequency, endpoint-level processing operations can be prioritized. For data transmission anomalies involving multiple endpoints, where the target UPS device is unresponsive, or with a high historical anomaly frequency, device-level processing operations can be matched. Specific matching conditions can be pre-configured based on the type of target UPS device, anomaly handling requirements, and actual operating conditions.

[0039] By comprehensively utilizing current and historical anomaly characteristics to determine the initial processing operation, the bias in selecting the processing method caused by relying solely on a single error message can be reduced. This ensures that the selected initial processing operation is more in line with the actual situation of the current data transmission anomaly and reduces invalid attempts at inapplicable processing operations.

[0040] In some embodiments of this application, the preset exception handling rules include: when the device response status indicates that the target UPS device does not return a response within a preset response time, or the historical exception frequency reaches a preset frequency threshold, the third processing operation is determined as the starting processing operation; when the device response status indicates that the target UPS device returns a response within a preset response time, the historical exception frequency does not reach the preset frequency threshold, and the number of exception endpoints is at least two, the third processing operation is determined as the starting processing operation; when the device response status indicates that the target UPS device returns a response within a preset response time, the historical exception frequency does not reach the preset frequency threshold, and the number of exception endpoints is one, the first processing operation or the second processing operation is determined as the starting processing operation according to the exception type and the endpoint transmission type.

[0041] Preset anomaly handling rules can be configured with matching priorities based on the overall device status, anomaly frequency, and anomaly impact scope. Device unresponsiveness and historical anomaly frequencies reaching preset thresholds will have higher matching priorities. If any one of these conditions is met, the third processing operation will be directly designated as the starting processing operation, without executing the first or second processing operation.

[0042] If the target UPS device fails to respond within the preset response time, it indicates that the electronic device can no longer confirm the current status of the device or endpoint through a status query request, and the current data transmission anomaly may no longer be limited to a specific endpoint. In this case, continuing to process a single endpoint may not restore data transmission; therefore, the target UPS device can be directly reset. If the historical anomaly frequency reaches a preset frequency threshold, it indicates that the target UPS device has repeatedly experienced anomalies during recent data transmissions. Even if the current anomaly manifests as a single endpoint anomaly, there may be persistent device status anomalies. By designating the third processing operation as the starting processing operation, the likelihood of anomalies recurring shortly after endpoint processing can be reduced. The preset frequency threshold can be set based on a preset number of historical data transmissions. For example, when analyzing the last ten data transmissions, reaching three anomalies can be used as a condition to trigger device-level processing.

[0043] If the target Unicode Passive Serial Bus (Unicode) device can return a normal response and the historical anomaly frequency has not reached the preset frequency threshold, the scope of the anomaly's impact can be further determined based on the number of anomaly endpoints. When at least two endpoints experience anomalies simultaneously, it indicates that the anomaly involves multiple data transmission channels within the device. Performing endpoint-level processing on multiple endpoints separately may increase the anomaly handling process and make it difficult to guarantee that the overall device state has been restored. Therefore, the third processing operation can be directly determined as the initial processing operation.

[0044] When the target UPS device can return a normal response, the historical anomaly frequency does not reach the preset frequency threshold, and only one endpoint experiences an anomaly, it can be assumed that the anomaly is mainly concentrated on that endpoint. In this case, a choice can be made between a first processing operation and a second processing operation based on the anomaly type and the endpoint transmission type. For example, if the anomaly type indicates that the target endpoint is in a stopped transmission state, and the endpoint is suitable for resuming data transmission by releasing the stopped transmission state, the first processing operation can be determined as the initial processing operation. If the anomaly type indicates that the target endpoint has an anomaly that cannot be recovered simply by releasing the stopped transmission state, or if the preset anomaly handling rules stipulate that the endpoint transmission type corresponds to endpoint reset processing, the second processing operation can be determined as the initial processing operation. The specific processing operations corresponding to the anomaly type and the endpoint transmission type can be pre-configured according to the operating characteristics of the target UPS device.

[0045] In some embodiments of this application, the first processing operation, the second processing operation, and the third processing operation are each set with a corresponding preset execution duration; the first processing operation includes: clearing the endpoint stop state indicated by the exception range by using an endpoint stop state clearing instruction provided by the Universal Serial Bus device file system; the second processing operation includes: resetting the endpoint indicated by the exception range by using an endpoint reset instruction provided by the Universal Serial Bus device file system; the third processing operation includes: resetting the target Universal Serial Bus device by using a device reset instruction provided by the Universal Serial Bus device file system; when the execution duration of any processing operation reaches the corresponding preset execution duration and the processing operation has not been completed, it is determined that data transmission has not been restored.

[0046] The Universal Serial Bus (USB) device file system can be used to provide the kernel driver layer with an interface for data transmission and status control of USB devices. The first, second, and third processing operations correspond to different processing objects and scopes, and are executed through their respective instructions.

[0047] The first processing operation can remove the target endpoint's stopped transmission state using the endpoint stop state clear command. Before executing this command, it can be confirmed that the endpoint indicated by the exception range is in a stopped transmission state. After execution, the data transmission status of that endpoint can be checked. Since the first processing operation only applies to the target endpoint, it is possible to attempt to resume data transmission at that endpoint without resetting the entire target UPS device.

[0048] The second processing operation can reset the endpoint indicated by the exception range using the endpoint reset command. If data transmission has not resumed after the endpoint has stopped transmitting, or if the second processing operation is directly determined as the starting processing operation based on the exception type and endpoint transmission type, the transmission state of the target endpoint can be restored using this command, and the endpoint can be re-checked to see if it can perform data transmission normally after the reset is completed.

[0049] The third processing operation can reset the entire target UPS device using a device reset command. This third processing operation applies to multiple endpoints and interfaces of the target UPS device, and therefore can be executed when endpoint-level processing fails to restore data transmission, or when the exception involves multiple endpoints and the entire device is unresponsive.

[0050] The preset execution duration for each processing operation can be set according to the execution scope and expected response time of the processing operation. For example, the timer can start when the processing instruction is initiated and stop when the processing completion result is received. For instance, the preset execution durations for the first, second, and third processing operations can be set to 500 milliseconds, 1000 milliseconds, and 5000 milliseconds, respectively. The above values ​​are only one optional setting and can also be adjusted according to the type of the target universal serial bus device, the communication rate, and the system response requirements.

[0051] In some implementations, the exception handling method is applied to an Android system, which includes an application layer, a Universal Serial Bus Hardware Abstraction Layer (USBHLS) service, and a kernel driver layer. The USBHLS service is configured with access permissions to USBH device nodes and includes a hardware abstraction layer wrapper. The hardware abstraction layer wrapper provides an exception handling interface to the application layer through the Android Interface Definition Language (API), and translates calls to the exception handling interface into calls to the USBH operation interface provided by the kernel driver layer, in order to obtain data transmission exception information and perform a first processing operation, a second processing operation, or a third processing operation.

[0052] In the above embodiments, the Android system may include an application layer, a Universal Serial Bus (USB) Hardware Abstraction Layer (HAL) service, and a kernel driver layer. The application layer can call the USB HAL service through interfaces defined by the Android Interface Definition Language (Android Interface Definition Language). The USB HAL service can run in an independent process and is configured with permissions to access USB device nodes to perform exception handling on the target USB device through the USB operation interface provided by the kernel driver layer. A hardware abstraction layer wrapper can be set in the USB HAL service to encapsulate the USB operation interface provided by the kernel driver layer into an Android Interface Definition Language interface that can be called by the application layer. These interfaces may include an endpoint stop state clearing interface, an endpoint reset interface, an endpoint status query interface, a hierarchical exception handling interface, and an exception handling result retrieval interface. The hardware abstraction layer wrapper can monitor the execution status of Universal Serial Bus (USB) data transmission operations. When a data transmission anomaly is detected, it obtains the bus number, device address, abnormal endpoint number, and anomaly type of the target USB device, and determines the corresponding processing operation based on the obtained data transmission anomaly information. For example, when performing the first processing operation, it calls the endpoint stop status clearing interface; when performing the second processing operation, it calls the endpoint reset interface; and when performing the third processing operation, it calls the device reset interface.

[0053] By encapsulating the kernel operation interface in the Universal Serial Bus Hardware Abstraction Layer service with the corresponding device access permissions, endpoint-level and device-level exception handling capabilities can be provided to the application layer, and the impact of system permission restrictions on the application layer's direct access to Universal Serial Bus device nodes can be reduced.

[0054] In some embodiments of this application, the method further includes: after the target UPS device completes enumeration, caching the device identification information and device configuration information of the target UPS device, wherein the device identification information includes a manufacturer identifier, a product identifier, and a device category, and the device configuration information includes device configuration parameters, interface configuration parameters, and endpoint configuration parameters; after performing the third processing operation, obtaining the current device address of the reset target UPS device; when no corresponding device configuration information is found based on the current device address, matching the device configuration information cached before the reset of the target UPS device based on the manufacturer identifier, product identifier, and device category of the reset target UPS device; and restoring data transmission with the target UPS device based on the matched device configuration information.

[0055] The device identification information above is used to establish a correspondence before and after the target UPS device is reset, and the device configuration information is used to restore the communication configuration of the target UPS device before the reset. After the target UPS device completes enumeration, the cache management module can read and cache the above information. For example, device configuration parameters may include configuration values ​​and device power consumption parameters, interface configuration parameters may include interface type, and endpoint configuration parameters may include endpoint address, endpoint transmission attributes, and maximum data packet length. The cached information can be stored in association with the target UPS device's current bus number and device address so that the corresponding device configuration information can be directly queried when the device address has not changed.

[0056] The third processing operation may cause the target UPS device to re-establish its connection with the Android system. The reset target UPS device may continue to use its original device address or may be assigned a new device address. Therefore, after executing the third processing operation, the current device address after the reset can be obtained first, and the previously cached device configuration information can be queried based on this current device address. When the corresponding device configuration information can be found based on the current device address, it can be read directly. When the corresponding device configuration information cannot be found based on the current device address, it can be assumed that the device address of the target UPS device has changed before and after the reset. In this case, the device address is no longer used as the sole basis for querying; instead, the manufacturer identifier, product identifier, and device category of the reset device are obtained, and these three are matched with the corresponding information of the cached device.

[0057] When the manufacturer identifier, product identifier, and device category match the target UPS device before the reset, it can be determined that the reset device corresponds to the device configuration information cached before the reset. This allows for the reading of the corresponding device configuration parameters, interface configuration parameters, and endpoint configuration parameters. Furthermore, based on the read device configuration information, the configuration state of the target UPS device and its interface and endpoint communication parameters can be restored, and data transmission can continue. For example, if the target UPS device is a camera, and the device address changes after the third processing operation, the manufacturer identifier, product identifier, and device category can be used to match the device configuration information cached before the reset, and the corresponding video transmission configuration can be restored. This reduces the possibility that a change in device address will render the original cached information unusable and shortens the communication recovery process after the target UPS device is reset.

[0058] In some embodiments of this application, the method further includes: after performing a bulk transfer through the bulk transfer endpoint of the target universal serial bus device, detecting the buffer state of the bulk transfer endpoint; when it is determined from the buffer state that there is residual data at the bulk transfer endpoint, generating data transmission exception information corresponding to the bulk transfer endpoint, and determining the first processing operation as the start processing operation to release the stopped transmission state of the bulk transfer endpoint.

[0059] Taking a printing device as an example, the batch transfer endpoint can be used to receive printing data. After each batch transfer, the endpoint that performed the batch transfer can be checked to determine whether there is any unprocessed data to be printed or unsent print command fragments in the endpoint's buffer. When residual data is detected at the batch transfer endpoint, it can be identified as an abnormal endpoint, and corresponding data transmission error information is generated, with the error range indicating the batch transfer endpoint. Since the error is initially manifested as the data transmission of a single batch transfer endpoint not completing normally, the first processing operation can be determined as the starting processing operation, and the stop transmission state of the batch transfer endpoint can be released by the endpoint stop state clearing command. After the first processing operation is completed, the data transmission of the batch transfer endpoint can be checked in the aforementioned manner to see if it has resumed; if the data transmission has not resumed, the second or third processing operation is executed according to the preset execution order.

[0060] In some embodiments of this application, step S130, which detects whether data transmission of the target UPS device has been restored, further includes: performing a transmission function verification on the endpoint indicated by the anomaly range and performing a device configuration integrity verification on the target UPS device; when the transmission function verification and the device configuration integrity verification are both passed, it is determined that data transmission has been restored; the anomaly handling result includes the actual processing operation performed, the anomaly handling time, whether data transmission has been restored, and whether the device address of the target UPS device has changed, and the anomaly handling result is fed back to the system layer.

[0061] Taking an Android 13 terminal connecting to a Universal Serial Bus (USB) printer as an example, the printer's batch output endpoint address is 0x01. The USB Hardware Abstraction Layer (HAL) service runs in an independent process with access permissions to USB device nodes. It provides the application layer with interfaces such as `clearEndpointHalt(int fd, int ep)` (removes the stop transmission status of the endpoint indicated by the exception range), `resetEndpoint(int fd, int ep)` (resets the endpoint indicated by the exception range), `getEndpointStatus(int fd, int ep)` (gets the current transmission status of the endpoint), `graduatedRelease(int fd, int ep, byte[] info)` (determines the initial processing operation based on data transmission exception information and implements hierarchical exception handling according to a preset execution order), and `getReleaseReport(int fd)` (gets the exception handling result of the target USB device). The HAL wrapper implements these interfaces and translates the interface calls into calls to the USB operation interfaces provided by the kernel driver layer.

[0062] After the initial printer enumeration is complete, the cache management module caches the printer's manufacturer identifier, product identifier, and device category, as well as device configuration information including device configuration parameters, interface configuration parameters, and endpoint configuration parameters. The cached information can be stored in association with the printer's current bus number and device address.

[0063] During the print job execution, the hardware abstraction layer wrapper detects that USBDEVFS_BULK (performing data transfer via a bulk transfer endpoint) returns an input / output error code EIO, and obtains the printer's bus number 1, device address 5, and the abnormal endpoint 0x01. After the bulk transfer is completed, the buffer status of this endpoint is also checked; if residual data is detected in the buffer, data transfer exception information corresponding to this bulk transfer endpoint is generated.

[0064] The anomaly classification decision engine generates a six-dimensional anomaly feature vector based on the obtained information. The anomaly type is input / output error; the number of anomaly endpoints is one; a status query is initiated via GET_STATUS (querying the response status of the target Unicode Concurrent Serial Bus device), and a response from the printer is confirmed within 50 milliseconds; the number of anomalies in the last ten data transmissions is zero; the anomaly time interval is calculated based on the occurrence times of the current and previous anomalies; and the endpoint transmission type is batch transmission. This anomaly feature vector matches the anomaly handling rules for input / output errors, single endpoints, responsive devices, historical anomaly frequency below a preset frequency threshold, unlimited anomaly time intervals, and batch transmission endpoints. Therefore, the first processing operation is determined as the initial processing operation.

[0065] The hardware abstraction layer wrapper first calls ioctl(fd,USBDEVFS_CLEAR_HALT,&ep), where USBDEVFS_CLEAR_HALT is used to clear the stop transmission state of the endpoint indicated by the exception range, i.e., to perform the first processing operation. After confirming that the stop transmission state of endpoint 0x01 has been cleared, 64 bytes of test data are sent via USBDEVFS_BULK to check whether data transmission has resumed.

[0066] If the first processing operation times out, or if the test data still returns an input / output error after the first processing operation is completed, then ioctl(fd,USBDEVFS_RESETEP,&ep) is called. USBDEVFS_RESETEP is used to reset the endpoint indicated by the exception range, i.e., to execute the second processing operation. After the endpoint is reset, the 512-byte transmission buffer is reinitialized, and the test data is sent again.

[0067] If the second processing operation times out, or if data transmission is not restored after the second processing operation is completed, ioctl(fd,USBDEVFS_RESET,0) is called. USBDEVFS_RESET is used to reset the target Universal Serial Bus device, i.e., the third processing operation is executed. If the third processing operation fails to complete within the preset execution time, it is determined that the exception handling failed to restore data transmission.

[0068] After the printer is reset, its current device address is obtained. If the corresponding device configuration information can be found based on the current device address, the device configuration information is read directly; if the corresponding device configuration information cannot be found based on the current device address, the device configuration information cached before the reset is matched with the printer's manufacturer identifier, product identifier, and device category after the reset, and the data transmission between the printer and the printer is restored based on the matched device configuration parameters, interface configuration parameters, and endpoint configuration parameters.

[0069] After data transmission is restored, an exception handling result is generated, which includes the exception type, the initial processing operation, the actual processing operation, the execution time of each processing operation, the data transmission restoration status, and the device address change information. The Universal Serial Bus Hardware Abstraction Layer service can feed back the exception handling result to the application layer through getReleaseReport(int fd).

[0070] The application and implementation of the exception handling methods described above are not limited to the Android system, but can also be applied to operating systems including, but not limited to, Windows, Linux, macOS, Unix-like operating systems, embedded operating systems, and real-time operating systems. In different operating systems, applications, system services, middleware, or device driver management modules can obtain data transmission exception information of the target UPS device, and perform processing operations such as releasing the endpoint from the stopped transmission state, resetting the endpoint, and resetting the target UPS device through the UPS driver interface, device control interface, or other equivalent operation interfaces provided by the corresponding operating system. The aforementioned Android interface definition language, UPS hardware abstraction layer service, and UPS device file system instructions are only one implementation method under the Android system; when applied to other operating systems, interfaces or instructions with the same or similar functions in the corresponding operating system can be used instead, without changing the exception handling logic of determining the initial processing operation based on data transmission exception information and continuing to execute subsequent processing operations according to a preset execution order when data transmission has not been restored.

[0071] Figure 3A schematic diagram of the structure of an exception handling device for a universal serial bus device provided in some embodiments of this application is shown. The exception handling device 300 for the Universal Serial Bus (USB) device includes: an acquisition unit 310, used to acquire data transmission exception information of the target USB device, the data transmission exception information including exception type, exception range and device response status, the exception range being used to characterize at least one endpoint or the target USB device where the exception occurred; a processing operation determination unit 320, used to determine a starting processing operation from a first processing operation, a second processing operation and a third processing operation based on the data transmission exception information, wherein the first processing operation is used to release the stop transmission state of the endpoint indicated by the exception range, the second processing operation is used to reset the endpoint indicated by the exception range, and the third processing operation is used to reset the target USB device; an execution unit 330, used to execute the starting processing operation and, after execution, detect whether the data transmission of the target USB device has been restored; when the data transmission has not been restored, the processing operations following the starting processing operation are executed sequentially according to a preset execution order of the first processing operation, the second processing operation and the third processing operation, and the data transmission is detected after each execution of the processing operation until the data transmission is restored or the third processing operation is completed; and a generation unit 340, used to generate the exception handling result of the target USB device.

[0072] Based on the same technical concept, this application also provides a computer-readable storage medium storing instructions thereon, which, when executed by a processor, implement the exception handling method for a universal serial bus device as provided in the above embodiments.

Claims

1. A method for handling exceptions in a universal serial bus device, characterized in that, include: Obtain data transmission anomaly information of the target Universal Serial Bus device. The data transmission anomaly information includes anomaly type, anomaly range, and device response status. The anomaly range is used to characterize at least one endpoint or the target Universal Serial Bus device where the anomaly occurred. Based on the data transmission anomaly information, a starting processing operation is determined from the first processing operation, the second processing operation, and the third processing operation, wherein the first processing operation is used to release the stop transmission state of the endpoint indicated by the anomaly range, the second processing operation is used to reset the endpoint indicated by the anomaly range, and the third processing operation is used to reset the target universal serial bus device. Perform the initial processing operation, and after the execution is completed, check whether the data transmission of the target universal serial bus device has been restored; When the data transmission is not restored, the processing operations following the initial processing operation are executed sequentially according to the preset execution order of the first processing operation, the second processing operation, and the third processing operation. After each processing operation is executed, it is checked whether the data transmission has been restored, until the data transmission is restored or the third processing operation is completed. Generate the exception handling result for the target Universal Serial Bus device.

2. The fault handling method for a universal serial bus device according to claim 1, characterized in that, The data transmission anomaly information also includes: historical anomaly frequency, anomaly time interval, and endpoint transmission type; The historical anomaly frequency is used to characterize the number of times a data transmission anomaly occurs in a preset number of historical data transmissions, and the anomaly time interval is used to characterize the time interval between the current data transmission anomaly and the previous data transmission anomaly. Based on the data transmission anomaly information, a starting processing operation is determined from the first processing operation, the second processing operation, and the third processing operation, including: The number of abnormal endpoints is determined based on the aforementioned abnormal range; The device response status is determined based on whether a response to the status query request is received from the target Universal Serial Bus device within a preset response time. The initial processing operation is determined by matching the anomaly type, the number of anomaly endpoints, the device response status, the historical anomaly frequency, the anomaly time interval, and the endpoint transmission type with preset anomaly handling rules.

3. The fault handling method for a universal serial bus device according to claim 2, characterized in that, The preset exception handling rules include: When the device response status indicates that the target universal serial bus device has not returned a response within the preset response time, or when the historical abnormal frequency reaches the preset frequency threshold, the third processing operation is determined as the starting processing operation. When the device response status indicates that the target universal serial bus device returns a response within the preset response time, the historical abnormal frequency does not reach the preset frequency threshold, and the number of abnormal endpoints is at least two, the third processing operation is determined as the starting processing operation. When the device response status indicates that the target universal serial bus device returns a response within the preset response time, the historical anomaly frequency does not reach the preset frequency threshold, and the number of anomaly endpoints is one, the first processing operation or the second processing operation is determined as the starting processing operation according to the anomaly type and the endpoint transmission type.

4. The fault handling method for a universal serial bus device according to any one of claims 1 to 3, characterized in that, The first processing operation, the second processing operation, and the third processing operation are each set with a corresponding preset execution duration; The first processing operation includes: clearing the stop transmission state of the endpoint indicated by the abnormal range using an endpoint stop state clearing instruction provided by the Universal Serial Bus device file system; The second processing operation includes: resetting the endpoint indicated by the exception range using an endpoint reset instruction provided by the Universal Serial Bus device file system; The third processing operation includes: resetting the target Universal Serial Bus device using a device reset command provided by the Universal Serial Bus device file system; When the execution time of any processing operation reaches the corresponding preset execution time and the processing operation has not been completed, it is determined that the data transmission has not been restored.

5. The method for handling exceptions in a universal serial bus device according to any one of claims 1 to 3, characterized in that, The exception handling method is applied to the Android system, which includes an application layer, a Universal Serial Bus Hardware Abstraction Layer service, and a kernel driver layer. The Universal Serial Bus Hardware Abstraction Layer (HAL) service is configured with access permissions to Universal Serial Bus device nodes and includes a HAL wrapper. The hardware abstraction layer wrapper provides an exception handling interface to the application layer through the Android interface definition language, and converts the call to the exception handling interface into a call to the general serial bus operation interface provided by the kernel driver layer, so as to obtain the data transmission exception information and execute the first processing operation, the second processing operation, or the third processing operation.

6. The fault handling method for a universal serial bus device according to claim 5, characterized in that, Also includes: After the target Universal Serial Bus (USB) device completes enumeration, the device identification information and device configuration information of the target USB device are cached. The device identification information includes the manufacturer identifier, product identifier, and device category. The device configuration information includes device configuration parameters, interface configuration parameters, and endpoint configuration parameters. After performing the third processing operation, obtain the current device address of the target universal serial bus device after reset; When no corresponding device configuration information is found based on the current device address, the device configuration information cached before the target Unicode device is matched based on the manufacturer identifier, product identifier, and device category of the target Unicode device after reset. Based on the matched device configuration information, data transmission with the target Universal Serial Bus device is restored.

7. The fault handling method for a universal serial bus device according to claim 5, characterized in that, Also includes: After performing a bulk transfer through the bulk transfer endpoint of the target Universal Serial Bus device, the buffer state of the bulk transfer endpoint is detected; When it is determined from the buffer state that there is residual data at the batch transmission endpoint, data transmission exception information corresponding to the batch transmission endpoint is generated, and the first processing operation is determined as the starting processing operation to release the stop transmission state of the batch transmission endpoint.

8. The method for handling exceptions in a universal serial bus device according to any one of claims 1 to 3, characterized in that, The detection of whether data transmission of the target Universal Serial Bus device has been restored includes: Perform transmission function verification on the endpoints indicated by the anomaly range, and perform device configuration integrity verification on the target Universal Serial Bus device; When the transmission function verification passes and the device configuration integrity verification passes, the data transmission is determined to be restored. The exception handling result includes the actual processing operation performed, the exception handling time, whether the data transmission was restored, and whether the device address of the target universal serial bus device changed, and the exception handling result is fed back to the system layer.

9. An exception handling device for a universal serial bus device, characterized in that, include: The acquisition unit is used to acquire data transmission anomaly information of the target Universal Serial Bus device. The data transmission anomaly information includes anomaly type, anomaly range, and device response status. The anomaly range is used to characterize at least one endpoint or the target Universal Serial Bus device where the anomaly occurred. A processing operation determination unit is configured to determine a starting processing operation from a first processing operation, a second processing operation, and a third processing operation based on the data transmission anomaly information. The first processing operation is configured to release the stop transmission state of the endpoint indicated by the anomaly range, the second processing operation is configured to reset the endpoint indicated by the anomaly range, and the third processing operation is configured to reset the target universal serial bus device. An execution unit is configured to execute the initial processing operation and, after execution, detect whether the data transmission of the target universal serial bus device has been restored. When the data transmission has not been restored, the unit executes the processing operations following the initial processing operation in a preset execution order of the first processing operation, the second processing operation, and the third processing operation, and detects whether the data transmission has been restored after each processing operation, until the data transmission is restored or the third processing operation is completed. The generation unit is used to generate the exception handling result of the target universal serial bus device.

10. A computer-readable storage medium, characterized in that, It stores instructions that, when executed by a processor, implement the exception handling method for a universal serial bus device as described in any one of claims 1 to 8.

Images