Pourquoi Windows affiche-t-il la notification "Ce périphérique peut fonctionner plus rapidement" si je le connecte maladroitement ?

Le message fait référence à la négociation de l'ancien débit de données à pleine vitesse (FS) de 12 Mbit/s, au lieu du débit de données à haute vitesse (HS) qui est de 480 Mbit/s. Il doit être vraiment difficile d'obtenir cet effet à partir d'un port USB2. Le protocole HS de l'USB2.0 est établi après une négociation assez compliquée entre un dispositif et l'hôte, parce qu'initialement chaque dispositif HS agit comme un dispositif FS.

Le processus normal est le suivant :

1. Le dispositif compatible HS tire vers le haut la ligne D+ après avoir reçu le signal VBUS avec une résistance de 1-1.5k à 3.3V. Tout comme le ferait un dispositif FS.

2. Le port hôte détecte que D+=high, et après un délai de désamorçage de 100ms minimum, l'hôte affirme l'état USB_RESET sur le bus, conduisant les lignes D+ et D- à la masse avec 45 drivers pendant 10 ou 50ms.

3. Si le dispositif est FS, il ne fait rien et attend la fin de USB_RESET.

4. Si le dispositif est HS, il conduirait D- haut en utilisant le driver HS (source 18mA) pendant environ 1ms. Cela créera une impulsion d'une amplitude d'environ 800mV (18ma dans une charge de 45) appelée "Chirp-K" ;

5. A la détection de la fin de Chirp-K, si l'hôte est capable de fonctionner en mode HS, il renvoie ce signal (même 18mA dans sa propre charge de 45), maintenant pendant environ 50µs. Si c'est un hôte FS, il ignore le Chirp-K, et procède comme FS.

6. Ensuite, si l'hôte est capable de fonctionner en mode HS, il commute son entraînement sur le fil D+, formant ainsi "Chirp-J", à nouveau pendant 50µs ;

7. L'hôte répète ce motif alternatif de 50µs pendant toute la durée de l'état USB_RESET (10ms sur les ports hub, 50ms sur les ports hub racines) ;

8. Après trois chirp-K/J alternés, le dispositif reconnaît que l'hôte est HS, et passe lui-même en mode HS. Cela implique d'activer la terminaison HS à l'extrémité du dispositif, ce qui porte la résistance totale du fil à 22, et l'amplitude du signal chirp chute à 400mV, à un niveau de signalisation HS standard.

9. L'hôte procède à l'envoi de paquets de début de trame (SOF) HS, et lance le processus d'énumération en mode HS.

Maintenant, tout le monde peut deviner quelle partie de l'agitation a brisé ce protocole, et a fait que l'hôte a marqué le port comme FS.

Lorsque vous branchez un périphérique sur un port USB2, l'ordinateur tente d'abord de négocier une connexion en utilisant le protocole de données USB2.
En cas d'échec, il réessaie en utilisant le protocole de données USB1.

Mon hypothèse la plus probable est que la connexion physique (due à l'agitation des contacts) n'est pas encore stable pendant la négociation USB2. Il revient donc à USB1, même si le périphérique est un périphérique USB2.

Il est assez amusant de constater que Windows se rend compte que le périphérique devrait être capable de fonctionner à la vitesse de l'USB2 (information qu'il obtient du pilote) et il en conclut que le port USB sur lequel vous l'avez branché était un port USB1 lent. Windows ne semble pas vérifier si le port lui-même est compatible USB2.
C'est pourquoi vous obtenez ce message d'erreur quelque peu trompeur.

P.S. Je viens de l'essayer moi-même avec une machine Windows 10 : Même effet ici.

Il se peut que vous l'ayez inséré assez lentement pour que Windows ait déjà terminé le processus de poignée de main avec le contrôleur et qu'à ce moment-là, les contacts nécessaires à la communication USB 2.0 ne se touchaient pas. Cela pourrait conduire Windows à confondre un périphérique USB 2.0 avec un périphérique 1.1 car il n'y aurait pas de réponse sur les rails marqués comme étant uniquement présents sur USB 2.0 et plus.