Un HMI embarqué démarre normalement, affiche son interface et répond au toucher. Après un délai d'inactivité, l'écran s'éteint. Le prochain événement de réveil remet le système en marche, mais l'écran LCD reste noir. Le redémarrage de l'appareil restaure l'image.

Cette défaillance est facile à mal interpréter. Un démarrage à froid réussi montre que le système peut produire une image dans une condition de démarrage donnée. Il ne montre pas que le panneau, le contrôleur d'affichage, le rétroéclairage et le logiciel peuvent récupérer après chaque état de basse consommation.

La question utile est la suivante : quelle partie du système d'affichage n'a pas réussi à revenir à son état de fonctionnement ? Répondez à cette question avant de remplacer l'écran LCD ou d'ajouter des délais au pilote. Ce guide fournit une démarche d'investigation pratique pour les équipes OEM intégrant des modules TFT LCD dans des systèmes HMI basés sur Linux ou Android.

1. Pourquoi un affichage peut démarrer correctement mais échouer après la reprise

Le démarrage à froid et la reprise partent de conditions différentes. Au démarrage, le chargeur d'amorçage et le système d'exploitation peuvent initialiser le matériel par étapes. Lors de la reprise, certains composants peuvent conserver leur état tandis que d'autres doivent être restaurés. Le chemin de reprise doit tenir compte de cette différence.

Par exemple, un chargeur d'amorçage peut initialiser le panneau avant que le noyau ne prenne le relais. Si le noyau s'appuie sur cette configuration initiale mais ne peut pas la restaurer après une perte d'alimentation, le premier démarrage peut sembler correct alors qu'un réveil ultérieur échoue. Considérez cela comme une hypothèse à vérifier par rapport au chargeur d'amorçage réel, au pilote de panneau et au package de support de carte (BSP).

Linux distingue la veille système de la gestion d'alimentation à l'exécution. La veille système modifie l'état de la machine dans son ensemble. La gestion d'alimentation à l'exécution permet à des dispositifs individuels d'entrer dans des états de basse consommation tandis que le système reste actif. Leurs interactions importent lorsqu'un dispositif d'affichage était déjà suspendu avant le début de la veille système.^[1]

Commencez l'investigation avec deux captures : un démarrage réussi et un réveil échoué. Comparez le point où leurs comportements divergent. Une transition de régulateur manquante, une commande de panneau infructueuse ou une mise à jour d'affichage absente constituent des preuves plus utiles que l'affirmation “ la reprise ne fonctionne pas ”.”

2. Identifier ce qui est réellement entré en veille

“Le terme ” veille » décrit souvent plusieurs actions différentes dans une spécification produit. L'utilisateur voit le même écran noir, mais les exigences d'ingénierie peuvent différer sensiblement.

État ou action	Ce qu'il faut établir	Pourquoi cela importe
Masquage applicatif	L'application a-t-elle dessiné un contenu noir ou masqué son interface ?	Le matériel d'affichage peut encore fonctionner normalement.
Rétroéclairage éteint	Seul l'éclairage LED s'est-il arrêté ?	La génération d'image peut se poursuivre sans éclairage visible.
État de basse consommation du panneau	Quelles commandes de panneau, modifications d'alimentation et actions de réinitialisation ont eu lieu ?	Le panneau peut nécessiter une séquence de sortie définie.
Suspension à l'exécution du sous-système d'affichage	Quelles ressources de contrôleur, de pont, d'horloge et d'alimentation ont changé ?	Le chemin d'image peut nécessiter une restauration tandis que le CPU reste actif.
Veille système	Quel état de veille de la plateforme a été atteint, et qu'est-ce qui l'a réveillé ?	La défaillance peut impliquer une récupération système au-delà de l'affichage.

Linux documente plusieurs états de veille système, notamment la suspension en veille inactive et la suspension en RAM. Les états disponibles et leur comportement dépendent du support de la plateforme. Le délai d'extinction d'écran d'un produit ne prouve pas, à lui seul, que la machine est entrée dans l'un ou l'autre de ces états.^[2]

