Nous continuons la série d'articles sur les tests d'automatisation des systèmes embarqués. Cet article vous expliquera comment intégrer rapidement et relativement facilement la capacité de contrôler la puissance de l'appareil testé à partir d'un script de test, ainsi que la possibilité de simuler la pression de boutons mécaniques sur une commande à partir d'un script de test.
Donc ce que nous avons:
- Des dizaines d'appareils embarqués dans lesquels vous devez tester la nouvelle version de FirmWare (pour être plus précis, l'assemblage quotidien du firmware)
- En raison de la nature de la procédure de démarrage FW, il peut être nécessaire de réinitialiser l'alimentation (le mode de téléchargement du micrologiciel en mode de capture à la mise sous tension)
- Je voudrais à certains moments précis au cours de l'exécution du script de test simuler l'appui sur les boutons mécaniques situés sur la carte de débogage du système intégré
Pourquoi le point 3 pourrait-il être nécessaire? Dans mon cas, la tâche est la suivante - en cas d'exception critique d'exécution de code, le système "se relève" à un état à moitié mort dont il ne sortira pas tant qu'il ne sera pas réinitialisé (autre raison de la gestion de l'alimentation). Mais la chose la plus intéressante est que si dans ce mode vous appuyez sur le bouton mécanique spécialement conçu à cet effet, le soi-disant Journal des exceptions - informations de débogage sur lesquelles il sera possible d'essayer de comprendre à quel endroit une exception s'est produite sur le code.
C'est précisément pour cette raison que pour l'automatisation efficace de la configuration de test, il est devenu nécessaire de pouvoir réinitialiser la puissance de l'appareil et simuler une pression sur les boutons mécaniques de la carte de débogage, ce qui "enregistre" des informations très importantes sur Exception de la perdre rapidement. tôt ou tard, un script de test se rendant compte qu'il n'y a pas de réponse de l'appareil tentera de le réanimer en réinitialisant l'alimentation.
Une petite digression lyrique - parfois vous courrez pendant des semaines derrière cette exception car elle n'apparaît qu'occasionnellement lorsque toutes les étoiles convergent et qu'un tas d'autres conditions ne sont pas remplies. Par conséquent, chacun de ces journaux de débogage est très important et nécessaire.
L'analyse du débogage de la carte de circuit imprimé a montré que le bouton ferme simplement la ligne GPIO tirée jusqu'à +3,3 V sur GND. Donc, si vous «soudez» le bouton et utilisez le relais pour fermer la ligne GPIO au sol, ce sera ce dont vous avez besoin.
Ensuite, la question s'est posée de choisir un appareil / module de contrôle auquel les exigences suivantes ont été avancées:
- Le nombre maximum de relais (vous avez besoin de 2 pièces par appareil, et il y a des dizaines d'appareils)
- Accès Ethernet
- Gérer les commandes URL
- Possibilité de copier et de faire évoluer le système
Par tradition, ils se sont arrêtés sur le module Etherent du relais Laurent-128:
Le module a tout arrangé pour nous selon tous les paramètres: il est possible de contrôler 14 appareils à la fois (un relais pour l'alimentation, l'autre sur simple pression d'un bouton) à l'aide de commandes URL (très pratique pour les langages de script dans lesquels l'automatisation des tests est écrite).
Le schéma de connexion et de communication de la carte de débogage de l'appareil testé et du module de contrôle est illustré dans la figure ci-dessous:
La «soudure» aux contacts d'un bouton mécanique sur l'exemple d'un des appareils testés ressemble à ceci:
Hourra! La partie technique est terminée. Il ne reste plus qu'à ajouter le code des procédures de test pour que si nécessaire (télécharger l'image du firmware après une réinitialisation de l'alimentation ou enregistrer le débogage au toucher d'un bouton) donner une commande pour activer / désactiver le relais souhaité.
La syntaxe des URL de commande de contrôle est simple et évidente. Par exemple, pour activer le relais sous le numéro 4, vous devez utiliser l'adresse HTTP suivante:
http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1
Et voici une fonction simple en Perl qui est appelée depuis la procédure de test principale si vous avez besoin de "tirer" le relais:
Je note que le système fonctionne de manière très fiable sans plantages ni gels. Laurent-128 et le Laurent-112 précédemment utilisé (pour 12 relais) ont fonctionné pendant quelques années sans échecs ni arrêts, en tenant compte du travail quotidien.
Et voici un exemple d'une telle exception qui a été identifiée lors de tests avec un assemblage de firmware quotidien extraordinaire. Après qu'il soit devenu clair pour le script de test qu'il n'y avait pas de réponse de l'appareil sur le port série (c'est-à-dire qu'il "est mort"), une tentative a été faite d'appuyer sur le bouton mécanique d'urgence pour enregistrer le débogage et cela a fonctionné - le rapport de test final généré par le script de test lui-même a été rempli d'informations utiles de l'emplacement d'un éventuel plantage du système pour une analyse plus approfondie par l'équipe de développement:
