Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes

Chaque exécution de suite de tests a un ID d'exécution unique qui est utilisé pour créer un dossier nommé results/execution-id dans le répertoire results. Les journaux de groupes de tests individuels se trouvent dans le répertoire results/execution-id/logs. Utilisez la sortie de la console IDT pour FreeRTOS pour trouver l'identifiant d'exécution, l'identifiant du cas de test et l'identifiant du groupe de tests du scénario qui a échoué, puis ouvrez le fichier journal du scénario de test nommé. results/execution-id/logs/test_group_id__test_case_id.log Les informations dans ce fichier incluent, entre autres :

Nous vous recommandons le flux de dépannage suivant :

Résolution des erreurs de configuration de l'appareil

Lorsque vous utilisez IDT pour FreeRTOS, vous devez mettre en place les bons fichiers de configuration avant d'exécuter le binaire. Si vous obtenez des erreurs d'analyse et de configuration, votre première étape devrait être de localiser et d'utiliser un modèle de configuration approprié pour votre environnement. Ces modèles sont situés dans le répertoire IDT_ROOT/configs.

Si le problème persiste, consultez les processus de débogage suivants.

Quels fichiers examiner ?

Commencez par lire la sortie de la console pour trouver des informations, telles que l'UUID d'exécution, qui est référencé en tant que execution-id dans cette documentation.

Ensuite, examinez le fichier FRQ_Report.xml dans le répertoire /results/execution-id. Ce fichier contient tous les scénarios de tests qui ont été exécutés et des extraits d'erreur pour chaque échec. Pour obtenir tous les journaux d'exécution, recherchez le fichier /results/execution-id/logs/test_group_id__test_case_id.log pour chaque cas de test.

Codes d'erreur IDT

Le tableau suivant explique les codes d'erreur générés par IDT pour FreeRTOS :

Débogage des erreurs d'analyse

Parfois, une faute de frappe dans une configuration JSON peut entraîner des erreurs d'analyse. La plupart du temps, le problème est le résultat d'une virgule, d'une apostrophe ou d'un crochet manquant dans le fichier JSON. IDT pour FreeRTOS effectue la validation JSON et imprime les informations de débogage. Il imprime la ligne dans laquelle l'erreur s'est produite, le numéro de ligne et le numéro de colonne de l'erreur de syntaxe. Ces informations devraient être suffisantes pour vous aider à corriger l'erreur, mais si vous ne parvenez toujours pas à la localiser, vous pouvez effectuer la validation manuellement dans votre IDE, un éditeur de texte tel qu'Atom ou Sublime, ou via un outil en ligne tel que JSONLint.

Défaillances du contrôle d'intégrité lors du débogage

Lorsque vous exécutez le groupe de RTOSIntegrity test Free et que vous rencontrez des échecs, assurez-vous d'abord de n'avoir modifié aucun des fichiers du freertos répertoire. Si ce n'est pas le cas et que vous rencontrez toujours des problèmes, assurez-vous d'utiliser la bonne branche. Si vous exécutez la list-supported-products commande IDT, vous pouvez trouver la branche balisée du freertos dépôt que vous devez utiliser.

Si vous avez cloné la bonne branche balisée du freertos dépôt et que vous rencontrez toujours des problèmes, assurez-vous d'avoir également exécuté la submodule update commande. Le flux de travail de clonage pour le freertos dépôt est le suivant.

git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive

La liste des fichiers recherchés par le vérificateur d'intégrité se trouve dans le checksums.json fichier de votre freertos répertoire. Pour qualifier un port FreeRTOS sans aucune modification des fichiers et de la structure des dossiers, assurez-vous qu'aucun des fichiers répertoriés dans les sections « » et exhaustive minimal « » checksums.json du fichier n'a été modifié. Pour exécuter avec un SDK configuré, vérifiez qu'aucun des fichiers de la section « minimal » n'a été modifié.

Si vous exécutez IDT avec un SDK et que vous avez modifié certains fichiers de votre freertos répertoire, assurez-vous de configurer correctement votre SDK dans votre fichier. userdata Dans le cas contraire, le vérificateur d'intégrité vérifiera tous les fichiers du freertos répertoire.

Défaillances du groupe de FullWiFi test de débogage

