Tests de stress et de longue durée en veille moderne

Article
06/19/2023

Les concepteurs de systèmes doivent exécuter des tests de contrainte et des tests de longue durée sur leurs systèmes de veilles modernes pour aider à identifier et à résoudre les problèmes de fiabilité potentiels. La veille moderne permet au système de continuer à fonctionner, même s’il est dans un état de faible consommation d’écran. Cet état est différent des états traditionnels de veille ACPI (S3) et veille prolongée ACPI (S4), dans lesquels une grande partie du matériel et des logiciels système sont arrêtés et restent inactifs jusqu’à ce qu’ils soient redémarrés ultérieurement.

La veille moderne permet au système de rester opérationnel pendant une durée totale beaucoup plus longue et peut donc exposer des problèmes de fiabilité matériels et logiciels qui ne seraient pas détectés sur un système qui prend uniquement en charge S3 et S4.

Entrer et quitter

Chaque système de veille moderne doit être validé pour entrer et quitter la veille moderne pendant au moins 1 000 cycles sans défaillance. Le fait d’entrer et de quitter la veille moderne est la principale interaction de l’utilisateur avec le fonctionnement à faible consommation d’énergie sur le système et doit être extrêmement fiable.

Le fait de pouvoir entrer et quitter la veille moderne valide un certain nombre de composants matériels, de microprogrammes et de pilotes de périphérique, notamment :

Le matériel de plateforme qui gère le fonctionnement du bouton d’alimentation, y compris l’IC de gestion de l’alimentation (PMIC).
Le matériel de gestion et d’initialisation du panneau d’affichage.
Le microprogramme et le pilote du périphérique Wi-Fi et réseau.
Le pilote de périphérique graphique.

Les tests de contrainte pour entrer et quitter la veille moderne peuvent être automatisés à l’aide de l’outil PwrTest. PwrTest doit être installé sur le système cible dans le cadre du Kit de pilotes Windows (WDK), qui inclut un logiciel supplémentaire pour automatiser le bouton d’alimentation du système sur les systèmes de veilles modernes.

Scénario de test	Résultat attendu	Notes de diagnostic
Le système peut entrer et quitter la veille moderne de manière fiable pendant au moins 1 000 cycles.	Utilisez l’outil PwrTest et l’option de ligne de commande /cs pour faire passer automatiquement le système en veille moderne pendant 1 000 cycles. Le résultat attendu est que le système termine les 1 000 cycles.	Nous vous recommandons d’augmenter progressivement le test de contrainte jusqu’à 1 000 cycles. Tout d’abord, effectuez un test de 100 cycles. Si une erreur est détectée, connectez le système à un débogueur de noyau et au débogueur matériel SoC, puis répétez le test de 100 cycles pour capturer et déterminer la cause racine du problème. Une fois le test de 100 cycles terminé avec succès, étendez le nombre de cycles à 500 cycles, puis à 1 000 cycles.

Transitions d’état à faible consommation d’énergie SoC

Le microprogramme et les pilotes responsables de la gestion des transitions SoC entre les états d’alimentation actif et inactif doivent être hautement fiables pour résister aux contraintes de fonctionnement pendant de longues périodes dans le mode veille moderne. Les transitions d’état à faible consommation d’énergie SoC doivent être mises à l’épreuve par des tests de veilles modernes de longue durée. Ce test permet de s’assurer que le système reste opérationnel de manière fiable pendant les longues durées de veille moderne, par exemple pendant le week-end. Ce test doit être effectué en étant connecté à l’alimentation secteur.