Enregistrez le déclencheur réel : délai d'expiration applicatif, politique d'alimentation du système d'exploitation, bouton physique, événement planifié ou test d'ingénierie manuel. Enregistrez également la source de réveil. Si un événement tactile ne peut pas réveiller le système mais qu'un bouton physique le peut, examinez la configuration de réveil avant de traiter le résultat comme un défaut de récupération d'image.

Cette distinction modifie également le plan de test. La gradation du rétroéclairage seul, la mise hors tension du panneau et la veille système nécessitent des cas de test distincts. Les regrouper sous une seule case à cocher “ veille/réveil ” peut masquer la transition défaillante.

3. Distinguer une défaillance de rétroéclairage d'une défaillance d'image

Avant de modifier le firmware, classez ce que font l'écran et le reste de l'appareil. Confirmez que l'hôte a repris via un canal indépendant approprié, tel qu'une console série ou un battement de cœur système. Un accès réseau seul peut être non concluant si la mise en réseau nécessite également une récupération.

Symptôme observé	Premières vérifications	Preuves à conserver
Aucun éclairage visible	Alimentation du rétroéclairage, signal d'activation, commande de luminosité, sortie PWM et état de défaut du pilote lorsqu'ils sont disponibles	Mesures d'alimentation et de contrôle avant la veille et après le réveil
Le rétroéclairage est allumé, mais aucune image n'apparaît	Alimentation du panneau, réinitialisation, initialisation, mode d'affichage actif et sortie d'image	Journaux du pilote de panneau et captures de signaux pertinentes
L'ancienne image reste figée	Mises à jour applicatives, activité du compositeur, état de balayage et tout mode de rétention de trame pris en charge	Modifications de contenu horodatées et observations de mise à jour d'affichage
L'image revient, mais le toucher ne fonctionne pas	Alimentation du contrôleur tactile, communication sur bus, comportement des interruptions, récupération du pilote et acheminement des entrées	Événements d'entrée et journaux du pilote tactile
Aucun signe indépendant de récupération de l'hôte	Erreurs de réveil système et de gestion d'alimentation de l'appareil	Sortie série ou journaux conservés de la transition échouée

Ces vérifications identifient des axes d'investigation ; elles ne prouvent pas une cause racine. Un rétroéclairage allumé ne prouve pas que l'écran LCD est initialisé. Une image figée ne prouve pas que l'application s'est arrêtée. Utilisez une image de test changeant délibérément pour distinguer un contenu obsolète d'une mise à jour réussie.

Pour un écran LCD transmissif, un examen attentif sous un éclairage externe peut révéler une image faible lorsque le rétroéclairage est éteint. Une observation positive peut aider à isoler le chemin d'éclairage. L'absence d'image visible n'est pas concluante, car l'empilement optique et les conditions d'observation affectent la visibilité.

Deux modules LCD TFT illustrant un écran éteint et un écran rétroéclairé sans contenu d'image visible.

Linux traite le contrôle du rétroéclairage comme un sous-système distinct. Son interface de pilote inclut les mises à jour de luminosité et la gestion optionnelle de suspension/reprise. Une valeur de luminosité logicielle doit donc être comparée à la sortie matérielle plutôt qu'acceptée comme preuve d'éclairage.^[3]

4. Vérifier l'alimentation, la réinitialisation et l'initialisation du panneau

La question suivante est de savoir si le panneau a reçu une séquence de récupération valide. Utilisez la fiche technique et les instructions d'intégration correspondant exactement au module LCD et à sa révision. Il n'existe pas de délai ni de séquence de commandes universels pour tous les écrans LCD TFT.

Comparer le comportement mesuré avec la séquence requise