Si vous constatez des défaillances dans le groupe de FullWiFi test et que le test « AFQP_WiFiConnectMultipleAP » échoue, cela peut être dû au fait que les deux points d'accès ne se trouvent pas dans le même sous-réseau que l'ordinateur hôte exécutant IDT. Assurez-vous que les deux points d'accès se trouvent dans le même sous-réseau que l'ordinateur hôte exécutant IDT.

Débogage d'erreur liée à un paramètre obligatoire manquant

Étant donné que de nouvelles fonctionnalités sont ajoutées à IDT pour FreeRTOS, des modifications peuvent être apportées aux fichiers de configuration. L'utilisation d'un ancien fichier de configuration peut corrompre votre configuration. Si tel est le cas, le fichier test_group_id__test_case_id.log sous le répertoire results/execution-id/logs répertorie explicitement tous les paramètres manquants. IDT pour FreeRTOS valide vos schémas de fichiers de configuration JSON pour s'assurer que la dernière version prise en charge a été utilisée.

Débogage d'une erreur de démarrage du test impossible

Vous pouvez voir des erreurs qui pointent sur des défaillances lors du démarrage du test. Comme il existe plusieurs causes possibles, vérifiez bien les points suivants :

Erreur d'absence d'autorisation d'accès à la ressource

Le message d'erreur « n'user/roleest pas autorisé à accéder à cette ressource » peut s'afficher dans la sortie du terminal ou dans le test_manager.log fichier ci-dessous/results/execution-id/logs. Pour résoudre ce problème, attachez la stratégie gérée AWSIoTDeviceTesterForFreeRTOSFullAccess à votre utilisateur de test. Pour de plus amples informations, veuillez consulter .

Débogage des erreurs de test réseau

Pour les tests basés sur réseau, IDT lance un serveur echo qui se lie à un port non réservé sur la machine hôte. Si vous rencontrez des erreurs dues à des délais impartis ou à des connexions indisponibles lors des WiFi tests de sockets sécurisés, assurez-vous que votre réseau est configuré pour autoriser le trafic vers les ports configurés compris entre 1024 et 49151.

Le test des sockets sécurisées utilise les ports 33333 et 33334 par défaut. Les WiFi tests utilisent le port 33335 par défaut. Si ces trois ports sont utilisés ou bloqués par un pare-feu ou un réseau, vous pouvez choisir d'utiliser d'autres ports dans userdata.json pour les tests. Pour de plus amples informations, veuillez consulter Configurer les paramètres de création, de flash et de test. Vous pouvez utiliser les commandes suivantes pour vérifier si un port spécifique est en cours d'utilisation :

Échecs de mise à jour OTA dus à la même version de charge utile

Si les scénarios de test OTA échouent parce que la même version se trouve sur l'appareil après l'exécution d'un OTA, cela peut être dû au fait que votre système de compilation (par exemple cmake) n'a pas remarqué les modifications apportées par IDT au code source de FreeRTOS et n'a pas créé de binaire mis à jour. L'opération OTA est alors effectuée avec le même binaire que celui qui est actuellement sur le périphérique, ce qui entraîne l'échec du test. Pour résoudre les défaillances de mise à jour OTA, commencez par vous assurer que vous utilisez la dernière version prise en charge de votre système de build.

Échec du test OTA sur le cas de test PresignedUrlExpired

Pour que ce test aboutisse, le temps de mise à jour OTA doit être supérieur à 60 secondes. Dans le cas contraire, le message d'erreur suivant se trouve dans le journal : « Test takes less than 60 seconds (url expired time) to finish. Please reach out to us. » (Le test dure moins de 60 secondes (délai d'expiration de l'URL). Veuillez nous contacter).

Débogage des erreurs d'interface et de port d'appareil

Cette section contient des informations sur les interfaces utilisées par IDT pour se connecter à vos appareils.

Plateformes prises en charge

IDT prend en charge Windows, macOS et Linux. Ces trois plateformes ont différents schémas de dénomination pour les appareils :

Pour vérifier le port de votre appareil :

Pour vérifier que l'appareil est connecté à un port :

Interfaces du périphérique

Chaque appareil intégré est différent, ce qui signifie qu'ils peuvent avoir un ou plusieurs ports série. Il est courant pour les appareils d'avoir deux connexions lorsqu'ils sont connectés à une machine :

Lecture des données du périphérique

IDT pour FreeRTOS utilise la création de périphériques individuels et des outils flash pour spécifier la configuration des ports. Si vous testez votre appareil et que vous n'obtenez pas de sortie, essayez les paramètres par défaut suivants :