Scénario de mesure	Résultat attendu	Notes d’alimentation
Le système peut rester en veille moderne pendant 100 heures consécutives et est fonctionnel en la quittant. Le système maintient la connectivité Wi-Fi pendant les 100 heures et la connectivité Wi-Fi est fonctionnelle à la sortie.	Mettez le système en veille moderne et réveillez-le avec le bouton Marche/Arrêt après 100 heures. Le résultat attendu est que le système s’allume instantanément et que la connexion Wi-Fi est opérationnelle sans configuration supplémentaire ou sélection d’un réseau Wi-Fi.	Nous vous recommandons d’augmenter progressivement le test de longue durée jusqu’à 100 heures. Tout d’abord, effectuez un test de 24 heures. Si une erreur est détectée, connectez le système à un débogueur de noyau et au débogueur matériel SoC, puis répétez le test de 24 heures pour capturer et déterminer la cause racine du problème. Une fois le test de 24 heures terminé avec succès, étendez la durée à 100 heures.

Le système peut rester en veille moderne pendant 100 heures consécutives et est fonctionnel en la quittant. Le système maintient la connectivité Wi-Fi pendant les 100 heures et la connectivité Wi-Fi est fonctionnelle à la sortie.

Mettez le système en veille moderne et réveillez-le avec le bouton Marche/Arrêt après 100 heures.

Le résultat attendu est que le système s’allume instantanément et que la connexion Wi-Fi est opérationnelle sans configuration supplémentaire ou sélection d’un réseau Wi-Fi.

Nous vous recommandons d’augmenter progressivement le test de longue durée jusqu’à 100 heures.

Tout d’abord, effectuez un test de 24 heures. Si une erreur est détectée, connectez le système à un débogueur de noyau et au débogueur matériel SoC, puis répétez le test de 24 heures pour capturer et déterminer la cause racine du problème.

Une fois le test de 24 heures terminé avec succès, étendez la durée à 100 heures.

Test de contrainte en veille moderne de Windows HLK

Le kit d’évaluation de matériel en laboratoire Windows (HLK) inclut un test de contrainte de veille moderne nommé Contrainte de veille connectée avec contrainte de simultanéité du vérificateur de pilote qui exerce des transitions automatiques de veilles modernes en même temps que les pilotes de périphérique sont exercés pour le fonctionnement du périphérique. Le test est conçu pour vérifier que l’appareil et son ou ses pilotes continuent de fonctionner pendant la transition du système vers et depuis l’état d’alimentation de veille moderne.

Ce test est un élément essentiel pour valider que le système continue de fonctionner comme prévu une fois qu’il a quitté la veille moderne. Ce test est inclus dans le cadre de Windows HLK et est requis pour la certification système.

Opération de test

Le test utilise les interfaces SimpleIO de Windows Device Testing Framework (WDTF) pour exercer des appareils énumérés sur le système. Ces appareils incluent les capteurs, les caméras, l’audio, les graphiques, le Wi-Fi, le stockage et les appareils Bluetooth. Le test place le système en veille moderne pendant une minute, puis le fait sortir de cette veille moderne et exerce les appareils pendant 30 secondes. Ce cycle se répète 150 fois.

Pendant l’exécution du test, le vérificateur de pilote est activé pour aider à identifier les bogues de pilote et les fuites de mémoire.

Le test permet d’identifier les problèmes suivants liés au système ou au pilote de périphérique :

Un système ne répond plus ou se bloque pendant le fonctionnement de l’appareil après une session de veille moderne.
L’incapacité du système à entrer dans l’état de faible consommation (état de plateforme d’inactivité d’exécution le plus profond, ou DRIPS) après l’activité de l’appareil.
Les problèmes de pilote identifiés par le vérificateur de pilote, notamment l’altération du système, les défaillances de pilote et les fuites de mémoire.
Les problèmes de pilote après la reprise de la veille moderne, y compris l’absence de réponse, les incidents ou les codes de problème.

Résolution des échecs de test

Le test exerce plusieurs appareils, ce qui peut entraîner différents types d’échecs de test. L’identification du type d’échec de test est la première étape pour trouver la cause racine des problèmes liés au système ou au pilote.

Le test échoue généralement dans l’un des trois modes d’échec suivants :

Le test échoue et l’échec est enregistré dans les journaux Windows HLK, qui contiennent des données sur l’échec détecté.
Le test échoue, mais le système ne signale pas au serveur Windows HLK à la suite de l’échec. Toutefois, le système est réactif et fonctionne avec une interaction locale.
Le test ne se termine pas et le système testé se bloque ou ne répond plus (écran noir figé).