Capturez les rails d'alimentation pertinents du panneau, le signal de réinitialisation et l'activation du rétroéclairage autour de l'événement défaillant. Vérifiez leurs niveaux et leur ordonnancement par rapport aux exigences du module. Incluez tout temps d'arrêt minimal ou exigence de décharge spécifié par le fabricant.

Comparez ensuite les actions prévues par le pilote avec les signaux mesurés. Un journal indiquant “ alimentation activée ” confirme qu'une action logicielle a été demandée ; il n'établit pas la tension au connecteur du panneau. Une alimentation en amont peut sembler stable alors que le rail local se comporte différemment pendant une transition.

Établir quel état a survécu

Si l'alimentation du panneau a été coupée, déterminez quelle initialisation le module nécessite après le retour de l'alimentation. Si l'alimentation est restée présente, établissez si le panneau est entré dans un état de veille commandé et comment il doit en sortir. Ne substituez pas une séquence de démarrage à froid à une séquence de reprise sans vérifier les exigences du panneau.

Les assistants de panneau DRM de Linux distinguent la préparation, l'activation, la désactivation et la dépréparation. Cette séparation illustre pourquoi l'alimentation du panneau et la sortie visible doivent être examinées comme des opérations liées mais distinctes. Les BSP de fournisseurs peuvent implémenter ces responsabilités différemment, il convient donc d'inspecter le code utilisé dans le produit.^[4]

Sonde positionnée sur un point de test de la carte contrôleur à côté d'un écran LCD TFT lors de l'investigation de l'alimentation et de la réinitialisation.

Utiliser des modifications de délai pour tester une hypothèse

Un délai ajouté peut réduire les défaillances sans identifier la cause. Si un délai semble utile, reliez-le à un événement mesuré : stabilisation du rail, libération de la réinitialisation, achèvement d'une commande ou autre exigence documentée. Répétez le test dans les conditions qui causaient précédemment la défaillance.

L'objectif d'ingénierie est une séquence justifiée avec une marge adéquate. Un délai qui passe un test sur banc est une preuve insuffisante pour un correctif de production.

5. Vérifier la liaison d'affichage et le chemin de récupération logicielle

Une fois le comportement d'alimentation et de réinitialisation compris, suivez le chemin de l'image depuis l'hôte jusqu'au panneau. Identifiez le composant responsable de la restauration de chaque partie de ce chemin. Incluez un pont actif ou une carte contrôleur lorsque la conception en utilise un.

MIPI DSI : comparer l'initialisation et la transmission

Pour une conception MIPI DSI, comparez l'initialisation documentée du panneau avec les commandes réellement émises lors de la récupération. Examinez les erreurs de commandes et la restauration de l'hôte DSI et du PHY selon ce qui s'applique au BSP. Vérifiez si le mode d'affichage attendu est actif après le réveil.

Une expérience utile sépare la récupération des commandes de la récupération du contenu. Si les commandes du panneau aboutissent mais qu'aucune image de test changeante n'apparaît, investiguez le reste du chemin d'image. Si les commandes échouent, établissez d'abord si le panneau et l'hôte sont prêts à communiquer. Évitez de traiter un délai d'attente comme preuve d'un LCD défectueux.

LVDS : vérifier la configuration de sortie reprise

Pour le LVDS, comparez la synchronisation restaurée, l'horloge, l'arrangement des voies et le mappage des données avec la configuration de référence fonctionnelle. Vérifiez également tout contrôleur intermédiaire. Comme le démarrage à froid fonctionne, investiguez ce qui change pendant la transition avant de revisiter chaque décision de sélection initiale.

Lorsqu'un pont est présent, vérifiez si sa configuration survit à l'état de veille sélectionné. La récupération de l'hôte peut réussir alors que le dispositif en aval reste non configuré.

eDP : inspecter la récupération de la connexion

Pour l'eDP, conservez les résultats de communication AUX et d'entraînement de liaison du pilote source lorsqu'ils sont disponibles. Comparez les tentatives de récupération échouées et réussies avec les mesures d'alimentation et de réinitialisation du panneau. Le comportement de récupération requis dépend du panneau, de la source et de la transition d'état.

