USB HUB enumeration method

Abstract

The invention provides a USB HUB enumeration method. The method comprises the following steps: step 1, establishing a multi-state control state machine comprising an initial delay state, an active detection state and a ready enumeration state in a USB HUB main controller; step 2, in response to a system wake-up event, configuring and starting an initial delay; step 3, entering the active detection state after the initial delay is ended, sending a detection request to a host and starting a first timer to monitor response of the host; 4, performing dynamic delay adjustment based on a monitoring result: if an effective host response is received before timeout of the first timer, entering the ready enumeration state; and if an effective host response is not received before the first timer is overtime, updating a delay parameter according to a preset retry strategy and returning to the step 3 for retry until a cycle termination condition is met, and executing an exception handling flow to recover enumeration. According to the invention, the unification of high compatibility and high wake-up efficiency is realized.

Description

Technical Field

[0001] This invention relates to the field of USB technology, and more particularly to a USB hub enumeration method. Background Technology

[0002] USB hubs often experience enumeration failures when computing devices wake up from sleep mode. The root cause is that the initialization speed of the hub hardware during the wake-up process is usually faster than the readiness speed of the host USB controller and its software stack, resulting in a timing race. The current mainstream solution is to use a fixed delay mechanism, which forces the hub to wait for a fixed time window after waking up before attempting enumeration communication with the host. However, this solution has significant drawbacks: setting the delay too long unnecessarily increases the overall system wake-up time, affecting user experience; setting it too short fails to accommodate slower-wake-up hosts, and the enumeration failure rate remains. Because the readiness speeds of different host devices and system environments vary greatly, a fixed delay value is difficult to balance between compatibility and wake-up efficiency, resulting in poor universality and becoming a long-standing technical pain point in this field. Summary of the Invention

[0003] This invention provides a USB HUB enumeration method, which aims to overcome the shortcomings of the prior art and achieve a balance between high compatibility and high wake-up efficiency.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows: This invention provides a USB hub enumeration method, comprising: Step 1: Establish a multi-state control state machine in the USB HUB host controller, including initial delay state, active probe state and ready enumeration state; Step 2: In response to the system wake-up event, configure and start the initial delay; Step 3: After the initial delay ends, enter the active detection state, send a detection request to the host and start the first timer to monitor the host response; Step 4: Dynamically adjust the delay based on the monitoring results: If a valid host response is received before the first timer expires, enter the ready enumeration state; if no valid host response is received before the first timer expires, update the delay parameters according to the preset retry policy and return to step 3 for retry until the loop termination condition is met, then execute the exception handling process to restore enumeration.

[0005] Specifically, configuring the initial delay in step 2 includes: Determine the current operating mode of the system; If it is in normal mode, the typical delay value or default delay value corresponding to the current host is loaded as the initial delay; If it is in recovery mode, the initial delay value of recovery mode is queried or calculated based on the number of historical recovery attempts and used as the initial delay.

[0006] Specifically, the initial delay value T_init_recovery(m) of the recovery mode is dynamically determined according to the number of historical recovery times m, and satisfies: T_init_recovery(m) = min( T_typical × (1.5 + k1 × ln(1+m)), T_typical × 3 ), where T_typical is the typical delay value and k1 is a preset growth coefficient.

[0007] Specifically, in step 4, if a valid host response is received, the learning steps are then performed: Record the total waiting time Tn for this successful enumeration; Only when the number of consecutive successful enumerations reaches a preset threshold, the typical latency value T_typical associated with the current host is updated based on the total waiting time Tn using a moving average algorithm. The update formula is: T_typical[new]=T_typical[old]×α+Tn×(1-α), where α is the smoothing coefficient.

[0008] Specifically, before updating the typical delay value, a verification step is also included: calculating the deviation between Tn and the current T_typical; if the deviation exceeds a preset percentage, Tn is regarded as an outlier and discarded, and is not used for updating.