Débogage des échecs de test enregistrés dans les journaux Windows HLK

Il existe deux types d’échecs courants lorsque les échecs de test sont enregistrés dans les journaux Windows HLK :

Le système n’a pas pu entrer dans l’état de faible consommation (DRIPS) pendant le test.
Le test a détecté qu’il ne pouvait plus communiquer avec un pilote, et un délai d’attente s’est produit.

Vous pouvez utiliser le rapport SleepStudy, qui est inclus dans les journaux de test, pour identifier les composants qui empêchent le système d’entrer dans l’état de faible consommation (DRIPS). Il existe plusieurs causes courantes :

Problèmes d’installation et de configuration du test, notamment l’utilisation d’un adaptateur Ethernet câblé qui ne prend pas en charge NDIS 6.3 et la fonctionnalité de veille moderne.
Problèmes de serveur DHCP sur le réseau LAN câblé.
Un appareil et/ou un pilote qui n’est pas correctement inactif dans son propre mode de faible consommation pendant la veille moderne.

Les journaux de test peuvent également inclure un message d’échec qui indique quels appareils n’ont pas répondu aux demandes d’E/S en temps opportun. Cette condition est considérée comme un échec de test, car elle peut empêcher l’utilisateur ou une application d’être fonctionnel lorsque le système sort de la veille moderne.

Les journaux de test indiquent les derniers appareils à effectuer des opérations d’E/S. Ces appareils sont l’origine de l’échec du test. La sortie du journal de test dans l’exemple suivant montre que l’appareil ACPI\XXXX\2&DAFA3FF&1 a expiré.

Message	16/07/2013 12:50:24.333	WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Location Sensor Device ACPI\XXXX\2&DAFA3FF&1)
Message	16/07/2013 12:59:50.333	WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Other Device XXX_XXX\UART_XXX\3&2F829BAD&0&F00D)

Une cause courante de défaillances est une mauvaise réception GPS, ce qui fait que l’appareil GPS prend beaucoup de temps pour répondre aux demandes d’E/S. Pour plus d’informations sur l’exécution de ce test sur des systèmes équipés d’appareils GPS, consultez Notes pour les systèmes équipés d’un GPS.

Débogage des échecs de test sans journaux (et un système réactif)

Si le système testé est toujours en cours d’exécution sans aucun signe indiquant que le test est toujours en cours d’exécution, la cause la plus probable est que le système a rencontré une erreur irrécupérable ou a redémarré. Pour déboguer ces problèmes, vérifiez dans le répertoire système les fichiers de vidage éventuels et désactivez toute surveillance matérielle susceptible de réinitialiser le système.

Débogage des échecs de test lorsque le système ne répond pas (écran noir)

Si le système est figé sur un écran noir, un débogueur de noyau doit être connecté au système pour diagnostiquer le problème.

Si le débogueur de noyau est déjà connecté et que le système ne répond pas au débogueur de noyau, un débogueur de matériel est nécessaire pour identifier la raison pour laquelle le système se bloque. Vous pouvez consulter le fournisseur principal Silicon/SoC pour obtenir une assistance supplémentaire sur le débogage.

Documentation HLK supplémentaire

Notes pour les systèmes équipés d’un GPS

Si le système à tester dispose d’un appareil GPS ou d’un capteur de localisation, les paramètres Windows suivants doivent être activés avant d’exécuter le test :

Panneau de configuration\Matériel et son\Paramètres d’emplacement\Activer la plateforme d’emplacement Windows
Paramètres du PC\Confidentialité\Emplacement : Permettre à Windows et aux applications d’utiliser mon emplacement

Vous pouvez utiliser l’outil de diagnostic du capteur dans le Windows Driver Kit (WDK) pour confirmer la réception du signal GPS sur le site de test. Pour plus d’informations, consultez Test des fonctionnalités de capteur avec l’outil de diagnostic de capteur.

Partager via