Utilisez le guide de compatibilité des panneaux LCD TFT eDP de RJY (référence au guide de compatibilité des panneaux LCD TFT eDP de RJY) pour l'examen d'intégration plus large. Cette investigation porte sur la question plus étroite de ce qui échoue après qu'une configuration déjà fonctionnelle entre en veille.

Vérifier la récupération du pilote avant la récupération de l'application

Une carte qui revient à une invite de commande n'a pas nécessairement restauré son chemin graphique. Inversement, une mire de test d'affichage fonctionnelle ne prouve pas que l'application normale a repris correctement. Testez ces couches séparément.

La gestion d'alimentation des périphériques Linux utilise des callbacks pour coordonner les transitions et les dépendances des périphériques. Examinez les erreurs et l'ordonnancement dans l'implémentation réelle du pilote plutôt que de supposer que tous les périphériques ont été récupérés parce que le système a repris.^[5]

Pour Android, comparez également le comportement du service d'affichage, du compositeur, de l'application et de l'entrée tactile sur l'image logicielle fournie. Les modifications requises dépendent de la révision de la carte et du BSP. Une correspondance d'interface générale ne peut pas établir la compatibilité logicielle.

6. Construire une matrice de test suspension–reprise reproductible

Une défaillance intermittente devient une preuve utile lorsque ses conditions sont reproductibles. Commencez par une configuration matérielle et logicielle fixe. Modifiez une variable à la fois jusqu'à ce que la limite de défaillance soit plus claire.

Variable de test	Couverture suggérée	Enregistrement
Transition	Rétroéclairage éteint/allumé, veille/réveil du panneau, suspension d'exécution prise en charge et suspension système prise en charge	État réel atteint et résultat de la récupération
Durée de veille	Intervalles courts et prolongés pertinents pour l'utilisation du produit	Durée exacte et comportement d'alimentation observé
Source de réveil	Chaque source requise par le produit	Si le système s'est réveillé et si l'image et le tactile sont revenus
Luminosité	Réglages bas, intermédiaires et élevés dans la plage validée	Luminosité demandée et sortie de contrôle mesurée
Activité de l'application	Interface utilisateur statique, graphiques changeants et charge de travail représentative	Temps jusqu'à la première image utilisable mise à jour
Cycles répétés	Une durée d'exécution définie basée sur le plan de validation du projet	Tentatives, défaillances, index de cycle et type de défaillance
Conditions du produit	Conditions d'alimentation et d'environnement approuvées avec le boîtier prévu	Conditions et différences de configuration

Définir un critère de réussite avant d'exécuter le test. Il doit couvrir l'image prévue, les mises à jour continues, le tactile utilisable lorsque requis, la luminosité correcte et la récupération dans le délai convenu du produit. Fixez cette limite en fonction du cas d'usage plutôt que d'emprunter un chiffre à un autre écran.

Préserver les journaux lorsqu'un cycle échoue. Lorsque cela est pris en charge, les utilitaires de débogage de gestion d'alimentation de Linux peuvent aider à isoler les étapes de la mise en veille du système. Leur disponibilité et leur pertinence dépendent de la configuration du noyau et de la plateforme.^[6]

Prototype d'IHM embarqué avec une image de test géométrique simple sur un banc de validation en laboratoire.

Rapporter les résultats observés avec précision. Une exécution sans défaillance établit ce qui s'est produit pendant cette exécution ; elle n'établit pas que le taux de défaillance est nul. Retester une correction proposée par rapport au reproducteur d'origine et aux conditions produit pertinentes.

7. Transformer un rapport d'écran noir en preuve d'ingénierie utile

“ L'écran reste parfois noir ” laisse le fournisseur deviner. Un rapport utile relie le symptôme à une configuration connue et à une transition reproductible.