[0009] Specifically, in step 4, the retry strategy is a phased strategy: In the first N retries, a linear increment strategy is adopted: new total latency = current total latency + ΔT, where ΔT is selected as the normal mode increment ΔT_normal or the recovery mode increment ΔT_recovery according to the current operating mode; In the Nth and subsequent retries, an exponential backoff strategy is adopted: new total delay = current total delay × β, where β is a backoff coefficient greater than 1; The calculated total delay does not exceed the preset maximum timeout threshold Tmax.

[0010] Specifically, when the system is in recovery mode, the recovery mode increment ΔT_recovery(m) and the maximum number of retries N_retry_recovery(m) are both dynamically determined based on the historical recovery count m, where: ΔT_recovery(m)=min(ΔT_normal×2^(m-1), ΔT_normal×8), N_retry_recovery(m)=max(N_normal-(m-1),1), Where N_normal is the maximum number of retries in normal mode.

[0011] Specifically, the exception handling process includes: Step 501: Perform a hardware reset on the USB HUB host controller; Step 502: Control the uplink port data line of the USB HUB to perform simulated physical disconnection and reconnection operations; Step 503: Mark the system running mode as recovery mode, update the historical recovery count, determine the recovery mode parameters based on the updated recovery count, and then return to step 2.

[0012] Furthermore, the method also includes: Step 6: When a change is detected in the currently connected host, clear the learning data associated with the previous host and rebuild the learning model for the current host.

[0013] Specifically, step 1 further includes the step of initializing non-volatile memory, wherein the non-volatile memory is logically divided into: a) A dynamic learning parameter area, used to store the typical latency values ​​and host feature fingerprints associated with different hosts; b) System status area, used to store the operating mode flag and the historical recovery count counter m.

[0014] The beneficial effects of this invention are as follows: By constructing an intelligent enumeration method that incorporates state awareness, active detection, and adaptive delay adjustment, this invention achieves a balance between high compatibility and high wake-up efficiency. This method establishes a state machine at the HUB end. After wake-up, instead of passively waiting, it actively sends a probe request to the host and dynamically determines the host's readiness state based on whether a timely response is received. Based on this determination, the system can intelligently perform only necessary, gradual additional waiting after a conservative initial delay until the host confirms readiness, thus avoiding the time waste of fixed-delay schemes. Simultaneously, the method introduces a machine learning mechanism, which can memorize and learn the readiness characteristics of different hosts, forming optimized delay parameters, making the speed of repeated wake-ups continuously approach the optimal level. Furthermore, a complete anomaly recovery logic ensures that the system can self-reset and simulate physical reconnection in extreme anomaly situations, fundamentally guaranteeing connection reliability. Therefore, this invention ultimately achieves a significant reduction in the average system wake-up time while maintaining a near 100% enumeration success rate, completely solving the technical challenge of traditional solutions in balancing compatibility, efficiency, and reliability. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the USB HUB enumeration method of the present invention. Detailed Implementation

[0016] The embodiments of the present invention are described in detail below with reference to the accompanying drawings. The drawings are for reference and illustration only and do not constitute a limitation on the scope of protection of the present invention.

[0017] In the process described in the specification, claims, or drawings of this invention, each step is numbered (e.g., step 10, 20, etc.). These numbers are used only to distinguish the steps and do not represent any execution order. It should be noted that the terms "first," "second," etc., used herein are only for distinguishing the objects being described and do not represent a chronological order, nor do they indicate that "first," "second," etc., are different types.

[0018] like Figure 1 As shown, this embodiment presents a USB hub enumeration method designed to address the enumeration failure issue caused by timing competition between the USB hub and the host controller when the system wakes from sleep mode. This method implements an intelligent adaptive state machine in the firmware of the USB hub controller to dynamically detect the host's ready state and adjust the waiting delay, thereby ensuring compatibility with host devices of varying performance. Specifically, it includes the following steps: 1. System initialization and state machine establishment.