Ces paramètres sont gérés par IDT pour FreeRTOS. Vous n'avez pas à les définir. Cependant, vous pouvez utiliser la même méthode pour lire manuellement la sortie de l'appareil. Sur Linux ou macOS, vous pouvez le faire avec la commande screen. Sous Windows, vous pouvez utiliser un programme tel que TeraTerm.

Screen: screen /dev/cu.usbserial 115200

TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.

Problèmes liés à la chaîne d'outils de développement

Cette section explique les problèmes qui peuvent survenir avec votre chaîne d'outils.

Code Composer Studio sur Ubuntu

Les dernières versions d'Ubuntu (17.10 et 18.04) incluent une version du package glibc qui n'est pas compatible avec Code Composer Studio 7.x. Nous vous recommandons d'installer Code Composer Studio 8.2 ou version ultérieure.

Voici les symptômes d'incompatibilité possibles :

Journalisation

Les journaux IDT pour FreeRTOS sont placés en un seul endroit. À partir du répertoire IDT racine, ces fichiers sont disponibles sous results/execution-id/ :

FRQ_Report.xml et logs/test_group_id__test_case_id.log sont les journaux les plus importants à examiner. FRQ_Report.xml contient des informations sur les cas de test qui ont échoué avec un message d'erreur spécifique. Vous pouvez ensuite utiliser logs/test_group_id__test_case_id.log pour approfondir le problème afin d'obtenir plus de contexte.

Erreurs de la console

Lorsqu'il AWS IoT Device Tester est exécuté, les défaillances sont signalées à la console par de brefs messages. Recherchez dans results/execution-id/logs/test_group_id__test_case_id.log pour en savoir plus sur l'erreur.

Erreurs de journal

Chaque exécution de suite de tests a un ID d'exécution unique qui est utilisé pour créer un dossier nommé results/execution-id. Les journaux des cas de test individuels figurent dans le répertoire results/execution-id/logs. Utilisez la sortie de la console IDT pour FreeRTOS pour trouver l'identifiant d'exécution, l'identifiant du cas de test et l'identifiant du groupe de test du scénario de test qui a échoué. Utilisez ensuite ces informations pour rechercher et ouvrir le fichier journal correspondant à ce scénario de test nommé results/execution-id/logs/test_group_id__test_case_id.log Les informations contenues dans ce fichier incluent la sortie complète de la commande flash et de la compilation, la sortie de l'exécution du test et la sortie de AWS IoT Device Tester console plus détaillée.

Problèmes liés au compartiment S3

Si vous appuyez CTRL+C pendant l'exécution d'IDT, IDT lancera un processus de nettoyage. Une partie de ce nettoyage consiste à supprimer les ressources Amazon S3 créées dans le cadre des tests IDT. Si le nettoyage ne peut pas être terminé, il se peut que vous rencontriez un problème lié à la création d'un trop grand nombre de compartiments Amazon S3. Cela signifie que la prochaine fois que vous exécuterez IDT, les tests commenceront à échouer.

Si vous appuyez CTRL+C pour arrêter IDT, vous devez le laisser terminer le processus de nettoyage pour éviter ce problème. Vous pouvez également supprimer de votre compte les compartiments Amazon S3 créés manuellement.

Résolution des erreurs de délai d'expiration

Si vous constatez des erreurs de délai d'expiration lors de l'exécution d'une suite de tests, augmentez le délai d'expiration en spécifiant un facteur multiplicateur de délai d'expiration. Ce facteur est appliqué à la valeur de délai d'expiration par défaut. Toute valeur configurée pour cet indicateur doit être supérieure ou égale à 1.0. Pour utiliser le multiplicateur de délai d'expiration, employez l'indicateur --timeout-multiplier lors de l'exécution de la suite de tests.

Fonctionnalité cellulaire et AWS frais

Lorsque la Cellular fonctionnalité est configurée Yes dans votre device.JSON fichier, vous FullSecureSockets utiliserez des EC2 instances t.micro pour exécuter des tests, ce qui peut entraîner des frais supplémentaires pour votre AWS compte. Pour plus d'informations, consultez les EC2 tarifs Amazon.

Politique de génération de rapports de qualification

Les rapports de qualification ne sont générés que par les versions AWS IoT Device Tester (IDT) compatibles avec les versions de FreeRTOS publiées au cours des deux dernières années. Si vous avez des questions concernant la politique d'assistance, veuillez contacter AWS Support.