Format de rapport illustratif, et non résultat de test produit : L'écran LCD fonctionne normalement après un démarrage à froid. Après l'intervalle de mise en veille système spécifié, le bouton de réveil physique restaure la console série. Le rétroéclairage s'allume, mais l'image de test changeante ne revient pas. Enregistrer le nombre de défaillances et l'index de cycle. Joindre le modèle exact du panneau, la révision de la carte, la version du BSP, les journaux de transition et les captures synchronisées d'alimentation/réinitialisation. Noter si le redémarrage de l'application, une réinitialisation d'affichage prise en charge ou un redémarrage complet de l'appareil restaure le fonctionnement.

Enregistrer les expériences de récupération séparément. Le redémarrage de l'application, la réinitialisation du chemin d'affichage et le cycle d'alimentation du panneau affectent différentes limites. Une expérience réussie circonscrit l'investigation, mais elle ne doit pas devenir la correction permanente sans comprendre ce qu'elle a modifié.

Pour une revue écran-et-contrôleur, fournir la fiche technique du LCD, la définition du connecteur, les détails du contrôleur tactile, la configuration de la carte, la version logicielle et le comportement basse consommation prévu. RJY Guide de correspondance entre écran LCD TFT et carte de contrôle Android couvre les exigences de sélection plus larges.

Le transfert le plus solide contient à la fois la référence fonctionnelle et la récupération échouée. Cette comparaison aide les équipes panneau, carte et logiciel à investiguer le même événement au lieu de tester différentes interprétations du “ sommeil ”.”

8. FAQ

Un démarrage à froid réussi prouve-t-il qu'un LCD prend en charge la mise en veille et la reprise ?

Non. Le démarrage à froid vérifie un seul chemin de démarrage. La mise en veille et la reprise doivent être testées pour le panneau, la carte, l'image logicielle et les états basse consommation exacts requis par le produit.

Si le redémarrage de l'appareil corrige l'écran noir, le problème est-il définitivement logiciel ?

Non. Le redémarrage peut modifier l'état logiciel, réinitialiser le matériel et restaurer l'alimentation ou l'initialisation. C'est une observation diagnostique utile, mais elle n'identifie pas la cause racine à elle seule.

Le tactile peut-il échouer après la reprise même lorsque l'image LCD revient ?

Oui. Le tactile a son propre contrôleur et ses propres dépendances de récupération. Vérifier séparément son alimentation, son interface de communication, son comportement d'interruption, la récupération du pilote et les événements d'entrée, indépendamment du chemin d'image.

Chaque écran LCD TFT doit-il utiliser le même délai de réinitialisation après le réveil ?

Non. Utilisez les exigences du module et du circuit intégré de commande exacts, ainsi que l'implémentation de la carte. Confirmez la séquence par la documentation et des mesures plutôt que d'appliquer un délai universel.

Quelles informations un OEM doit-il fournir pour une revue de récupération d'affichage ?

Fournir le modèle et la fiche technique du panneau, la révision de la carte, la version logicielle, l'état de veille réel, la source de réveil, les étapes de reproduction, les comptages de défaillances, les journaux et les mesures disponibles d'alimentation, de réinitialisation et de rétroéclairage.

Discuter de vos exigences de récupération d'affichage avec RJY

RJY Display prend en charge les projets LCD TFT avec adaptation de carte de contrôle et support firmware dépendant du projet. Pour une IHM embarquée, soumettez vos exigences d'écran et de carte de contrôle ainsi que le comportement de veille et de réveil attendu. La compatibilité et la portée de l'adaptation doivent être examinées pour le panneau, la carte, la configuration tactile et l'environnement logiciel spécifiques.

Références

Les sources Linux ci-dessous décrivent les frameworks upstream. Vérifiez leur applicabilité à la version du noyau et au BSP fournisseur utilisés dans votre produit. Les tableaux de diagnostic et le format de rapport sont des méthodes d'ingénierie proposées, et non des résultats de test RJY rapportés.