[0019] First, a multi-state control state machine is established in the USB HUB's main controller firmware. This state machine includes at least the following states: Idle (IDLE), Initial Delay (INIT_DELAY), Active Probe (ACTIVE_PROBE), Ready Enumeration (READY), and Fault Recovery (FAULT_RECOVERY). The state transition rules are defined as follows: after the system wakes up, it enters the Initial Delay state from the Idle state; after the Initial Delay state expires according to a preset timer, it unconditionally transitions to the Active Probe state; after receiving a valid response from the host, the Active Probe state transitions to the Ready Enumeration state. If no valid response is received within a predetermined time, it decides whether to return to the Initial Delay state or enter the Fault Recovery state according to a preset retry strategy.

[0020] Secondly, initialize the system's static configuration parameters. These parameters serve as the baseline for algorithm operation and include: the default latency baseline value T0 (e.g., a value between 50 and 100 milliseconds), the latency increment ΔT_normal in normal mode (e.g., 50 milliseconds), the maximum number of retries N_normal in normal mode (e.g., 8 times), and the global maximum timeout threshold Tmax (e.g., 2000 milliseconds). In actual deployment, a high-precision timer needs to be configured according to the main controller's clock frequency, and the above time parameters should be adjusted with, for example, 1 millisecond as the minimum timing unit.

[0021] This step also includes the following sub-steps: Initializing non-volatile memory for persistent storage, such as EEPROM or Flash memory. Logically, this storage space is divided into two areas: a) a dynamic learning parameter area, used to store learning results related to a specific host device. Its data structure includes fields such as device fingerprint hash value, typical latency value T_typical obtained through the learning algorithm, last update timestamp, and successful enumeration count statistics; b) a system status area, used to store status variables during system operation, including a recovery count counter m, a success count counter for the learning algorithm, and a system operation mode flag indicating whether the current mode is "normal mode" or "recovery mode". To extend memory lifetime, a wear leveling algorithm is enabled to manage write operations.

[0022] 2. Wake-up event detection and delay value configuration.

[0023] When the system needs to wake up from hibernation, perform the following steps: Step 201: Detect the wake-up event. This is specifically achieved by monitoring the recovery of the VBUS power supply voltage on the USB uplink port or the bus activity on the D+ / D- data lines. One implementation involves configuring a power management chip to monitor the VBUS voltage; when it rises from 0V to the standard operating voltage (e.g., 5V ± 0.25V), a wake-up event is triggered. Simultaneously, a differential amplifier can be configured to monitor changes in the data line level. To eliminate noise interference, a debouncing mechanism can be employed; for example, continuously monitoring for 10 milliseconds to confirm signal stability before finally determining it as a valid system wake-up event.

[0024] Step 202: Determine and configure the operating mode. The system reads the "system operating mode flag" stored in non-volatile memory. If the flag indicates that the current mode is "recovery mode", the system further reads the current value of the recovery count counter m, which is also stored there. Based on this value of m, the "recovery mode initial delay value" T_init_recovery(m) is calculated (or obtained from a pre-calculated lookup table) using a predefined strategy or formula. This value is set as the "current delay value" for this wake-up cycle, and the system proceeds directly to step 204 to start the delay. If the flag indicates "normal mode", the system continues to the next step.

[0025] Step 203: Configure the initial latency in normal mode. The system attempts to read historical learning records from the dynamic learning parameter area of ​​the memory that match the "device fingerprint" of the currently connected host. The device fingerprint can be generated by collecting information such as the vendor ID (idVendor), product ID (idProduct), and device version number (bcdDevice) from the host device descriptor and performing a hash operation. If a match is successful and the data passes the validity check (such as CRC check), the "typical latency value" T_typical stored in the record is loaded as the "current latency value". If no valid matching record is found (e.g., the first connection to the host), the default latency baseline value T0 in the static configuration parameters is loaded as the "current latency value". In this case, the system can be marked as being in "learning mode".

[0026] Step 204: Start Delay and Wait. Using the "Current Delay Value" determined in Step 202 or Step 203, configure and start the internal high-precision timer. During this delay period, the physical layer (PHY) of the USB HUB should be set to a high-impedance state, remaining silent and not responding to any enumeration requests that the host may initiate, thereby ensuring that the host controller has sufficient preparation time.

