Compartilhar via

Redefinição e recuperação de rádio Bluetooth

A reinicialização e recuperação de rádio Bluetooth é uma tecnologia no Windows 10, versão 1803 e posterior que introduz um mecanismo robusto de reinicialização e recuperação para rádios Bluetooth. Esse mecanismo permite que os rádios Bluetooth se recuperem de falhas de hardware que levam ao mau funcionamento, perda de conectividade ou falta de resposta aos comandos operacionais. O objetivo é recuperar automaticamente o rádio, tornando a experiência do usuário perfeita e reduzindo a probabilidade de exigir uma reinicialização do sistema.

A reinicialização e recuperação de rádio Bluetooth pode ser implementada com ou sem dependências de firmware. Os parceiros de hardware podem estender os mecanismos de redefinição baseados em software disponíveis em todos os PCs Windows com mecanismos de redefinição no nível do dispositivo ou firmware com suporte para aumentar a probabilidade de recuperação bem-sucedida.

Importante

Este tópico é para desenvolvedores. Se você for um cliente com problemas de bluetooth, consulte Corrigir problemas de Bluetooth no Windows 10.

Cenários de redefinição e recuperação de Bluetooth

Há três grandes categorias de problemas em que a redefinição e a recuperação são iniciadas:

  • Falhas de enumeração de barramento: O rádio falha na enumeração ou reenumeração pelo barramento subjacente (geralmente USB ou UART), conforme indicado por um estado de falha visível (estrondo amarelo) no Gerenciador de dispositivos, que pode ser sintomático de erros de hardware subjacentes.

  • Falhas de enumeração de driver: O rádio Bluetooth está em um estado de falha após a enumeração bem-sucedida pelo barramento subjacente. Esse estado de falha normalmente ocorre ao criar a pilha de driver para o rádio. Por exemplo, quando um filtro ou driver de função é instalado no nó do dispositivo de rádio Bluetooth. Falhas podem ocorrer se um driver encontrar um erro durante uma ou mais operações de início e, como resultado, relatar uma falha PnP. Um exemplo de tal operação poderia ser um download de firmware para o dispositivo.

  • Falhas de não enumeração: o dispositivo não está em um estado de falha, mas não está operacional, conforme determinado pela pilha de drivers. Essas falhas estão fora do caminho de enumeração e podem ser falhas críticas gerais específicas de transporte ou falhas específicas do dispositivo, como um erro catastrófico de firmware. Os seguintes mecanismos de redefinição e recuperação Bluetooth são usados nesses casos.

Mecanismos de redefinição e recuperação

Embora existam diferentes abordagens para se recuperar de um estado com falha, o Bluetooth usa um mecanismo de recuperação padronizado baseado em ACPI para tentar restaurar o rádio para um estado de funcionamento.

GUID_DEVICE_RESET_INTERFACE_STANDARD define dois níveis de redefinição. Os mecanismos de reinicialização funcionam apenas para dispositivos internos, portanto, rádios Bluetooth conectáveis externamente, como dongles, não são suportados. Os mecanismos de redefinição exigem suporte no Windows (normalmente pela pilha de driver de função) e no firmware subjacente (normalmente no BIOS ACPI) para realmente executar a redefinição. O mecanismo de reinicialização real é específico do sistema.

Redefinir nível Implementação
Redefinição do dispositivo no nível da função (FLDR) A operação de redefinição é restrita a um dispositivo específico e não é visível para outros dispositivos. Não há reenumeração. Os drivers de função devem assumir que o hardware retornou ao seu estado original após a operação. O estado intermediário não é preservado.
Redefinição de dispositivo no nível da plataforma (PLDR) A operação de reinicialização afeta um dispositivo específico e todos os outros dispositivos conectados a ele por meio do mesmo trilho de alimentação ou linha de reinicialização. A operação de redefinição faz com que o dispositivo seja relatado como ausente do barramento e reenumerado. Esse tipo de redefinição tem o maior impacto no sistema, já que todos os dispositivos que compartilham o recurso voltam ao seu estado original.

  • Para oferecer suporte ao FLDR , deve haver um método __RST definido dentro do escopo do dispositivo, conforme detalhado no firmware ACPI: redefinição no nível da função.

  • Para suportar PLDR , deve haver um método __RST or__PR3 definido no escopo do dispositivo, conforme detalhado no firmware ACPI: Redefinição no nível da plataforma. Se um método PR3 for usado, ACPI usa o mecanismo de ciclo de energia D3Cold para redefinir. O mecanismo de ciclo de energia D3Cold emula a remoção de energia do dispositivo e, em seguida, restaura-o. Se outros dispositivos compartilharem o mesmo trilho de alimentação, eles também serão redefinidos. Se an__RST método for definido e referenciado por um _PRR (PowerResource), todos os dispositivos que usam esse PowerResource serão afetados.

    • Como o PLDR funciona apenas para dispositivos internos, ele deve ser declarado como tal na ACPI. Para dispositivos USB, para especificar uma porta interna (não visível para o usuário) e que possa ser conectada a um dispositivo integrado, defina o UPC. PortIsConnectable byte para 0xFF e the__PLD. UserVisible bit para 0.

    • Se o mecanismo _PR3 (D3Cold) for usado para PLDR, verifique se cenários como SystemWake e DeviceWake continuam funcionando. Nominalmente, isso significa que existem recursos de potência apropriados definidos para D2, e.g._PR2. A tabela a seguir é um guia útil:

Estado de energia Recurso ACPI Comportamento
D2 _PR2 Qualquer energia ou relógios necessários para a funcionalidade reduzida definida pela classe desse estado.
D3 Quente (obrigatório) _PR2 Os mesmos recursos que o próximo estado superior com suporte (D2, D1 ou D0).
D3Frio _PR3 Somente a energia ou os relógios necessários para que o dispositivo apareça em seu barramento e responda a um comando específico do barramento.