Partager via

Réinitialisation et récupération radio Bluetooth

La réinitialisation et la récupération de la radio Bluetooth sont une technologie dans Windows 10, version 1803 et ultérieure, qui introduit un mécanisme de réinitialisation et de récupération robuste pour les radios Bluetooth. Ce mécanisme permet aux radios Bluetooth de récupérer des défaillances matérielles qui entraînent un dysfonctionnement, une perte de connectivité ou une non-réponse aux commandes opérationnelles. L’objectif est de récupérer automatiquement la radio, ce qui rend l’expérience utilisateur transparente et réduit la probabilité d’exiger un redémarrage du système.

La réinitialisation et la récupération radio Bluetooth peuvent être implémentées avec ou sans dépendances de microprogramme. Les partenaires matériels peuvent étendre les mécanismes de réinitialisation basés sur le logiciel disponibles sur tous les PC Windows avec des mécanismes de réinitialisation au niveau de l’appareil ou du microprogramme pris en charge pour augmenter la probabilité d’une récupération réussie.

Important

Cette rubrique est destinée aux développeurs. Si vous êtes un client qui rencontre des problèmes bluetooth, consultez Résoudre les problèmes Bluetooth dans Windows 10.

Scénarios de réinitialisation et de récupération Bluetooth

Il existe trois grandes catégories de problèmes où la réinitialisation et la récupération sont lancées :

  • Échecs d’énumération de bus : la radio échoue en énumération ou réécriture par le bus sous-jacent (généralement USB ou UART), comme indiqué par un état d’échec visible (bang jaune) dans Gestionnaire de périphériques, ce qui peut être symptomatique des erreurs matérielles sous-jacentes.

  • Échecs de l’énumération du pilote : la radio Bluetooth est dans un état d’échec après l’énumération réussie par le bus sous-jacent. Cet état d’échec se produit généralement lors de la génération de la pile des pilotes pour la radio. Par exemple, lorsqu’un filtre ou un pilote de fonction est installé sur le nœud de périphérique radio Bluetooth. Des défaillances peuvent se produire si un pilote rencontre une erreur pendant une ou plusieurs opérations de démarrage et, par conséquent, signale une défaillance PnP. Un exemple de telle opération peut être un téléchargement de microprogramme sur l’appareil.

  • Échecs de non-énumération : l’appareil n’est pas dans un état d’échec, mais n’est pas opérationnel comme déterminé par la pile des pilotes. Ces défaillances sont en dehors du chemin d’énumération et peuvent être des défaillances spécifiques au transport critiques ou des défaillances spécifiques à l’appareil, telles qu’une erreur de microprogramme catastrophique. Les mécanismes de réinitialisation et de récupération Bluetooth suivants sont utilisés dans ces cas.

Mécanismes de réinitialisation et de récupération

Bien qu’il existe différentes approches de récupération à partir d’un état défaillant, Bluetooth utilise un mécanisme de récupération basé sur ACPI standardisé pour tenter de restaurer la radio à un état de travail.

GUID_DEVICE_RESET_INTERFACE_STANDARD définit deux niveaux de réinitialisation. Les mécanismes de réinitialisation fonctionnent uniquement pour les appareils internes, de sorte que les radios Bluetooth enfichables externes telles que les dongles ne sont pas prises en charge. Les mécanismes de réinitialisation nécessitent la prise en charge à la fois dans Windows (généralement par la pile des pilotes de fonction) et le microprogramme sous-jacent (généralement dans le BIOS ACPI) pour effectuer la réinitialisation. Le mécanisme de réinitialisation réel est spécifique au système.

Niveau de réinitialisation Implémentation
Réinitialisation de l’appareil au niveau de la fonction (FLDR) L’opération de réinitialisation est limitée à un appareil spécifique et n’est pas visible pour d’autres appareils. Il n’y a pas de réécriture. Les pilotes de fonction doivent supposer que le matériel est retourné à son état d’origine après l’opération. L’état intermédiaire n’est pas conservé.
Réinitialisation de l’appareil au niveau de la plateforme (PLDR) L’opération de réinitialisation affecte un appareil spécifique et tous les autres appareils connectés via le même rail d’alimentation ou la même ligne de réinitialisation. L’opération de réinitialisation entraîne le signalement de l’appareil comme manquant dans le bus et réinscrit. Ce type de réinitialisation a le plus d’impact sur le système, car tous les appareils qui partagent la ressource reviennent à leur état d’origine.

  • Pour prendre en charge FLDR , il doit y avoir une méthode __RST définie à l’intérieur de l’étendue de l’appareil, comme détaillé dans le microprogramme ACPI : Réinitialisation au niveau de la fonction.

  • Pour prendre en charge plDR , il doit y avoir une méthode __RST or__PR3 définie sous l’étendue de l’appareil, comme détaillé dans le microprogramme ACPI : Réinitialisation au niveau de la plateforme. Si une méthode PR3 est utilisée, ACPI utilise le mécanisme de cycle d’alimentation D3Cold pour réinitialiser. Le mécanisme de cycle d’alimentation D3Cold émule la suppression de l’alimentation de l’appareil, puis la restauration. Si d’autres appareils partagent le même rail d’alimentation, ils sont également réinitialisés. Si an__RST méthode est définie et référencée par un _PRR (PowerResource), tous les appareils qui utilisent powerResource sont affectés.

    • Étant donné que PLDR fonctionne uniquement pour les appareils internes, il doit être déclaré comme tel dans ACPI. Pour les périphériques USB, pour spécifier un port interne (non visible par l’utilisateur) et pouvant être connecté à un appareil intégré, configurez l’UPC . Octet PortIsConnectable vers 0xFF et the__PLD. Bit UserVisible à 0.

    • Si le mécanisme _PR3 (D3Cold) est utilisé pour PLDR, assurez-vous que les scénarios tels que SystemWake et DeviceWake continuent de fonctionner. Nominalement, cela signifie qu’il existe des ressources d’alimentation appropriées définies pour D2, e.g._PR2. Le tableau suivant est un guide utile :

État d’alimentation Ressource ACPI Comportement
D2 _PR2 Toute puissance ou horloge requise pour les fonctionnalités réduites définies par la classe de cet état.
D3 Chaud (obligatoire) _PR2 Les mêmes ressources que l’état supérieur suivant qui est pris en charge (D2, D1 ou D0).
D3Cold _PR3 Seules les horloges ou la puissance requises pour que l’appareil apparaisse sur son bus et réponde à une commande spécifique au bus.