[0027] 3. Actively detect the host status.

[0028] After the initial delay ends, the state machine enters the active probing phase, which aims to actively confirm whether the host controller is ready.

[0029] Step 301: Send a probe request. The state machine switches to the ACTIVE_PROBE state. The USB HUB sends a standard USB Hub-class request command, such as a "Get_Port_Status" request, to the host via its control transfer endpoint 0. This request is harmless and is a necessary response for HUB-class devices, making it suitable for probing. Simultaneously, a "transmission timeout" timer (e.g., set to 20 milliseconds) is started for this control transfer, and monitoring logic for the Start of Frame (SOF) packet is enabled.

[0030] Step 302: Monitor Link Response. Simultaneously with sending the probe request, start a shorter-period "response timeout" timer (e.g., set to 15 milliseconds). This timer monitors the uplink data link for any signs of valid activity from the host, such as ACK (acknowledgment), NAK (negative acknowledgment), or STALL (stagnation) handshake packets. This process operates in parallel with the "transmission timeout" step 301, but aims to detect host activity more quickly.

[0031] Step 303: Parse Host Feedback. The system continuously monitors SOF packets on the USB bus. For full-speed devices, SOF packets appear every 1 millisecond; for high-speed devices, every 125 microseconds. Detecting a predetermined number (e.g., 3) of valid SOF packets consecutively serves as strong evidence that the host is active. Simultaneously, the system is also prepared to receive and parse the host's complete data response packet to the Get_Port_Status request. Any valid handshake packet, consecutive SOF packets, or complete data response received within the "response timeout" period is considered a "valid host response."

[0032] 4. Dynamic delay adjustment and learning.

[0033] This step is the core of the adaptive mechanism, dynamically adjusting behavior and accumulating experience based on the detection results.

[0034] Step 401: Process Successful Response. If a valid host response is received within the "response timeout" period, it indicates that the probe was successful and the host is ready. First, calculate the total waiting time Tn for this successful connection. This value is the sum of the "current delay value" configured in this wake-up cycle (from step 202 or 203) and the "probe phase time". The probe phase time is calculated as follows: starting from the moment the first Get_Port_Status request packet is sent, and ending at the moment the first valid host response (such as ACK, a specified number of SOFs, or a complete data packet) is received. This Tn value is used as the raw data and stored in the dynamic learning parameter area of ​​the memory along with the timestamp and host feature fingerprint. Subsequently, the system exits the delay waiting state, configures the USBPHY to normal mode, and prepares to enter the standard USB enumeration process. Simultaneously, this is a successful connection event, so the system sets the operating mode flag to "normal mode" and persistently stores the recovery count counter m after clearing it, indicating recovery from the abnormal state.

[0035] The processing of successful responses also includes a learning process: the system maintains a "success count counter," and only after a preset number of consecutive successes (e.g., 3) is the "typical delay value" T_typical updated. The update uses a moving average algorithm, with the formula: T_typical[new] = T_typical[old] × α + Tn × (1 - α), where α is the smoothing coefficient (0 < α < 1, e.g., 0.8), and Tn is the total waiting time for the latest success. Before updating, a rationality check can be added; for example, if the current Tn deviates from the historical T_typical by more than 50%, it can be considered an outlier and discarded.

[0036] Step 402: Handling Timeouts and Dynamic Increment. If a probe times out (i.e., no valid response is received within the "response timeout" period), the total waiting time is updated using a phased strategy based on the number of retries already performed, and preparations are made for the next probe. The specific strategy is as follows: a) Linear Increment Phase: When the current number of retries N is less than a preset threshold (e.g., 5 times), execute "New Total Latency = Current Total Latency + Incremental Parameter". The "Incremental Parameter" depends on the system operating mode: ΔT_recovery(m) in recovery mode and ΔT_normal in normal mode.

[0037] b) Exponential backoff phase: When the current number of retries N reaches or exceeds the above threshold, the exponential backoff algorithm is activated, i.e., "new total delay = current total delay × backoff coefficient" (for example, the backoff coefficient is 1.5).

[0038] c) Regardless of the strategy used, the calculated total latency value must not exceed the global maximum timeout threshold Tmax. Here, "current total latency" is a dynamic variable, initialized to the initial latency value configured for this wake-up cycle, and updated to a new calculated value after each execution of this step.

[0039] Step 403: Determine if the loop terminates. After each failed probe, it is necessary to determine whether the current probe loop should be terminated. The determination criteria are: whether the current number of retries has reached the maximum allowed number of retries in the current mode (N_retry_recovery(m) in recovery mode, N_normal in normal mode), or whether the accumulated total time (calculated from wake-up) has exceeded Tmax. If either condition is met, proceed to the exception handling step (step 5), and clear the "success count counter" before proceeding to interrupt any possible continuous success counting. If the termination condition is not met, use the "new total delay" calculated in step 402 as the "current total delay" for the next wait, and return to step 3 to start a new round of active probing.

[0040] 5. Anomaly handling and recovery mechanism.

[0041] When the probe loop terminates due to multiple failures, the system enters an exception handling process and attempts to force recovery.

[0042] Step 501: Perform a hardware reset and save the current state. First, trigger the hardware reset sequence of the main controller (e.g., via a watchdog timer) to ensure the HUB itself is in a deterministic state. Before resetting, save the fault information of this cycle (such as the number of retries, the results of each probe, and the timestamp) to a specific area of ​​non-volatile memory for subsequent analysis.

[0043] Step 502: Simulate Physical Reconnection. After reset, the system controls the simulated switch connected to the uplink port to perform a simulated physical disconnection and reconnection operation on the D+ and D- data lines. A specific timing sequence is: first disconnect the USB data line connection for at least 100 milliseconds, then sequentially disconnect the D+ line, then disconnect the D- line, maintaining the disconnected state for approximately 150 milliseconds, and finally reconnect. This operation aims to electrically simulate the process of a user unplugging and plugging in a USB device, forcing the host to restart the complete enumeration process.

[0044] Step 503: Enter and configure recovery mode. After completing the simulated reconnection, the system sets the "System Run Mode Flag" to "Recovery Mode". The current recovery count counter m is read from memory, incremented by 1 (i.e., m = m + 1), and then written back to memory for persistence. Subsequently, the specific parameters for recovery mode are calculated based on the new m value: a) Initial delay value for recovery mode: T_init_recovery(m) = min( T_typical × (1.5 +k1 × ln(1+m)), T_typical × 3 ), where k1 is an adjustable growth coefficient (e.g., 0.3).

[0045] b) Recovery mode delay increment: ΔT_recovery(m) = min( ΔT_normal × 2^(m-1), ΔT_normal × 8 ).

[0046] c) Maximum number of retries in recovery mode: N_retry_recovery(m) = max( N_normal - (m-1),1 ).

[0047] To reduce real-time computational overhead, all parameters can be pre-calculated during the compilation phase based on the formulas, and a lookup table can be generated. At runtime, the parameters are retrieved by looking up the value of m in the table. After parameter configuration, the method returns to step 2 to start a new round of attempts in recovery mode.

[0048] 6. Host change detection.

[0049] As an optimization, this method also includes host change detection logic (step 6). When the system detects that the feature fingerprint of the currently connected host does not match the stored learning records, it can be determined that the host device has changed. At this time, specific learning data related to the old host (such as typical latency values) should be cleared from the dynamic learning parameter area, but static configuration parameters and system state parameters should be retained to rebuild the learning model for the new host. Subsequently, the process returns to step 1 or step 2 to start the adaptive interaction process with the new host in the initial state.

[0050] Through the above implementation methods, this invention can intelligently adapt to hosts with different response speeds, significantly shortening system wake-up time while ensuring enumeration success rate. Experimental tests show that compared with traditional fixed-latency schemes, this method can reduce the average wake-up time by more than 30%, and the optimization effect can reach 50% to 70% in typical scenarios, effectively solving the technical problem of difficulty in balancing compatibility and efficiency.

[0051] The above-disclosed embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A USB HUB enumeration method, characterized in that, include: Step 1: Establish a multi-state control state machine in the USB HUB host controller, including initial delay state, active probe state and ready enumeration state; Step 2: In response to the system wake-up event, configure and start the initial delay; Step 3: After the initial delay ends, enter the active detection state, send a detection request to the host and start the first timer to monitor the host response; Step 4: Dynamically adjust the delay based on the monitoring results: If a valid host response is received before the first timer expires, enter the ready enumeration state; if no valid host response is received before the first timer expires, update the delay parameters according to the preset retry policy and return to step 3 for retry until the loop termination condition is met, then execute the exception handling process to restore enumeration.

2. The method according to claim 1, characterized in that, Configuring the initial delay in step 2 includes: Determine the current operating mode of the system; If it is in normal mode, the typical delay value or default delay value corresponding to the current host is loaded as the initial delay; If it is in recovery mode, the initial delay value of recovery mode is queried or calculated based on the number of historical recovery attempts and used as the initial delay.

3. The method according to claim 2, characterized in that, The initial delay value T_init_recovery(m) of the recovery mode is dynamically determined according to the number of historical recovery times m, and satisfies: T_init_recovery(m) = min( T_typical × (1.5 + k1 × ln(1+m)), T_typical × 3 ), where T_typical is the typical delay value and k1 is a preset growth coefficient.

4. The method according to claim 1, characterized in that, In step 4, if a valid host response is received, the learning steps are then executed further: Record the total waiting time Tn for this successful enumeration; Only when the number of consecutive successful enumerations reaches a preset threshold, the typical latency value T_typical associated with the current host is updated based on the total waiting time Tn using a moving average algorithm. The update formula is: T_typical[new]=T_typical[old]×α+Tn×(1-α), where α is a smoothing coefficient, and the smoothing coefficient α satisfies 0<α<1.

5. The method according to claim 4, characterized in that, Before updating the typical delay value, a verification step is also included: calculating the deviation between Tn and the current T_typical; if the deviation exceeds a preset percentage, Tn is regarded as an outlier and discarded, and is not used for updating.

6. The method according to claim 1, characterized in that, In step 4, the retry strategy is a phased strategy: In the first N retries, a linear increment strategy is adopted: new total latency = current total latency + ΔT, where ΔT is selected as the normal mode increment ΔT_normal or the recovery mode increment ΔT_recovery according to the current operating mode; In the Nth and subsequent retries, an exponential backoff strategy is adopted: new total delay = current total delay × β, where β is a backoff coefficient greater than 1; The calculated total delay does not exceed the preset maximum timeout threshold Tmax.

7. The method according to claim 6, characterized in that, When the system is in recovery mode, the recovery mode increment ΔT_recovery(m) and the maximum number of retries N_retry_recovery(m) are both dynamically determined based on the historical recovery count m, where: ΔT_recovery(m)=min(ΔT_normal×2^(m-1),ΔT_normal×8), N_retry_recovery(m)=max(N_normal-(m-1),1), Where N_normal is the maximum number of retries in normal mode.

8. The method according to claim 1, characterized in that, The exception handling process includes: Step 501: Perform a hardware reset on the USB HUB host controller; Step 502: Control the uplink port data line of the USB HUB to perform simulated physical disconnection and reconnection operations; Step 503: Mark the system running mode as recovery mode, update the historical recovery count, determine the recovery mode parameters based on the updated recovery count, and then return to step 2.

9. The method according to claim 1, characterized in that, The method further includes: Step 6: When a change is detected in the currently connected host, clear the learning data associated with the previous host and rebuild the learning model for the current host.

10. The method according to claim 1, characterized in that, Step 1 further includes the step of initializing non-volatile memory, wherein the non-volatile memory is logically divided into: a) A dynamic learning parameter area, used to store the typical latency values ​​and host feature fingerprints associated with different hosts; b) System status area, used to store the operating mode flag and the historical recovery count counter m.

Images